Removing Policies Without Resetting Policy Costs

Vicevirtuoso

The Modetta Man
Joined
May 14, 2013
Messages
775
Location
The Wreckage, Brother
Apparently, using pPlayer:SetHasPolicy(iPolicy, false) causes the cost of the player's next social policy to reset to the default culture cost the next turn. Is there any way to avoid this? I've tried the old pPlayer:SetNumFreePolicies(1), pPlayer:SetNumFreePolicies(0) trick, and it doesn't seem to be working anymore.
 
If anything removing a policy is gonna reduce the cost of next social policy.
SetNumFreePolicies had never any sense to use upon removing a policy, because the trick is reducing the CoSP (cost of next social policy) by 1 (or more if needed).

CoSP is based on number of social policy adopted - SPA.
You use a trick, you have SPA = -1 (SPA - 1);
You add a (dummy/normal) policy, you have SPA = 0 (SPA + 1);
You remove a policy, you have SPA = -1 (SPA - 1);
That's why if you have dummy policy that works only under condition (ex. at war) you make two dummy policies (one with effects and second without - empty) and then you use a trick (once), add one policy and then every turn you set one policy to true and other to false (depends on condition), to keep the SPA/CoSP the same.

The same with removing normal policies, you have to prepare empty dummy policies to control the cost.

You might try to make your question more clear next time. To avoid what? There isn't something like default culture cost - define next time.
 
You might try to make your question more clear next time. To avoid what? There isn't something like default culture cost - define next time.


As in, the base cost of adopting your first social policy before the multipliers for number of policies adopted kicks in.

One of the mods I tested did indeed have a system which swapped between one dummy policy and another, so if what you said is true, this issue shouldn't have occurred there. I'll test it some more later when I get home.
 
Do you have a specific use case? Just compared CvPolicyClasses.cpp (where all this happens) between 3.124 and 3.276 and there are no material differences (just a few extra methods for newly added features) between the two code bases - so it's either not changed, been like this for a long time, or being caused by something else.
 
Alright, so you indeed have to make sure that you do not give the player another free policy when you change or remove policies; do so only when adding them.

And apparently, the game doesn't like when you iterate over a table containing certain policy IDs and set them that way. When I explicitly defined which policies to set to true and false in the function and removed the SetNumFreePolicies lines, it worked fine.
 
Has anyone else experienced an issue where giving free policies using the
Code:
player:SetNumFreePolicies(1)
player:SetNumFreePolicies(0)
player:SetHasPolicy(iPolicyID, true)
method causes the social policy "choose next social policy" notifications to no longer appear, even though the game appears to be correctly calculating the cost of the next social policy ?

I've been using LastSword's method of adding a dummy policy whenever a "real" policy is being taken away, and this seems so far as I have found to be the only reliable method to not break the social policy cost calculation whenever any policy is ever taken away.

Only adding policies (and never thereafter removing any of them) using the "free policies" trick seemed never to have any negative effect on the social policy costs, but does (at least for me) seem to be breaking the notification pop-up system. I can easily code around it, but if no one else has experienced this issue then I think I need to figure out what I am doing wrong.

Full disclosure: on 1st game set-up I am giving each major player a basket-boatload full of free dummy policies using the "free policies" trick mentioned earlier for each and every one of these dummy policies I give to the major player. Then I can swap a dummy for each of the dynamic effect policies I need to add to give a specific dynamic effect amount. See here to understand what I am trying to accomplish (that thread does not have a link to the latest version of the code I am using). The Oops alert mentioned in the OP of that thread is related to some of these issues regarding social policy costs and pop-up notifications.

I've attached the current version of the Dynamic Policy Effects mod in case that is of use to tell me what I'm doing wrong here wrt social policy notification and giving out policies, etc.
 

Attachments

So, in experimentation with this, I have found a couple "interesting" results:
  1. Giving more than 23 free dummy (hidden, player-specific, etc.) social policies to the human player breaks the pop-up notifications for "May Adopt Policy"
    • using the method of giving the policies by the Free=1, Free=0, Add A Dummy Policy does not break the next social policy cost calculation so far as I have been able to determine.
  2. Even using LastSword's method of giving dummy stand-ins, and then swapping out the stand-in for the "real" social policy you wish to give based on real-time conditions will also break the human player pop-up notification if too many swap-outs have occured. I have not been able to determine the minimum number of these swap-outs that triggers the failure of the pop-up notification.
    • Using LastSword's method of giving dummy stand-in policies and then swapping these in and out for "real" policies does not break the next social policy cost calculation so far as I have been able to determine, even when an absolutely huge number of policy swaps are occuring or have occured.
  3. Giving out a set of free policies via iterating through a table of listed policies or through a "for....do" loop does not have any different effect than merely hard-coded listing of the policies to be given.
    • This sort of thing
      Code:
      for i = 1, iDummyPoliciesToAddLimitNumber do
      	local iTempPolicyToGive = DummyStandinPolicies[i]
      	if pPlayer:IsHuman() then
      		if bDebugMode then print("DummyStandinPolicies policy to be given = " .. GameInfo.Policies[iTempPolicyToGive].Type) end
      	end
      	pPlayer:SetNumFreePolicies(1)
      	pPlayer:SetNumFreePolicies(0)
      	pPlayer:SetHasPolicy(iTempPolicyToGive, true)
      end
      Seems to have no different effect than this sort of thing:
      Code:
      pPlayer:SetNumFreePolicies(1)
      pPlayer:SetNumFreePolicies(0)
      pPlayer:SetHasPolicy(GameInfoTypes.POLICY_DUMMY_STANDIN_001, true)
      pPlayer:SetNumFreePolicies(1)
      pPlayer:SetNumFreePolicies(0)
      pPlayer:SetHasPolicy(GameInfoTypes.POLICY_DUMMY_STANDIN_002, true)
      pPlayer:SetNumFreePolicies(1)
      pPlayer:SetNumFreePolicies(0)
      pPlayer:SetHasPolicy(GameInfoTypes.POLICY_DUMMY_STANDIN_003, true)
 
I am able to 'fix' the issue by forcing the social policy pop-up during turn processing:
Code:
function PlayerSocialPolicyPopUpNotification(iPlayer)
	local pPlayer = Players[iPlayer]
	if pPlayer:IsHuman() then
		if pPlayer:GetJONSCulture() >= pPlayer:GetNextPolicyCost() then
			pPlayer:AddNotification(NotificationTypes.NOTIFICATION_POLICY, "SocialPolicy" ,"May Adopt Policy", -1, -1)
		end
	end
end
GameEvents.PlayerDoTurn.Add(PlayerSocialPolicyPopUpNotification)
And it functions for the human player just like the Notification the game would otherwise generate. I still seem to have a little massaging to do of the actual text showing from the Notification in-game.

My concerns were:
  1. I was doing something stupidly wrong since no one else was responding with any of "yup, me too!", "Nope. Never had that", or "What in the world are you talking about?"
  2. While I can fix the issue for the human player, is this also breaking something re Social Policies for the AI that is not directly apparent.
#2 is still a bit of a concern even though so far I have not seen anything of that nature. But I have not had opportunity to make any full-out whole-game test looking for this sort of thing. Nor am I sure yet how to best go about making a true test wrt AI on the possible non-obvious consequences.
 
I supposed that that workaround wouldn't block the player from progressing to the next turn, but then, perhaps that's an inherent quality of the notification type.

I've informed Pope Gazebo of this issue in the hopes that he can shed some further light from the DLL side of things.
 
Back
Top Bottom