-
Notifications
You must be signed in to change notification settings - Fork 225
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Restore part of "Trim edict list on load" in order to fix 'autofastload'
Otherwise autofastload leaks edicts, eventually aborting game when max_edicts is reached BEWARE: this _may_ break old savegames !
- Loading branch information
Showing
3 changed files
with
58 additions
and
45 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how does it show if the save games do not work? Only when saving?
are new savegames still be compatible with ironwail /qs /qss ?
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'old' savegame stats 133 kills 16 secrets (skill 1)
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly.
I have no idea. This is the same format as before, except the amount of saved entities is "optimized", so to speak so I would say the problem is only between the old and new vkQuake saves.
In any case, the compatibility between QSes is already shaky because there are a shitton of optional fields loaded under the section
// QuakeSpasm extended savegame
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not feel compelled to change now, there is no performance gain with that latest version as you know.
On the other hand, there is a piece of code by @temx in the Trim edict on load commit that was supposed to assure 'compatibility with old saves' (whatever that means) that I purposfully do not add, because I thought it was a super-niche problem. Do you think it is worth adding it back ?
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've added back the old savegame compatibility trick, If you want to test it.
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if this is a good change for a minor release update.
could you add this extra code in an extra branch pls?
it's possible that the savegame will break later anyway if I continue playing normally.
save game compatibility:
most of the time I was able to load a savegame in other engines as long as I made sure that all extentions were available
i.e r_fteparticles 1 vkquake > qss (AD maps)
r_fteparticles 0 vkquake > ironwail (AD maps )
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unfortunately still get the same errors when saving.
I have two more savegames from this play test (immortal v1.5) and the one with 102 kills fails as well and the one quite early ( 57 kill) seem to work. At least no error when saving.
I tried the same with two AD savegames and they seem to work (load / save test )
save_immortal_1.5.zip
I guess immortal is special in every possible way...
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
save_immortal_1.5.zip
Well here with actually v1.7 installed, all 3 saves load !
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
loading is not the problem. It fails when saving!
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's pure luck that these savegames load with immortal 1.7. And there is a high risk they will have game breaking bugs. Previous updates didn't load old savegames successfully at all.
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I see the same thing as you. Now I'm bound to play The Immortal Lock until it crashes, it seems.
If I reproduce the bug then I'll revert the Trim Edict on load things. This is a pity because without it 'autofasload' is broken (leaks edicts like crazy, which in turns inflates the ones saved, until you are stuck and cannot continue) and it would be really usefull for this kind of monster precisely.
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's more worring, could this also happen if you start fresh without loading an old savegame?
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK with 0416d90 I can now save in Immortal Lock.
The 'Ultra-fast' loading mode may starts leaking edicts again but in fact it entirely depends on the level : Immortal Lock for instance looks unnaffected. (looking at
edictcount
before and after loading a level)Now that I have tested the few mods I have installed, the only pathological case I still have is Replicon : leaking like crazy.
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might have missed here something. What's the diference between autoload 2 and autoload 3?
they look the same to me. Both restart immediately.
ok got it. fastload instead of load
ok I'll try this later. but immortal is the 1st map I would consider using the fastload feature
9e3cfe2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
autoload 3
=autoload 2
(a.k.a Fast) +autofastload 1
(hidden from user, default = 0) which is the equivalent of making the commandload SAVE
(including through menu) behave likefastload SAVE
all the time.The loading speed difference is huge, you litterally teleports to the previous place.
You can always bind a shortcut like:
but this is not public knowledge.