Main > Software Forum
HiToText (Version 2010.11.4).
MustardTent:
I did something like this a few years back with another member here. If you're interested, here's a spreadsheet with some of our findings.
Good luck, there's lots of games to decode.
Fyrecrypts:
Thank you MustardTent that does help, I'll try and add these games as I find time.
On that same note, I'm not sure if I'm going to have the time to completely revamp to use a .hid file, but I still think it's a good idea to probably do. I'm in the middle of changing up the UI a little bit (nothing major, just adding some things I think should be added), and I've got some other games I'd like to add pretty soon as I am using this with many of my friends and they have some requests I want to get in for them. After that's done, I'll do what I can about converting everything to a .hid format, unless someone else gets there first I guess.
headkaze:
Creating our own scripting language was sort of what we were talking about when we realised that a dat file would not be enough to describe how to encode and decode a hi file.
Playing with some of the code to decypher in the beginning I think it would be hard to write our own scripting language to do it. In fact I'm sure there will be games in the future that will be even harder to decypher. Having the full C# language at our disposal ensures we don't need to keep updating the scripting language which would require the binary to be updated and distributed every time which sort of cancels out the benefits it would bring.
It's possible to have the decyphering in C# scripts and compile them at runtime, but I don't actually see any great time saving benefits, as it only takes a moment to compile the whole program again, and upload to the forum.
Another option would be to move the decyphering into lua scripts, but again I don't see a huge benefit going that way, and let's face it two of us here are C# coders (me and Fyrecrypts), and one is VB.NET (tom) and the other is C++ (NOP).
I have some experience in implementing C# scripting so let me know if your serious about going that way. But to be honest I don't see any great benefits.
If anything I would prefer to go with dll's for each game, that way we could have both managed and unmanaged dll's that share a common API. I have experience creating a plugin system that supports both managed and unmanaged dll's so I'm happy to share code on how to do that. That being said compiling each one as a dll is more time consuming than the current method because each dll would have to be it's own project in VS - so I don't see any time saving benefit there either except that we could have more people writing the code to decypher, but lets face it, the coding is not the hard part, it's decyphering all the games. It's interesting to mention though, the more I played around with the code in the beginning I started thinking it would actually be easier to use C++ with structs and pointers than C#! (Hey no language is perfect I guess)
As long as the project stays open source so it doesn't dissappear with us stuck with the binaries; then I'm happy to stay with the C# classes. But I'm still open to suggestions though and what I wrote is just IMHO.
NOP:
--- Quote ---I am using this with many of my friends and they have some requests I want to get in for them.
--- End quote ---
post those requests and I'll chip in too. I didn't see anything on the 1st post about what games we're hoping to support.
Fyrecrypts:
Sure, I'll update it right now actually. I've also put up a new HiScanner, and new HiToText with the most recent games deciphered.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version