9 replies to this topic

[klop422]

I've just thought - it'd be nice if it were possible to just copy one save file into another slot. Obviously you'd get to rename the new slot. Just seems like a comparatively simple thing that is kind of expected in games nowadays that ZC doesn't have (and so games released in it wouldn't either).

[Emily]

Do you.... mean.... this?

[Titanium Justice]

Did he mean that, or is he reffering to the copying of the zc.sav file? Because it would be useful if you could have a way to manage multiple .sav files.

[Emily]

a way to manage multiple .sav files.

Oh, you mean like what's been in ZCL for at least half a year?

[Mani Kanina]

Oh, you mean like what's been in ZCL for at least half a year?

Assuming they are sitting on the latest versions of ZC, which uh, is not really a given.

[klop422]

...April fools?

 

Nah, I'm just impressively stupid.

[Lüt]

As long as the topic is up though, I do think it could be improved by 1) allowing a slot choice instead of automatically duplicating to the next open slot 2) allowing to overwrite an existing slot (confirmation dialogue ideal) 3) allowing a new name to be entered.

[Mani Kanina]

As long as the topic is up though, I do think it could be improved by 1) allowing a slot choice instead of automatically duplicating to the next open slot 2) allowing to overwrite an existing slot (confirmation dialogue ideal) 3) allowing a new name to be entered.

While we are at it, is the number of save slots still like, limited to like, 4 pages x 3 saves? Cause I see no reason for such a low limit.

[Emily]

Assuming they are sitting on the latest versions of ZC, which uh, is not really a given.

It kinda should be if they are making a feature request. Requesting features while using outdated versions doesn't make much sense.

As long as the topic is up though, I do think it could be improved by 1) allowing a slot choice instead of automatically duplicating to the next open slot 2) allowing to overwrite an existing slot (confirmation dialogue ideal) 3) allowing a new name to be entered.

This... could maybe be done? Would be a bit difficult, though; the code for this stuff is janky AF.

While we are at it, is the number of save slots still like, limited to like, 4 pages x 3 saves? Cause I see no reason for such a low limit.

5 pages x 3 saves. I know that the 3 pages per save is a hard limit, due to palette restrictions of the quest icons; but I have no clue why a 5-page limit was chosen. I'll ask Zoria.

[Timelord]

You can now have as many .sav files as you want.

 

These are set in ZCL, or in zc.cfg under:

 

[SAVEFILE]
save_filename = zc.sav

 

 

 

In ZCL, it is a button:

 

 

Note that each running instance of ZC is tied to the .sav file loaded when it was launched. If you launch multiple ZC instances, each should interface only with the save file that was used to launch it. Thus, you can launch on einstance of ZC Player with lazpoc.sav and a second instance with eiyuu.sav, an each instance should only be able to r.w to and from the appropriate file.

 

I could probably provide a small launch script in the future that allows setting the save file into a Windows icon, but that isn't portable. I specifically detached this from modules so that the end-user is not forced to use a specific file for modules, but can instead use whatever save file they wish, but you either must run a second instance after changing the save file value, or exit and relaunch ZC, to shift to the different file.

 

This works in much the same way as LTM's launcher, except that it is now built into the software. If anything, I may ass a CLI param to set the savefile, so that it is easier to add an eternal interface to launch C with a specific save file along with other params.

 

It is not logistically possible to allow having blank slots and copying to slots in an non-continuous manner. All save data is contiguous, including things such as script variables (saved as vector data), which scale based on the number of global vars and some other script elements in a quest. Thus, each save slot is of a unique size, which is what prohibits having blank save slots, in-between populated save slots.

 

If that were allowed, then if you write to an unused save slot:

 

e.g. Slots 0 and 2 have data, now you want to use slot 1.

 

The data would partially overwrite slot 2, corrupting the entire save file. Because there isn't a fixed length to the data in each slot, and it needs to report to ZC how much data it contains, this is beyond infeasible. if I fix the length, then each slot will bloat to use more space than needed, and it would restrict future expansion.  Save file data is a concatenated stream of linear binary streams. When save slots are read, ZC finds where the last slot ends, and immediately appends data after it.

 

It is not random access.

 

This is also why script save data requires a new save slot if you add/delete a global var or array, as those are allocated as pointers with values in the quest save slot!

 

Having more slots per file is also feasible, but it would have side-effects:

 

1. .Save files would be far larger.

2. Loading ZC would take longer.

3. Refreshing the Select Quest menu would take longer.

 

If I were to authorise an increase, what number is something that people would feel satisfactory? The way I see things, if I were to increase the number to 27, then people would want 32. If increase it to 32, people will want 60, and I am unwilling to add that kind of bloat now that you can have a set of save files for a series of quests, and swap between them with include tools. 

 

Doing that would add immense amounts of bloat to ZC, using RAM, and CPU cycles every time that ZC needs to red them. The initial launch time would double if I double the number of slots in a save file.

 

Changing the name of slots is feasible, but this would require adding a file select mode--let's call it Z3 mode, that has an option to do this. ZC still emulates NES Z1, and changing the base file select to look like something else would upset more people than I care to enumerate; so a third mode (don't forget NES name entry!) would be need.

 

It may be possible to do this with a menu option, but I think that a new, additional, name entry UI pair is needed, that emulates full Z3 name entry (with reticule), and typed name entry with the same display, an options. I am willing to explore this option in the future, along with minimal size cap increases if people can supply us with a reasonable number and logistically explain the benefit.

 

I do worry about how this will interact with modules that load by quest number, rather than filename, but this issue persists across modules in general, and is not as important as it may otherwise have been, because of that.

 

Having save slots filled with blank slots between them is out of the question, due to the non-fixed size of the data.