DLL - Various Mod Components

[Serp]

Have two improvements, one with the higher yields but un-buildable. Use the PlotBuilt event (or whatever it's called) and when a suburb is built next to a city, swap it for the one with the higher yield.

The problem with adding columns to the database tables is that they are totally specific - they do X and only X, if another modder wants to do Y you have to add another column. The beauty of events is that they are generic. I can implement them such that not only are X and Y both possible, but also A, B and C tomorrow and L, M, N and O the week after (which we haven't even thought of yet!)

Yes you are right
Thank you for the workaround

 

[whoward69]

v77 uploaded to the web site and GitHub

• "Units - XP Times 100" - micro-mod switches on the 2dp accuracy in unit XP calcs
• "Units - Tough Nuts" - example of giving units >100 HPs
• "Units - Missiles No Supply" - example of setting units NOT to count against supply limits
• "Policy - Diplomatic Marriage" - example of how to use a trait bonus as a policy bonus
• "Belief - One With Natural Wonders" - example of how to use a trait bonus as a belief bonus
• "UI - Unit List Enhancements" - updated to display units with >100 HPs correctly
• "UI - Condensed Promotions" - fixed a typo bug
• "DLL - Various Mod Components" - yeah well ... if you don't know what this is for by now ...

Also BUGFIX_DUMMY_POLICIES ...

Spoiler BUGFIX_DUMMY_POLICIES :

BUGFIX_DUMMY_POLICIES fixes various issues with using orphaned policies. Thanks to LeeS for assistance with this.

Firaxis assume that EVERY policy is attached to a branch, either directly (Policies.PolicyBranchType is not NULL),
or indirectly (by reference from PolicyBranchTypes.FreePolicy or PolicyBranchTypes.FreeFinishingPolicy)

However, modders (being sneaky little buggers) have discovered that policies don't need to be attached to branches
(that is they are orphans) and can use them as dummy policies as a way of getting access to the bonuses in the
Policies table for civilization unique attributes (UAs) etc. They (mainly me!) have also discovered an exploit
to grant policies without affecting the cost of the next policy (the "pPlayer:SetNumFreePolicies(1); pPlayer:SetNumFreePolicies(0)" magic).

This however leads to a number of issues
- buildings (eg Prora) that give "happiness per X policies" include the orphaned policies in the count X
- the player's overall score includes a (small) amount per policy adopted, this also includes orphaned policies
- orphaned policies are included in the replay data, which can lead to weird roller-coaster looking graphs
- the player's count of remaining polices that can be adopted gets skewed, resulting in the loss of the Adopt Policy notification

We could write a method that calculates if a policy is an orphan (doesn't reference the PolicyBranchType
table either directly or indirectly) but that would then break every existing mod that uses dummy policies and
the free policy exploit.

So the adopted solution is to add a "Dummy" column to the Policies table to explicitly flag a policy as a dummy.
This way, existing mods are unaffected and new mods can use the new database column (along with the new Grant/Revoke/Swap API)
and not have to bother with the free policy exploit. Happiness all round

Standard Lua API method changes
- pPlayer:GetNumPolicies() takes an optional parameter bExcludeOrphans (defaults to the BUGFIX_DUMMY_POLICIES configuration value)

In addition, three new pPlayer Lua API methods are provided - GrantPolicy, RevokePolicy and SwapPolicy

local bGranted = pPlayer:GrantPolicy(iPolicy, bFree)
If pPlayer has NOT already adopted the specified policy, they will be granted it. Use bFree to indicate if this is a free policy (ie should NOT increase the culture cost of the next policy).
Returns true if the policy was granted as a result of this call (ie returns false if pPlayer already has the policy).

local bRevoked = pPlayer:RevokePolicy(iPolicy)
If pPlayer HAS already adopted the specified policy, it will be revoked (ie they will no longer have it). This method preserves the culture cost of the next policy.
Returns true if the policy was revoked as a result of this call (ie returns false if pPlayer does not already have the policy).

local bSwapped = pPlayer:SwapPolicy(iPolicyNew, iPolicyOld)
If pPlayer has NOT already adopted the specified NEW policy AND HAS already adopted the OLD policy, then the old policy is revoked and the new policy granted.
If the old policy was free, the new policy will also be free; consequently this method preserves the culture cost of the next policy.
Returns true if the policies were swapped as a result of this call.

A mod should not mix Grant/Revoke/SwapPolicy methods with SetNumFreePolicies/SetHasPolicy methods for the same (group of) policies.

 

[Lynnes]

Very nice update, I will use all of the new mods!

Well, except for UI - Unit List Enhancements, since I never got it to work and haven't found out the reason yet.
I don't use any other mods that alter the UnitList.lua..


Hm.. I just tried it with only the VMC DLL + Unit List Enhancements and no EUI, and I still don't see any new columns for XP or HitPoints. Could it be that it depends on another PNM-mod?

 

[whoward69]

Just tried it (DLL + UI Enhanced Unit List only) and no errors and I see the two additional columns.

Check the Lua.log file, you should have a line with "[timestamp] UnitList: This is the modded UnitList from 'UI - Unit List Enhancements'"

 

[Lynnes]

Oh no, I just checked the mod's screenshot again!
I was always using the Military Overview and forgot that there's another list in the vanilla UI that's called "Unit List" (too much EUI for me I guess ).
Okay, with the Unit List it works like a charm!

 

[Typhlomence]

Also BUGFIX_DUMMY_POLICIES ...
*snip*

Very interesting...

I guess if I use dummy polices in the future, I can make an if else statement that checks for whether your DLL mod is active, and use your method, and if not, use the old exploit method (to retain compatibility with the default DLL).

 

[whoward69]

While you can use a test in Lua (check for pPlayer.GrantPolicy not nil), there's no "else" that'll work in SQL/XML. However, if you put the BUGFIX_DUMMY_POLICIES "on" and the set Dummy=1 SQL/XML all in a single file (to activate after the file that adds the actual policies), if the Policies table doesn't have the Dummy column, the file will fail - but that's OK in this situation. (Same theory as discussed here.)

 

[Typhlomence]

I did know I would have to do something like that but I forgot to mention it in my post. Thanks for explaining it, though.

 

[Tokata_RuNeLess]

Nice update, WHoward
I noticed that you have fixed some bugs that confused us in the earlier versions, however I noticed some new problems, wish to be fixed in your next update:

- The prophet from Byzantium's trait is not able to enhance a religion, I wonder if it's a new setting or a bug.
- If you skip 'Founding a panthon' (ie using IGE) and found a religion directly, it will be considered as an enhanced religion is found.

 

[whoward69]

The prophet from Byzantium's trait ...

doesn't exist. Byzantium's trait is to gain an extra belief.

 

[Tokata_RuNeLess]

doesn't exist. Byzantium's trait is to gain an extra belief.

O I forgot I used a mod... well, a prophet comes from a trait (whatever it is), just like a Venetian trait of a free Merchant of Venice, is not able to enhance a religion (and it used to be able to do so).

 

[whoward69]

Let me gaze into my crystal ball to guess what mod you're using to get the prophet for Byzantium and to auto-analyse every other mod you're using that may be causing a conflict ...

Or perhaps you could a) confirm that when playing with JUST the DLL and the prophet mod (no pseudo-DLC either please) you see the same behaviour, b) if so, provide the name of the mod, and c) possibly a save game.

 

