Talk:Plan for new save format

Jump to: navigation, search

[Mystic]: Kind of seems like it would make it easy for any guy with a hex editor to cheat, doesn't it? Open the heroes bin and edit the stats/level...

The Mad Cacti: It would be exactly as easy as it is now. Besides, there is already a tool or two for cheating on OHR games. We don't really care about it.

RE:Sharing Data Between Games[edit]

The Mad Cacti: I'm assuming that this interface is only meant for reading files written by other scripts. We might have talked about writing arbitrary binary files, like a character dump in text format which a player can take away, but it seems to me that that is now a completely different feature from save files, which are hidden away in a saved games folder. I still think that being able to write (and read, I suppose) text files would be very useful, but don't see a need for a binary interface.

Assuming that's the case, continuing:

There'll be no point having a raw interface.

There should be no difference between integers and other data types. Haven't you heard of Plan for dynamic types in HamsterSpeak? The file format would be the same as whatever is used elsewhere, perhaps with a dictionary at the toplevel, instead of an array like the globals file.

That will end us up with a single 'share' file per slot, so there's no point in having a 'share' subfolder.

Slightly aside, what about game-global save data? We could have 34 save slots numbered -1 through 32, where 0-31 are the regular save slots, 32 is quicksave/load (if we keep that), and -1 is a special slot suggested for saving global game data like high score lists. It would contain only globals and shared data, and couldn't be normally saved/loaded. Just seems slightly cleaner than everyone using a random save slot for global data.

NeoTA: As I understand it, the proposed interface is for semi-global data; ie. global data that belongs to a particular save slot. while what you propose allows a simple scheme like 'you can only begin part 2 once you've finished part 1', it doesn't allow schemes like 'continue in part 2 with the abilities and special items you acquired in part 1 (pick a save).

Bob the Hamster: Yes, the data sharing thing was indeed intended for scripted data only. I would be totally happy to skip both the integer interface and the raw interface, and only implement the object interface (yes, I remember about Plan for dynamic types in HamsterSpeak)

Anyway, the whole shared data thing is just a thought, and no priority compared to the new save format.

Which brings me to the proposal. I was at one point thinking of binary files for the various save lumps, but reload files would probably be better, assuming that we are agreed on the frozenness of the reload format.

The Mad Cacti: Neo: I didn't say that we should add a single shared global save slot instead of per-slot shared data.

I'm wondering whether there really is any need to only let games read explicitly shared data from other games? How much harm could allowing read access all save game data do? What is the point - to prevent the creation of cheating utilities with scripts?

Bob the Hamster: The point of not allowing reading of all save data was because games could be broken by changes to the save format... although the new save format could indeed reduce that risk a lot.

The Mad Cacti: Oh! I don't think I follow. You were thinking of preventing people from using the raw binary interface to read other save lumps, such as NPC data? How else would a change to the save format break games?

So perhaps we could ditch the share lump altogether, and share data between games via globals. We could even add a way to look up globals by name. Aside from that, reading of other data, like items or map states would make things tremendously easier for users, if it could be done in a forward compatible and cross-game way (unlikely).

Bob the Hamster: Yeah, I didn't want people to have direct access to, for example, NPC data, because then they would have to manually implement a reader for NPC data in plotscripting which would break if we changed that format.

I think the idea of just allowing access to globals as you described is a great idea. That seems simpler than adding a new separate lump, and when dynamic types are done, it will provide all the same functionality of the "object" interface I proposed.