help me with new palace idea, please

[EmperorFool]

Normally, yes. Technically, the active player is the player sitting at the computer. For multiplayer games, each human is the active player on their own PC. For hot seat and BPEM games, the active player is the human player whose turn it is.

I just found a second case where the active player is passed. When you conquer a city and have the option to liberate it, it passes the active player to CityAcquiredAndKept. I just changed BULL to pass in the new owner. Given that the event fires before the city changes hands, this makes sense.

 

[The_J]

That can't be...somehow.
I've done a modcomp, which uses iPlayer as the owner of the city.
Somebody complained, that this produces an error (-> i thought, the variable could mention the last owner), and then another modder said, that he uses this variable to give a new conquered city culture from the conquerer, and that this works.

 

[EmperorFool]

So what should this player be? The conqueror? What about when the city isn't conquerored? It is fired in six places in the SDK:

1. Kept after cultural flipping
2. Kept after conquest
3. Kept after conquest by an AI
4. Kept after conquest when there's no option to raze or liberate
5. Liberated after conquest
6. Gifted to an AI (no choice to disband)

2-4 should be the same, but they are fired from different locations in the SDK.

The bug that was first fixed was for case #3: it was passing the active player which would not be either player in an AI-AI war. That is clearly incorrect. I changed it to pass in the new owner.

The new bug (or maybe it isn't) is in case #5: again it was passing in the active player. Given that this is in the popup-handling code and AIs don't get an option to liberate conquered cities, the conquering player must be the active player.

Are you saying that modders depend on it being the conquering player? I can see some logic in that. Cases 1-5 relate to a conquered city (#1 is by culture but similar). Case #6 doesn't; what should be passed here?

 

[The_J]

i don't see the problem with 6.
The variable should contain the playernumber, to whom the city is gifted to.

 

[God-Emperor]

To anyone writing onCityAcquiredAndKept handlers: how are you treating the ePlayer parameter? The SDK seems to always pas the active player. I fixed one place to make it the new owner, but I just found another place (gifting) that passes the active player. I think I'll fix this second call in BULL and pass it along to the UP.

I have to ask, what "ePlayer" parameter?

That paramter is an argsList which the base BtS CvEventManager splits up via "iOwner,pCity = argsList". So it is not "ePlayer" it is "iOwner".

The value of iOwner ought to be the owner of the city.
Who is the owner of the city? The player that kept it.

 

[EmperorFool]

The same parameter is called iPlayer in CvEventReporter, ePlayer in CvDllPythonEvents, and iOwner in CvEventManager.py.

Looking at how liberation via conquest occurs, here is the sequence of events:

1. CityAcquired, eOldOwner is loser
2. CityAcquiredAndKept, eOwner is conqueror
3. CityAcquired, eOldOwner is conqueror
4. CityAcquiredAndKept, eOwner is new owner

I guess that makes sense. I didn't think the event pair would be fired twice during liberation, but now that I see that I will revert my latest change.