Event timing

[Pazyryk]

Does PlayerDoTurn run before or after city yields have been added for the turn?

 

[Spatzimaus]

Pretty sure that yields are added to a city at the END of the turn (after the end-of-turn serial event for the active player, in your case), not the start of the following turn; whether it happens before the PlayerDoTurn for the next player or not is something else, but I'd guess that the event happens after your yields are adjusted.

 

[Pazyryk]

Pretty sure that yields are added to a city at the END of the turn (after the end-of-turn serial event for the active player, in your case), not the start of the following turn; whether it happens before the PlayerDoTurn for the next player or not is something else, but I'd guess that the event happens after your yields are adjusted.

You think so? But I always thought that if a building completed, that you would have already gotten the benefit of that building on the first turn you see it. But I could easily be wrong. (I could test this of course, but I thought you might save me the 15 minutes.)

What I've done is put all of my "yield effects" together in two functions, UpdateCityEffects() and UpdateGlobalEffects(). The first adds/removes buildings or other city manipulations, the second add/removes policies, techs and such. These functions can be called at any time (when "something happens") so that the effects can be seen immediately in the UI. But they also need to be called once per turn to account for any other changes. This should happen before but as close to the actual yield additions as possible (some of my mod effects could be an action by one player that affects another's yields, like making an inter-civ "trade route"). But I'm not sure when that is.

With Gedemon's strange observation that PlayerDoTurn fires for player 1 before ActivePlayerTurnEnd, I wonder if it is even possible that yields are applied for player 0 right after PlayerDoTurn for player 1.

It has to work for all players, so I'm kind of limited to either PlayerDoTurn or catching the player after their turn (at the start of the next player's turn). With PlayerDoTurn (player 1) firing before But I guess the former would be better

 

[Spatzimaus]

You think so? But I always thought that if a building completed, that you would have already gotten the benefit of that building on the first turn you see it.

It's possible that it's the start of the following turn, but I remember having to deal with the end-of-turn recalculation issues for Happiness, and at the time I thought I tested this to see if I could fix it by using the start-of-turn event for the following AI players with no luck.

In the particular case of buildings, it could easily be split, where the production is added to the building at the end of the turn, but the check to see if the building is complete could still happen at the start of the following turn. Just make your GameEvent print out how many shields player #0 has towards his current production in his capital. Then see which player's turn shows the first increase. Repeat for gold, research, food, culture, great person points, golden age progress, etc.

What I've done is put all of my "yield effects" together in two functions, UpdateCityEffects() and UpdateGlobalEffects(). The first adds/removes buildings or other city manipulations, the second add/removes policies, techs and such.

Interesting. The UI automatically catches updates for most yields and such, except that I've had issues with Happiness from my Priest/Empath specialists (since those are tied to a hidden building awarded at the end of the turn), but I don't try to do so much during the other AI's turns.

With Gedemon's strange observation that PlayerDoTurn fires for player 1 before ActivePlayerTurnEnd, I wonder if it is even possible that yields are applied for player 0 right after PlayerDoTurn for player 1.

Yeah, that would definitely be possible. But again, that's easy enough to check; just have each PlayerDoTurn print the total gold for player#0, and see where it goes from the amount you had on turn X to the amount you have on turn X+1.

 

[Pazyryk]

Spatzimaus, another question while I have you in the thread:

Is there any hard-coded or practical limit to the number of buildings I can (or should) use for various yield modifiers? Let's say that I have a lot of different things that could contribute to a gold percent bonus/penalty. Let's say that these all add up to +63% for a player on a particular turn. Would it work to create a single hidden building with a +1% gold modifier, then add 63 instances of this building? (Sure, I could round to the nearest 5%. But is there any reason to do so?)

 

[Spatzimaus]

Would it work to create a single hidden building with a +1% gold modifier, then add 63 instances of this building?

Yes, it would; there's usually no reason to have multiple denominations when you can just stack more instances of a 1% or +1 shift. My mods use stackable hidden buildings for this, with SetNumRealBuildings, except that I mostly use flat +1 increases instead of percentages (with the sole exception being gold in my "Head Start" mechanism for late-era starts). I primarily use this mechanism for my Priest and Empath specialists' Happiness boost, but I've also done this for other yields to handle other temporary bonuses (like the Seasons focus in the Mythology mod, where it rotates which two yields the shrine boosts depending on the turn number). It's worked very well.

The first thing I'd suggest is modding CityView.lua to hide these buildings. In my mod, any building with the <NoLimit> flag set for its building class is hidden automatically, although I could also toss a Cost check in there as well. If you don't, then the buildings will be shown in the city view; this wouldn't be terrible, of course, but the UI doesn't display how many instances of a building exist, so you wouldn't be able to tell the difference between 1 copy and 63 copies in a city. (I also drop these buildings from the Civilopedia.)

