View Issue Details

IDProjectCategoryLast Update
0021437AI War 2Gameplay IdeaSep 25, 2020 9:57 pm
ReporterChris_McElligottPark Assigned ToChris_McElligottPark  
Status closedResolutionno change required 
Summary0021437: Multiplayer: Make ship creation scheduled.
DescriptionThis will also help to avoid desyncs, and in general make desync repair easier. Mostly this already happens, when it comes to things like the players clicking to build ships from the build menu: those already come from GameCommands.

However, we should make it so that ships that are created as a result of Factories building things, or Drones or Transports deploying ships, or guard posts deploying ships, also become GameCommands and thus don't get mixed up between the states on different machines.

In an ideal world we're not running into desyncs with these anyway, but we'll be able to be absolutely sure that the PrimaryKeyIDs are the same between the host and all clients if we handle this stuff centrally. And the delay in the ships coming out will be fairly minimal (and consistent between single player games and multiplayer as well). I think it's maybe 200ms of a delay. And only new for things that are not directly player-caused anyway.

Note that we're not going to do this with shots because we just don't care enough for sync for those, and for anything during mapgen that's already host-only and gets transferred to players later on. And anything that is being spawned by third party factions I think already goes through GameCommands, too -- certainly if it's in long term planning, which IIRC is host-only in the first place.

The stuff popping out of waves I can't recall, that will have to be looked at to see if it needs to be run through a GameCommand or not.
TagsNo tags attached.

Relationships

related to 0021440 resolvedChris_McElligottPark Multiplayer: ship desync detection code. 
child of 0021432 resolvedChris_McElligottPark Multiplayer todo - parent issue. 

Activities

BadgerBadger

Aug 1, 2019 10:59 am

manager   ~0052365

Are there any ship creates that shouldn't be done via this mechanism once it's implemented?

Other pathways not mentioned here include minor faction ship creation, the rebuilding of AI defenses via reconquest, the AI building more turrets, and possibly others.

Chris_McElligottPark

Aug 1, 2019 11:41 am

administrator   ~0052366

"Are there any ship creates that shouldn't be done via this mechanism once it's implemented?"

Not that I can think of, no. We'd be likely to have primary key conflicts, so definitely would want to avoid that.

"Other pathways not mentioned here include minor faction ship creation, the rebuilding of AI defenses via reconquest, the AI building more turrets, and possibly others."

All of those things are scheduled by GameCommands already, to my knowledge. So these already happen in a way that is synchronous (aside from PKID assignment). All of these things are from the long-term-planning thread, IIRC.

Pathways that aren't mentioned that might be of relevance and don't use GameCommands right now: hydra splitting and other ondeath stuff, possibly zombification, possibly remains returning to life or ships being captured from naturalobject if that's changing the PKID.

BadgerBadger

Aug 17, 2019 2:30 am

manager   ~0052574

I'm pretty sure all the minor faction unit creation I wrote (with the exception of Mercenaries) just calls GameEntity_Squad.CreateNew() from the Sim thread. I made it a point not to do stuff like that in LongRangePlanning, since that definitely does require GameCommands for synchronization.

BadgerBadger

Aug 17, 2019 7:56 pm

manager   ~0052575

Last edited: Aug 17, 2019 8:51 pm

One thing that complicates this is that a lot of minor faction code follows the "Create new game entity, then set some external data flags on it" pattern. For example, the Marauders and Nanocaust both track which outpost/nanobot center created a unit, to enforce strength caps. And the AI creates units for Exogalactic Strikeforces then immediately puts the "I am part of exo strikeforce X" flag on it. If the paradigm is now "Call a GameCommand, then get the units 'sometime later'" then that's going to require a significant rejiggering of logic.

Chris_McElligottPark

Aug 19, 2019 12:36 pm

administrator   ~0052577

Option 1:

It will be a substantial rejiggering of logic, but there's a pretty straightforward flow that I can implement for that -- essentially making sure that it does a callback (with a custom string code of your choosing) to a method after creation. But this sort of thing is pretty livable.

Option 2:

This sort of logic is probably rare enough that if it was only run on the host, and then a manual do-full-sync was sent to all the clients, then we have no problem anymore. The data couldn't be entered into the actual sim on the first frame, but the entity and all its data could be created, and then scheduled for entry into the desired place as needed.

TLDR:

It is a rejiggering either way, but there are a couple of options for keeping it less painful. I use both of those methods, in different ways, as part of the lobby sync for instance.

BadgerBadger

Oct 7, 2019 1:32 pm

manager   ~0053530

Last edited: Oct 7, 2019 4:28 pm

I'm intending to simplify some of this by putting some more data on the Entity and not in External code. This is done primarily for ease of stacking improvements, but it will also help this. So instead of needing to do some thing fancy, we can just pass in a "Please set this particular field on the newly created Entity" parameter to the CreateGameEntity GameCommand.

Edit: this is done, the variable is GameEntity_Squad -> int MinorFactionStackingID

Chris_McElligottPark

Oct 7, 2019 4:22 pm

administrator   ~0053534

I'm a really big fan of these changes!

Chris_McElligottPark

Sep 25, 2020 9:57 pm

administrator   ~0058688

Thank goodness we don't need to do this.

Issue History

Date Modified Username Field Change
Jul 31, 2019 4:09 pm Chris_McElligottPark New Issue
Jul 31, 2019 4:09 pm Chris_McElligottPark Status new => assigned
Jul 31, 2019 4:09 pm Chris_McElligottPark Assigned To => Chris_McElligottPark
Jul 31, 2019 4:09 pm Chris_McElligottPark Relationship added child of 0021432
Jul 31, 2019 4:32 pm Chris_McElligottPark Relationship added related to 0021440
Aug 1, 2019 10:59 am BadgerBadger Note Added: 0052365
Aug 1, 2019 11:41 am Chris_McElligottPark Note Added: 0052366
Aug 17, 2019 2:30 am BadgerBadger Note Added: 0052574
Aug 17, 2019 7:56 pm BadgerBadger Note Added: 0052575
Aug 17, 2019 8:51 pm BadgerBadger Note Edited: 0052575
Aug 19, 2019 12:36 pm Chris_McElligottPark Note Added: 0052577
Oct 7, 2019 1:32 pm BadgerBadger Note Added: 0053530
Oct 7, 2019 4:22 pm Chris_McElligottPark Note Added: 0053534
Oct 7, 2019 4:28 pm BadgerBadger Note Edited: 0053530
Sep 25, 2020 9:57 pm Chris_McElligottPark Status assigned => closed
Sep 25, 2020 9:57 pm Chris_McElligottPark Resolution open => no change required
Sep 25, 2020 9:57 pm Chris_McElligottPark Note Added: 0058688