This object is in archive!
[BETA] Frequent crash to desktop: System.NullReferenceException
Solved
While attempting to print PMW homing missiles from a blueprint, I very frequently encounter a crash to desktop.
It appears to be something to do with the welding (from blueprint) of the movement or offensive combat modules.
Files:
SpaceEngineers_...
I have the same bug
Further testing indicates that this only occurs when the modules are welded while there is a valid enemy target nearby.
I have confirmed that welding these components while <IsActivated>true</IsActivated> causes the crash under these conditions, but welding them with <IsActivated>false</IsActivated> does not cause this behavior.
Further testing indicates that this only occurs when the modules are welded while there is a valid enemy target nearby.
I have confirmed that welding these components while <IsActivated>true</IsActivated> causes the crash under these conditions, but welding them with <IsActivated>false</IsActivated> does not cause this behavior.
Changing the blueprint to disable (<IsActivated>false</IsActivated>) the Offensive modules also results in inconsistent behavior.
If the modules are activated before they are released from their main subgrid, they seem to work about 75% of the time, identifying and tracking targets.
If the modules are activated while they are still being welded up, the game instantly crashes to desktop when the button is toggled.
If the modules are activated after they have been disconnected from their subgrid, they do not engage in any behaviors at all, and claim their Offensive AI module is "disabled", and never engage in any targets.
Changing the blueprint to disable (<IsActivated>false</IsActivated>) the Offensive modules also results in inconsistent behavior.
If the modules are activated before they are released from their main subgrid, they seem to work about 75% of the time, identifying and tracking targets.
If the modules are activated while they are still being welded up, the game instantly crashes to desktop when the button is toggled.
If the modules are activated after they have been disconnected from their subgrid, they do not engage in any behaviors at all, and claim their Offensive AI module is "disabled", and never engage in any targets.
"If the modules are activated after they have been disconnected from their subgrid, they do not engage in any behaviors at all, and claim their Offensive AI module is "disabled", and never engage in any targets."
I've experienced the same behavior when trying to make a torpedo rack.
"If the modules are activated after they have been disconnected from their subgrid, they do not engage in any behaviors at all, and claim their Offensive AI module is "disabled", and never engage in any targets."
I've experienced the same behavior when trying to make a torpedo rack.
Further update:
- This seems to only occur on the "second" print of the missile that has the Offensive AI block. The one that is spawned by pasting in the blueprint is unaffected by the crash.
- It does not matter what method is used to set the AI Enabled as "Active". Using a timer block, manually toggling it, or any other method of triggering it (including the creation event from welding it up) will cause the crash.
- It occurs even if the Offensive AI block has merely *seen* an enemy block prior to activation. If the enemy block is removed, enabling AI Behavior still results in a crash.
- It does not appear to be affected by grouping vs individual references.
- The first generation of missiles (printed or pasted) function correctly.
Further update:
- This seems to only occur on the "second" print of the missile that has the Offensive AI block. The one that is spawned by pasting in the blueprint is unaffected by the crash.
- It does not matter what method is used to set the AI Enabled as "Active". Using a timer block, manually toggling it, or any other method of triggering it (including the creation event from welding it up) will cause the crash.
- It occurs even if the Offensive AI block has merely *seen* an enemy block prior to activation. If the enemy block is removed, enabling AI Behavior still results in a crash.
- It does not appear to be affected by grouping vs individual references.
- The first generation of missiles (printed or pasted) function correctly.
Breakthrough:
The crash occurs regardless of whether there is an enemy object nearby.
If the first ship or missile that was produced has targeted an enemy, then enabling AI on the second print will cause the crash regardless of whether there is a valid enemy target nearby.
Therefore, I conclude that this is a memory pointer or reference issue, where the Offensive AI blocks are sharing the same state despite being 'separate' instances. This also explains why reloading the game world results in the next printed instance of the ship/missile being functional.
Breakthrough:
The crash occurs regardless of whether there is an enemy object nearby.
If the first ship or missile that was produced has targeted an enemy, then enabling AI on the second print will cause the crash regardless of whether there is a valid enemy target nearby.
Therefore, I conclude that this is a memory pointer or reference issue, where the Offensive AI blocks are sharing the same state despite being 'separate' instances. This also explains why reloading the game world results in the next printed instance of the ship/missile being functional.
Another discovery:
The AI reference is tied to the grid or subgrid that it originated on. Once any Offensive AI block on that subgrid has acquired a target, ANY offensive blocks will cause a crash if their AI state is then Enabled.
Therefore, the identity of the problematic AI controller is tied to a specific grid, and is not de-referenced if the grid is split.
Another discovery:
The AI reference is tied to the grid or subgrid that it originated on. Once any Offensive AI block on that subgrid has acquired a target, ANY offensive blocks will cause a crash if their AI state is then Enabled.
Therefore, the identity of the problematic AI controller is tied to a specific grid, and is not de-referenced if the grid is split.
Hello, Slacker,
thank you for letting us know.
We are already aware of this issue and it will be fixed in the next update.
Kind Regards
Keen Software House: QA Department
Hello, Slacker,
thank you for letting us know.
We are already aware of this issue and it will be fixed in the next update.
Kind Regards
Keen Software House: QA Department
Replies have been locked on this page!