Bug Tracker – Bug 1123

Save Game field always resets

Last modified: 2016-11-14 23:57:37 UTC
Bug 1123 - Save Game field always resets
Summary: Save Game field always resets
Alias: None
Product: Odamex
Classification: Unclassified
Component: Client (show other bugs)
Version: 0.7.x (Old)
Hardware: All All
: P1 minor
Assignee: Odamex Bug Reporter
Depends on:
Reported: 2014-09-29 05:12 UTC by Catoptromancy
Modified: 2016-11-14 23:57 UTC (History)
2 users (show)

See Also:


Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Catoptromancy 2014-09-29 05:12:32 UTC
Choosing a Save Game slot automatically inserts a date/time stamp. This prevents giving real names to demos easily. 

It is possible to select a save game slot, use backspace to delete the date/time stamp, type a human-readable save game. But this needs to be done for every single save. The date/time stamp will always overwrite what was written.

Happens in linux, not sure about the others.
Comment 1 Mike Wood 2014-09-29 05:18:42 UTC
I implemented this behavior some years ago so that saved games could have a unique identifier on game consoles and handhelds when someone does not have a keyboard plugged in. I think this is still good default behavior but we could add an option to toggle it off.
Comment 2 Catoptromancy 2014-09-29 16:40:08 UTC
How about "date/time pwadname" as the auto field. 

Another idea is having a constant autofield at the start, but a user defined field after. 

"date/time usercomment", then saving over it will bump the date/time but does not change usercomment.

"usercomment" would be best as players, can label thier saves once and make it pwadname anyway.
Comment 3 Mike Lightner 2014-12-16 00:08:46 UTC
If the slot already has a name, it should not be overwritten with the timestamp.  That sounds like the most egregious thing happening in this bug.
Comment 4 Mike Lightner 2014-12-16 00:32:09 UTC
r5162 fixes the worst part, now previously-named slots won't be overwritten with the date+time.
Comment 5 HeX_Vulture 2016-11-14 23:57:37 UTC
Cato is this considered resolved by you?