Wengier
commented
4 years ago I think we can give users more options by implementing both (both save slot and save files). Save files do have its advantages (no limit to the number of save slots), but it is more intended to non-beginners. For beginners, they simply want the save and load state feature to be handled automatically by the software, without having to select a folder and save files. Just click save, very easy. Virtually all software that provides the save and load feature will support save slots, and only some of them will also support save files (along with save slots). DOSBox-X can implement both to give users more options, without forcing users to use the save file approach. Also, I think remarks can be implemented for save states so that users will know the comment they optionally left when they saved a state.
ghost
aybe
In the most recent version of dosbox-x, I have seen that you have added a "Capture" menu and in this menu the user can perform the following actions or commands:
There are more items above and in addition to these three items that I mentioned above in the "Capture" menu, but my feature request is unrelated to them at all, so I won't mention any of them here at all.
As I understand there is a static variable that is an index that always refers to or points at some save slot, so called "the current save slot", and both "Save state" and "Load state" actions or commands operate on that save slot.
"Select save slot" simply allows every user to change and modify this static variable or it's value to make both "Save state" and "Load state" actions or commands to operate on other different save slot. Every user may find this useful if he or she wants to create a new save state and he or she does not want to overwrite the current save state.
I also noticed that there are 10 pages and 10 save slots per page. In other words each page has exactly 10 save slots, so in total there are 10*10=10x10=100 save slots.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Yes, my feature request is indeed related to a problem.
What happens or what do I do if or when I want to play a lot of and many dos video games, even much more than 100, and for each dos video game I want to use a lot of and many save slots.
Unfortunately I both think and believe that 100 save slots is both not enough and insufficient for my needs in my opinion for 100 different dos video games and more.
Also I find this difficult to remember which pages are used for which dos video games that I play, which save slots are used for which moments in the dos video game that I play, because all the save slots and pages are numbered and the user is not able to give for any of them a meaningful name as a string rather than as an integer.
Describe the solution you'd like A clear and concise description of what you want to happen.
Below "Select save slot", add new action or command "Select save file" and then below the "Select save file" action or command, add new checkbox "Use save file instead of save slot".
"Select save file" simply allows the user to select any file from his or her computer.
If the checkbox "Use save file instead of save slot" is unchecked then both "Save state" and "Load state" actions or commands operate on the current save slot exactly as how you implemented this already (in this scenario the current save file is completely ignored).
But if the checkbox "Use save file instead of save slot" is checked then both "Save state" and "Load state" actions or commands operate on the current save file and not on the current save slot (in this scenario the current save slot is completely ignored).
You simply have to add another static variable that is handle to the open save file and another static std::string variable that is both the path and name of the open save file.
Whenever the user changes or modifies the current save file via the "Select save file" action or command then the application so called "dosbox-x" attempts to open the selected file and if the application succeeds to open this file then the application (dosbox-x) closes the old file and the two new static variables mentioned above are updated both accordingly and respectively.
When the user closes dosbox-x, save these two static variables to the config file, and when the user launches or starts dosbox-x, load these two static variables from the config file.
The functions that save state from the memory to a file and load state from a file to the memory are already written and implemented.
You simply have to reuse them i.e. use them again. That is all.
This is both so easy and simple.
The motivation for doing all this:
This way every user is able to create much more than 100 save states, in fact as many as his or her physical hard drive can handle, and also give for each file a meaningful name unlike with slots.
This feature also allows every user to choose where to save each file in which folder and give every folder a meaningful name too, also unlike with pages, so users can organize the save states and associate, sort and arrange them to categories, sets and groups exactly how they want to, so the usage of both save and load state becomes both very easy, convenient, comfortable and fast! This feature will also allow the users to save their states to a folder and then make from this folder a zip or rar archive by using an archiver, like 7-Zip and WinRar, and then upload that archive file to the cloud, like Google Cloud, then in a different computer that has connection to the internet, download this archive file from the cloud, extract all the saved states with an archiver, like 7-Zip and WinRar, and then use these saved states in a different computer that has connection to the internet! All users may like this very much! I am sure of it!
No wonder that emulators, like VisualBoyAdvance-M and PPSSPP, already allow every user to save and load state to and from a file.
With this new feature, playing dos video games with dosbox-x will be much more fun for everyone including me and you.
I also both very and highly suggest, recommend and advise, but not forcing you at all, to remove the "Select save slot" item entirely from the "Capture" menu, so that you don't have to add the "Use save file instead of save slot" checkbox at all and implement it's functionality as I both suggested, recommended and advised above, because I both think and believe that "Select save file" feature is always much more better and powerful than "Select save slot" in everything and all or most users including me will always prefer and use "Select save file" rather than "Select save slot" and they will always leave the "Use save file instead of save slot" checkbox checked permanently, but leave it there if you both think and believe that I am wrong and you find any advantage that "Select save slot" have that "Select save file" does not have and there is any reason and justice that the user may ever find "Select save slot" more both useful, powerful and better than "Select save file" and both prefer and want to use it more in any scenario and situation.
I know what you both think and believe. You allowed every user to both "Select previous slot" and "Select next slot" with "Left Alt+Left Ctrl+F7" and "Left Alt+Left Ctrl+F8" respectively, so every user can now change the current save slot a very little faster, but not very faster, with his or her keyboard only and the user does not have to touch his or her mouse at all and only for an action that the user may want to perform very infrequently anyway!
This feature also saves a very little both energy, effort and time for all the users, but only very little and not very much, and only for an action that the user may want to perform very rarely anyway!
This is indeed only very little more both convenient and comfortable to select both previous and next slots with the keyboard rather than mouse, but only very little more and not very much, and only for an action that the user may want to perform very seldom anyway!
I do see a very little advantage in this feature, but only very little! I both very barely and hardly count this as an advantage!
In fact I do see a very large disadvantage in this feature that the feature that I suggest does not have this disadvantage at all!
I find this feature very both risky, dangerous and unsafe at all!
In other words there is a very large risk and danger if the user selects either previous or next save slot with his or her keyboard and not with the mouse!
What happens if the user quickly and he or she does not notice that he or she pressed firstly "Left Ctrl+F7" and then "Left Alt"?
He or she simply wants to select the previous slot, but he or she also overwritten the current save slot both mistakenly and accidentally, and this is both unacceptable and not desired sir. Not at all.
Then he or she is very both frustrated and upset. He or she lost progress and time to make this save state and now he or she has to recover it by doing all what he or she did all over again! What a waste of time!
Another common possible mistake or accident is when the user mistakenly and accidentally, quickly and firstly pressed "Left Ctrl+F8" and then "Left Alt"!
He or she simply wants to select the next slot, but he or she loaded the last saved state in the current slot and lost all the progress he or she did since the last capture! Now he or she has to repeat everything all over again! Another waste of time! This is also unacceptable and not desired sir! Not at all! Again the user is very both frustrated and upset!
Using the mouse is much more safe then using the keyboard. Through the menus the user can see exactly what he or she is doing and he or she won't do any mistake or accident that can result in loss of progress and this is not necessary at all to perform an action so quickly that the user wants to perform very infrequently!
This is indeed okay to let every user to quickly both save and load state with his or her keyboard only, because the user wants to perform these two actions very frequently, but this is not the case with "Select save slot" at all!
Overall I find "Select save slot" very much more bad than good feature for everyone and that is why I simply very and highly both recommend, suggest and advise you to simply remove it from the "Capture" menu entirely and simply replace it with the "Select save file" action or command instead for the benefit of all.
But you can still leave it there if you still think that I am both wrong, an idiot and stupid, you are both more clever, smarter and wiser than me, and there is still any good reason that this have to be there and this is still meaningfully better for the user in some scenarios.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
I don't consider any alternatives solutions or features.
Additional context Add any other context or screenshots about the feature request here.
I don't have any additional context to add or provide here.