CTD if not exit mine in multiplayer
In a multiplayer game, any time I die from not making it out the exit before the reactor time expires, I get the following error immediately after loading the next level:

Error: "similar\main\object.cpp:1778: object_move_one: error: Unknown control type 5 in object 0, sig/type/id = 0/4/0"

Note: Sometimes the first number is 1722 instead of 1778. And sometimes the first number of "#/4/0" is different.

This happens in all game modes, all campaigns, regardless of server settings. If I make it out of the mine in time, the error does not occur. I networked 2 players into the same game, blew up the reactor, then had one exit the mine, while the other stayed to die.
-If the host exits the mine, the host continues to the next level. Any client that doesn't exit receives the error.
-If the host doesn't exit the mine, all players receive the error.

Builds that gave me the error:
D1X v0.60 - 04-14-18
D1X Current Clone
D2X v0.60 - 04-14-18
D2X Current Clone

Both v0.58.1 builds did not give the error. 
I produced this error in Windows 7. I did not test any other OS.

This is obviously very troubling, considering it breaks the game for any player who doesn't exit the mine in time. If you need me to do any additional testing, please let me know.
I cannot reproduce this. However, I did hit a related crash that seems to be introduced by Replace calls to window_set_visible in DoPlayerDead() with stop/start_time(), which causes this abort:
terminate called after throwing an instance of 'valptridx<d2x::object>::null_pointer_exception'
  what():  similar/main/slew.cpp:152: NULL pointer used: base=0x555555aaec60 size=350
Bypassing that abort leads to a corrupted palette on the next level. Fixing this is non-trivial since the offending commit deliberately bypassed some code with the intent of avoiding some unwanted side effects of that code. I need to identify which bypassed pieces need to be restored.

The problems might be related. The bypass seems to cause object movement to be processed in a context where it previously was not processed. If the object table is in an inconsistent state, the crash you saw might happen.
I ran the same test on Win10 build 1803, and Win10 build 1607 with the same result. The 4 computers I tested this on had very different hardware. Two are desktop PCs, one is a laptop, and one is a Windows tablet.

It's good to know that you have a potential lead on this. Please let me know when you update the code with a potential fix and I will test it on my end.
Hide game window when advancing a dead player to the next level fixes the crash I saw where the host would abort if the mine countdown expired while the host was dead. The problem was that the game would run level processing logic too early, with a tremendous amount of level setup not yet executed. Inconsistencies caused by not doing this setup explain my crash, and possibly yours too.
Yay!! Problem solved! Thank you!

Forum Jump:

Users browsing this thread: 1 Guest(s)