Help! I signed up for an MP game & don't know basic mechanics

[naufragar]

I was playing as Cathy and went to whip a settler that had 55/100 hammers invested, but the game wanted two pop, where I would expect it needed just one. (30h normal speed +50%=45). If I add just one more hammer, bringing it to 56/100, I can one pop whip, so it's not like the game wants the whip hammers to finish the settler w/o modifiers. To make sure I wasn't going crazy, I checked if the granary or the creative library needed the whip to overflow. Nope. 30h invested plus 1 pop; totally fine.

I'm sure I'm missing something obvious, but I've been world buildering scenarios in BtS and RtR for like a day and still can't figure out the mechanic.

[Krill]

Holdover bug that has been there for years iirc.

[naufragar]

Thanks. Sanity restored.

[Bacchus]

True story. Happened to us in PB37.

[TheHumanHydra]

IIRC it happens when the hammers are modified (most commonly by a forge). Not sure why it didn't affect your Creative library, tbh.

[RefSteel]

Yeah, this is slightly crazy. I documented it way back in PB3 and I still don't know why it happens.  In detail, for base BtS:

Okay, I'm at a total loss to explain the whipping bug.  But at least I now know what it actually does.

A few observed phenomena:

+25% hammer bonus, 37h remaining:  1-pop whip.  (Correct; whip gives 37.5, rounded down)
+25% hammer bonus, 75h remaining:  3-pop whip(!)  (whip gives 112(.5 rounded down) hammers; 2-pop would give 75)
+50% hammer bonus, 45h remaining:  2-pop whip(!?)  (whip gives 90h; 1-pop would give 45)
+50% hammer bonus, 90h remaining:  2-pop whip(!!!!!)  (whip correctly gives 90h exactly)

Look at those last two again.  It works the same way whether the hammer bonus consists of two +25%s (OrgRel + Forge) or one +50% (Bureau cap).  I can think of no variety of rounding error or simple programming mistake that could explain this behavior; it absolutely boggles the mind.

Also note, by the way, that if you put another hammer or two into the builds, you can whip these builds for the correct number of pop and the whips generate the correct number of hammers!  There is no problem at all with the way the game calculates the number of hammers generated by a whip - only with the way it calculates how many whips will be needed!

Oh, and:

+50% bonus, 135h remaining:  4-pop whip.  Naturally.  (3-pop would give 135 exactly)
+25% bonus, 150h remaining:  5-pop whip(!!!!@$*&*#E$*!!!!) (4-pop would give 150 exactly)

So after staring in dumbfounded amaze at this for a while and running a few more tests, I think I have detected a completely illogical but apparently correct pattern:

While a 25% or 75% (or 125%, etc.) total hammer bonus applies, it is not possible to whip an even number of population units if doing so would complete the build to the exact hammer.

While a 50% (or 150%, etc.) total hammer bonus applies, it is not possible to whip an odd number of population units if doing so would complete the build to the exact hammer.

Now, as far as I can tell, this makes no sense - trying to imagine the insane contortions of code that might have resulted in something this preposterous is making me see cross-eyed - but for purposes of city planning, all that really matters is that it's true.

Since RtR changed the number of hammers generated by multi-pop whips, it might also have changed these figures, so I'd definitely worldbuild a quick test on important occasions.  Also, I didn't test the figures for cases of +10% or +35% (or don't remember what the results were if I did).

[EDIT: Since this might not have been clear, any bonus that's a whole multiple of 100% is fine; the bug never applies to those cases.]

[naufragar]

Wow. Thanks Ref! I would never have thought to extend it to hammer multipliers. I was thinking it had something to do with food hammers.

And yeah, I just double checked that creative library (didn't see your edit), and 100% multipliers are fine.

[TheHumanHydra]

The 90h and 100% modifier cases make me think that the bug doesn't apply to cases where an unmodified whip would result in exact hammers also (30 + 30 + 30 = 90 or 45 + 45 = 90) -- i.e. that it applies in all other cases. The only one that doesn't fit this pattern is the one-pop whip for 37; I wonder if the fact that the hammers actually exceed 37 (by 0.5) before rounding down causes that one to be an exception.

[T-hawk]

I remember digging through that code for RtR.  Yes, it is different code paths to determine the hurry cost (population) versus actually granting the yield. The first has some intermediate truncations that the second doesn't. This happens because the hurryCost function is more generalized: it's not specific to whipping but also handles cash rushing and is meant to be moddable for any additional arbitrary types of rushing as well.