[Tokata_RuNeLess]

Let me gaze into my crystal ball to guess what mod you're using to get the prophet for Byzantium and to auto-analyse every other mod you're using that may be causing a conflict ...

Or perhaps you could a) confirm that when playing with JUST the DLL and the prophet mod (no pseudo-DLC either please) you see the same behaviour, b) if so, provide the name of the mod, and c) possibly a save game.

Almost just DLL and that mod (and I think the only change comes from DLL, though). I will make a more simple mod to do this tomorrow, it's near 2 a.m. here in my position...

 

[Klisz]

I just tested it, and indeed prophets spawned from Trait's FreeUnit column seem to be incapable of enhancing a religion. Test mod and save attached. On the chance that it affects anything, I should note the first prophet, to found a religion to be enhanced at all, was plopped with the tuner.

 

[whoward69]

Well, I've just tried a game with ONLY the trait changing mod enabled, and that doesn't work. So the bug is in the core DLL, and nothing I've changed. The reason it doesn't work is because the prophet isn't dropped in the city, but around it

 

[JFD]

In addition, three new pPlayer Lua API methods are provided - GrantPolicy, RevokePolicy and SwapPolicy

local bGranted = pPlayer:GrantPolicy(iPolicy, bFree)
If pPlayer has NOT already adopted the specified policy, they will be granted it. Use bFree to indicate if this is a free policy (ie should NOT increase the culture cost of the next policy).
Returns true if the policy was granted as a result of this call (ie returns false if pPlayer already has the policy).

local bRevoked = pPlayer:RevokePolicy(iPolicy)
If pPlayer HAS already adopted the specified policy, it will be revoked (ie they will no longer have it). This method preserves the culture cost of the next policy.
Returns true if the policy was revoked as a result of this call (ie returns false if pPlayer does not already have the policy).

local bSwapped = pPlayer:SwapPolicy(iPolicyNew, iPolicyOld)
If pPlayer has NOT already adopted the specified NEW policy AND HAS already adopted the OLD policy, then the old policy is revoked and the new policy granted.
If the old policy was free, the new policy will also be free; consequently this method preserves the culture cost of the next policy.
Returns true if the policies were swapped as a result of this call.

A mod should not mix Grant/Revoke/SwapPolicy methods with SetNumFreePolicies/SetHasPolicy methods for the same (group of) policies.

Do these new methods essentially just condense the SetNumFreePolicies() > SetHasPolicy() method? Or do they improve upon that method?

 

[whoward69]

@JFD, they improve upon it. GrantPolicy() remembers whether or not the policy was free, and Revoke/SwapPolicy() then use that information to keep the internal counters in sync.

While you can do SetFree(1), SetFree(0), SetHasPolicy(iPol) to make iPol free, there is then no way to remove the policy, you have to swap in a "do nothing" one.

If you do GrantPolicy(iPol, true) you can then just do RevokePolicy(iPol) and it's exactly as if you never gave the policy in the first place

 

[JFD]

Would it be too much of a pun, then, to say that this is a God-send?

Sounds good for Sovereignty, which switches dummy Policies left-and-right (another pun... because you choose between leftist-rightist-centre reforms... I'll show myself out )

 

[bane_]

v77 is awesome.
Thank you very much!!

 

[whoward69]

- If you skip 'Founding a panthon' (ie using IGE) and found a religion directly, it will be considered as an enhanced religion is found.

Again, using only Vanilla BNW + LiveTuner vs BNW with DLL + LiveTuner I get exactly the same results.

Start a game, found your capital
Using LiveTuner, drop a prophet outside the capital
Move prophet into the capital and found a religion, you have to pick Pantheon, Founder and Follower beliefs only
Next Turn
Using LiveTuner, drop a prophet into the capital.
You can enhance the religion and have to pick the second follower and the enhancer beliefs

EXACTLY the same with and without the DLL

SEP (Hitch Hikers's Guide to the Galaxy reference)