BTS-Bugthread v.3.17/ v. 3.19 [Sammelthread]

[The_J]

Details bitte .

[Zulan]

Also das ganze ist ziemlich kompliziert. Das in aller fülle aufzuschreiben würde mich jetz zu viel Zeit kosten. Nur soviel.

Der Maximal übertragene Überschuss entspricht (zunächst) dem größeren von:
1) Den reinen Baukosten der Einheit/des Gebäudes (gilt fast immer)
oder
2) Deiner bonifizierten Basisproduktion.

Der Überschuss wird allerdings vor der anrechnung nochmal durch die Bonifizierung geteilt!

Verloren gegangener Überschuss wird NICHT als Gold ausgezahlt.

Tritt allerdings der Fall 2 ein d.h. deine bonifizierte BASIS-Produktion (also ohne Holz/Sklaven/Überschuss) übersteigt die Baukosten UND die Bonifizierung auf das aktuelle Bauprojekt (Heldenepos,Militärakademie,Stein) ist höher als die allgemeine Bonifizierung (Schmiede etc.) - dann bekommt man Geld ausgezahlt unabhängig davon ob Überschuss verloren geht.

Ich kann das auch nochmal schön aufschreiben aber die Fälle sind eh nicht so wahrscheinlich. Man kann dass evtl im späten Spiel mit Mining und ner extremen Militärstadt ausnutzen. Ansonsten hält sich das in grenzen.

[The_J]

versteh' ich grad leider nicht.
Kannst du mal ein Beispiel vorrechnen?

[Zulan]

Jaaa das ist nicht so einfach. Vorm Beispiel hier mal der code dazu.

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;

Angenommen du hast 120 basis in einer Stadt und produzierst eine Inantrie (140 ) von 0 an. In der Stadt steht eine Schmiede und Fabrik ( +50% genereller Bonus) und Militärakademie und Heldenepos ( +150% Militärbonus).

iOverflow = (120 +50%+150%) - 140.
iOverflow = 360 - 140.
iOverflow = 220

iMaxOverflow = max(140, (120 +50%+150%))
iMaxOverflow = max(140, 360)
iMaxOverflow = 360

iOverflow = min(220, 360)
iOverflow = 220

iMaxOverflowForGold = max(140, (120 +50%))
iMaxOverflowForGold = max(140, 180)
iMaxOverflowForGold = 180

iProductionGold = max(0, 220-180)
iProductionGold = 40

iRealOverflow = 220 -50%-150% = 73

Und das ganze nochmal in Bildern:




Ich überlasse es jetz mal der Kreativität der Leser was man damit schönes anstellen kann - der Schlüssel zum Reichtum gezieltes anproduzieren und extrem hohe Grundprodkution. Es ist jedoch wirtschaftlich recht harmlos, weil es erstmal eine so hohe Grundproduktion voraussetzt. Der Knackpunkt ist aber dass man das Gold bekommt obwohl der Überschuss in voll angerechnet wird.

Lohnen tut sich das aber wohl kaum, vorallem da man so fies viel rechnen muss. Ich halte es deshalb balancetechnich für relativ unrelevent, deswegen rede ich auch offen drüber. Wenn das jemand als gefährlichen MP-Exploit einstuft können wir das gerne rauslöschen.

Und weils so schön ist. Eigentlich müsste der code wohl irgnedwie so aussehen:

iOverflow = getUnitProduction(eTrainUnit) - iProductionNeeded;
int iMaxOverflow = std::max(iProductionNeeded, getCurrentProductionDifference(false, false));
iOverflow = std::min(iMaxOverflow, iOverflow);
if (iOverflow > 0)
{
  changeOverflowProduction(iOverflow, getProductionModifier(eTrainUnit));
}
setUnitProduction(eTrainUnit, 0);

