Changes to IMyEntity.SetPosition() as of version 01.129

[Spcemarine]

First: I'm not home currently so I don't have access to a computer that runs SE, the following is taken from a discussion with our fellow modders like Trysis, rexxar, MMaster and others.

With the new update the mentioned method must be executed on the server side according to Tyrsis. This will affect mostly characters but it might affect ships and floating objects too (but I'm not really sure about that). Obviously we need to rework the MoveEntity(...) methods in Support.cs. Maybe it's worth it to check if floating objects are synced correctly now. Sorry for not being able to look it up and to fix it myself currently.

[midspace]

I've been checking floating objects, and haven't seen any issues. With floating objects we current move them on all sessions. Server and Client. It was the only way it would work, as the server would not sync to clients.

With characters, I noticed an issues 2 weeks ago when trying to move another player character to a set location. I tried moving the character first. Then tried having them get in as a passenger into a ship, and teleporting the ship. They appeared to be in the right location, but they observed they were still in the old location. After exiting and moving, their character visually disappeared from the new location. So there is something to be fixed there.

I should point out, the ship I used was unpowered so it didn't physically move. It probably didn't trigger any sync updates.

[Spcemarine]

Yeah I know how we handle floating objects currently but if it would sync automatically after the changes that were introduced we could get rid of some manual sync.

Concerning the character: Until the last update: To move the entity controlled by a player (regardless if it was a ship or character) it must have been update from this player's client to sync correctly. (My own experience and rexxar had the same) As of now: It must be called on the server. (According to Tyrsis. rexxar confirmed that SetPosition(...) called from client does not work anymore.)

[midspace]

It feels like this may have changed a couple of weeks ago, and not specifically in 1.129.

[Spcemarine]

Hmm... I don't know for sure if it was introduced with 129 but it would make sense as they changed the position update hierarchy from Client > Server to Server > Client.

[midspace]

The check in I've made will hopefully resolve this. However, what I am doing is the same as what has been done for floating objects. Setting the position on the Server and all connected Clients.

In my testing: setting the Client only caused rubber banding and you would end up where you started. setting the Server only appeared to work, however it was inconsistent when the Client was synced. setting the Server and all clients appears to move the object/player without any jerky behaviour.

I am concerned my approach is too chatty. There is supposed to be a method to force sync update of position information to clients. However I cannot remember what it is called. We should consider testing it to see if it is any better.

[Spcemarine]

I got the following crash after executing a /tp command controlling a character tping to a static grid from the listships hotlist:

Exception occured: System.NullReferenceException: Object reference not set to an instance of an object.
   at Sandbox.Game.Replication.MyCharacterPositionVerificationStateGroup.CustomClientRead(UInt32 timeStamp, MyTimeStampValues& serverPositionAndOrientation, BitStream stream)
   at Sandbox.Game.Replication.MyEntityPositionVerificationStateGroup.ClientRead(BitStream stream)
   at Sandbox.Game.Replication.MyEntityPositionVerificationStateGroup.Serialize(BitStream stream, EndpointId forClient, UInt32 timestamp, Byte packetId, Int32 maxBitPosition)
   at VRage.Network.MyReplicationClient.ProcessStateSync(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.Game.RunSingleFrame()
   at Sandbox.Engine.Platform.FixedLoop.<>c__DisplayClass1.<Run>b__0()
   at Sandbox.Engine.Platform.GenericLoop.Run(VoidAction tickCallback)
   at Sandbox.Engine.Platform.Game.RunLoop()
   at Sandbox.MySandboxGame.Run(Boolean customRenderLoop, Action disposeSplashScreen)
   at SpaceEngineers.MyProgram.RunInternal(String[] args)
   at SpaceEngineers.MyProgram.Main(String[] args)

So we have to watch out for possible crashes.

[midspace]

Was this offline, multiplayer or ds? Can you replicate it?

As it is a game crash, any chance of a full copy of the log?

[Spcemarine]

Whoops. I forgot to save the full log. And it was on my local DS, but my client crashed and I haven't been able to reproduce it at all. It seemed pretty random to me as I was using the /tp command very often and everything was fine except for this one time.

[Spcemarine]

I was able to reproduce it: Die and respawning in suit. Do not move. Then teleport a grid (in my case it was about 20km away). Permanent death was enabled, not sure if it affects the outcome.

[midspace]

I think this has been fixed in the next version. I was able to reproduce it in 1.130.012, but not after that.

[midspace]

Please retest this now.

[Spcemarine]

I couldn't reproduce it anymore.