Die Mathematik hinter der Sklaverei

[Penguin]

Beim Überschuß peitschen sollte man bedenken, dass die Höhe des Überschusses begrenzt ist.
2 Grenzen
1. Höhe der aktuellen Produktion
2. die zur Erstellung nötige Produktion.

Es gilt aber immer die höhere Grenze aus den beiden.
Bsp.:
Eine Stadt mit 50 Basishämmern (ohne Schmieden oder sonstige Boni) baut einen Späher. Es wird 50-15=35 Hämmer Überschuss geben, da die 1. Regel gilt.
Eine Stadt mit 1 Basishammer baut einen Späher mit 5 Hämmern an und sklavt ihn in der nächsten Runde. Dann wird die Runde der Sklaverei mit 36/15 beim Späher beendet. Der Überschuss müsste 21 betragen, aber es tritt die 2. Grenze in Kraft und es gibt nur den Preis des Spähers als Überschuss, also 15 Hämmer.

[Yasmin D'Ahara]

Sicher? Ich habe schon so gesklavt, dass da Geld rausgesprungen ist Oder ist das ein Anzeigebug vom BUG-Mod

Haste BASE Gespielt? Da ist das so. Ansonsten dürfte es nicht der Fall sein.

[Flunky]

Der BUG-Mod zeigt das bei mir auch ohne BASE an.

[HUSch]

Angezeigt wird es bei mir auch, bloß bekomme ich nichts.

[ThomasBX]

Sicher? Ich habe schon so gesklavt, dass da Geld rausgesprungen ist Oder ist das ein Anzeigebug vom BUG-Mod

Ich glaube das war noch bei Vesrion 3.17 der Fall, ist es jetzt aber definitiv nicht mehr.

[alpha civ]

Im Code ist die Goldzufuhr aber auf jeden Fall noch drin:

Achtung Spoiler:

void CvCity::popOrder(int iNum, bool bFinish, bool bChoose)
{
	[...]

	switch (pOrderNode->m_data.eOrderType)
	{
	case ORDER_TRAIN:
		[...]

		if (bFinish)
		{
			iProductionNeeded = getProductionNeeded(eTrainUnit);

			// max overflow is the value of the item produced (to eliminate prebuild exploits)
			iOverflow = getUnitProduction(eTrainUnit) - iProductionNeeded;
			int iMaxOverflow = std::max(iProductionNeeded, getCurrentProductionDifference(false, false));
			int iMaxOverflowForGold = std::max(iProductionNeeded, getProductionDifference(getProductionNeeded(), getProduction(), 0, isFoodProduction(), false));
			iOverflow = std::min(iMaxOverflow, iOverflow);
			if (iOverflow > 0)
			{
				changeOverflowProduction(iOverflow, getProductionModifier(eTrainUnit));
			}
			setUnitProduction(eTrainUnit, 0);

			int iProductionGold = std::max(0, iOverflow - iMaxOverflowForGold) * GC.getDefineINT("MAXED_UNIT_GOLD_PERCENT") / 100;
			if (iProductionGold > 0)
			{
				GET_PLAYER(getOwnerINLINE()).changeGold(iProductionGold);
			}

                        [...]
                }
        }
}

[rucivfan]

Kann sein, aber in der aktiven BTS-DLL für 3.19 ist er es nicht.

[alpha civ]

Doch, er ist vorhanden. Nur leider Firaxistypisch fehlerhaft. Man braucht sich nur mal die verwendete Methode "getProductionDifference" anschauen. Die ersten beiden Parameter werden hier gar nicht verwendet.
Es wird also gar nicht eine Differenz berechnet, wie der Name suggeriert, sondern einfach die derzeitige Produktion.
iMaxOverflowForGold hat dann den gleichen Wert wie iMaxOverflow, was zur Folge hat, das stets iOverflow - iMaxOverflowForGold < 0 ist. Somit gibt es nie Gold für verloren Überschuss.

Achtung Spoiler:

int CvCity::getProductionDifference(int iProductionNeeded, int iProduction, int iProductionModifier, bool bFoodProduction, bool bOverflow) const
{
	if (isDisorder())
	{
		return 0;
	}

	int iFoodProduction = ((bFoodProduction) ? std::max(0, (getYieldRate(YIELD_FOOD) - foodConsumption(true))) : 0);

	int iOverflow = ((bOverflow) ? (getOverflowProduction() + getFeatureProduction()) : 0);

	return (((getBaseYieldRate(YIELD_PRODUCTION) + iOverflow) * getBaseYieldRateModifier(YIELD_PRODUCTION, iProductionModifier)) / 100 + iFoodProduction);

}

[rucivfan]

Dafür waren die sinnfreien Parameter mal gedacht, interessant.

[rucivfan]

Nach dem Code wird überschüssige Produktion durch aus noch in Gold umgewandelt, aber eben nur unter seltenen Gegebenheiten. Hier gibt es eine Beispielrechnung.

edit: Habe jetzt mal selber nachgerechnet bzw ein Beispiel mir erstellt und ausprobiert.

Produktion mit alten Überschuss ist zum Beispiel 180. Die Grundproduktion ist 36 und der Produktionmultiplikator ist 150%.

Gebaut wird ein Bogenschütze.

iUnlimitedOverflow = 180 - 25(Bogenschütze) = 155
iMaxOverflow = max(Kosten Bogenschütze, Bonifizierte Produktion) = max(25,90) = 90
Die 90 Produktion Überschuss fließt unbonifiziert mit 36 Produktion in der nächsten Produktion ein.

Jetzt das Gold (MAXED_UNIT_GOLD_PERCENT ist 100 und kann damit weggelassen werden.):

iMaxOverflowOverGold = max(Kosten Bogenschütze, Unbonifizierte Produktion) = max(25,36) = 36

iProductionGold = max(0, iOverflow - iMaxOverflowOverGold ) = max(0, 54) = 54

Ich habe 54 Gold auf das Konto bekommen und extra noch mal nachgeprüft.. Der Fehler ist hier aber, dass ich eigentlich von der positiven Differenz (iUnlimitedOverflow - iMaxOverflow) Geld auf das Konto bekommen müsste. Tatsächlich bekomme man aber Gold abhängig vom Maximal Überschuss. Je mehr Überschuss in die nächste Produktion fließt, desto mehr.

Real ist das nur selten der Fall. Häufig sind die Kosten einer Einheit höher als die bonifzierte Produktion.

[Bacchus]

Um hier mal anzuknüpfen, anstatt wie sonst eher aus dem Bauch heraus zu spielen, versuche ich in einem aktuellen PBEM gerade, mein Spiel etwas zu optimieren.

Mein erster Versuch, mit maximalem Überschuss zu sklaven, ist dabei grandios gescheitert, der zweite hat hingegen funktioniert.
Stadt 1 hat einen Ele bis auf 29/60 angebaut, der Überschuss (pop 2) sollte in ein Wunder fließen.
Stadt 2 hat eine Bib auf 59/90 angebaut, der Überschuss sollte in eine Schmiede gehen.

Stadt 1 konnte aber nur noch pop 1 sklaven. Der Unterschied beider Städte ist der, dass dort schon eine Schmiede steht (und der Org-Reli Bonus, der aber mein Ele-Bau keine Rolle spielen dürfte). Stadt 2 bekommt keinen Bonus. Kann also nur an der Schmiede liegen, aber wo genau liegt mein Denkfehler? Warum konnte ich den Ele, dem genau 31 fehlten, nur noch pop 1 sklaven?

[Frozen]

Eigentlich recht simpel:
Die Schmiede gibt +25%
von 30 sind das 7,5
--> pop1= 37,5

Fast irrelevante Miniausnahme:
Du hast eine Schmiede (kein OR) und willst nen Markt bei 75/150 pop2 sklaven. Das geht nicht, da civ abrundet --> 37*2=74, berechnet aber nacher korrekt 37,5*2=75

[Bacchus]

Eigentlich recht simpel:
Die Schmiede gibt +25%
von 30 sind das 7,5
--> pop1= 37,5

Hm, klingt wirklich simpel.
Wenn ich also 'ne Schmiede in der Stadt habe, baue ich Einheiten nicht bis auf 31 , sondern nur bis auf 38 an, richtig? Und der maximal mögliche Überschuss beträgt dann 36 statt 29 .

Was ist mit Gebäuden mit Schmiede und Org-Bonus? Zählt der auch? Baut man demnach Gebäude unter diesen Voraussetzungen nur bis auf 46 (30 + 50% = 45 ) an?

[BoggyB]

Hm, klingt wirklich simpel.
Wenn ich also 'ne Schmiede in der Stadt habe, baue ich Einheiten nicht bis auf 31 , sondern nur bis auf 38 an, richtig? Und der maximal mögliche Überschuss beträgt dann 36 statt 29 .

Was ist mit Gebäuden mit Schmiede und Org-Bonus? Zählt der auch? Baut man demnach Gebäude unter diesen Voraussetzungen nur bis auf 46 (30 + 50% = 45 ) an?

Es zählt jeder Bonus, der auch für die normale Produktion zählt
Der Überschuss wird allerdings wieder entbonifziert, hast also ne Schmiede in einer Stadt und 20 Überschuss, werden daraus 20/1,25=16. Die werden allerdings in der nächsten Runde wieder mit allen Boni multipliziert, die das nächste Bauprojekt bekommt, also wieder 16*1,25=20. Wichtig ist das hauptsächlich, wenn die zwei Bauprojekte unterschiedliche Bonifikatoren haben (durch Heldenepos, OrgReli, sonstwas).

[Bacchus]

Vielen Dank für die Erläuterungen!