Main > Software Forum
HiToText (Version 2010.11.4).
dna disturber:
--- Quote from: Cananas on June 29, 2009, 04:31:03 pm ---
It does not work because it seems that this top6 is stored in the nvram, at offset 0x3a4 (932). I suppose there is a checksum, because if you try to change something, the games reset the scores.
Something like robotron and defender.
--- End quote ---
Yes that's right the (daily) top6 scores begin at 932 , right behind the top41. But these scores get reset to default names every time you leave the game and start it up again (that's the reason I mentioned that these scores must come from the hi file and not from the nvram, otherwise they are always the same default names used by the program)
This is why you need to have a hi entry in order to keep those scores.
On the other hand , when you use a hi entry the only thing you gonna accomplish is that the daily top 6 will become the same as the first 6 in the top 40.
My 2cents: Keep the daily top 6 as it was designed for (no hi entry) so that lesser players can have a score put on the board as well (even if it is just for one sitting).
Because the hiscores from the top 40 are saved you're not going to miss out on anything.
:cheers:
dna disturber:
M :o rtal K :o mbat
--- Quote ---(mk , mkr4)
uses nvram only
Things to extract:
***top 15***
Initials
Wins in a row
Score
The Bytes:
6144,6146,6148 initials score 1
6150 score 1 winnings (in hex for instance 12H = 18 Wins)
6160,6158,6156,6154 score 1 (in hex , convert to decimals to get the score)
6162,6164,6166 initials score 2
6168 score 2 winnings (in hex for instance 0AH = 10 Wins)
6178,6176,6174,6172 score 2 (in hex , convert to decimals to get the score)
...
...
6396,6398,6400 initials score 15
6402 score 15 winnings (in hex for instance 04H = 4 Wins)
6412,6410,6408,6406 score 15 (in hex , convert to decimals to get the score)
The characters:
00h = A
01h = B
...
...
19h = Z
Other Clones *** the bytes begin 18432 further on then with the T-Unit models (mk , mkr4)
Perhaps you can use the parent with an if statement (if game=mkla1 address = adress +
18432 or something.....)
(mkla1 , mkla2 , mkla3 , mkla4 , mkprot8 , mkprot9, mkyawdim)
uses nvram only
The Bytes:
24576,24578,24580 initials score 1
24582 score 1 winnings (in hex for instance 12H = 18 Wins)
24592,24590,24588,24586 score 1 (in hex , convert to decimals to get the score)
24594,24596,24598 initials score 2
24600 score 2 winnings (in hex for instance 0AH = 10 Wins)
24610,24608,24606,24604 score 2 (in hex , convert to decimals to get the score)
...
...
24828,24830,24832 initials score 15
24834 score 15 winnings (in hex for instance 04H = 4 Wins)
24844,24842,24840,24838 score 15 (in hex , convert to decimals to get the score)
The characters:
00h = A
01h = B
...
...
19h = Z
I would suggest that you always use "wins" for the wins in a row because with just 1 win
you don't make it to the score-board (so no extra programming needed if value = 1 etc and
no need for win(s) ).
--- End quote ---
Dna Disturber :cheers:
dna disturber:
Mortal kombat 2
Mortal kombat 3
Ultimate Mortal Kombat 3
--- Quote ---(mk2 , mk2chal , mk2r14 , mk2r21 , mk2r32 , mk2r42 , mk2r91)
(mk3 , mk3r10 , mk3r20 , mk3p40)
(umk3 , umk3r10 , umk3r11)
uses nvram only
Things to extract:
***TOP 15***
Initials
Wins in a row
*Score (although not displayed in the game)
The Bytes:
6144,6146,6148 initials score 1
6150 score 1 winnings (in hex for instance 12H = 18 Wins)
6162,6164,6166 initials score 2
6168 score 2 winnings (in hex for instance 0AH = 10 Wins)
...
...
6396,6398,6400 initials score 15
6402 score 15 winnings (in hex for instance 04H = 4 Wins)
The Characters:
00h = A
01h = B
...
...
19h = Z
Characters only used in MK3 en UMK3 (on initial scoreboard, can't enter these characters within the initials entry):
F0h = 1
F1h = 2
F2h = 3
F3h = 4
Note:
Although in Mortal Kombat 2 and 3 ( *not in ultimate mortal kombat 3) the scores are taken out, the system is still intact.
In the nvram, scores can be found together with the initials and "wins in a row".
Upon testing, these scores are indeed changing and are the actual points you would have scored !
Here's the dilemma :
Should we put these scores in HiToText?
It's a nice thing to have but people who use it may be a bit confused when they suddenly see a score where there isn't any in the game.
My vote tends to go to a NO
*******************************
But to complete the info on this game I will put the scores down (mk2 , mk3):
6160,6158,6156,6154 score 1 (in hex , convert to decimals to get the score)
6178,6176,6174,6172 score 2 (in hex , convert to decimals to get the score)
...
...
6412,6410,6408,6406 score 15 (in hex , convert to decimals to get the score)
*If the score doesn't need four bytes , in this case (score 15) byte 6412 then the value of that byte will be set to FF
The maximum score with 3 bytes = 16.777.215
*******************************
By the way , the adresses of the bytes are the same as in (mk , mkr4).
The scores however are somewhat different , in mortal kombat the 4th byte of the score is not set to FF when it isn't needed. In mortal kombat the value would then just be 00.
--- End quote ---
Dna Disturber :cheers:
wwwombat:
--- Quote from: Fyrecrypts on June 29, 2009, 10:46:01 am ---Track and Field has been updated to use the new nvram file format which was changed after 130u1.
--- End quote ---
Okay... thought I'd revisit this again after the latest update... certainly a hitotext -ra trackfld.nv on the 132 version seems to read the records. So (to be sure) I deleted the trackfld.nv, reset it in mame to the default and exited (checked the hitotext read again to see it looked like the default scores in mame...it did) and then set about re-entering my paper-stored high scores.
Interesting to note that there seems to be some internal validation in hitotext? i.e. my son's top 3 Long Jump scores are 9.09m, 8.77m and 8.37m. Entering the first one (hitotext -wa trackfld.nv "LONG JUMP WORLD RECORD" 1 9.09m NTW) seems to store okay. Entering the other 2 don't seem to take effect as they aren't better than the default scores - the third distance in this case is 8.77m (although I thought in the game if you tied a world record then you took precedence?). That's a slight pity if such validation does take place as I was hoping to alter all 3 JAVELIN scores (only the 3rd place of which we've managed to claim so far) initially to something we could beat more readily.
Where we hold all 3 top scores (hitotext -wa trackfld.nv "HIGH JUMP WORLD RECORD" 2.42m WOM & ditto for 2.41m/WOM 2.40m/WOM and hitotext -wa trackfld.nv "HAMMER TOSS WORLD RECORD" 93.36m WOM & ditto for 92.76m/NTW 90.50m/NTW) then they seemed to store and display okay under hitotext.
Wondering about this possible validation I decided to mess around and didn't seem to matter what I put in the rank field i.e. if I put in originally hitotext -wa trackfld.nv "LONG JUMP WORLD RECORD" 3 9.09m NTW then it would still correctly be placed in first place. This is intentional Firecrypts?
With this in mind I then proceeded to reverse-write the score hi score table i.e. hitotext -w trackfld.nv 1 67680 NTW and then hitotext -w trackfld.nv 1 75910 WOM and then hitotext -w trackfld.nv 1 99640 NTW.
However it appears that each time I write out one of these records what appears in that section of the tale instead of my score is RANK|900000|NLA so that after I done these three entries and did a hitotext -r trackfld.nv again I had
1|900000|NLA
2|900000|NLA
3|900000|NLA
4|10000|...
5|10000|...
etc.
103|10000|...
104|10000|...
105|0|...
106|0|...
etc.
160|0|...
Some..my scores don't exist at all and I'm filling the tables with scores I couldn't possibly beat in my dreams.
Could someone else validate this for me and confirm as something for Firecrypts to look at? (after backing up their trackfld.nv first of course for later restoration)
Fyrecrypts:
--- Quote from: wwwombat on July 01, 2009, 06:20:34 am ---
--- Quote from: Fyrecrypts on June 29, 2009, 10:46:01 am ---Track and Field has been updated to use the new nvram file format which was changed after 130u1.
--- End quote ---
Okay... thought I'd revisit this again after the latest update... certainly a hitotext -ra trackfld.nv on the 132 version seems to read the records. So (to be sure) I deleted the trackfld.nv, reset it in mame to the default and exited (checked the hitotext read again to see it looked like the default scores in mame...it did) and then set about re-entering my paper-stored high scores.
Interesting to note that there seems to be some internal validation in hitotext? i.e. my son's top 3 Long Jump scores are 9.09m, 8.77m and 8.37m. Entering the first one (hitotext -wa trackfld.nv "LONG JUMP WORLD RECORD" 1 9.09m NTW) seems to store okay. Entering the other 2 don't seem to take effect as they aren't better than the default scores - the third distance in this case is 8.77m (although I thought in the game if you tied a world record then you took precedence?). That's a slight pity if such validation does take place as I was hoping to alter all 3 JAVELIN scores (only the 3rd place of which we've managed to claim so far) initially to something we could beat more readily.
Where we hold all 3 top scores (hitotext -wa trackfld.nv "HIGH JUMP WORLD RECORD" 2.42m WOM & ditto for 2.41m/WOM 2.40m/WOM and hitotext -wa trackfld.nv "HAMMER TOSS WORLD RECORD" 93.36m WOM & ditto for 92.76m/NTW 90.50m/NTW) then they seemed to store and display okay under hitotext.
Wondering about this possible validation I decided to mess around and didn't seem to matter what I put in the rank field i.e. if I put in originally hitotext -wa trackfld.nv "LONG JUMP WORLD RECORD" 3 9.09m NTW then it would still correctly be placed in first place. This is intentional Firecrypts?
With this in mind I then proceeded to reverse-write the score hi score table i.e. hitotext -w trackfld.nv 1 67680 NTW and then hitotext -w trackfld.nv 1 75910 WOM and then hitotext -w trackfld.nv 1 99640 NTW.
However it appears that each time I write out one of these records what appears in that section of the tale instead of my score is RANK|900000|NLA so that after I done these three entries and did a hitotext -r trackfld.nv again I had
1|900000|NLA
2|900000|NLA
3|900000|NLA
4|10000|...
5|10000|...
etc.
103|10000|...
104|10000|...
105|0|...
106|0|...
etc.
160|0|...
Some..my scores don't exist at all and I'm filling the tables with scores I couldn't possibly beat in my dreams.
Could someone else validate this for me and confirm as something for Firecrypts to look at? (after backing up their trackfld.nv first of course for later restoration)
--- End quote ---
There is a validation, yes. It was built that way because the first application I created was HiScanner which saved scores, so per-game to know whether a score was better or not entering a score forced the validation first. It's currently not easy to replace scores with lower scores unless you delete the entire nvram/hi file and place in the scores you want to be placed. However, it appears that my debugging code got into this version of HiToText and so all those writes you are seeing are getting my debugging info instead of what you actually put in there. I'll put out a hot fix in a few hours.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version