Bug Tracker – Bug 1123

Save Game field always resets

Last modified: 2016-11-14 23:57:37 CST
Bug 1123 - (ARRAY(0x5668520)) Save Game field always resets
(ARRAY(0x5668520))
Save Game field always resets
Status: ASSIGNED
Product: Odamex
Classification: Unclassified
Component: Client
0.7.x
All All
: P1 minor
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-09-29 05:12:32 CDT by Catoptromancy
Modified: 2016-11-14 23:57 CST (History)
2 users (show)

See Also:


Attachments

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 CDT
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 CDT
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 CDT
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. 

Example:
"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 CST
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 CST
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 CST
Cato is this considered resolved by you?