int iProductionGold = std::max(0, iOverflow * (getBaseYieldRateModifier(0) / getBaseYieldRateModifier(getProductionModifier())) * GC.getDefineINT("MAXED_UNIT_GOLD_PERCENT") / 100;

Was genau die Entwickler da geraucht haben weden wir wohl nicht erfahren. Getestet auf korrektheit haben sie den Code jedenfalls nicht.

[The_J]

... ähm...also der Bug ist, dass bei der Überschussproduktion für das produzierte Gold alle Produktionsmodifikatoren durch Gebäude, etc, mitdraufgerechnet werden. Sehe ich das richtig?

[Zulan]

... ähm...also der Bug ist, dass bei der Überschussproduktion für das produzierte Gold alle Produktionsmodifikatoren durch Gebäude, etc, mitdraufgerechnet werden. Sehe ich das richtig?

Nein.

Der Bug ist das du Gold bekommst obwohl kein Überschuss verschwendet wird.

Der Grund dafür ist eine völlig unsinnige Berechungsbasis.

[The_J]

Achso, hab' die Berechnung für iRealOverflow übersehen.

Der Bug tritt immer dann auf, wenn man irgendetwas innerhalb von einer Runde mit Überschuss produzieren kann, richtig?
Wie sieht's mit sklaven + holzen aus? Gibt's da diese Möglichkeit auch?

[Zulan]

Achso, hab' die Berechnung für iRealOverflow übersehen.

Der Bug tritt immer dann auf, wenn man irgendetwas innerhalb von einer Runde mit Überschuss produzieren kann, richtig?

Es muss zusätzlich ein Projektspezifiischer Multiplikator wie Stein, Heldenepos im Spiel sein.

Was genau man jetz hier als bug bezeichnet ist schwierig - denn eigentlich ist der ganze Gold-Overflow-Code ein einziger Bug: Der nicht-angerechnete--Überschuss hat garnichts mit der Goldanrechnung zu tun. Am schlimmesten finde ich den Aspekt, dass man im normalfall also Hämmer verschwendet ohne dafür einen Ausgleich zu bekommen. Der Aspekt mit dem Gold dass man eigentlich nicht haben sollte ist eher akademischer Natur.

Wie sieht's mit sklaven + holzen aus? Gibt's da diese Möglichkeit auch?

Prinzipiell nein, denn Sklaven/Holzen zählt nicht zur Basisproduktion - es wird da nur interessant um erstmal das Projekt fertig zu stellen. Der Goldbetrag ist ja am höchsten wenn der Überschuss maximal wird und das kann er ja nicht werden wenn du nur ganz regulär was produzierst. Aber wenn z.B. die Überschusshämmer vom letzen Projekt genau ausreichen um das aktuelle Projekt in genau einer Runde fertigzustellen und dann noch deine normale Produktion größer als die Projektkosten ist gibst die maximale Auszahlung. Alles klar

[The_J]

Wie zum Geier hast du diesen Fehler denn überhaupt gefunden ?
Kann ja nicht sein, dass dir das zufällig aufgefallen ist .

Wie auch immer, ich update vorne mal.

[Zulan]

Wie zum Geier hast du diesen Fehler denn überhaupt gefunden ?
Kann ja nicht sein, dass dir das zufällig aufgefallen ist .

Wie auch immer, ich update vorne mal.

Das ist mir natürlich nicht zufällig aufgefallen. Ich habe mir eigentlich aufgrund des Patchlogs direkt den code angeschaut weil ich wissen wollte wie sie das Problem gelöst wurde... Mir ist dann irgendwie nicht klar geworden wie das funktionieren soll und da habe ich etwas probiert... und dann wieder den code angeschaut.

[The_J]

schonmal drüber nachgedacht, den richtigen Code reinzumodden?
Bei den Fanatics werden übrigens immer SDK-Coder gesucht .

[Zulan]

Ich hatte einfach bislang noch keine lust auf den Visual-Studio Krams. Mal sehn was da noch so geht.

[Scanner]

Ich hab folgendes Problem:

Civ4+bts, civ4 wg bts ohne patch, bts mit 3.17.

danach installierte ich folgende MOD´s.

BUGMOD

Rhye´s and Fall of Civilization

Rhye´s and Fall RAND

Mars, jetzt!

Fuer den aktuellen Patch von Mars,jetzt! wollte ich die 3.19 aufspielen.

Doch auf einmal findet der Wizard keine Installierte Civ-Dateien.
Darauf hab ich noch mal die BTS+CIV4 DVD eingelegt und tatsaechlich...
Ich bekomme beim Startupmenue "Installieren" und nicht "Spiel Starten"...

Was ist da schief gegangen?

Als versuch hab ich mal den BUGMOD deinstalliert, da der doch recht stark in das Spiel eingreift... aber auch das hat nix gebracht.

Muss ich jetzt ernsthaft Civ4+BTS neu installieren?
Kann ich evt die Registry ueberlisten?


Um es nicht falsch zu verstehen: Das Spiel funktioniert einwandfrei, alle MOD´s wie auch BTS oder Vanilla, aber der aktuelle RFC RAND waere mir lieb da da einige Bugs rausfliegen.

[The_J]

Wo ist denn das Problem beim neuinstallieren ?
Dauert doch weniger als ne Stunde.

[Herzschritt]

Klingt, als hätte jemand es geschafft, Civ unter Vista ohne Administratorberechtigungen zu installieren. (?)