View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003082 | Dwarf Fortress | Technical -- Saving/Loading | public | 2010-08-21 20:36 | 2012-02-13 09:14 |
| Reporter | Khift | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Platform | PC | OS | Windows XP | ||
| Product Version | 0.31.12 | ||||
| Summary | 0003082: Use of the auto-save and auto-backup features results in save folders with confusing, ridiculously long titles. | ||||
| Description | If you have Autosave: Seasonal and Autobackup enabled, when it performs the seasonal autosave it adds the season and the year to the end of the name of the new save folder. While in itself this is innocuous, if you're playing from an autosave it doesn't replace the previous suffix and instead adds another. Play long enough and every time you load from an autosave you end up with another suffix, and your save folder gets ridiculously confusing. My current most up to date save, for example, is region1-win-1051-aut-aut-1057 -- it seems to stop adding things to the end after a bit, too. Add with it the fact that if you save while playing from an autosaved folder it overwrites the folder you loaded from, not the base folder, and after 10 years in-game it gets particularly difficult to find out which save is actually the most recent one due to all of the tags being added. | ||||
| Steps To Reproduce | Play with autosave and autobackup enabled. After it performs an autosave, exit the game and load it. Play until it autosaves again and verify. Should be 100% repeatable. | ||||
| Additional Information | Obviously not a gamebreaking issue, just results in a very confusing save list after ten years of playing. Each time I sit down to play it's a game to figure out which save is the most recent one, sometimes taking two or three attempts. A similar issue is that after loading an autosave using the manual save feature will overwrite the autosave folder, not the main folder for the region. If that were fixed this issue would likely solve itself; the file save name would 'reset' itself every time you manually saved so this issue would never go on for long enough to compound itself into a real problem like it does now. | ||||
| Tags | No tags attached. | ||||
|
|
You're not supposed to actually load and play seasonal backups, only your primary save. If you need to restore from a backup, you should delete your main copy and copy/paste the seasonal backup in its place. |
|
|
See 0001979 and the Suggestions thread it spawned: http://www.bay12forums.com/smf/index.php?topic=57735.0 |
|
|
I am sorry, but the fact that the save system cannot name and manage it's files properly is not a feature, it's a bug. If the intended functionality is that you replace your save files with your backups manually then the backups should not be listed as save files and this needs to be described in the d_init.txt as it's functionality. As it is the d_init.txt file indicates nothing of the sort, leaving the user to assume that the autosave and backup features function as they do in every other game that includes them and it definitely does not. It is an issue, and it should be fixed, one way or another. |
|
|
If the intended functionality is that you replace your save files with your backups manually then the backups should not be listed as save files and this needs to be described in the d_init.txt as it's functionality. It's not the one and only "intended functionality" per se -- the backups are just a quick and dirty solution to be used in whatever way makes sense to you. Just because a feature is crappy and unfinished doesn't mean it's a bug. It's working in the way the programmer intended. Also, this report is a duplicate of 0001979. Please voice any further sentiments in the thread linked above. |
|
|
"It's not the one and only "intended functionality" per se -- the backups are just a quick and dirty solution to be used in whatever way makes sense to you." So this IS a bug then. If you're supposed to be able to use it in this manner (loading straight from the saves), then this report and the report 1979 ARE bugs. You can dance around it all you want but trying to pass this off as working as intended is crap. Either you're supposed to be able to load straight from the backup saves, in which case these two reports are bugs, or you are not supposed to load from the backup saves, in which case the very fact that you can is itself a bug. |
|
|
Either you're supposed to be able to load straight from the backup saves, in which case these two reports are bugs You are supposed to be able to, yes, and you are able to. It causes your folder names to get confusing, but confusing folder names aren't a bug. They're crappy in an entirely intentional way, just like many other incomplete features in DF. The purpose of this tracker is to assist Toady in fixing bugs. Toady has repeatedly confirmed that these crappy-but-intentional defects are not bugs and do not belong on the bug tracker. Clear now? |
|
|
'Intentional defect' and 'known bug that is low priority and not game-breaking' are just potayto - potahto. Still, the whole purpose of this report is to make sure Toady is aware of it. If he is aware of this issue, whatever you want to call it, without it being on this tracker then I'm happy as a lark. |
|
|
'Intentional defect' and 'known bug that is low priority and not game-breaking' are just potayto - potahto. It's more like "intended potato" vs. "unintended potato." If he is aware of this issue, whatever you want to call it, without it being on this tracker then I'm happy as a lark. He reads Suggestions, so yes, if he wasn't aware before, he will be: http://www.bay12forums.com/smf/index.php?topic=57735.0 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-08-21 20:36 | Khift | New Issue | |
| 2010-08-21 21:37 | Quietust | Note Added: 0011991 | |
| 2010-08-21 21:37 | Quietust | Note Edited: 0011991 | |
| 2010-08-21 21:58 |
|
Relationship added | duplicate of 0001979 |
| 2010-08-21 21:58 |
|
Note Added: 0011992 | |
| 2010-08-21 21:58 |
|
Status | new => resolved |
| 2010-08-21 21:58 |
|
Resolution | open => no change required |
| 2010-08-21 21:58 |
|
Assigned To | => user6 |
| 2010-08-21 23:18 | Khift | Note Added: 0011994 | |
| 2010-08-21 23:18 | Khift | Status | resolved => feedback |
| 2010-08-21 23:18 | Khift | Resolution | no change required => reopened |
| 2010-08-21 23:58 |
|
Note Added: 0011996 | |
| 2010-08-21 23:59 |
|
Note Edited: 0011996 | |
| 2010-08-22 00:00 |
|
Note Edited: 0011996 | |
| 2010-08-22 00:00 |
|
Status | feedback => resolved |
| 2010-08-22 00:00 |
|
Resolution | reopened => no change required |
| 2010-08-22 00:00 |
|
Note Edited: 0011996 | |
| 2010-08-22 00:01 |
|
Resolution | no change required => duplicate |
| 2010-08-22 11:54 | Khift | Note Added: 0012016 | |
| 2010-08-22 11:54 | Khift | Status | resolved => feedback |
| 2010-08-22 11:54 | Khift | Resolution | duplicate => reopened |
| 2010-08-22 13:16 |
|
Note Added: 0012019 | |
| 2010-08-22 13:16 |
|
Note Edited: 0012019 | |
| 2010-08-22 13:17 |
|
Note Edited: 0012019 | |
| 2010-08-22 14:40 |
|
Tag Attached: AWAITING UPDATE | |
| 2010-08-22 15:13 | Khift | Note Added: 0012023 | |
| 2010-08-22 15:13 | Khift | Status | feedback => assigned |
| 2010-08-22 15:42 |
|
Note Added: 0012024 | |
| 2010-08-22 15:42 |
|
Note Edited: 0012024 | |
| 2010-08-22 15:45 |
|
Note Edited: 0012024 | |
| 2010-08-22 15:45 |
|
Status | assigned => resolved |
| 2010-08-22 15:45 |
|
Resolution | reopened => no change required |
| 2010-08-26 20:40 |
|
Tag Detached: AWAITING UPDATE | |
| 2012-02-13 09:11 |
|
Relationship added | has duplicate 0005044 |
| 2012-02-13 09:12 |
|
Relationship replaced | has duplicate 0001979 |
