Assigning AI to the same team breaks the mod

Had i quick play of the latest SVN revision in multiplayer, humans vs AI teams and the fix works.
Was not expecting such a quick resolution, thank you.
Honestly it's kindof a severe issue from the perspective of cascading bugs it could cause.
 
Thank you for reporting the bug, and it helped a lot that you had pinned down what causes the issue; we didn't even know there was an issue with team games, and it's been there for half a decade without us modders noticing.

I am new to this mod, so I wasn't sure what was going on at first.

If it wasn't for information provided by @Kajukin and @raxo2222 in this thread, which is linked in my first post. I would not have been able to narrow down the problem.
Thanks to both.

Few players play custom games with teams or co-op multiplayer so bugs which are identifiable in these modes are often unreported.

Unfortunately I had to go back to playing Realism Invictus & FFH2 because there are still a few out of sync issues with this mod in multiplayer, even with events/automation disabled and settings synced. Hopefully the team gets time to play test some more multiplayer/co-op in the future.
 
I think I saw some floats being used in c++ files.
There are defines for them.

@MattCA could remove floats and doubles or at least convert them to integer types before being further processed if game is multiplayer.
 
Last edited:
I think I saw some floats being used in c++ files.
There are defines for them.

@MattCA could remove floats and doubles or at least convert them to integer types before being further processed if game is multiplayer.
Floats and doubles are not the usual issue of OOS errors in Civ4. They are as deterministic as integers.
The most common cause is using unsynchronized functions (like local player) or unsynchronized game state (that is usually UI state) from the synchronized code part or using functions that change the synchronized game state from unsynchronized code (that is mostly UI code but also includes any use of the synchronized random).
A lot of the caching is used from both synchronized and unsynchronized code and therefore can also easily cause an OOS if the result is different depending on a cache hit or miss (which it should not if it is exact caching but some bugs might cause differences there).
Anything from unsynchronized code that is supposed to change game state has to go through net messages, e.g. a button that should have a game effect like destroying or building something. That can sometimes be easy to miss if you don't know exactly which parts of the code are synchronized and which are not.
Apart from that any uninitialized variable or bad pointer access might go unnoticed in single player but causes OOS in multiplayer.

The main issue with OOS errors is that it is hard to pin them down. The game state has grown and not all of it is included in the number that is calculated from a lot of game state that is then compared between the computers to find out if the synchronized game state differs and if you don't catch it right away, it causes more and more changes and it becomes hard to find out the root difference in the OOS log.
 
Floats and doubles are not the usual issue of OOS errors in Civ4. They are as deterministic as integers.
The most common cause is using unsynchronized functions (like local player) or unsynchronized game state (that is usually UI state) from the synchronized code part or using functions that change the synchronized game state from unsynchronized code (that is mostly UI code but also includes any use of the synchronized random).
A lot of the caching is used from both synchronized and unsynchronized code and therefore can also easily cause an OOS if the result is different depending on a cache hit or miss (which it should not if it is exact caching but some bugs might cause differences there).
Anything from unsynchronized code that is supposed to change game state has to go through net messages, e.g. a button that should have a game effect like destroying or building something. That can sometimes be easy to miss if you don't know exactly which parts of the code are synchronized and which are not.
Apart from that any uninitialized variable or bad pointer access might go unnoticed in single player but causes OOS in multiplayer.

The main issue with OOS errors is that it is hard to pin them down. The game state has grown and not all of it is included in the number that is calculated from a lot of game state that is then compared between the computers to find out if the synchronized game state differs and if you don't catch it right away, it causes more and more changes and it becomes hard to find out the root difference in the OOS log.
So @Toffer90 was wrong in thinking, that floats cause OOS in multiplayer.

BUG options is most likely culprit then, as most likely players have different BUG options.
 
So @Toffer90 was wrong in thinking, that floats cause OOS in multiplayer.
They are not an issue because there is no cross platform. When you have multiple platforms there will not be the exact same processor instructions because of different compilers and their optimizers, sometimes not even the same instruction set. And floats are more susceptible to getting differences then because they are stored in a higher resolution in registers compared to memory so depending on what the compiler does you can get very small differences. But small differences break determinism and eventually lead to completely different game states.
Not in Civ4 modding though because it is all the exact same code generated by the exact same compiler with the exact same settings.
That does remind me though that I don't know how deterministic the build result of the compiler used here is. It could in theory produce different code if the participants in the multiplayer match all separately compile the code (even though it is the same code).

EDIT: Unlike in the C++ code there is a chance that Floats can be an issue in Python as that is compiled at runtime and might not always result in the same instruction code. I don't think that is the case though.

BUG options is most likely culprit then, as most likely players have different BUG options.
I vaguely remember that they are synchronized for multiplayer, using the BUG options of the host (at least the game changing ones of those).

EDIT: On a fast search I did not find any code that seems to do that so maybe I remember that wrong (I might have looked at the wrong place though). It is a good idea to make sure all have the same setting in BUG anyway (at least any game state changing BUG options).
 
Last edited:
So @Toffer90 was wrong in thinking, that floats cause OOS in multiplayer.
I thought it could be one reason, not that it was the reason, there are much more likely reasons than that in any case, like having code use active player to change game state so that each player in a multiplayer match change a thing about themselves when only that thing should have been changed for one of the players.
 
EDIT: On a fast search I did not find any code that seems to do that so maybe I remember that wrong (I might have looked at the wrong place though). It is a good idea to make sure all have the same setting in BUG anyway (at least any game state changing BUG options).
It should be there, somewhere in python I think, using modNetMessages. It is quite some time since I last saw the code, but iI can't imagine anyone removed it.
 
It should be there, somewhere in python I think, using modNetMessages. It is quite some time since I last saw the code, but iI can't imagine anyone removed it.
Ah, that code is not actually in the BUG part of the code where I looked but in the Afforess folder. It does look slightly wrong though.
Code:
def changedHideAutomateHunt(option, value):
   GC.getActivePlayer().setModderOption(ModderOptionTypes.MODDEROPTION_HIDE_AUTO_HUNT, value)
   CyMessageControl().sendModNetMessage(MODDEROPTION_EVENT_ID, GC.getGame().getActivePlayer(), int(ModderOptionTypes.MODDEROPTION_HIDE_AUTO_HUNT), int(value), 0)
I don't think that part should call setModderOption as that introduces a time until the arrival of the net message when the local game already considers the option changed but the game on the other computers does not.
Mod net messages are sent to all computers including the sender and including single player so only in the receive part of the net message should the change of the option be done.
 
I actually noticed the original bug before but thought Team Starts were not supported because it throws the timeline out of wack.

If you start with "Personalize Map," the landmark signs flash between your team's colors when you move throughout the map. It's also hard to get teams to spawn together, and Culturally linked starts doesn't seems to work at all.
 
Top Bottom