search

midspace / Space-Engineers-Admin-script-mod

Modding script for Space Engineers with dozens of Admin commands for creating game scenarios or supporting servers.
43 stars 13 forks source link

Chat commands broken in multiplayer because of the 1.105 update. #123

Open midspace opened 8 years ago

midspace commented 8 years ago

Works:

Will cause crash in Client: - [ ] /pasteprefab - I don't have a solution for this one. It's crashing during the paste phase which is Keen code.

Will not work as expected:

Will be restricted because of how the game now delivers chunks of data:

Commands not yet investigated but may be affected:

midspace commented 8 years ago

We need to do a restructure of the ChatCommandLogic to make use of ChatCommandService on the Server side.

This is required to do Security checks for players when Messages are called. And to call UpdateBeforeSimulation...() on the ChatCommands.

I'm wondering if we need to go further, and just move the ChatCommands to the server. Have all commands run only on the server.

Players may enter a chat command, but we do a simple check (am I a valid chat command ignoring parameters?), then route the chat message to the server to process.

Spcemarine commented 8 years ago

That reminds me of the way we developed minecraft plugins back then. It might really be easier to run everything on the server but I am not really sure what's better.

midspace commented 8 years ago

I've been thinking on how to approach this for last 24 hours, and have a good idea how to approach it now.

Adding two new enum to ChatCommandFlag to indicate Client or Server commands. Security will continue to be sent to Clients, for Client commands. We will have some, like Help.

The ChatCommand.Invoke() will have new parameters to indicate the steamId and playerId (others may be added on further consideration).

The ChatCommandService will check the ChatCommandFlag and run local for Client or send message to server for Server.

A new message class will process the message, and check security, before calling the server side ChatCommandService to Invoke, passing through appropriate parameters.

Spcemarine commented 8 years ago

Sounds like a good Plan. I'd like to add that we'll only need a Server flag as the processing will start on the client anyway. Further I'd clearly separate the sever stuff into a method named InvokeOnHost(ulong steamId). If we put the relevant values into fields, we'll just need to send the whole ChatCommand and then call InvokeOnHost(...) from MessageCommand.ProcessServer(). This way we just have to do a check if we need to send the message or if we can call the InvokeOnHost(...) directly (SP, hosted games). Lastly we should define a method that handles the feedback of the command (mainly the ShowMessage(...) calls). It has to send the message to the client if necessary, in SP or on the hosted instance we can show it directly.

midspace commented 8 years ago

I've been working on /status and /tpp as the first converts, and have run into an issue. The IMyEntity.SetPostition() command doesn't appear to work on the dedicated server. I'm not sure if I have somehow used the wrong entity, or it just does not sync to Clients. More investigation for me to follow up on. :sleepy:

Spcemarine commented 8 years ago

While working on a jump gate mod I encountered the same problems. It seems like that if an entity is controlled by a player the client of the player has to update the position. At least that worked for me.

midspace commented 8 years ago

So far, the basic rules are: Creating object, must be done on Server. Moving object, must be done on all Clients and Server. Faction changes, must be done on Server. Affecting players, must be done on Server.

More than likely, if it doesn't work, it should be carried out on the server. Though some things, like Session commands still have some effect when turned on locally, though they have been limited somewhat since 1.105, like CopyPaste.

midspace commented 8 years ago

I've been putting off doing the server side commands for too long, so I've started working on them. There are a lot of interconnected commands that are reliant on information been there on the server side.

There is a high level of complexity especially the teleport commands, depending on where information has to come from.

There are basics which I'm still working on. /status and /listships commands will be called server side. Teleport commands are going to be called server side. all other commands which depend upon listships and status will be called server side.

Exceptions will be commands which work with player point of view, ie., /on and /off' I need to test if Spectator view can be retrieved server side. if not, these will have to be called client side, and then finish execution server side. The /id command will probably continue to work client side, but send a message server side to indicate the last entity tagged by the player so it can be used by server side commands like /tp.