Seite 5 von 8 ErsteErste 12345678 LetzteLetzte
Ergebnis 61 bis 75 von 118

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

  1. #61
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Zitat Zitat von Commander Bello Beitrag anzeigen
    Allerdings werde ich nun wohl ein paar Tage damit beschäftigt sein, mir RaR2.2 anzusehen und mir Gedanken über das Einheitenbalancing zu machen...
    Oo, da habe ich wohl geschlafen.
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  2. #62
    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 Commander Bello Beitrag anzeigen
    Allerdings werde ich nun wohl ein paar Tage damit beschäftigt sein, mir RaR2.2 anzusehen und mir Gedanken über das Einheitenbalancing zu machen...
    O weia, das wird nicht einfach...


  3. #63
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Ich stoße gerade (unabhängig von RaR 2.2) auf folgendes Problem:
    Typischerweise werden entweder Feature-relevante Modifikatoren oder Terrain-relevante Modifikatoren in die Kampfwertberechnung einbezogen.
    Also, wenn ein Geländefeld mit Wald bewachsen ist, gelten die Modifikatoren für den Wald, und nicht die für das darunterliegende Terrain (gilt für Verteidiger wie für Angreifer). Das ist in aller Regel auch sinnvoll.

    Es gibt allerdings den Sonderfall des dschungelbewachsenen Sumpffeldes.
    Ich bin der Meinung, dass sich in diesem Spezialfall die Modifikatoren summieren sollten (wie im Falle der Hügel ebenfalls). Gibt man z.B. Sumpf einen Verteidigungsmodifikator von +20% und Dschungel einen Verteidigungsmodifikator von +50%, dann sollte der Verteidiger m.E. insgesamt +70% erhalten, und nicht nur +50%.
    Für den Angreifer sollte die Summierung ebenso gelten.

    Mal gucken, was ich da mache...


  4. #64
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Zitat Zitat von Commander Bello Beitrag anzeigen
    Ich stoße gerade (unabhängig von RaR 2.2) auf folgendes Problem:
    ...
    Jo, habe gerade nachgeschaut und hatte den selben Eindruck! Der scheint in diesem Fall nur den Verteidigungswert des Features zu berücksichtigen.

    Das Price-Normalizing Feature bekommst du nach umbau auf 2.2!
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  5. #65
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108

    Post Price-Normalizing Feature

    So, der Compiler hat alles geschluckt und RaR startet normal! Soll heißen das ich wohl nichts vergessen habe mit rüber zu nehmen. Ich habe es jetzt nicht im Spiel getestet aber es müsste ganz normal funktionieren und das tun was es halt tun soll!

    Ich habe fYieldPriceNormalizingMultiplier jetzt in fPriceNormalizingMultiplier umbenannt um den Multipler nominell nicht nur Auf Yields zu beschränken. Ich kann die Price-Normalizing dann noch auch noch auf die Units ausweiten. Muss man dan gucken wie du das gerne hättest? Aber vorab schon mal zum reingucken!

    Die Berechnungen um "YieldBoughtTotal" sind in RaR etwas umfangreicher. Da muss ich mir noch ein paar Gedanken ob ich das noch was raus-nehme (Stichwort "iEuropeVolumeAttrition").

    In einer PN konnte ich die Datei nicht anhängen also hab ich das hier gemacht.

    Gruß
    Kermit
    Angehängte Dateien Angehängte Dateien
    Geändert von Kermit87 (25. September 2014 um 01:13 Uhr)
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  6. #66
    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
    (Stichwort "iEuropeVolumeAttrition")
    Das hatte ich mir vor geraumer Zeit schon mal (allerdings nur sehr flüchtig) angesehen. Ich bin mir aus der Erinnerung heraus gar nicht sicher, ob das überhaupt genutzt wird.
    Bei nochmaligem Nachdenken könnte es wohl doch genutzt werden, aber ich war mir beim damaligen Betrachten zumindest nicht sicher, ob es messbare Auswirkungen haben würde.
    Ein weiterer Blick darauf könnte sich jedenfalls lohnen.

    Achtung Spoiler:
    Es gibt eine ähnliche Funktionalität für die Einheiten (irgendwas mit immigrationdecay oder so ähnlich), die nach meiner Feststellung auch nicht genutzt wird (steht zwar im Code, ist aber wohl nirgends in der Civ4UnitInfos.xml eingestellt).


  7. #67
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Es gibt ja verschiedene Spieleinstellungen die den PriceNormalizingMultiplier beeinflussen können:

    bei der Spielgeschwindigkeit ist zB. zu beachten das sich bei einer Höheren Spielgeschwindigkeit jedoch nicht die Menge der in einer Runde erwirtschafteten Yields erhöht. Kannst Du mit deinem analytischen Schafsinn überlegen woran Du die Höhe des PriceNormalizingMultiplier anknüpfen würdest?

    - Spielgeschwindigkeit
    - Schwierigkeitsgrad
    - oder erstmal statisch
    - oder vielleicht die PriceNormalizingMultiplier aus: "(Spielgeschwindigkeit + Schwierigkeitsgrad) / 2" mitteln


    Ich arbeite auch gerade an einem Prototyp von/um: CvTeam::normalizeEuropeUnitsPrices()
    Geändert von Kermit87 (26. September 2014 um 17:12 Uhr) Grund: Schreibfehler
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  8. #68
    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
    Es gibt ja verschiedene Spieleinstellungen die den PriceNormalizingMultiplier beeinflussen können:

    bei der Spielgeschwindigkeit ist zB. zu beachten das sich bei einer Höheren Spielgeschwindigkeit jedoch nicht die Menge der in einer Runde erwirtschafteten Yields erhöht. Kannst Du mit deinem analytischen Schafsinn überlegen woran Du die Höhe des PriceNormalizingMultiplier anknüpfen würdest?

    1) Spielgeschwindigkeit
    2) Schwierigkeitsgrad
    3) oder erstmal statisch
    4) oder vielleicht die PriceNormalizingMultiplier aus: "(Spielgeschwindigkeit + Schwierigkeitsgrad) / 2" mitteln
    (Die Nummerierungen stammen von mir)

    Puh. Das sind "spielphilosophische" Fragen.

    1) Spielgeschwindigkeit
    Bei TAC-normal haben wir 300 Runden, bei Marathon 900 Runden.
    Da gibt es eigentlich zwei Ansatzpunkte: Entweder, man führt die Routine nur jede x-te Runde aus, wobei sich das x aus dem Verhältnis der Runden aus der gewählten und aus der als "normal" angesehenen Rundenzahl ergibt. Oder man führt die Berechnung jede Runde aus, dann aber mit einem angepassten Prozentsatz. Letzteres wäre "unauffälliger", ersteres vermutlich minimalst weniger rechenintensiv (über die gesamte Spieldauer gesehen).

    2) Schwierigkeitsgrad
    Da geht's dann in die Philosophie, ähnlich wie bei Kämpfen, die (für den menschlichen Spieler) ja auch schwierigkeitsgradunabhängig sind (für den KI-Spieler nicht, sobald es um Kämpfe gegen Eingeborene geht).
    Da gibt es m.E. keine ja/nein-Antwort, das ist persönliches Ermessen. Es gibt für beide Ansichten gute Gründe.
    Persönlich tendiere ich dazu, den Korrekturfaktor unabhängig vom Schwierigkeitsgrad zu lassen, das ist aber lediglich ein persönliches Bauchgefühl und kann nicht weiter begründet werden.

    3) Statisch
    Das verstehe ich als das Verwenden des gleichen Prozentsatzes, unabhängig von Spielgeschwindigkeit oder Schwierigkeitsgrad.
    Da die Spielgeschwindigkeit die mögliche Ausbringungsmenge während des jeweiligen Gesamtspiels beeinflusst, sollte man tatsächlich diesbezüglich korrigieren wie unter 1)
    Statisch würde ich es also nicht lassen

    4) Mittelung aus Spielgeschwindigkeit + Schwierigkeitsgrad
    Wenn man auf 1) und 2) guckt, ergibt sich schon die Antwort.
    Davon unabhängig muss man sich überlegen, was von beiden Faktoren in welchem Maße den größeren Einfluss hat; oder anders ausgedrückt, ich halte die Formel (Spielgeschwindigkeit + Schwierigkeitsgrad) / 2 für ungeeignet.
    Je höher Spielgeschwindigkeit und Schwierigkeitsgrad, desto niedriger die Korrekturfaktoren. Diese dann noch zu halbieren, würde den Effekt ja nur verstärken und die Korrektur nachher vermutlich bis in den nicht mehr messbaren Bereich minimieren.

    Kurz und knapp: ich würde empfehlen, im Moment das Augenmerk nur auf Punkt 1) zu richten.


  9. #69
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Gut dann werde ich mich auf Punkt 1) konzentrieren. Danke!

    Frage zu Syntax:
    Code:
    int iVar_A = (iVar_B == iVar_C) ? iVar_D : iVar_E;
    Verstehe ich das richtig das iVar_A der Wert von iVar_D zugewiesen wird wenn Die (iVar_B == iVar_C) "true" ergibt. Sollte dies nicht der Fall sein so wird iVar_A der Wert iVar_E zugewiesen. Ist das so korrekt?

    Frage:
    Gibt es eigentlich eine Funktion oder möglichkeit die mir die Nachkommastellen einer float fVar zurückgibt?
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  10. #70
    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
    Gut dann werde ich mich auf Punkt 1) konzentrieren. Danke!

    Frage zu Syntax:
    Code:
    int iVar_A = (iVar_B == iVar_C) ? iVar_D : iVar_E;
    Verstehe ich das richtig das iVar_A der Wert von iVar_D zugewiesen wird wenn Die (iVar_B == iVar_C) "true" ergibt. Sollte dies nicht der Fall sein so wird iVar_A der Wert iVar_E zugewiesen. Ist das so korrekt?
    Genau.
    "?" ist ein sogenannter "ternärer Operator", der genau so wirkt, wie du das beschrieben hast. Eignet sich hervorragend, um überflüssige und unübersichtliche if-Statements zu umgehen.


    Zitat Zitat von Kermit87 Beitrag anzeigen
    Frage:
    Gibt es eigentlich eine Funktion oder möglichkeit die mir die Nachkommastellen einer float fVar zurückgibt?
    Vermutlich hilft dir modf() weiter.


  11. #71
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Zitat Zitat von Commander Bello Beitrag anzeigen
    1) Spielgeschwindigkeit
    Bei TAC-normal haben wir 300 Runden, bei Marathon 900 Runden.
    Da gibt es eigentlich zwei Ansatzpunkte: Entweder, man führt die Routine nur jede x-te Runde aus, wobei sich das x aus dem Verhältnis der Runden aus der gewählten und aus der als "normal" angesehenen Rundenzahl ergibt. Oder man führt die Berechnung jede Runde aus, dann aber mit einem angepassten Prozentsatz. Letzteres wäre "unauffälliger", ersteres vermutlich minimalst weniger rechenintensiv (über die gesamte Spieldauer gesehen).
    Es ist ja momentan eh möglich den PriceNormalizingMultiplier für die unterschiedlichen Spielgeschwindigkeiten zu setzen, ohne dabei in der GameCoreDLL herumzubasteln. Dann lasse ich das einfach so!

    Prototyp zu Unit-Price-Normalisizing:
    Achtung Spoiler:
    Code:
    void CvTeam::doTurn()
    {
    	// Kermit87 - Price-Normalisizing(
    	normalizeEuropeUnitsPrices();
    	// )Kermit87 - Price-Normalisizing
    
    	PROFILE_FUNC();
    	FAssertMsg(isAlive(), "isAlive is expected to be true");
    	AI_doTurnPre();
    	testFoundingFather();
    
    	AI_doTurnPost();
    }
    
    int CvTeam::getEuropeUnitsPurchased(UnitClassTypes eIndex) const
    {
    	FAssertMsg(eIndex >= 0, "eIndex is expected to be non-negative (invalid Index)");
    	FAssertMsg(eIndex < GC.getNumUnitClassInfos(), "eIndex is expected to be within maximum bounds (invalid Index)");
    	// Kermit87 - Price-Normalisizing(
    	// return m_aiEuropeUnitsPurchased[eIndex];
    	return m_aiEuropeUnitsPurchased[eIndex] / 10000;
    	// )Kermit87 - Price-Normalisizing
    }
    
    void CvTeam::changeEuropeUnitsPurchased(UnitClassTypes eIndex, int iChange)
    {
    	FAssertMsg(eIndex >= 0, "eIndex is expected to be non-negative (invalid Index)");
    	FAssertMsg(eIndex < GC.getNumUnitClassInfos(), "eIndex is expected to be within maximum bounds (invalid Index)");
    	// Kermit87 - Price-Normalisizing(
    	//m_aiEuropeUnitsPurchased[eIndex] += iChange;
    	m_aiEuropeUnitsPurchased[eIndex] += iChange * 10000;
    	// )Kermit87 - Price-Normalisizing
    	FAssert(getEuropeUnitsPurchased(eIndex) >= 0);
    }
    
    void CvTeam::changeEuropeUnitsPurchased(UnitClassTypes eIndex, int iChange)
    {
    	FAssertMsg(eIndex >= 0, "eIndex is expected to be non-negative (invalid Index)");
    	FAssertMsg(eIndex < GC.getNumUnitClassInfos(), "eIndex is expected to be within maximum bounds (invalid Index)");
    	m_aiEuropeUnitsPurchased[eIndex] += iChange;
    	FAssert(getEuropeUnitsPurchased(eIndex) >= 0);
    }
    
    // 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"
    			m_aiEuropeUnitsPurchased[eLoopUnit] = (int) (m_aiEuropeUnitsPurchased[eLoopUnit] * GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getPriceNormalizingMultiplier());
    		}
    	}
    }
    // )Kermit87 - Price-Normalisizing
    Geändert von Kermit87 (27. September 2014 um 14:29 Uhr)
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  12. #72
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Es mag sein, dass ich gerade etwas wesentliches übersehe, aber CvTeam::changeEuropeUnitsPurchased und CvTeam::getEuropeUnitsPurchased ändern doch nur die Anzahl "gekaufter" Einheiten. Warum die Multiplikation/Division mit 10000?


  13. #73
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Das habe ich so gemacht wegen dem Runden. Unterstellen wir dem Computer mal das er immer aufrundet (was er glaube ich auch tut), dann wäre bei einem PriceNormalizingMultiplier von 0,95 unter einem m_aiEuropeUnitsPurchased[eUnitClass] Wert von 20 Schluss!

    Beispiel (jede Runde):
    Code:
    0,95 * 30 = 28.50	≈ 29	sinkend
    0,95 * 29 = 27,55	≈ 28	sinkend
    0,95 * 28 = 26,60	≈ 27	sinkend
    0,95 * 27 = 25,65	≈ 26	sinkend
    0,95 * 26 = 24,70	≈ 25	sinkend
    0,95 * 25 = 23,75	≈ 24	sinkend
    0,95 * 24 = 22,80	≈ 23	sinkend
    0,95 * 23 = 21,85	≈ 22	sinkend
    0,95 * 22 = 20,90	≈ 21	sinkend
    0,95 * 21 = 19,95	≈ 20	sinkend
    0,95 * 20 = 19,00	≈ 19	Stagnation
    0,95 * 19 = 18,05	≈ 19	Stagnation
    0,95 * 19 = 18,05	≈ 19	Stagnation
    0,95 * 19 = 18,05	≈ 19	Stagnation
    usw.
    …
    Deswegen habe ich das Komma um vier Stellen verschoben.
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

  14. #74
    Ein Platz an der Sonne Avatar von Commander Bello
    Registriert seit
    05.06.05
    Ort
    Nähe Koblenz
    Beiträge
    6.209
    Nein, tut er nicht.
    Integerwerte sind immer der Ganzzahl-Anteil. Also 28,34 wird zu 28 und 28,84 wird auch zu 28.

    Außerdem überrascht mich gerade, dass du die Anzahl der Einheiten mit dem PriceNormalizingMultiplier multiplizieren willst? Ich wäre ja vom jeweiligen Preis ausgegangen...
    Allerdings komme ich auch grade vom Radfahren zurück und bin einigermaßen erschossen... Ich gucke mir das morgen noch mal an.


  15. #75
    Basteler Avatar von Kermit87
    Registriert seit
    18.02.11
    Ort
    bei Bonn
    Beiträge
    108
    Zitat Zitat von Commander Bello Beitrag anzeigen
    Nein, tut er nicht.
    Integerwerte sind immer der Ganzzahl-Anteil. Also 28,34 wird zu 28 und 28,84 wird auch zu 28.
    OK, dann Rundet er sozusagen immer ab!

    Das künstliche erhöhen Zahlen erhöht die sogesehen die Auflösung der Berechnung. Sonst würde die Preisentwicklung teilweise stark verfälscht!

    Außerdem überrascht mich gerade, dass du die Anzahl der Einheiten mit dem PriceNormalizingMultiplier multiplizieren willst? Ich wäre ja vom jeweiligen Preis ausgegangen...
    Allerdings komme ich auch grade vom Radfahren zurück und bin einigermaßen erschossen... Ich gucke mir das morgen noch mal an.
    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?
    Geändert von Kermit87 (30. September 2014 um 01:37 Uhr)
    Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!

Seite 5 von 8 ErsteErste 12345678 LetzteLetzte

Berechtigungen

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