Openrct2: Tile inspector should be available in multiplayer

[janisozaur]

Version: 0.0.6-develop

Tile inspector, one of the prominent OpenRCT2 additions, calls all the functions directly to modify global game state. This makes it unusable for multiplayer, as it only affects client's local state.

It is currently hidden in multiplayer, but with recent emergence of high profile servers, especially https://nedesigns.com one, there is an interest in having this feature available for multiplayer as well.

This issue is meant to track progress of converting tile inspector from using direct calls to using our engine event loop based on game_do_command calls.

Things to do:

Modify element

• [ ] common actions (not element specific)
  
  
  
  • [ ] rotate selected
  
  
  • [ ] copy (keep client-only)
  
  
  • [ ] change base height (take multiple tiles into account)
  
  
• [ ] surface
  
  
  
  • [ ] remove/restore park fences
  
  
  • [ ] toggle raised corner flag
  
  
  • [ ] toggle diagonal flag
  
  
• [ ] path
  
  
  
  • [ ] toggle connected edges and corners
  
  
  • [ ] toggle slope (missing, should be added)
  
  
• [ ] track
  
  
  
  • [ ] toggle chain lift (take multiple tiles into account)
  
  
• [ ] scenery
  
  
  
  • [ ] select quadrant location
  
  
  • [ ] toggle colliding quadrants
  
  
• [ ] entrance
• [ ] fence
  
  
  
  • [ ] change slope
  
  
• [ ] large scenery
• [ ] banner
  
  
  
  • [ ] toggle blocking paths
  
  
• [ ] corrupt elements
  
  
  
  • [ ] clamp to next element
  
  

Modify tile

• [ ] insert corrupt
• [ ] remove element
• [ ] move up/down in the list
• [ ] sort
• [ ] paste (uncertain, if we can send an entire map element?)

[janisozaur]

I have assigned this to myself for now, as I will try spearheading the effort, but others are welcome to contribute too. Looking at you @Broxzier ;)

For reference, you can see an example of such conversion here: e25c768a3e1ab6c79f2f931cf7ffa1f75d7ce89c. This had all required functionality already in place, but I expect some new code for handling actual commands will be needed. For the commit in question you can see the code for handling it: https://github.com/OpenRCT2/OpenRCT2/blob/3037e6f/src/openrct2/ride/ride.c#L3958 and what it does in the end: https://github.com/OpenRCT2/OpenRCT2/blob/3037e6f/src/openrct2/ride/ride.c#L3803

[Margen67]

Duplicate of #3245?

[janisozaur]

Part of it or a sub-issue. There are more debug tools than just TI. But thanks for pointing it out, I sometimes do create duplicates and in any case it's useful to have them linked even if not a dupe.

[IntelOrca]

One way you could do this, is send the entire tile to the server which replaces the old one. It would reduce parameterising the game command to all the different things it needs to do.

[Broxzier]

@IntelOrca: For large elements (track pieces, large scenery) they cover multiple tiles, so then multiple tiles will need to be sent over. Another issue with that is that when more than one person is working on the same tile, their changes might be overwritten.

[IntelOrca]

For large elements (track pieces, large scenery) they cover multiple tiles, so then multiple tiles will need to be sent over

I suppose you could send all of them, but I hadn't thought about this so maybe it's not such a good idea.

Another issue with that is that when more than one person is working on the same tile, their changes might be overwritten.

I wouldn't worry about that - that's going to cause problems either way, they would only lose one or two changes.

[janisozaur]

@Broxzier in case you are not familiar with our event loop, it goes roughly like this:

1. Player wants to perform some action
2. Player's client validates if it is a sane thing to do
3. If it is, the action gets sent over network to server for being enqueued (without executing it on the client)
4. Server starts processing input queue collected from all the clients, in particular the command sent by us
5. Server validates if the command is a sane thing to do again (never trust remote client)
6. If it performs the action successfully, it is registered and sent out to all connected clients
7. Server finishes processing of current game tick and all the clients get notified the simulation has moved on to new frame
8. All clients should have received the messages sent out by the server in order and start processing local queue of actions
9. Goto 1.

This skips some details, but provides a general idea of how it all works.

Yes, some changes may get overwritten if two users modify the same tile in a compatible way (otherwise the second change would be prevented from happening, as the state has already been mutated), but they would be overwritten atomically, so there's no danger of ending up in some state in between. It will be either player A's or player B's state.

However, until we do refactor of game commands, there's limited space in arguments and it might turn out better to perform what it does now, only from within game command handler.

[Nubbie]

How demanded is it?

Note; #4673 & #4985 should probably get merged before, will probably cause less issues

Edit; @Broxzier Saw on Gitter that quote, but from _where_

[Broxzier]

@Nubbie The paint clipping PR will not have conflicts with this. Quote from janisozaur on gitter:

nedesigns folks requested that as their #1 feature that's missing from MP

_"that"_ meaning this request

I'm curious to see where they ask for this.

[janisozaur]

I asked some people when I was connected to their server. Sadly, it was on another person's computer and I don't have the logs to prove.

[Nubbie]

Doesn't that always happen when someone ask about something? They always want more and more not thinking about the complications?
It's a feature people would say yes to but doesn't mean it would be used, free is good, more is better

_Note; my knowledge about getting TI in MP is that it's hard to get right and in the first place working correctly_

[janisozaur]

This is a valid point, @Nubbie. I asked them this question just now: http://www.nedesigns.com/topic/32012/openrct-advantages-and-disadvantages/?p=713117

Getting TI in MP will be some work, but I think it is quite useful and I would like to see all our tools being available in MP just like in SP. At this point I'm willing to spend some time porting it and so does @Broxzier, so I see no reason why can't we just do it ;)

[janisozaur]

The responses so far from the thread:

^being able to use tile_inspector. I find it quite annoying having to delay my park, because I need to go into tile inspector to do something.

-- nicman http://www.nedesigns.com/topic/32012/openrct-advantages-and-disadvantages/?p=713118

Multiplayer is just incredible, well done.

-- Louis! http://www.nedesigns.com/topic/32012/openrct-advantages-and-disadvantages/?p=713119

The only thing missing from multiplayer is the tile inspector. Other than that, it's perfect.

-- GammaZero http://www.nedesigns.com/topic/32012/openrct-advantages-and-disadvantages/?p=713140

I asked for input from some more acknowledged members of their community, but so far it looks like TI missing is indeed a hurdle to them.

[Nubbie]

@janisozaur
Louis quote doesn't say much about it and Nicman is more from multiplayer in general than NEdesign, but I get the point and if plausable, go for it :p

[janisozaur]

Implemented in #5110