My new
mod that adds victory conditions seems to conflict with the
dll, and I have been unable to find out why.
I now know why it's doing it, but not why with only a replacement DLL - my DLL makes no changes to the way victory conditions are computed - so the following should be identical in an unmodded game core DLL (unless Firaxis have changed it and not updated the SDK which is always a possibility!)
At the end of every major player's turn, the game core loops the VCs in turn (if enabled during setup) and then loops each major player to see if they have met the VCs conditions. This doesn't happen until 10 turns have passed (which is why victory is always on turn 11). If multiple players have won via one or more VCs, then a player/VC combination is chosen at random as the ultimate winner.
Now, the way VCs are computed is really, really silly. The game core assumes the VC
has happened, and then tests to see if it hasn't - checking each of the possible standard winning methods (domination, cultural, pop percent, project race, etc) in turn. Because your new VCs don't enable any of the possible winning methods, the game core doesn't bother to check if they've not been met, so it just drops all the way though the testing code and at the end goes "yep, that's a winning solution". So on turn 11 every player wins by both economic and religious VC, and the game then choses one at random as the actual winner.
You can fix this by setting WinsGame = false in the XML for the two new VCs - as this will stop the game core testing for that VC itself, but won't stop Lua setting it as a VC
Code:
<WinsGame>false</WinsGame>
There is also a dedicated GameEvent that fires for Lua to check for a VC, so you'd be better hooking that than PlayerDoTurn
Code:
GameEvents.GameCoreTestVictory.Add(CalculateEconomicVictoryProgress);
GameEvents.GameCoreTestVictory.Add(CalculateReligiousVictoryProgress);
)
