Seite 6 von 8 ErsteErste ... 2345678 LetzteLetzte
Ergebnis 76 bis 90 von 118

Thema: [Modmod] CB-mod 0.7.x für RaR

  1. #76
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Zitat Zitat von Kermit87 Beitrag anzeigen
    So habe ich das auch mit den Yields gemacht. Ausschlaggebend für den steigenden Preis sind ja die gekauften Einheiten. Vielleicht habe ich deinen Einwand aber auch nicht richtig verstanden?
    Ja, natürlich verursachen die gekauften Einheiten den gestiegenen Preis. Aber der ist es ja, den du langsam aber sicher auf den ursprünglichen Wert zurückführen willst, nicht die Anzahl der Einheiten.


  2. #77
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Dann lass mal durchblicken wie du dir das vorstellst!
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  3. #78
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Zitat Zitat von Kermit87 Beitrag anzeigen
    Dann lass mal durchblicken wie du dir das vorstellst!
    Ich habe nicht viel Zeit, daher nur zusammengestoppelter Pseudocode:
    Code:
    // Kermit87 - Price-Normalisizing(
    void CvTeam::normalizeEuropeUnitsPrices()
    {
        for (int iUnitClass = 0; iUnitClass < GC.getNumUnitClassInfos(); ++iUnitClass)
        {
            UnitTypes eLoopUnit = (UnitTypes) GC.getCivilizationInfo(getCivilizationType()).getCivilizationUnits(iUnitClass);
            if (eLoopUnit != NO_UNIT)
            {
                // (?) Direktzugriff auf "m_aiEuropeUnitsPurchased"
    
                            // CB ab hier Pseudocode
                            float fKorrekturfaktor = ....; // aus XML-Wert auslesen, wäre in deinem Beispiel 0.95
                            int iAktUnitPrice = ....; // den aktuellen UnitPrice auslesen, wo immer er auch stehen mag 
                            int iStdUnitPrice = ....; // CvUnitInfos.xml -> iEuropeCost            
                            
                            if (m_aiEuropeUnitsPurchased[eLoopUnit] > 0) // Preiskorrektur ist nur dann sinnvoll, wenn die entsprechende Einheit auch schon einmal gekauft wurde
                            {
                                if (iAktUnitPrice > iStdUnitPrice) // muss der Preis überhaupt korrigiert werden?
                                {
                                   iAktUnitPrice = std::max(iStdUnitPrice, (int) iUnitPrice * fKorrekturfaktor); // verhindern, dass der Preis unter den Normalpreis fällt
                                   setAktUnitPrice(iAktUnitPrice); // Funktion, um den gegenwärtigen aktuellen Preis zurückzuschreiben 
                                }
                            }
            }
        }
    }
    // )Kermit87 - Price-Normalisizing
    Wie gesagt, das ist jetzt "quick and dirty" heruntergeschrieben, aber tut das, was gefordert ist: den aktuellen Preis (der durch 1, 2 oder 39 Einheitenkäufe angestiegen ist) pro Runde mit dem Korrekturfaktor multiplizieren (also verringern), und zurückschreiben, bis der Preis dem "Normalpreis" entspricht.
    Wie oft ein Einheitentyp gekauft wurde, tut in diesem Zusammenhang m.E. überhaupt nichts zur Sache.


  4. #79
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Dieses Kampfsystem macht mich zunehmend fertig.


  5. #80
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    zu #78:
    Ja kann mann so machen, ist aber aufwändiger.

    Zitat Zitat von Commander Bello Beitrag anzeigen
    Dieses Kampfsystem macht mich zunehmend fertig.
    Das kann ich mir vorstellen. Der Code um das Kampfsystem herum ist ja auch nicht gerade leichte Kost!
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  6. #81
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Zitat Zitat von Kermit87 Beitrag anzeigen
    Das kann ich mir vorstellen. Der Code um das Kampfsystem herum ist ja auch nicht gerade leichte Kost!
    Das Schlimme ist, dass es völlig unübersichtlich gestaltet worden ist.
    Da gibt's Funktionen, die nahezu das gleiche tun, da werden Funktionen sechsmal hintereinander mit unterschiedlichen Parametern aufgerufen, da werden (m.E.) komplett überflüssige Berechnungen durchgeführt...
    Und zu guter Letzt kommt die .exe hinzu, die z.B. bei einem bestimmten Assert (!) abstürzt.

    Im Moment bin ich notgedrungenermaßen dabei, Zeile für Zeile zu ändern und dann jeweils eine neue Debug-DLL zu erstellen. Das befördert den Vorgang nicht unbedingt...


  7. #82
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Zitat Zitat von Commander Bello Beitrag anzeigen
    Das Schlimme ist, dass es völlig unübersichtlich gestaltet worden ist.
    Da gibt's Funktionen, die nahezu das gleiche tun, da werden Funktionen sechsmal hintereinander mit unterschiedlichen Parametern aufgerufen, da werden (m.E.) komplett überflüssige Berechnungen durchgeführt...
    Und zu guter Letzt kommt die .exe hinzu, die z.B. bei einem bestimmten Assert (!) abstürzt.

    Im Moment bin ich notgedrungenermaßen dabei, Zeile für Zeile zu ändern und dann jeweils eine neue Debug-DLL zu erstellen. Das befördert den Vorgang nicht unbedingt...
    ich errinnere mich an:
    Zitat Zitat von Commander Bello Beitrag anzeigen
    Dieses Kampfsystem kann sich nur jemand ausgedacht haben, der a) im Vollrausch und b) vom Weltenhass zerfressen war.
    Hört sich ganz so an als würde da was arg an deinen Nerven herum fressen.
    Wie läuft es denn so? Nicht das ich im Moment auf einen Release warte. Ich frag halt einfach mal ob du die Probleme überwunden hast und vorangekommen bist?
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  8. #83
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Es läuft nicht gut, weil ich im Moment demotiviert bin.
    Und ja, diese Demotivation hängt ganz eng damit zusammen, dass ich aufgrund der diversen Schwächen des Kampfsystems extrem angefressen bin. Es gibt z.B. drei unterschiedliche Funktionen, die Kampfwahrscheinlichkeiten zu berechnen. So was zieht mir glatt die Schuhe aus.

    Um es kurz und knapp zu sagen: der bestehende Code ist funktionsfähig, aber schlecht; sowohl von der Implementierung wie von der Konzeption her.


  9. #84
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Irgendwie laufe ich hier ständig in neue Probleme, die z.T. dadurch vorgegeben sind, wie das Kampfsystem von Firaxis aufgesetzt wurde (hauptsächlich durch die Entscheidung, die meisten Modifikatoren auf der Verteidigerseite in Ansatz zu bringen).

    Ich muss meine Konzeption wohl noch einmal grundsätzlich überarbeiten und denke in die Richtung, die Berechnung der Kampfwerte mit nur einem Funktionsaufruf für beide beteiligten Einheiten durchzuführen.
    Das bedeutet aber, dass die Sequenzen der aufrufenden Funktionen entsprechend überarbeitet werden müssen (und vorher erst noch gefunden, was auch nicht ganz so einfach ist).

    Weiterhin bin ich ziemlich unglücklich mit der RaR-2.2-Entscheidung, zusätzliche "Veteran-Einheiten" einzuführen. Ich glaube, das werde ich wieder rückgängig machen.


  10. #85
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Ich sehen schon da muss Du wohl sehr weit ausholen. Ein echtes Mautprojekt! Du tust mir leid bei den ganzen Widrigkeiten von den du berichtest!
    Ich müsste mich auch mal wieder ans basteln ran schmeißen.
    Im Moment versuche ich einen Freund dem Civilization generell nicht ganz unbekannt ist für den Multiplayer zu begeistern. Wenn das dann hoffentlich bald ins rollen kommt steigt Civ und Col massiv im Kurs und nimmt wieder Fahrt auf!
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  11. #86
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Das wird sogar noch komplizierter, als ich dachte.

    Es gibt für die Berechnung der Kampfstärke (und das ist ja nur der erste Schritt!) prinzipiell sechs verschiedene Fälle:

    1) Berechnung der reinen Stärke des Angreifers (= Berechnung der reinen Stärke einer Einheit, unabhängig von der A/V-Rolle)
    2) Berechnung der Stärke des Angreifers bezogen auf ein anzugreifendes Feld
    3) Berechnung der Stärke des Angreifers bezogen auf den Verteidiger auf dem anzugreifenden Feld
    4) Berechnung der reinen Stärke des Verteidigers (= Berechnung der reinen Stärke einer Einheit, unabhängig von der A/V-Rolle)
    5) Berechnung der Stärke des Verteidigers auf seinem Feld
    6) Berechnung der Stärke des Verteidigers auf seinem Feld gegen einen definierten Angreifer

    Die Fälle 4 und 5 kann man zusammenziehen, denn ein Verteidiger steht immer auf einem Feld.
    Will man nur seine reine Kampfstärke haben, muss man das in der aufrufenden Funktion spezifizieren (das ist aber gleichbedeutend mit Fall 1).

    Fall 2 kommt zum Tragen, wenn man z.B. bestimmen möchte, welche Einheiten eine Stadt angreifen sollen, ohne dass man schon im Detail weiß, welche Einheiten diese Stadt verteidigen.
    Fall 5 kommt zum Tragen, wenn man die Verteidiger für eine Stadt bestimmen möchte, ohne dass der Angreifer schon feststeht (z.B., wenn Angreifer in der Nähe entdeckt werden, und Bürger zu Soldaten gemacht werden müssen).
    Fall 3 und Fall 6 sind die "Normalfälle".

    Leider hat Firaxis den Fall 1 etwas komplizierter gemacht, weil dort die Extrakampfstärke hineinspielt. Diese wird jedoch nicht nur durch die Veteranbeförderungen bestimmt, sondern auch durch Traits wie im Falle der Spanier, die 20% Kampfstärke gegen Ureinwohner bekommen. Ob man gegen Ureinwohner kämpft, weiß man aber im Fall 1 nicht.
    Das muss also noch in anderen Funktionen aufgedröselt werden - was wiederum bedeutet, dass z.B. die Funktionen zur Anzeige der Kampfstärke überarbeitet werden müssen, was bedeutet, dass man auch noch an die Textdateien gehen muss. Ob noch irgendwelche Pythondateien betroffen sind, weiß ich im Moment noch nicht.

    Es ist ein endloser Rattenschwanz...


  12. #87
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    So, ich hab mich mal wieder rangeschmissen und setze gerade das Unit-Price-Normelizing nach deinem Muster um!

    Nebenbei ver-MyMod'e ich gerade noch "Realism Invictus" 3.25 (falls bekannt?). So ein paar kleine Änderungen. Dann is das auch mal wieder auf dem neusten Stand. Das könnte ich ja auch mal wieder spielen!
    Spielst du auch manchmal Civ4 oder nur Col?
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  13. #88
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Zitat Zitat von Kermit87 Beitrag anzeigen
    So, ich hab mich mal wieder rangeschmissen und setze gerade das Unit-Price-Normelizing nach deinem Muster um!

    Nebenbei ver-MyMod'e ich gerade noch "Realism Invictus" 3.25 (falls bekannt?). So ein paar kleine Änderungen. Dann is das auch mal wieder auf dem neusten Stand. Das könnte ich ja auch mal wieder spielen!
    Spielst du auch manchmal Civ4 oder nur Col?
    Ich spiele eigentlich seit Jahren nur noch Col. Früher habe ich auch exzessiv Civ4 mit RoM gespielt, aber seit dem ich meine eigenen kleinen Moddingversuche mache, ist es tatsächlich nur noch Col.
    Realism Invictus sagt mir nur dem Namen nach etwas, ich hatte es nie ausprobiert.

    Bzgl. meiner Moddingbemühungen bin ich mittlerweile tief in den Schründen des Kampfsystems verschwunden. Die ehemalige maxCombatStr() habe ich nun umgearbeitet, und nun kämpfe ich mich Schritt für Schritt durch die aufrufenden Funktionen. Das klingt eigentlich ziemlich simpel, aber meine (beabsichtigten) Änderungen sind dennoch so tiefgreifend, dass es eine endlose Abfolge von Dingen ist, die nun entsprechend angepasst werden müssen. Dummerweise verzettele ich mich dabei auch immer wieder.
    Jedenfalls bin ich meinem Zeitplan sicherlich einen guten Monat hinterher...

    Aber dass du dich auch wieder drangesetzt hast, finde ich gut! Bin schon auf die Ergebnisse gespannt


  14. #89
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Zitat Zitat von Codestelle in Beitarg: #78
    int iStdUnitPrice = ....; // CvUnitInfos.xml -> iEuropeCost
    Ich stelle gerade fest das es doch definitiv einfacher wäre das so zu machen wie ich ursprünglich angedacht habe. Ich könnte schlecht die drei Preise einmal am Anfang bevor überhaupt jemand eine Einheit gekauft ermitteln und als Standartpreis abspeichern. Zum Beispiel weil die Preise für jeden der drei Häfen doch etwas umfangreicher und dynamischer (zB. je nach Ära) berechnet werden. Eher könnte ich mir den Aufwand machen und dann noch drei Funktionen für die Berechnung des Standartpreises absondern. Aber da packt man das Problem doch lieber minimalinvasiv an der Wurzel: dem Zähler für die gekauften Einheiten. Wenn dieser Zähler nirgends anders außer zur Preisberechnung verwendet wird stört das doch niemanden. Den Zähler Integral erhöhen, als float speichern und jede runde mit dem "PriceNormalizingMultiplier" langsam im float Bereich zurückschreiben und zur Preisberechnung als Integer ausgeben. So zersplittert das uns auch die Preise nicht so.
    Wärst du damit einverstanden?

    Wenn du mal wieder eine CB-Mod-Version veröffentlichst kann ich gerne die von dir gewünschten Features einfügen. Dann schaust du dir meine Arbeit an und nimmst wenn es dir beliebt noch Änderungen vor. Oder ich gebe dir die fertigen Musterdateien und du integrierst sie.

    Ich drück dir die Daumen das es bei dir im weiteren verlauf etwas glatter geht als bisher!
    Geändert von Kermit87 (22. Oktober 2014 um 17:07 Uhr)
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  15. #90
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Zitat Zitat von Kermit87 Beitrag anzeigen
    Ich könnte schlecht die drei Preise einmal am Anfang bevor überhaupt jemand eine Einheit gekauft ermitteln und als Standartpreis abspeichern.
    Das ist mir jetzt nicht ganz klar. Gerade der Standardpreis steht doch fest - er steht in der Civ4UnitInfos.xml.

    Zitat Zitat von Kermit87 Beitrag anzeigen
    Zum Beispiel weil die Preise für jeden der drei Häfen doch etwas umfangreicher und dynamischer (zB. je nach Ära) berechnet werden.
    Auch hier gewinnst du doch nach deiner Vorstellung gar nichts. Äraabhängige Berechnungen (plus Schwierigkeitsgrad, und ggf. noch Kartengröße) erfolgen ohnehin, egal, ob du die Preisreduzierung über die Anzahl der Einheiten, oder über den aktuellen Verkaufspreis realisieren möchtest.

    Zitat Zitat von Kermit87 Beitrag anzeigen
    Eher könnte ich mir den Aufwand machen und dann noch drei Funktionen für die Berechnung des Standartpreises absondern. Aber da packt man das Problem doch lieber minimalinvasiv an der Wurzel: dem Zähler für die gekauften Einheiten. Wenn dieser Zähler nirgends anders außer zur Preisberechnung verwendet wird stört das doch niemanden.
    Mein Problem mit der von dir genannten Vorgehensweise liegt einfach daran, dass die Anzahl der gekauften Einheiten nur indirekt (spätestens nach der ersten Reduzierung) noch etwas mit dem Einheitspreis zu tun hat. Ich bin zwar auf der einen Seite ein Freund kurzen, schnellen Codes, gleichzeitig aber auch von klarem Code.

    if ( iA = 0)
    {
    fA(1000.0) = (float) iS=1000 (Hafen);
    }
    ...
    if (iX>0 = 2)
    {
    fA(1400.0) = fA(1000.0) * (float) (1 + ( iX = 2 * fE = 0.2 ));
    iX = 0;
    }
    ....
    {
    fA(1330.0) = fR 0.95 * fA(1400.0) // pro Hafen // pro Runde
    fA(1330.0) = std::max( fA(1330.0), (1.0f * iS = 1000 (E/A/P)));
    iA(1330) = (int) fA(1330.0);
    }

    (fA = akt. Preis,
    iX = Anzahl Einheiten (1, 2, 3, .... 139, ... - Annahme: iX wird gespeichert. Wird es im Standardcode nämlich (glaube ich) nicht, da wird ein Einheitenkauf nach dem anderen durchgeführt und die Preiserhöhung direkt gemacht),
    fR = Reduktionsfaktor (0.95),
    fE = Erhöhungsfaktor (0.2),
    iS(Hafen) = StdPreis aus XML)

    Dann muss ich nur dreimal durch die gleiche Funktion laufen (for-Schleife) - das muss ohnehin getan werden - und den Hafen , und damit ggf. iS(Hafen) (= entsprechender Wert: m_iUnitPriceEur/Afr/PRo) jeweils ändern (switch-case) - das muss auch ohnehin getan werden.

    Das ist jetzt wieder quick'n'dirty und vielleicht nicht 100% akkurat, aber ich bin auch müde.
    Zitat Zitat von Kermit87 Beitrag anzeigen

    Den Zähler Integral erhöhen, als float speichern und jede runde mit dem "PriceNormalizingMultiplier" langsam im float Bereich zurückschreiben und zur Preisberechnung als Integer ausgeben.
    So zersplittert das uns auch die Preise nicht so.
    Wärst du damit einverstanden?
    Der markierte Teil zeigt das Problem:
    Der Zähler (in meinem obigen Beispiel iX) startet mit iX == 0. Dann wird er um mindestens einen ganzzahligen Wert erhöht (Annahme: 2) und steht nun bei iX == 2.
    Dann wandelst du ihn in einen float-Wert um (fX = (float) iX) - Wert ist nun 2.00f.
    Dann multipliziert du ihn mit fR (0.95f) und er hat nun den Wert fX == 1.90f.
    Dann wandelst du ihn in einen int-Wert zurück (Preisausgabeberechnung) und er hat den Wert... 1 ! (Integerwerte sind immer die Ganzzahlanteile)
    Egal wie, gerade dadurch "zersplitterst" du dir deine Werte.

    Verstehe mich bitte nicht falsch: ich möchte dir weder etwas "madig" reden noch dich belehren, wie du deine Änderungen durchzuführen hast.
    Ich gebe lediglich meinen Input und meine Gedanken, der Rest bleibt völlig bei dir. Ob die Lösung von vorn oder von hinten, von links oder von rechts erfolgt, ist völlig egal, solange sie richtig ist.

    Zitat Zitat von Kermit87 Beitrag anzeigen
    Wenn du mal wieder eine CB-Mod-Version veröffentlichst kann ich gerne die von dir gewünschten Features einfügen. Dann schaust du dir meine Arbeit an und nimmst wenn es dir beliebt noch Änderungen vor. Oder ich gebe dir die fertigen Musterdateien und du integrierst sie.
    Da komme ich gern drauf zurück, aber das wird sicherlich noch mindestens 2 Wochen dauern.

    (Sorry, völlig übermüdet... Ich hoffe, man kann meine Gedankengänge nachvollziehen)
    Geändert von Commander Bello (23. Oktober 2014 um 04:23 Uhr)


Seite 6 von 8 ErsteErste ... 2345678 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •