Jump to content

torino

User
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Neutral

About torino

  • Rank
    Lurker
  • Birthday 03/03/1941
  1. Yes, with 'input recordings', it's just the question who will be responsible to watch and verify them. Twin Galaxies have referees to do this, while at MARP every participant is also a referee too. In the first case scores are unpublished until verified and proven valid, while in the other case scores are immediately published but can be disqualified later on. It does not seem there is more than a few people actually interested to use any of this, so I don't think it's worth the effort, but I suppose if you have nice collection, with good scores, you could upload it in case the situation changes and someone else decides to complete the project. Yes, that can be done with HiToText and simple .BAT script. On the other hand my solution would need to have special function for that type of merging since it's doing it internally, but that's as easy to write as the .BAT script.
  2. Impatience is important part of being optimal, and very appropriate in this particular situation. It is me who suggested you how to complete this project. Take it or leave it. I don't quite understand how you turned this around as if it is me asking something from you. -- You were interested when I initially made the proposal, which is why I realised it with the 'proof of concept' solution, so I find it strange you have nothing to say about it now that it's actually done.
  3. Fyrecrypts & Dna Disturber, You are not really interested in this project, I just wasted my time and I should not really expect any further posts in this thread, not even a simple comment about my magnificent solution, right? - If I have eight hours for cutting wood, I spend six sharpening my axe.
  4. Hi-Score Wizard: hsw-v01.zip ======================= http://www.mediafire.com/file/ywgx3agths06u3z/hsw-v01.zip NAME formats: Normal, Reverse, Padding, Rev+Padd SCORE formats: ASC_6_6, RAS_6_6, ASC_6_3, RAS_6_3, ASC_5_5, RAS_5_5, ASC_5_3, RAS_5_3, HEX_6_3, RHX_6_3, HEX_5_2, RHX_5_2, ASC_4_4, RAS_4_4, ASC_4_2, RAS_4_2 "ASC_" = ASCII "RAS_" = Reversed Asc. "HEX_" = Hexadecimal "REX_" = Reversed Hex. "x_" = 1st number says how many digits are in the format "_x" = 2nd number says how many bytes store that value amidar.hi anteater.hi apb.hi arabian.hi arkanoid.hi asteroid.hi bagman.hi bankp.hi blueprnt.hi boblbobl.hi bombjack.hi boomrang.hi brubber.hi btime.hi bullfgt.hi calipso.hi cclimber.hi circusc.hi commando.hi congo.hi crush.hi csilver.hi digdug.hi dkong.hi dkong3.hi dkongjr.hi docastle.hi dorunrun.hi dowild.hi fnkyfish.hi frogger.hi futspy.hi galaga.hi gberet.hi gng.hi gunsmoke.hi gyruss.hi higemaru.hi hopmappy.hi ikari.hi imsorry.hi ironhors.hi jailbrek.hi jjack.hi junofrst.hi kchamp.hi kicker.hi kungfum.hi ladybug.hi mappy.hi mario.hi matmania.hi mhavoc.hi mikie.hi missile.hi mmonkey.hi mrdo.hi mrviking.hi nibbler.hi pang.hi pengo.hi pepper2.hi pingpong.hi pooyan.hi popeyebl.hi raiden.hi rescue.hi rocnrope.hi scramble.hi tempest.hi theend.hi timeplt.hi travrusa.hi turtles.hi tutankhm.hi upndown.hi vanvan.hi wboy.hi yiear.hi zaxxon.hi EXAMPLE [R]EAD USAGE: hsw r dkong.hi EXAMPLE [C]RACK USAGE: hsw c dknog.hi * delete game definitions from "hswizard.dat" to crack them again Most of the games I tried were cracked successfully, the other ones fall in several different categories. Some games are not yet supported for the sake of simplicity, like the ones that use more than 6 digits counters, then some games use rare formats so there was no point including it auto-cracking algorithm. There are also hi-score files which produce multiple matches, so those results need to be verified manually, and some games use no logical character mapping or number formatting what-so-ever, they have to be both cracked and defined manually, or so it would seem. By the way, the source code and all those hi-score files are included in the zip as well. 1.) EASY - can be included in auto-cracking wizard starwars, airwolf: * scores w/ more 6 digits wboy, ???: * shifted ASCII score format 2.) MEDIUM - need manual verification or mapping congo, mario, zaxxon: * multiple HI-SCORE matches timeplt, gyruss, ambush: * need manual char mapping 3.) HARD - need manual cracking, and maybe not? gng, 1942: * unsorted scores in memory mappy, qbert: * random/unique score formats In summary, I think this auto-cracking method in its first release can already support 70% of the games. Cracking is really fast and easy once hi-score file is ready with proper scores and initials. If people could supply all the ".hi" and ".nv" files with some nice scores I suppose I could crack all the games myself in the next two weeks. -- Opinions, comments, questions?
  5. Yes, just like ideal name entry is "ABZ", as opposed to "AAA", so for the scores ideal entry will also have all of the places populated and different, so to produce "unique pattern", like "984,750", as opposed to "1,000". The same goes for manual cracking, if we want to make it less error prone we have to make scores and names easy to recognize among all the other bytes, so we can be more certain about their starting point and byte length, as well as to properly identify their formats. That's also why there have to be at least two entries given to cracking-tool and supplied in hi-score file, so algorithm can double-check the format and in case there is no match algorithm loops to a different format and continues to compare until it finds both entries in the same format. Once complete match is found program calculates starting point and location difference between the fields of the 1st two entries and with this relative offsets prints out the whole scoreboard, then it checks with user whether everything looks as it should - if not, it's tough luck, but if yes it saves new game definition to the database and from then on this game's hi-score file should be supported for reading, writing and merging.
  6. 30% would be depressing, but 20% is ok, although I expected it to be less than 10%, and I really did not even dream the formats would run so wild, but on the other hand I think most of the games can actually be auto-cracked fairly easy, which I hope to demonstrate by the next week. I think if the average user could decipher every 3rd game with auto-cracking tool it would be "good enough", so the two thirds would be left to us to either fix manually or improve cracking algorithm, whichever seem more optimal solution for the given number of remaining games.
  7. Great, thank you. "10,000 = 00 00 01 00 00" does not look right if you write the whole number down: "0010,0xx" ...unless the counter actually shows 7 digits. -- In any case I obviously need to rename those formats in order to allow for even greater diversity, unfortunately. Luckily, as long as those formats conform to some rules and map linearly/continuously they can be searched for and found by the cracking algorithm, pretty much in the same way we can find it with our eyes - by looking for some "pattern". I will now comment on other "crazy formats" that I think would be hard to search for and require specialized algorithms. I am afraid some of those games would still need to be cracked manually, or perhaps semi-manually, and I hope there is not too many of them, so more troubling I think is how to define such "random" formats in the database and still keep it all simple for the other games. For example my ".dat" file has this entry for Donkey Kong: "5 0 | 7 34 6 173 | 15 34 3 80", and thats all it needs to know in order to read and write to "dkong.hi". The program found those numbers by itself since it knew what pattern to look for, and the same algorithm should work for any other game that uses "ASCII_6" format and if score/name entries are evenly spaced in the memory, but if the format is more "random" than "ordered" it's not only hard to look for particular entries, but also once cracked it would be hard to "describe" in general terms and without addressing every single entry individually. For now I use *relative* and very general format description, for it does not matter if the order is reversed, and offsets too can be both positive and negative, so I can read the data from end to start and define all the reversed byte formats as "mirrors cases" with just one flag. That kind of stuff makes it all very tedious to implement. -- In any case, I would like to base the decision on what byte formats to include in auto-cracking tool in relation to how common particular format is. If there is just a few games using something like that then they could be cracked manually and the program should still be able to read & write hi-scores once it knows how to shift those numbers and obtain correct values. The program does not really need be able to crack every format, just know how to use them. Additional effort would then be required to include those formats into auto-cracking algorithm. Ay, why do they have to do that. It all really depends on how many games do such things, but in any case cracking tool should be useful, even if only to crack just "names" and show them in readable format so to make "scores" easier to find and crack manually, or vice versa. Alternatively, there is some logic and pattern in that format as well, and if more than, say 10% of games used it I suppose it would be justifiable to included it in the crack-format database, still though, this "crack-wizard" is only meant to assist, but even if it only ends up working 50% of the time, it would still be better than doing it all manually, or so it would seem. That was fantastic, it saves me a lot of time and I can now think a little bit more in advance than before. There are two problems, two "mappings". 23 --> 58 --> "black & red heart symbol" First number is the actual number in ".hi" file, second number is mapping to our systems character set, and for A-Z this mapping should be simple linear shift, but for any other symbols this same offset number would most likely not map to appropriate characters any more, however all those symbols would still get to be mapped - somewhere, it's just that non-letters like exclamation mark might translate to question mark, or smiley face, or whatever gibberish symbol from the ASCII set, and it should really be up to front-end or web-server to provide this second mapping and adequate representation for those symbols, which can be done on top of first "shift" mapping. As long as the feature itself exist so additional characters CAN be mapped I don't think the main development should be too much concerned about actually providing those extra definitions and include all the mapping for all the games, we only need to provide what is necessary and make it simple enough so any enthusiastic user could extend, or even completely change, this default mapping themselves. I agree at least some other characters would be welcome, but if we have to choose between supporting 90% of the games with only A-Z, or supporting 20% of the games fully, then I am ready to welcome the sacrifice of all the other characters, except the alphabet itself, and leave the extended mapping for the future, while certainly keeping it in mind to allow for easy expansion. Let's first finish the project and improve it later, rather than looking for the completeness and perfection all along the way and never actually get to finish it at all.
  8. Searching for the string "shark" with "Total Commander" apperantly failed, for some reason. -- I see it now, cheers! It is easier for me to start from scratch and re-write the whole thing in order to see what is really going on, so I'll be using different formating, but the numbers that come out of "cracking' algorithm" will surely be meaningful for HiToText as well. I would not want to have my little project separate from yours, I see it more as some simplification or mini version of HiToText, a port to C language if you will, but hopefully those simplifications and modifications can make some room for automation and facilitate speedy game inclusion, in which case we will probably want to "merge" the two projects, somehow. Anyway, I am sure going to try, and so far my little demo program can decipher (read/write) "dkong.hi". Let us see how far can I get with this in the next couple of days, and with your help we will be able to make proper conclusions and adequate decisions about it by the next week. -- So, my second semi-auto crack attempt is now "crush.hi", and here I encountered two new score formats, I call them "HEX_6" and "HEX_5", while the format in "dkong.hi" I call "ASCII_6". a.) ASCII_6 --> 987,500 = 09 08 07 05 00 00 b.) ASCII_5 --> 987,50x = 09 08 07 05 00 c.) ASCII_4 --> 987,5xx = 09 08 07 05 d.) HEX_6 --> 987,500 = 98 75 00 e.) HEX_5 --> 987,50x = 09 87 50 f.) HEX_4 --> 987,5xx = 98 75 Crush Roller keeps "table-scores" in HEX_5 format, but the Hi-Score itself (top of the screen) is kept in HEX_6 format?! If they rounded their scores to hundreds they could ignore two last zeros, instead of only one, and save one byte of storage by using HEX_4 format, but having two different formats for no reason is just making my auto-deciphering algorithm bigger and uglier than I'd like it to be, ughh. I'm still optimist though. Can you tell me (with example) what other formats have you discovered for scores and names? Do you see any problem if there was a limit to use only A-Z characters for NAME entries? -- I mean that's how people are supposed to write their names, all the other characters are unnecessary really, and there is not even equivalent graphics available on any platform to represent many of those unique and random symbols, only within emulated game-platform itself, so I think that's really important decision to make as it can make everything much more simple. I find the greatest problem is lack of people interested to participate. -- If there are at least 3-5 people ready to play in a little competition we can test "Live Arcade Scoreboard" in the same time while we are experimenting with automation of hi-score cracking.
  9. Ok, thank you. 98,750 = "00 09 08 07 05 00" you would call "ASCII", right? Please describe the difference between: ASCII - BCD - HEX ? I am making a little 'proof of concept' program that should be able to: ®ead, (w)rite, ©rack and (m)erge hi-score files. Basically it is a complete re-write of HiToText, but using pretty much the same concept, only instead of .xml it will use some arbitrary formating to keep all the necessary info, and will be written in C. Cracking option should be able to inspect and decipher some yet unsupported format and automatically update the database with this new game, which will require some user input as well as that hi-core file contains "proper entries", i.e. at least 1st and 2nd position must be properly registered where corresponding two names have first three characters as unique A-Z symbols. Character mapping is the greatest problem here, the only one which can not be automated fully. However, the good thing is, that's not really important if we do score merging internally, where we insert, sort and replace whatever bytes without needing to know what characters or symbols those 'name entries' actually represent. -- This is really a separate problem, it is specific only to the situation when we want to display those scoreboards *outside* of the game itself, like in some front-end or in some .html file somewhere on the interenet, but otherwise we can limit ourselves to only A-Z and make everything much, much more simple. So, without that problem and as far as sharing and merging goes, all we need to find out where the 1st score starts and offset for the next one, similarly where the 1st name starts and the offset for the next one, the same for "stage" or whatever other fields as well. Cracking would require user to manually enter scores and names for the first two top records as in the supplied hi-score file, plus the number of total positions as well as the maximum number of digits/symbols. Hopefully then adding a new game to the database could be done in a matter of minutes and by anyone without needing to know anything about it except how to provide adequate hi-score file and run auto-deciphering program.
  10. Yes, I got that, thank you. I thought it was not the most recent source code becasue .EXE supports reading and writing to "skyshark.hi", while there is no mention of that game anywhere in the source code or .xml file. Q1.) So, are you still interested in this project? If yes, then we should make a tool to automatize .hi score decryption process and speed up inclusion of new games. Basically, I want to help you finish the project and I think it can all be done in less than two months, so that HiToText supports all the games supported by the most recent HiScore.DAT itself. -- How does that sound? Q2.) My primary interest for your tool is to share hi-scores online. For example Twin Galaxies or MARP could keep the database of hi-score files to reflect current submitted records so people could actually see those scoreboards inside the game itself. -- Was this not your original intention and purpose for HiToText? Q3.) I have a simple .BAT script that uses free shared "web-folder" account to act as server for smaller circle competitions, so for example a group of friends can beat each others records with "Live Internet Scoreboard", to make it all more interesting. -- What do you think about it? Q4.) Reading "dkong.hi" works, but not writing, can this be fixed just by editing .xml file?
  11. Where can we find your xml updates, can you post it here, Dna Disturber? Reading "dkong.hi" works, but now writing, can that be fixed by editing xml? Is there any interest to continue work on this project and include all the rest of the games? -- How can we contact Fyrecrypts to aks him if he has completely given up, and ask him to share the latest updates and source code?
×
×
  • Create New...