The above video goes away if you are a member and logged in, so log in now!
it would be nice to see a one size fits all save editor... and it could happen... with template files to supplament the data needed to process the data in a save type... say a save file editor is made... with simple text, and hex editing with search functions, compare 2 saves, and a patching system...
then the template system is applied for seperate games... someone writes a template that will allow the editor to read and understand a GT3 save file... allowing for patches and self editing of the files.... another person might make a template that reads NASCAR thunder 2004... and so on...
I am amazed that you guys are talking about this. I started working on a program like this already, with the EXACT same features you guys are discusing... I have titled it SaveCracker and it is a sourceforge project!(http://sourceforge.net/projects/savecracker) Check out a screenshot at http://sourceforge.net/project/scree...roup_id=144157 (the screenshot is a few versions behind the current code)
The final plan is to have "plugin" checksum correction, and XML data sheets to use as templates!
The program is being written in Java (J2SE 5) and currently has the following features:
Unlimited number of files (limited only by your PCs memory)
Greater than searches
Not equal to
Differs by 'X' value
Differs by at least 'X' value
Exact value searches
Support for Big Endian/Little Endian
Support for signed/unsigned searches
Support for Byte/Word/DWord searches
I haven't released the source yet, because I was hoping to get a couple checksum routines down... Our target thus far has been Nintendo DS, but the project is aimed at all platforms! If any of you are Java programmers, I would appreciate all the help I can get! I will have the source posted by Sunday.
We have been actively discussing this topic at http://www.gscentral.com/vb/showthread.php?t=13926
email me at email@example.com or find me on AIM as Caligrapher, or MSN Messenger (by my hotmail name) and I will get you added to the developers list!
I posted another screenshot to the sourceforge site. I'm going to get this code released very soon.
As we speak, I am uploading the source and binary files to http://sourceforge.net/projects/savecracker/
Remember, this is an alpha release, much of the code is "hacked" together, and there are some known issues. To run the program simply download the .jar file. Windows users can simply double click the file to launch. Optionally you can start the program from the command line by typing 'java -jar SaveCracker-v0.5.93.jar'. Make sure That you have the latest version of the Java runtime environment (NOTE: This program REQUIRES J2SE 5 (1.5) to run. If you are running jre 1.4.2, you MUST upgrade!)
Last edited by Accolades; 07-28-2005 at 02:53 AM.
There was a little delay today because my fiance decided she wanted to go to the aquarium. So of course, I got stuck looking at fish for four hours today. Not to mention the place is almost two hours away from my apartment, but I digress.
I finally got SaveCracker v0.6 posted to sourceforge. I incorporated the requests from shelvey and labmaster, as well as various other tasks, such as commenting the source code and moving all of the class initializations, so that not everything loads at the very beginning (causing delays)
I was planning to implement 64bit data searches today, when I realized I had a little problem with that. See, I've been using Integers (32 bit in Java) to store data. Smaller data (Byte/Word) is easily cast to an Integer, the high order bits are simply ignored, but a 64 bit compare is going to require a long primitive. It can be done, but it would take some effort. Before I bother to include 64 bit searches, I wanted to ask you guys how necessary do you think it would be? Do we really expect to be searching for values that are up to 18,446,744,073,709,551,615 ?
Floats are much more important to include that Int64, you obviously need to incorporate the 32bit and 64bit float var types for full compatability.
In my own software I always stick to a specific var type when doing compares (floats are a bitch for 'equal to' values) and let the user select which one they want to search for, usually defaulting the choice to Int to start with.
Doesn't Java have a 'native' (used very loosely there) Int64 var type? That would make things a lot easier
Last edited by gothi; 07-29-2005 at 03:32 PM.
Reason: confusion over float sizes
Java has the long, float, and double data types, all of which I believe are 64 bits... I'd have to go look them up. Full compatibility is what I'm after, so it looks like I'll be doing a little more work on the comparison routine
I'm trying to get the word out about this as much as possible. I could really use a couple of test PSP save files, (with minor value changes, such as money increasing from $20 to $40 between two saves) If anyone would be willing to supply me with this kind of help, it would be greatly appreciated.
I'm pretty sure that PSP saves are protected by AES encryption. I've not done much loooking into it but what brief searches I did left me very much with that idea