As to how it works in practice? The AI occasionally makes mistakes with it. Because it's a building, the AI will take the extra yield into account when deciding whether to build something, which is good, but it won't understand that that yield will be taken away a few turns later. So it might commit to building a World Wonder (which normally have a 50-turn cutoff, as in, if a city would take more than 50 turns to complete the wonder it won't even try to start it) in a city with a temporary production boost, and then it can't change its mind once that boost goes away and might be stuck on a 100-turn build action. Granted, you already run into this same thing with Golden Ages in the standard game, but if you're using this hidden building mechanism heavily, it might occur much more often.
But generally speaking, the AI handles it pretty well; at least, it's no worse than the AI handles anything else in this game.

Now, whether or not you'd want to use multiple types for each yield depends what exactly you're using it for. For instance, in my mods, I've got four things that can temporarily boost Happiness behind-the-scenes:
> Priest and Empath specialists
> The Head Start mechanism for late-era starts
> Researching the Transcendent Thought tech at the end of the Ascension tech tree
> Certain rare events can give your empire a permanent +1
At the moment, the first three are added together to determine how many copies of my +1 Happiness building I need to spawn in each city, and the fourth is handled separately. But I'm now looking at splitting the first type up further, because I'm trying to teach the AI how to handle Priests/Empaths, and for that, I need to know how many of them I'm using at any given moment. Being able to just count up instances of a building is MUCH more convenient than looping over all cities, looping over all buildings, and counting up the slots of that type. So creating two or three different building types with the same +1 Happiness effect is not a bad idea, if you need consistent bookkeeping for other reasons.

 

[Pazyryk]

Great. Thanks!

I have effects spread out all over the place (both +'s and +%'s) and I'm currently consolidating them down to one place (OK, two places: UpdateCityEffects() and UpdateGlobalEffects()). Those functions are just going to go through a bunch of different stored values that change in real time (associated with leaders and other things that change) to calculate a single total +gold, +%gold, etc. and apply in one place. So then I just need a set of buildings like: BUILDING_GOLD_PLUS_1, BUILDING_GOLD_PLUS_1_PERCENT, and so on (and negative versions too, where they work).

 

[Spatzimaus]

Those functions are just going to go through a bunch of different stored values that change in real time (associated with leaders and other things that change) to calculate a single total +gold, +%gold, etc. and apply in one place.

Personally, I'd suggest splitting it up chronologically instead of by scope. As in, some things will only change once per turn, some will change whenever the players do X (which might be multiple times per turn), and some things will only rarely change during a game if at all. This was the trap I fell into in my own mod; I ended up wasting far too much time checking variables that I KNEW wouldn't be changing often, because they shared the same structure as variables that would change constantly.

So then I just need a set of buildings like: BUILDING_GOLD_PLUS_1, BUILDING_GOLD_PLUS_1_PERCENT, and so on (and negative versions too, where they work).

Right. The only one whose negative version doesn't work is Happiness, although you can get around that if you use a hidden policy system in your mod (like I do in mine), but that sort of system has all sorts of other drawbacks so I wouldn't recommend it if you'd only use it for this. But yes, you'd want the array of buildings like that for the four yields, happiness, culture, and whatever else you feel like throwing in (golden age length modifiers, great person production, etc.)

 

[Pazyryk]

use a hidden policy system in your mod (like I do in mine), but that sort of system has all sorts of other drawbacks so I wouldn't recommend it if you'd only use it for this.

I do and it was remarkably easy. I just set policy cost at 99999999 (or something like that) and do all policy advancement via Lua, using my own formula.

 

[Spatzimaus]

I do and it was remarkably easy. I just set policy cost at 99999999 (or something like that) and do all policy advancement via Lua, using my own formula.

That policy cost field doesn't seem to be used for anything internally; I've never seen it make a difference. And I was referring to the part where the AI would get stuck trying to take a policy it couldn't ever choose because of its branch biases, which'd require an override. If you're handling all Policy advancement yourself then this isn't a problem, but anyone trying to take advantage of this hidden policy mechanism in the existing engine will run into all sorts of other issues.

 

[Pazyryk]

UPDATE Defines SET Value=999999 WHERE Name='BASE_POLICY_COST';

...the Defines cost, not the one in Policies table. But I forgot about all the UI and AI work I did, so not as easy as my statement indicated.

 

[Spatzimaus]

...the Defines cost, not the one in Policies table.

Ah, okay, thought you were talking about the <CultureCost> field in the Policies table, which does nothing. (How stupid is that?) So yes, that 9999999 will disable the normal culture cost mechanism entirely. If you're completely overhauling the Policy selection mechanisms, then sure, that'll work.

But I forgot about all the UI and AI work I did, so not as easy as my statement indicated.

Yeah. I mean, I understood that you'd changed all sorts of other things in this area, I just figured that if someone other than us ever read this thread, I didn't want them thinking it was a trivial change they could use in their own mods. There were a bunch of times where I almost decided to do what you did and toss the whole vanilla mechanism out and code up my own version, but I was trying to stay as close to the baseline logic as I could, if only so that my mod would be compatible with other people's ones.