[modrelated] Savegame procedure actively refuse to work with runtime defs

Started by RawCode, August 13, 2014, 07:49:51 AM

Previous topic - Next topic

RawCode

Generation of runtime defs and spawning things defined at runtime is perfectly fine.
Diablo like drops and mobs are possible.

Red deer of infernal death - no problem.
Murdering holy grenade of destruction - here you go.
Unlimited level upgrades - fast and easy.

Perfectly fine as long as you not going to save that game and load it later, because it will attempt to resolve everything before you will get a chance to regenerate all runtime defs you need.

Actually you can hack into loading process, but this very very version specific and probably platform specific.

Also its possible to define 100500 "abstract" defs, that will be filled with data later (currently i am going to implement stuff this way, by managing pool of runtime defs) but garbage collection issue is raised and such system feature huge overhead.

Why bug, because there is no trycatch section in few locations of code, this cause complete failure in case of missing defs without any chance of recovery.

How i see fast easy and no cost support of runtime defs (this is how minecraft forge solve references missing from game\world):

1) If game is failed to load some object due to missing def or any other reason, that object is placed to *dead* list with error message attached, without ruining main thread by exception.
Good objects initialized instantly.

2) After all other objects are loaded *dead* list loaded again.
3) Objects that managed to load (probably other object generated required def or altered some variable required) removed from list and initialized.
4) Process repeats as long as no objects left *dead* list after iteration.

5) After *dead* list is finalized - alive objects granted opportunity to inspect list of dead objects and change\edit objects or list itself.
Or just store debug data or sent bug report.

After that all invalid objects simply removed.