Open sbularca opened 8 years ago
Yes, this is a confirmed issue.
I ran across this bug last week, and I became suspicious of this one a few days ago when it happened again figuring it had to do with /savecockpit
.
Steps to reproduce.
/savecockpit
2016-01-26 08:54:41.924 - Thread: 1 -> Checking file access for files in target dir.
2016-01-26 08:54:43.250 - Thread: 1 -> Session snapshot save - END
2016-01-26 08:54:52.951 - Thread: 1 -> Exception occured: System.NullReferenceException: Object reference not set to an instance of an object.
at Sandbox.Game.EntityComponents.MyResourceDistributorComponent.RemoveSink(MyResourceSinkComponent sink, Boolean resetSinkInput, Boolean markedForClose)
at Sandbox.Game.Entities.MyCockpit.RemovePilot()
at Sandbox.Game.Entities.MyCockpit.OnControlledEntity_Used()
at Sandbox.Game.Multiplayer.MySyncControllableEntity.ControlledEntity_UseCallback(MySyncControllableEntity sync, ControlledEntity_UseMsg& msg, MyNetworkClient sender)
at Sandbox.Game.Multiplayer.MySyncControllableEntity.ControlledEntity_UseRequest(MySyncControllableEntity sync, ControlledEntity_UseMsg& msg, MyNetworkClient sender)
at Sandbox.Game.Multiplayer.MySyncLayer.MyCallbackEntity`2.Handle(TMsg& msg, MyNetworkClient player, TimeSpan timestamp)
at Sandbox.Game.Multiplayer.MySyncLayer.MyCallbackBase`1.OnHandle(TMsg& msg, MyNetworkClient player, TimeSpan timestamp)
at Sandbox.Game.Multiplayer.MySyncLayer.MyCallbackBase`1.Handle(TMsg& msg, UInt64 sender, TimeSpan timestamp)
at Sandbox.Game.Multiplayer.MySyncLayer.MyCallbackBase`1.Sandbox.Engine.Multiplayer.ITransportCallback.Receive(ByteStream source, UInt64 sender, TimeSpan timestamp)
at Sandbox.Engine.Multiplayer.MyTransportLayer.HandleOldGameEvent(MyPacket packet)
at Sandbox.Engine.Multiplayer.MyTransportLayer.ProcessMessage(Byte[] data, Int32 dataSize, UInt64 sender, TimeSpan timestamp)
at Sandbox.Engine.Multiplayer.MyTransportLayer.HandleMessage(Byte[] data, Int32 dataSize, UInt64 sender, TimeSpan timestamp)
at Sandbox.Engine.Networking.MyReceiveQueue.ProcessMessages(NetworkMessageDelegate handler, TimeSpan delay)
at Sandbox.Engine.Networking.MyReceiveQueue.Process(NetworkMessageDelegate handler, TimeSpan delay)
at Sandbox.Engine.Networking.MyNetworkReader.Process(TimeSpan lag)
at Sandbox.MySandboxGame.Update()
at Sandbox.Engine.Platform.Game.UpdateInternal()
at Sandbox.Engine.Platform.FixedLoop.<>c__DisplayClass2.<Run>b__1()
at Sandbox.Engine.Platform.GenericLoop.Run(VoidAction tickCallback)
at Sandbox.Engine.Platform.Game.RunLoop()
at Sandbox.MySandboxGame.Run(Boolean customRenderLoop, Action disposeSplashScreen)
at VRage.Dedicated.DedicatedServer.RunInternal()
at VRage.Dedicated.DedicatedServer.RunMain(String instanceName, String customPath, Boolean isService, Boolean showConsole)
at VRage.Dedicated.DedicatedServer.ProcessArgs(String[] args)
at VRage.Dedicated.DedicatedServer.Run[T](String[] args)
at SpaceEngineersDedicated.MyProgram.Main(String[] args)
At the moment, the only workaround I have is to eject the player from the cockpit immediately before trying to rewrite the cockpit.
There are still issues with the ResourceSink however with the Eject. It appears, the player's power, oxygen may still be linked the cockpit if we don't eject them correctly.
I haven't mentioned this on the Steam Forum, as it can be used crash servers intentionally.
If any server admin believes they are at risk, they can temporarily disable the command until we release a fix.
Use with the following command to disable it:
/perm command setlevel savetoolbar none
And then enabled again later with:
/perm command setlevel savetoolbar 0
Thankfully my brother and I only play on a private DS so we're the only two people ever on it. We'll just have to be careful and only use the command before doing a server restart, instead of every time we change something on a hot bar like we normally do, until a fix can be found.
Any idea if saving the cockpit then killing yourself would get around it? Just until a more permanent solution can be identified? Also, I'm going to delete my comment from the Steam page just in case it draws attention to it for other servers.
The only current workaround, is to exit your cockpit immediately after using /savecockpit
.
Then you can re-enter, and it should be safe to dock the ship to a connector.
Ok thank you, that seems a lot less drastic than committing suicide every time haha.
That is a good workaround, thanks!
The mod is crashing the dedicated server when trying to exit cockpit, in a small ship, while connected with a station using locked connectors (the cockpit is saved via /savetoolbar). I have other mods but activating yours causes the crash, every time.
Game version is 01_118_011.
SpaceEngineersDedicated.txt