Welcome to the ZDoom Forums!

...PRICELESS! I've always desired some way of detecting reloads!

That'd allow to make a reload detector... Even let you detect how many times the game has been saved. Pseudocode:

wildweasel wrote:Will this flag be exposed to Decorate? I suspect it'll be in modders' best interests to attach the flag to things like gore, bullet puffs, and debris.

This would be nice indeed. While I suspect this will break some save games if misused... Guess it's the modder's fault in that case.

Oh... they'll be recreated?

Yes, precisely. In the case of dynamic lights that would be fine because they will be recreated afterward anyway.

Does this mean that objects not written out to save games will be removed entirely if the save is reloaded?

randi wrote:Sounds like I need to add an OF_Transient flag you can use to mark objects that should not be written out to save games, then.

Will this flag be exposed to Decorate? I suspect it'll be in modders' best interests to attach the flag to things like gore, bullet puffs, and debris.

(And shopkeepers, for those wanting to mimic the old Daggerfall save glitch. =P)

Graf Zahl wrote:GZDoom, in order to reduce save file size, destroys all attached lights before saving out the data and restores them right afterward.

Sounds like I need to add an OF_Transient flag you can use to mark objects that should not be written out to save games, then.

http://imgur.com/a/zwRWv

Info in the image descriptions. Will provide even more info if needed.

You can do one thing, which will work in both ZDoom and GZDoom:

enter 'stat gc' in the console, and once the freeze occurs, tell us what it says in the bottom left corner.

Any tests I can do? Can replay the hangar map with ZDoom instead of GZDoom and log the activity, but I'm not sure if it'll work.

I have no idea. The savegame code seems an unlikely cause here, but there's one important difference between ZDoom and GZDoom here that may be important: GZDoom, in order to reduce save file size, destroys all attached lights before saving out the data and restores them right afterward. So it is doing a high number of allocations that could end in a memory-constrained situation and trigger the GC. But I have no clue how it could lock up. It never happened to me, even under the most stressed situations.

Graf Zahl wrote:That sounds like a problem with the garbage collector, not the save system.

Except I'm pretty sure it doesn't get triggered during saving. It does a full collection at map change, and the only other time it should trigger (excepting via console command) is as part of the world think when memory usage warrants it, and then it's only incremental collection until it finishes.

I believe the save freezes are the same thing. This is not the savegame system but the garbage collector that's screwing up. The save system does not have any potentially infinite loops that might occur, when I rewrote it I made damn sure that there's nothing recursive or potentially endlessly looping at all in there.

Ok... but more specifically, I meant an active thread... because this thread is about save freezes. I don't want to create a new thread if there's one already bringing attention to the problem...