chickenbc wrote:
Broken savegame - Referencing invalid CargoPacket
Error: Assertion failed at line 53 of /home/leebc/openttd/21531_mod/trunk/src/core/multimap.hpp: !map_iter->second.empty()
Thank you for the information.
multimap.hpp is part of CargoDist ...
That being said, it might be that the bug is already fixed as CargoDist has been updated in v11_5. It may also be because of you changing grfs earlier.
I ran your pre-crash savegame in v11_5_1 well past the date that shows in your screenshot and it did not crash ... then again I just let it run and did not build anything.
I should run it again in v11_3 which I will do later today to see if I can make it crash there with the older version of CargoDist.
I will also build a debug build to see if I an get some more info out of your crash.sav.
Your mousepointer is over the smallmap links in your screenshot, did you do anything in particular before the crash?
The smallmap links are still the old version, as I prefer that version, please do not yet go reporting to fonso before I know for sure that the bug is not coming from that.
I noticed that your savegame is eating CPU I do not yet know where it comes from ... most likely some advanced settings that are too high.
Also I wonder if OpenTTD supports multiple cores now ... CPU usage showed between 80 and 180% ... I know that for saving it used the second core but I did not have autosave enabled.

I tried loading a coopsavegame with 1100 trains and 600 roadvehicles or so and that did not use as much.
I would suggest continuing from your pre-crashed savegame in the newest version and see if it crashes again ... do keep a backup just in case.

I will let you know If I find what causes the extreme system load.
NekoMaster wrote:
Did you know...
Setting "scenario_developer" to True (default is false) will allow you to change your grfs in game. Only use this grf if you know what your doing.
There are a few more developer settings that enable it again.
It should only be used for testing and not for longlasting games ...
The only semi-safe thing you can do is add grfs to the end of the list and then only if they do not conflict with other grfs that are already in the list.
The order should never be changed and removing some is also a big nono.
I will stop trying to debug savegames with altered grfs presets once I have broken savegamecompatibility with previous versions and restored compatibilty for recent trunk savegames.
IIRC Devs do not bother neither as it is practically impossible to fix, let alone find the error in such savegames.
I know you mean well but please stop giving advice that will only cause more problems, unless you are going to debug those savegames in the future.
The option has been removed for a very good reason.
ps:
Please do not make me remove the option entirely (in the patchpack).

-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.