View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0021437 | AI War 2 | Gameplay Idea | Jul 31, 2019 4:09 pm | Sep 25, 2020 9:57 pm | |
| Reporter | Chris_McElligottPark | Assigned To | Chris_McElligottPark | ||
| Severity | minor | ||||
| Status | closed | Resolution | no change required | ||
| Summary | 0021437: Multiplayer: Make ship creation scheduled. | ||||
| Description | This 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. | ||||
| Tags | No tags attached. | ||||
| related to | 0021440 | resolved | Chris_McElligottPark | Multiplayer: ship desync detection code. |
| child of | 0021432 | resolved | Chris_McElligottPark | Multiplayer todo - parent issue. |
|
|
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. |
|
|
"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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
I'm a really big fan of these changes! |
|
|
Thank goodness we don't need to do this. |
| 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 |
