Variable Tick Rate

[Reznal]

Variable tick rate implementation

• Standard VTR of 1 on any map that has any players
• Any other maps run at 15 (ticks every 15 ticks instead of every 1)
• Keeps track of player count on each map now via a new command

Updates:

• Now correctly update map player counts on unexpected disconnects
• Handled Projectile and WorldItem VTR
• No longer counts a player as on a map if they have the world map open (Need to test Odyssey scenarios)

NOTE: This will not work by itself, it needs other general 1.6 updates as found in my other PR
I separated this one as I think it could have some discussion around the best way to implement it.

[SokyranTheDragon]

A fix for Projectile and WorldObject classes is still needed.

[SokyranTheDragon]

WorldObject could probably work if it was hardcoded to a tick rate of 15, no point in adding a system to track which world objects are selected.

[Reznal]

A fix for Projectile and WorldObject classes is still needed.

I didnt notice these before :)
I agree, WorldObject can probably be hard coded at 15, projectiles can probably use the player per map system
I'll have a look into them

[SokyranTheDragon]

Does this system handle players switching the view to the world map? I personally wouldn't consider a player checking the map as being active on a map.

[SokyranTheDragon]

(This message is mostly me thinking about the future, it's not a request to change anything in here. Just discussing plans for the future.)

I've got to say, this is a good system, but I personally feel it could be expanded to include periodically sending player camera info (once every few seconds at most if camera position/zoom level changed).

Perhaps also configurable? Option to sync maps only or maps and camera data. As well as frequency of re-sending camera data.

My reasons for syncing camera positions:

• It would allow us to finally properly sync unnatural corpse event (since it relies on the entity not being seen by the player)
• It would allow players to benefit from the VTR on maps they are always active on
• We could expose this to the API, allowing other mods to benefit from this system

Perhaps we could make it work similar to how I've handled it in my Rocketman fork?

I've use this simple data structure with a dictionary, which (excluding the map) we could perhaps use instead of just the player count on a given map:
https://github.com/SokyranTheDragon/RimWorld-RocketMan/blob/c9344f31dda0dec60a91a25632587a27ed97fa37/Source/Cosmodrome/Core/Multiplayer/MultiplayerCameraLister.cs#L15-L38

[Reznal]

Does this system handle players switching the view to the world map? I personally wouldn't consider a player checking the map as being active on a map.

Currently yes, I'm not sure it would be worth it changing and informing everyone they are no longer on a map if they open the world map?
I could implement the change though. Would have to see how it handles space maps also, assuming they are counted as maps on a different layer so should be fine.

[SokyranTheDragon]

Would have to see how it handles space maps also, assuming they are counted as maps on a different layer so should be fine.

I believe that space maps use WorldRendererUtility.CurrentWorldRenderMode of WorldRenderMode.Background, while watching the world uses WorldRenderMode.Planet. Or to simplify it, world is selected if WorldRendererUtility.WorldSelected is true, and space maps if WorldRendererUtility.WorldBackgroundNow is true.

[SokyranTheDragon]

Actually, looking back at my old Rocketman code made me think... Does this code properly handle player disconnections? If some were to join, open a map, and then disconnect, would the counter go down as expected?

[Reznal]

Actually, looking back at my old Rocketman code made me think... Does this code properly handle player disconnections? If some were to join, open a map, and then disconnect, would the counter go down as expected?

I don't think it will, another thing I'll have a look at

[Reznal]

(This message is mostly me thinking about the future, it's not a request to change anything in here. Just discussing plans for the future.)

I've got to say, this is a good system, but I personally feel it could be expanded to include periodically sending player camera info (once every few seconds at most if camera position/zoom level changed).

Perhaps also configurable? Option to sync maps only or maps and camera data. As well as frequency of re-sending camera data.

My reasons for syncing camera positions:

• It would allow us to finally properly sync unnatural corpse event (since it relies on the entity not being seen by the player)
• It would allow players to benefit from the VTR on maps they are always active on
• We could expose this to the API, allowing other mods to benefit from this system

Perhaps we could make it work similar to how I've handled it in my Rocketman fork?

I've use this simple data structure with a dictionary, which (excluding the map) we could perhaps use instead of just the player count on a given map: https://github.com/SokyranTheDragon/RimWorld-RocketMan/blob/c9344f31dda0dec60a91a25632587a27ed97fa37/Source/Cosmodrome/Core/Multiplayer/MultiplayerCameraLister.cs#L15-L38

I did initially have something like this, only taking into account the players mouse position though, camera is definitely a better way to do this.
I originally changed it to this as the resyncing I had implemented to take into account the regular changes by position wasn't working and I wanted to move on to something else :)

[Reznal]

@SokyranTheDragon
I have made 2 more commits

• Now correctly update map player counts on unexpected disconnects

• Handled Projectile and WorldItem VTR

• No longer counts a player as on a map if they have the world map open (Need to test Odyssey scenarios)

• I like the idea of changing to a camera based system, however for now I think this does the job and allows us to move on to other issues.

[Reznal]

I've just noticed these are already defined in Thing, we could probably use those.

[SokyranTheDragon]

Thinking a bit more about this - perhaps we should change this in the future to keep a HashSet of player IDs, rather than a count of player? It would be a tad bit safer in case of unexpected issues - just check if there's an ID of player who's disconnected, or perhaps the same player ID on multiple maps, etc.

Again, just like with syncing the camera, this is mostly me sharing my ideas. Low priority and all that.

[Reznal]

Thinking a bit more about this - perhaps we should change this in the future to keep a HashSet of player IDs, rather than a count of player? It would be a tad bit safer in case of unexpected issues - just check if there's an ID of player who's disconnected, or perhaps the same player ID on multiple maps, etc.

Again, just like with syncing the camera, this is mostly me sharing my ideas. Low priority and all that.

I like this idea.
I had thought about creating a static map somewhere that keeps track of playerId & mapid which would allow for an easy recalculation if ever needed but I like your idea better.
I may implement this soon as I'll have to revisit this for Odyssey potentially.