BULL: Mod Options

[Afforess]

There are some problems with the above.

1. There is no such thing as an MP host in LAN/INTERNET games.

There is... Kinda. Only Player 0 can choose the gameoption and MPOptions in the beginning of the setup.

2. Picking player 0 as the host is problematic: what happens when that player disconnects?

3. Picking the first human player is problematic: when they disconnect control shifts to another player (probably just fine); when another player joins and takes over a lower # slot they take control (probably not fine).

4. I really don't want to build a system of selecting the player in control. First, there's not really a big need for it. Second, it will take a lot of extra work. This has already turned out to be more than I was hoping.

Well, my opinion is irrelevant. Choose whichever option causes the least complications.

 

[EmperorFool]

There is... Kinda. Only Player 0 can choose the gameoption and MPOptions in the beginning of the setup.

If it's anything like a single-player game, the host can choose to be player 1 and either leave player 0 open for a human or assign an AI.

 

[EmperorFool]

Stuck: The only reference to the game start event is in the event reporter itself. The EXE must call this function because the SDK does not. Worse, the OnLoad event doesn't even have that much!

Preliminary Solution: When the game is created, BULL will load the mod options from GlobalDefinesAlt.xml and fall back on the defaults from CIV4ModOptionInfos.xml. When BUG gets the OnLoad/GameStart events, it will send the player's settings to BULL.

Actually, this isn't a problem. If BUG isn't present BULL shouldn't be asking it for settings anyway. Crisis averted!

 

[EmperorFool]

It looks like updateHuman() is called from quite a few places:

• CvInitCore::reassignPlayer(PlayerTypes eOldID, PlayerTypes eNewID)
• CvInitCore::resetPlayer(PlayerTypes eID)
• CvInitCore::setType(GameType eType)
• CvInitCore::setMode(GameMode eMode)
• CvInitCore::setSlotStatus(PlayerTypes eID, SlotStatus eSlotStatus)
• CvInitCore::read(FDataStreamBase* pStream)
• CvPlayer::reset(PlayerTypes eID, bool bConstructorCall)
• CvPlayer::read(FDataStreamBase* pStream)

The slot status looked promising, but it's called from a lot of places that don't see entirely relevant. Is there some other function that is clearly called only when a human reconnects? Also, how will this look from the Python side? Does the player load a game? If that's the case I can do the same as above.

 

[Afforess]

Could you fire an event only when the human status in updateHuman is changed?

 

[Afforess]

Just out of curiosity, how far along is this?

 

[EmperorFool]

I have no time to devote to BUG during the week except scanning the forums, and this weekend was a little busy. The networking (was easy) and the storage (also easy) code is done. BUG is aware of which options are synced and tells BULL when their values are changed. The tricky part of sending the initial values remains. This is why I started the discussion about how to choose who decides the shared options.

Individual player options are also tricky due to rejoining after a disconnect/OOS.

To recap, the (pre)start and load events are triggered by the EXE so either this feature will require BUG (might not be so bad) or we wait until I can figure out the best place for BULL to send the values. This point must be after the above events because they are when BUG gets initialized, and BULL cannot ask BUG for the values before BUG has been initialized.

For the non-shared options I cannot find a good place to sync when a player rejoins. One option is to have the player continue using whatever settings it had when its owner disconnected until the beginning of the next turn or they change a value, but that also forces BUG into the issue.

Could you perhaps ask jdog if he has any ideas here? He knows the SDK far better than I do, especially when it comes to issues with players and the AI.

 

[Afforess]

For the non-shared options I cannot find a good place to sync when a player rejoins. One option is to have the player continue using whatever settings it had when its owner disconnected until the beginning of the next turn or they change a value, but that also forces BUG into the issue.

I wouldn't care if it just used the existing in-game player(s) settings, and just informed the joining player which settings have been altered.

Could you perhaps ask jdog if he has any ideas here? He knows the SDK far better than I do, especially when it comes to issues with players and the AI.

Sure, but his time is probably even more limited than yours.

 

[jdog5000]

Sorry guys, I don't have any ideas beyond what you're already looking at ...

 

[Afforess]

Okay, I would really like to start using this, regardless of what state it is in.

As for the problem of syncing Game-Wide Options, I came up with two scenarios here:

Both Scenarios Occur when CvPlayer::updateHuman is called:

Scenario 1 (Best Case)
2 Players are in-game with identical settings, and 1 player is joining. The joining player adopts the settings of what the majority have. Because 66% of the players have option X, the new player is switched to option X.

Scenario 2 (Worst Case)
1 Player is in game, 1 is joining. There is no identifiable majority. The joining play simply adopts all the options of the in-game player(s). They are both notified, and can change them from there.

Scenario 3
No players are joining, and update Human is fired for an unknown reason. Since all players have identical settings, nothing changes.

Even in the worst case, all the players are notified, and can easily switch them to what is desired. Since game-wide options are already in the extreme minority (BUG only will have 1 - Global Warming), it isn't a hassle to change it.

At least, that's my 2 .

 

[NotSoGood]

I just found this thread. Has there been any advance on this during the last month?

 

[EmperorFool]

Not since my last post. Work has me pretty well occupied except for posting to the forums on occasion. I still hope to complete this sometime soon. I think I have a solution to the problems discussed above: when a player rejoins the game, the first time their PC needs an option value it would send a request that all players broadcast their settings again. I don't know if that would work exactly, but at least it's something to try.

My main concern is that whatever I end up doing may cause more OOS issues, and these would be unfixable due to how Civ4 works. Given that fear, it's been harder to muster the energy to write that code.

 

[Afforess]

If you feel that the game-wide options are too daunting, you can always opt to not add those. The player-by-player options are more important, and I could just switch back to using Gameoptions like I have been.