Ergebnis 1 bis 8 von 8

Thema: [Tortuga] Liste der DLL-Änderungen (bloß Dokumentation, keine Diskussion)

  1. #1
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896

    Poison [Tortuga] Liste der DLL-Änderungen (bloß Dokumentation, keine Diskussion)

    Bitte in diesem Thread nur dokumentieren, nicht diskutieren. Diskussionsbeiträge werden kommentarlos verschoben oder gelöscht - ich bitte um Verständnis. - W.B.



    Da ich mittlerweile einige Änderungen durchgeführt habe, will ich versuchen hier diese Änderungen zu dokumentieren. Das soll euch z.B. eine bessere Übersicht über neue XML-Eigenschaften geben, die ich hinzugefügt habe. Die Liste wird nach und nach erweitert.

    Neue XML-Eigenschaften:
    • CIV4BuildingInfo.xml:
      • FreeBuildings, RemoveBuildings: Legen fest welche Gebäunde bei Fertigstellung eines anderen Gebäudes zusätzlich gebaut werden.
        Es ist auch möglich dass sich ein Gebäude selber sofort wieder löscht, wenn es gebaut wurde. Die Syntax von FreeBuildings und RemoveBuildings ist identisch.
        Beispiel:
        Achtung Spoiler:

        Die Schiffsverbesserung „Normale Ausrüstung“, welche als Gebäude implementiert ist, löscht andere vorhandene Ausrüstungsstufen des Schiffes
        Code:
        			<FreeBuildings/>
        			<RemoveBuildings>
        				<RemoveBuilding>
        					<BuildingType>BUILDING_SHIP_GALLEON_PROVISION_LIGHT</BuildingType>
        				</RemoveBuilding>
        				<RemoveBuilding>
        					<BuildingType>BUILDING_SHIP_GALLEON_PROVISION_HEAVY</BuildingType>
        				</RemoveBuilding>
        			<RemoveBuildings>
      • bDestructable: Legt fest, ob ein Gebäude (bei Schiffen sollte man eher an Aufbauten/Ausbauten denken) wieder entfernen kann. Im Schiffsbildschirm wird ein Button (WIDGET_DESTRUCT_BUILDING ) eingeblendet, über den
        ein Menü zum Entfernen von Gebäuden eingeblendet werden kann. Gebäude, die Voraussetzungen von anderen gebauten Gebäuden sind, können nicht entfernt werden.
      • PortBuildingClass: Ist dieser Wert ungleich NONE und handelt es sich um eine „Schiffs-Stadt”, so wird geprüft ob in der Stadt, in dem sich das Schiff derzeit befindet, diese Gebäudeklasse vorhanden ist. Damit kann man den Bau von Verbesserungen auf Schiffen beispielsweise davon abhängig machen, ob ein Trockendock vorhanden ist. Man kann damit auch komplett den Bau von Verbesserungen auf hoher See unterdrücken (das ist derzeit auch das Ziel).
    • CIV4UnitInfos.xml:
      • bShipCrew: Gibt an, ob eine Einheit Berufe auf Schiffen ergreifen kann.
        Derzeit gilt, dass normale Bürger auf Schiffen nicht arbeiten können und Mitglieder einer Schiffsmannschaft nicht in normalen Städten. Man kann normale Bürger aber auf Schiffen anheuern, was sie in Matrosen (Standardeinheit für Schiffe) umwandelt.
    • CIV4PromotionInfos.xml:
      bNextPromotionIsBetter markiert eine Beförderung als Vorgängerbeförderung der nächsten in der XML-Datei. D.h. die Reihenfolge der Einträge ist wichtig. Dies wird benutzt, um das Beförderungs-Icon des Vorgängers im Interface auszublenden, wenn auch die Nachfolgebeförderung vorhanden ist. Im SDK und Python wurden die entsprechenden Methoden zum Auslesen der Eigenschaft implementiert. isNextPromotionIsBetter().




    Neue Python-Eigenschaften:
    • Screens/CvMainInterface.py:
      • Enthält die Daten für den Schiffsbildschirm. Das ist der normale Stadtbildschirm, für den an bestimmten Stellen im Code
        ein paar Änderungen vorgenommen wurden. Es wird für die Unterscheidungen die Boolean-Variable pCity.hasCityShip() getestet.
      • An der Stelle an der die Positionen der Gebäude definiert werden (BUILDING_DATA) wird auch noch ein Array BUILDING_SHIP angelegt, welches speichert, ob es ein Gebäudeslot für Schiffe oder normale Städte ist. Die Gebäudegrafik wird dann nur in einem der beiden Fälle gezeichnet.
      • MAX_NUMBER_OF_CARGO_YIELDS_PER_SCREEN: Gibt die Anzahl der Waren in der Leiste des Stadtbildschirms an. Standardwert ist 20 (bis Handelswaren/Rum).
      • ShipYields (Array): Gibt die Waren an, welche im Schiffbildschirm am unteren Rand eingeblendet werden. Es wird darauf geachtet, dass die Waren im Schiffsbildschirm an den gleichen Positionen landen, wie im normalen Schirm, wenn es zu überschneiden kommt. Zur Zeit wird das Feature nicht genutzt und dieses Array entspricht den gleichen Waren wie im Stadtbildschirm.
      • ExtraYields Dieses 3x3-Array enthält die Yield-Typen, die im Schiffsbildschirm in der Mitte eingeblendet werden. (Dort, wo üblicherweise die Stadtfelder angezeigt werden.)
      • CityManagerBackgroundShip: Die Hintergrundgrafik im linken Bereich des Bildschirms.
      • CityPlotHider: Der Grafikcontainer, welcher die Stadtfelder überdeckt.
      • Neue Buttons: Im Code nach 450, 451, 452,… suchen. Bisher gibt es Buttons zum
        • Öffnen des Stadtbildschirmes (450),
        • Anheuern eines Matrosen (451),
        • Anschluss eines Matrosen (451),
        • Einlagern von Waren in Schiffinnerem (451) und,
        • Rausschmiss eines Matrosen (452)

      Auslesen der Anzahl an Runden, die ein Schiff nicht in einer Stadt stationiert war (z.B. für Events): pUnit.getOutOfTownRounds() .


    DLL-Änderungen:
    • Liste der neuen Yields, die für die Verwendung auf Schiffen gedacht sind. Fünf Namen können sich noch ändern.
      Achtung Spoiler:
      Code:
      YIELD_SHIP_SPEED,
      YIELD_SHIP_MOBILITY,
      YIELD_SHIP_VISION,
      YIELD_SHIP_CREW_QUALITY,
      YIELD_SHIP_PROP5,
      YIELD_SHIP_PROP6,
      YIELD_SHIP_PROP7,
      YIELD_SHIP_PROP8,
      YIELD_SHIP_PROP9,

    • Es stehen folgende neue Methoden zum Auslesen/Ändern der Einheitenwerte zur Verfügung:
      Achtung Spoiler:
      Code:
      //für jede getMethode die entsprechende set-Methode. Alle auch in Python verfügbar
      int getExtra2Compat(()
      int getExtra2VisibilityRange() 
      int getExtra2Moves() 
      int getExtra2MoveDiscount() 
      int getExtra2Withdrawal() 
      int getExtra2BombardRate() 
      int getExtra2EnemyHeal() 
      int getExtra2NeutralHeal() 
      int getExtra2FriendlyHeal() 
      int getExtra2CombatPercent() 
      int getExtra2CityAttackPercent() 
      int getExtra2CityDefensePercent() 
      int getExtra2HillsAttackPercent() 
      int getExtra2HillsDefensePercent() 
      int getExtra2TerrainAttackPercent(TerrainTypes eIndex) 
      int getExtra2TerrainDefensePercent(TerrainTypes eIndex)

      Um beispielsweise die Stärke einer Einheit zu ändern, kann „setExtra2Combat(iVal)“ genutzt werden.
    • In Städten kann man mit [get|set|has]CityShip(...) die Verbindung zu einer Einheit prüfen oder setzen.
    • In Einheiten kann man mit [get|set|has]ShipCity(...) die Verbindung einer Stadt prüfen oder setzen.
    • Intern wurden viele Methoden um einen zusätzlichen Parameter für eine Stadt versehen, damit es technisch möglich ist mehrerer Städte auf ein Feld zu setzen. (Dann liefert pPlot->getCity() im Allgemeinen nicht die richtige Stadt.)
    Geändert von Writing Bull (19. August 2013 um 10:57 Uhr)

  2. #2
    hat den Blues Avatar von Elwood
    Registriert seit
    05.11.07
    Beiträge
    4.352
    Sehr schön, gut, dass du hier hinterlegst, was bereits alles möglich ist
    ... und beeindruckend , was du schon alles geschafft hast
    Geschichten zum Lesen ...

    Der seltsame Fall des William Penn | Col II --- TaC-Mod | abgebrochen
    Wahnsinn mit Methode? | Col II --- TaC-Mod | beendet | SdM April 2012
    Visiting Vvardenfell | TES III Morrowind | pausiert
    Es war einmal (noch) kein Portugal | Civ IV --- PAE-Mod | beendet
    Pack die Thermohose ein ... | Icewind Dale --- Trials of the Luremaster | läuft
    NEU: [RL] ... wie Gott nach Frankreich - Elwoods ??? | Modellbaubericht | läuft

  3. #3
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896

    Die neuen Sichtweitenlevel

    @Mods: Könnt ihr die drei Beiträge darüber löschen/verschieben? [Erledigt. - W.B.]

    Bei der Sichtweite ist jetzt eine feinere Unterteilung möglich und pro Sichtweiten-Level wird nicht ein ganzer neuer Ring um die Einheit ausgeleuchtet.
    Dazu wurde in den XML-Dateien bei allen Einheiten das Flag
    Code:
    <bLineOfSight>1</bLineOfSight>
    gesetzt. Anderenfalls wird die Blickrichtung nicht vom Programm ermittelt und der Standardwert NO_DIRECTION verwendet.

    Die Ingame-Ansicht der neuen Level sind hier http://www.civforum.de/showthread.ph...=1#post5390252 auf Screenshots dokumentiert. (Sie können sich noch ändern.)
    Erhöhte Felder, wie Hügelfelder, werden auch weiterhin angezeigt, wenn sie einen Ring weiter entfernt sind, als die Einheit normalerweise blicken kann. Aber sie werden nicht ausgeleuchtet. Das Verschanzen von Einheiten beeinflusst die Sichtweite (+1 oder +2) und in Städten wird die maximale Sichtweite mit +2 limitiert.

    Für jedes Sichtweiten-Level werden drei Arrays definiert, welche die Ausleuchtung für die drei Fälle
    C++
    In CvUnits.cpp wird eine neue Klasse CvSights definiert, die die Sichtweitenlevel enthält. (Die Level werden derzeit nicht aus XML-Dateien ausgelesen, da ich das nicht programmieren wollte.)

    • Einheit blickt in senkrechter oder horizontaler Richtung
    • Einheit blickt in diagonaler Richtung
    • Einheit besitzt keine Blickrichtung.
    angeben.
    Beispiel für Level 2:
    Achtung Spoiler:

    Code:
      int S2cardinal[9] = {
    		X,X,X,
    		1,X,1,
    		1,1,1
    	};
      int S2diagonal[9] = {
    		1,X,X,
    		1,X,X,
    		1,1,1
    	};
      int S2nodir[9]    = {1,1,1, 1,X,1, 1,1,1};


    Es sind die Einträge 0,1 und X zulässig. Die Arrays sollten als Umgebung einer Einheit aufgefasst werden, welche nach Norden
    oder Nordosten blickt. Die Mitte entspricht dem Standpunkt der Einheit. Einträge mit X werden aufgedeckt und ausgeleuchtet.
    Einträge mit 1 werden nur aufgedeckt und bei 0 bleiben sie komplett schwarz (sofern sie nicht schon aufgedeckt sind.)
    Im obigen Beispiel wird also das Feld auf dem die Einheit steht ausgeleuchtet und die drei Felder in Blickrichtung.


    Da nun im allgemeinen nicht mehr alle Felder direkt neben der Einheit ausgeleuchtet sind, kann es vorkommen, dass man auf ein Feld ziehen möchte, auf dem eine Einheit steht. Da der Spieler auf diese neue Situation vielleicht reagieren möchte, wird dieser Zug nicht ausgeführt, sondern nur das Feld aufgedeckt. Diese Abfrage befindet sich am Beginn der CvUnit::move-Routine. Diese Routine gibt nun außerdem zurück, ob ein Zug erfolgte (war vorher void, das ist wichtig für Einheitengruppen (CvSelectionGroup) ).
    Geändert von Writing Bull (06. Juni 2013 um 17:28 Uhr)

  4. #4
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896

    Änderungen der Feldertragsberechnung

    In den XML-Dateien unter XML/Terrain wurden folgende Änderungen vorgenommen.

    • Der Terrain-Ertrag wird nun direkt für die vier Landarten (Flach, Ozean, Hügel, Berg) angegeben. Das ersetzt die Definition über den "iHillChange" und "iPeakChange" Achtung, Gebirge erben nun auch die Erträge von Flachland und verhalten sich in der Berechnung analog zu Hügeln. D.h. wenn man den Abbau einer Ware dort verhindern will, muss man in den letzten iYield-Tag eine Null eintragen.
      Die Einträge haben die Form
      Code:
              <YieldIntegerTuple>
                <YieldType>YIELD_FOOD</YieldType>
                <iValue>3</iValue>  ← Ertrag im Flachland
                <iValue>2</iValue>  ← Ertrag im Ozean
                <iValue>2</iValue>  ← Ertrag auf Hügeln
                <iValue>2</iValue>  ← Ertrag auf Bergen
              </YieldIntegerTuple>
      Tipp: Der Ozean-Eintrag ist in den meisten Fällen überflüssig. Dort sollte dann der gleiche Wert wie beim Land eingetragen werden. Eine Null einzutragen ist manchmal keine gute Idee, da das gewissen "Von-Bis"-Berechnungen bei der Ertragsanzeige stören könnte.

    • Die Erträge bei Features können vom Terrain des Feldes abhängen. Dafür wurden in den Terrain-Booleans ein weiterer Tag eingefügt, in dem man die Änderungen eintragen kann. Diese habe die gleiche Form wie in Punkt 1. Beispiel:
      Code:
            <TerrainBooleans>
              <TerrainBoolean>
                <TerrainType>TERRAIN_GRASS</TerrainType>
                <bTerrain>1</bTerrain>  ← Wenn hier eine 0 steht, spielt YieldIntegerTuples keine Rolle.
      					<YieldChangeTuples>
      						<YieldIntegerTuple>
      							<YieldType>YIELD_FOOD</YieldType>
      							<iValue>0</iValue>
      							<iValue>0</iValue>
      							<iValue>1</iValue>
      							<iValue>0</iValue>
      						</YieldIntegerTuple>
      					</YieldChangeTuples>
      				</TerrainBoolean>
            <TerrainBooleans>
      Dies führt dazu, dass auf Grasland-Hügeln eine Nahrungseinheit mehr erwirtschaftet wird.

    • Das gleiche klappt auch bei Bonus-Ressourcen, wobei diese sogar auf Terrain und Features reagieren können.
      Achtung, in CIV4BonusInfos.xml gibt es drei Gruppen: TerrainBooleans, FeatureBooleans und FeatureTerrainBooleans.
      Die Angaben in Terrain-Booleans werden genau dann benutzt, wenn das Feld kein Feature hat (NO_FEATURE). Anderenfalls werden die beiden anderen Angaben benutzt.


    • Die Anzeige der Erträge in der Colopädie versucht diese Änderungen darzustellen, indem die Extremwerte der möglichen Ertragsänderungen angegeben werden.
      Das könnte sogar so weit gehen, dass für ein Yield etwas wie "-3- +2 [Yield]" angegeben werden. D.h. von negativen Werten bis pos. Werten ist alles dabei. So etwas sollte nat. der Übersicht halber vermieden werden.
    Geändert von Elwood (19. August 2013 um 21:08 Uhr)

  5. #5
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896

    See-Hütten

    Es können jetzt Goodys auf dem Meer gefunden werden. Dafür habe ich ein Improvement aus RaR 1.5 übernommen, ein 3D-Model (Wrack) selber erschaffen und den C++-Code geschrieben.

    Goody-Einträge haben jetzt die neuen Eigenschaften bWaterGoody und iMaxOccur (z.B. für einmalige Events.)

    Beispieleintrag für ein Goody: Bei diesem Event wird Silber in ein Schiff geladen, wenn genug Platz vorhanden ist.
    Code:
        <GoodyInfo>
          <Type>GOODY_FOUND_SILVER</Type>
          <Description>TXT_KEY_SHIPWRECKED_FOUND_YIELD</Description>
          <Sound>AS2D_GOODY_GOLD</Sound>
          <AnnounceText>TXT_KEY_GOODY_SHIPWRECKED</AnnounceText>
          <ChiefText>TXT_KEY_CHIEF_SHIPWRECKED</ChiefText>
          <iGold>20</iGold>
          <iGoldRand1>10</iGoldRand1>
          <iGoldRand2>0</iGoldRand2>
          <iMapOffset>0</iMapOffset>
          <iMapRange>0</iMapRange>
          <iMapProb>0</iMapProb>
          <iExperience>0</iExperience>
          <iHealing>0</iHealing>
          <iDamagePrereq>0</iDamagePrereq>
          <bBad>0</bBad>
          <bWar>0</bWar>
          <UnitClass>UNITCLASS_SILVER</UnitClass>
          <TeachUnitClass>NONE</TeachUnitClass>
          <iCityGoodyWeight>0</iCityGoodyWeight>
          <bWaterGoody>1</bWaterGoody>
          <iMaxOccur>0</iMaxOccur>
          <GoodyWeights/>
        </GoodyInfo>

  6. #6
    hat den Blues Avatar von Elwood
    Registriert seit
    05.11.07
    Beiträge
    4.352
    Wunderbar , werde mir beides so bald als möglich ansehen. Wäre es möglich, dass Treibgut/Schiffswracks dynamisch im Spiel neu generiert werden? Also bspw. nachdem ein Sturm getobt hat oder als Ereignis der Machart "Die Galeone xyz verließ den Hafen von abc und wird seitdem vermisst ..."


    Bitte hier nur dokumentieren, nicht diskutieren. Diskussion zu deiner Frage hier. - W.B.
    Geändert von Writing Bull (19. August 2013 um 10:53 Uhr)
    Geschichten zum Lesen ...

    Der seltsame Fall des William Penn | Col II --- TaC-Mod | abgebrochen
    Wahnsinn mit Methode? | Col II --- TaC-Mod | beendet | SdM April 2012
    Visiting Vvardenfell | TES III Morrowind | pausiert
    Es war einmal (noch) kein Portugal | Civ IV --- PAE-Mod | beendet
    Pack die Thermohose ein ... | Icewind Dale --- Trials of the Luremaster | läuft
    NEU: [RL] ... wie Gott nach Frankreich - Elwoods ??? | Modellbaubericht | läuft

  7. #7
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896

    Bauaufträge für Nichtpioniere

    In CIV4BuildInfos, CIV4ProfessionInfos und CIV4UnitInfos wurde der Eintrag iWorkGroup aufgenommen. (In der letztgenannten Datei hat der Wert aber derzeit keinerlei Bedeutung und wurde nur aufgenommen, weil es dort auch den Eintrage iWorkRate gibt.)
    Es können nur die Bauaufträge ausgeführt werden, die den gleichen iWorkGroup-Eintrag haben wie der Beruf. Der Wert iWorkGroup=0 ist den normalen Bauaufträgen der Pioniere zugeordnet.

    Damit ist es möglich Einheiten mehrründige Aufträge zuzuweisen, die dann wie Bauaufträge bearbeitet werden. Beispielsweise kann ein Späher ein Dschungelfeld "erkunden". Dabei ist zu beachten, dass man die neue Aktion auch einem KI-Skript bekanntmachen sollte. In meinem Beispiel musste die Funktion von UNITAI_EXPLORE erweitert werden.

  8. #8
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896

    Verbindung von Schiffscrew mit Schiffsaktionen

    Vor ein paar Monaten war ich an der Stelle stehen geblieben, bei der Schiffe eine Besatzung(Crew) besitzen und die Besatzung bestimmte Crew-Beförderungen erhalten kann. Diese Crew-Beförderungen bestehen derzeit aus
    "SAILOR_PROMOTION1-5" (Deckschrubber bis Seeveteran), welche die Erfahrung der Einheit darstellen.
    Dazu kommt natürlich noch der Beruf, den die Einheit an Bord ausführt und die Einheitenklasse. (Die Unterscheidung von Beruf und Klasse kann wie schon im normalen Col zu Verwirrungen führen...)

    Es blieb die Frage offen, wie das Spiel auf die Besatzung reagiert. Daher habe ich die Schiffsaktionen jetzt mit der Besatzung verzahnt, was ich hier kurz skizzieren möchte.

    Meine Probleme bei der Realisation:
    1. Die Crew-Eigenschaften sollten sich innerhalb einer Runde nicht ändern. (Vermeiden von MM innerhalb der Runde)
    Daher kann muss der Status einmal pro Runde gespeichert werden, was eine extra Datenstruktur erfordert.
    2. Es wäre für die KI wünschenswert, wenn man das vorhandensein einer Crew für KI-Schiffe simulieren kann, ohne im Hintergrund eine "Schiffsstadt" anzulegen. Dafür wird ebenfalls eine extra Datenstruktur gebraucht.
    3. Unberücksichtigt habe ich die Interaktion zwischen mehreren Schiffen/Angreifern, weil es dann noch komplexer geworden wäre.

    => CvUnit-Klasse wurde um eine Variable der folgendene Struktur (die bei Bedarf erweitert werden kann) erweitert:
    Code:
    struct CvShipCrewSkills{
      int sumCrewLvl;
      int numCrewPromotions[NUM_SAILOR_PROMOTIONS];
      int numCrewProfessions[NUM_SAILOR_PROFESSIONS];
      int numCrewTypes[NUM_SAILOR_TYPES];
    };
    Für die Interpretation der Arraypositionen sei auf CvEnums.h verwiesen

    Die Aktionen der Schiffe testen ungefähr so, ob sie erlaubt sind:
    Code:
    bool CvUnit::isActionAvailable( CvUnit* pDefender, ActionTypes eAction ) const{
      CvShipCrewSkills skills = this->getCrewSkills();
    
      switch( eAction ){
        case ACTION_NORMAL:
          return true; 
        case ACTION_BUSS:
          if( skills.sumCrewLvl > 2 ) return true; 
    		// usw
      }
      return false;
    }
    Wenn die Crew-Eigenschaften, die Gewinnwahrscheinlichkeit einer Aktion beeinflussen sollen, ist CvUnit::getActionModifier die stelle, an der man ansetzen kann. Das Info-Popup einer Aktion wird in CvUnit:arseAction gesteuert.

    Leider habe ich für die Aktionen keine XML-Datenstrukturen erschaffen. Die werden direkt in der DLL definiert :fftt: Die Liste der Aktionen ist daher nicht ganz so einfach erweiterbar.

Berechtigungen

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