RtR mod 2.0.7.6

[Dreylin]

Incase you're not following PB22:

I think there's a bug in the "hide diplo windows during pauses" feature - not only did it not work, but when I came back into the game, the diplo window is now gone completely!

[novice]

OK, I tested this in a local pitboss and I can confirm that this does not work as intended. The diplo screen showed up even though the game was paused. I then exited to desktop, logged on as another player, unpaused, logged back in as the player receiving the diplo offer, and the diplo screen was gone. So I saw the same behavior as GermanJojo.

[novice]

I looked at the code. There's no wonder the fix isn't working, as it's never made it into the code base.

Here's plako's description of the fix. So I guess it's just a matter of implementing it and testing it.

I've found a cure to the diplo window stuck when paused problem in pitboss games. Solution is so simple that I'm really surprised it hasn't been done. It prevents diplo window opening while paused and opens them when unpausing. You can still shoot yourself in the foot i.e. open diplo window while paused, but other people logging in when you've opened diplo window can now upause. I've set a pull request to T-Hawk's git repository, but here are all the code changes needed:

Add this line to cvplayer.h after the declaration of m_listDiplomacy (empty diplo list that can be used when paused):

Code:

CvDiploQueue m_listDiplomacyEmpty;

And then these lines in the beginning of the getDiplomacy function in the CvPlayer class:

Code:

    if (GC.getGameINLINE().isPaused()) {
        return m_listDiplomacyEmpty;
    }

This might cause somethig strange in PBEM games so better check it before starting a game with this.

So what GJ and I saw was just the standard BTS behaviour, I know I clicked the Exit diplomacy button while the game was paused, so I guess that's what registered when the game was unpaused.

[novice]

OK, so I added the pause fix, and it seems to work. I check that the game is a pitboss game, to avoid any PBEM problems. The fix can also be disabled through an xml setting in GlobalDefines.xml.

Here are the code details:
https://github.com/novice-rb/Civ4RealmsB...b34debf61d

And here is an unofficial 2.0.7.2 release of RtR, with the fix added:
https://dl.dropboxusercontent.com/u/1521....0.7.2.zip

[Caledorn]

I believe there is a way to modify yhe save files to accept the updated mod, but I need to ask the Spanish guys that made the APTMod that's being used in th ISDG how they did it. If you guys are interested, that is.

[Dreylin]

If it can be done, I can see it saving a lot of hassle down the road...

[Krill]

First post updated with link to the fixed version of hte mod.

[Elum]

I'm a bit embarrassed because it's likely I'm being an idiot but I think I've found a 'bug'.

I have a game using the mod and as an imperial leader I can't 1 pop slave a settler when at 52/100.

My understanding is that: 30h (slave) * 160% (imperial) = 48h, so 52 + 48 = 100

I've checked that I have enough pop (3) and am in slavery (lol). I can slave if at 55h so maybe it's something to do with the extra 10%? Or more likely I'm being an idiot.

I'm using 2.0.7.2

I can't upload the save with this post because it won't let me but here is a link Save.

[Krill]

Hmm, this is interesting.

EDIT: I know why the bug exists, coming up in nexct post.

[Krill]

Back in vanilla Civ 4 there was a problem with slavery, such that when slaving with hammer multipliers it was possible to slave 1 pop away and around get 2 pops worth of hammers. It was easily abusable with OR, and it was known about a long time ago:

http://www.civfanatics.com/civ4/strategy/whip.php

1.61 EXPLOITS

Patch 1.61 has a bug in the whip production calculation that allow you to generate game breaking numbers of hammers from the whip. The nature of the bug is that population and production bonuses, which are used in the calculation to determine how much population must be whipped, are not considered when calculating the yield.

Instead, the number of hammers you get is simply the number of hammers you need, rounded up to the nearest multiple of 30.

Now, this bug can work against you. For instance, if you try to whip an archer (25 hammers) with nothing invested, two population are sacrificed. So the production of the archer should be 2 * 20 = 40 hammers. Instead, you get 30 hammers - the lowest multiple of 30 greater than 25.

If you instead whip an axeman (35 hammers) with nothing invested, the bug breaks in your favor. Two population are again sacrificed, so your yield should be 40 hammers. Instead, you are getting 60 hammers. In effect, the bug allows you to instantly whip axemen at no penalty.

Where things get really silly is the case where you have a production bonus available. A 25% production bonus should give you 37 hammers per pop. So if you invest a single hammer in an axeman, then whip, the game correctly recognizes that a single pop point will complete the unit. But instead of 37 hammers, the bug gives you 60 hammers (the lowest multiple of 30 that is greater than 34).

But have a care - if you invest 5 hammers in the axeman, the bug will reduce your yield to 30 hammers, rather than the 37 you are entitled to.

This is, I believe, essentially the same bug. Which doesn't really help me much because I can't remember what the fix was.