-
Notifications
You must be signed in to change notification settings - Fork 1
How does it work?
- The Save Editor Copies the Raw Save File to Memory un-altered
- The Editor then launches several complex classes which cascade down and randomly read the Save file for the parts their interested in. Only 1 class ever reads from 1 part of the In-Memory Raw Save file for simplicity. This creates an expanded and workable copy in-memory.
- The UI and UX pull from the 2nd expanded copy in Javascript format and work with that directly/
At all times 2 copies are in memory, the raw form and the expanded Javascript Format. This is an important design decision and not a mistake of lazy programming. Since the 2 are both kept in memory both are editable separately in a non-error-prone way. One of the biggest advantages of this is the Wipe Unused Space
feature which Zero's out all bytes of the raw file so that upon save only relevant bits are written back thus cleaning up the Save file and erasing any malicious tampering.
- The editor asks the expanded Save File to intelligently write back only exactly what needs to be written back to the raw file. The complex cascade of classes write back to the same areas they read from except only as needed.
- A Program recalculates needed checksums, checksums that are marked to be ignored are ignored and not calculated.
- The edited raw file is then dumped back to disk with proper checksums.
A big rule throughout all of this is the editor will only read exactly the bits and bytes needed to be read and write only the bits and bytes needed to be written. Everything else is left as-is completely untouched.
- If a Pokemon is deleted the editor will mark 2 bytes indicating it's been deleted but not actually remove any of the bytes.
- If there's no Wild Pokemon in the area then all the wild Pokemon data will be skipped and not read.
- If this is a new game that's never changed boxes before then the boxes will not be read nor will the checksums be calculated for them. This is because the game itself doesn't care about the boxes either until the first box switch.
The editor tries it's best to only touch exactly what needs to be touched simply because it has no business to modify anything else. Certain emulators will make use of the save file in their own custom way and certain edits or tools will leverage the save file in a special way.
It's not the editors duty to muck around with anything but what it's asked to edit. Any other tools that leverage the save file in a special way or make use of certain regions should still work just as well after using the editor.