Neue Moddingmöglichkeiten in BtS (Civ4)

Ein Modder-Leitfaden zu Beyond the Sword
(Original unter: http://forums.civfanatics.com/showthread.php?t=229557

Über die Autoren: Kael – Chefdesigner des BtS-Szenarios „Fall from Heaven: Age of Ice“ Impaler[WrG]- Chefdesigner und Programmierer der Einheitendarstellungsarten- und „Modulares XML“-Eigenschaften BtS', Teamleiter des CCCP (Civ4 Community Core Project) Solver- Designberater und Programmierer für Beyond the Sword

Wir haben Artikel gelesen, die das in BtS kommende neue Gameplay beschreiben und spannende Hinweise, was es anbieten wird. Dieser Artikel wurde geschrieben, um einige der neuen Features genauer zu beschreiben, die vielleicht dem Durchschnittsspieler nicht viel bedeuten, aber für Modder wichtig sein werden.

Disclaimer: Bis BtS ausgeliefert werden wird, ist noch nichts endgültig festgelegt. Alles in diesem Leitfaden kann noch geändert werden. ALLES, das in BtS so ist oder nicht so ist wie hier beschrieben, kann auf letzte Änderungen oder meine Fehler beim Dokumentieren zurückzuführen sein.

1.0 Weniger Routinearbeit

Zuallererst zwei Dinge, die BtS entfernt: Modder kennen die Dateien Civ4FormationInfos.xml und Civ4CityLSystem.xml sehr gut. In Vanilla und Warlords müssen alle zum Spiel hinzugefügten Einheiten in der „formation“-Datei und alle Gebäude in der „CityLSystem“-Datei ergänzt werden. BtS schafft die Notwendigkeit ab, diese Dateien mit jedem neuen Eintrag auf den neuesten Stand bringen zu müssen.

1.1 CIV4FormationInfos.xml

Stattdessen enthält die formation-Datei alle Formationsarten. Wenn du eine neue Einheit erstellst, definierst du ihre Formationsart (z.B. FORMATION_TYPE_ANIMAL) und es verwendet diese Formationsdefinition mit der Einheit, anstatt dass eine solche für jede Einheit festgelegt werden muss. Das Folgende wäre also das Attribut einer Einheit in der CIV4UnitInfos.xml-Datei:

<FormationType>FORMATION_TYPE_DEFAULT</FormationType>

Ich werde hier eine Kopie der Definitionen einer Formationsdatei hier einfügen. Aber in der Regel werden Modder sie niemals anrühren müssen. Ich selbst habe meine verändert um einige größere Gruppen als die üblichen hinzuzufügen. Aber selbst das war einfacher als in Vanilla oder Warlords, weil ich lediglich die neue Formation erstellen und FORMATION_TYPE_DEFAULT (oder welchen Formationstyp ich auch immer verwenden wollte) zuweisen musste und die Einheiten sie zu nutzen begannen.

<UnitFormation>

               <Name>IDLE (1)</Name>
               <FormationType>FORMATION_TYPE_DEFAULT</FormationType>
               <EventMaskList>
                       <EventType>ENTITY_EVENT_IDLE</EventType>
                       <EventType>ENTITY_EVENT_SURRENDER</EventType>
                       <EventType>ENTITY_EVENT_CAPTURED</EventType>
                       <EventType>ENTITY_EVENT_GREAT_EVENT</EventType>
                       <EventType>ENTITY_EVENT_FOUND</EventType>
                       <EventType>ENTITY_EVENT_BUILD</EventType>
                       <EventType>ENTITY_EVENT_PARADROP</EventType>
                       <EventType>ENTITY_EVENT_SHOVEL</EventType>
                       <EventType>ENTITY_EVENT_DIE_ANIMATION</EventType>
               </EventMaskList>
               <UnitEntry>
                       <UnitEntryType>UNIT</UnitEntryType>
                       <Position>
                               <x>-0.0201342281879</x>
                               <y>-0.201342281879</y>
                       </Position>
                       <PositionRadius>13.0384048104</PositionRadius>
                       <Direction>3.14159265359</Direction>
                       <DirVariation>0.188679622641</DirVariation>
               </UnitEntry>
               <UnitEntry>
                       <UnitEntryType>GENERAL</UnitEntryType>
                       <Position>
                               <x>-0.332214765101</x>
                               <y>0.694630872483</y>
                       </Position>
                       <PositionRadius>22.0</PositionRadius>
                       <Direction>3.11129889367</Direction>
                       <DirVariation>0.440454310911</DirVariation>
               </UnitEntry>
               <UnitEntry>
                       <UnitEntryType>SIEGE</UnitEntryType>
                       <Position>
                               <x>-0.573825503356</x>
                               <y>-0.53355704698</y>
                       </Position>
                       <PositionRadius>25.0</PositionRadius>
                       <Direction>2.44685437739</Direction>
                       <DirVariation>0.521536192416</DirVariation>
               </UnitEntry>
       </UnitFormation>

1.2 CIV4CityLSystem.xml

Genauso wird die Lsystem-Größe eines Gebäudes in seiner „art“-Definition gesetzt (z.B. LSYSTEM_3x2) anstatt jedes Gebäude in der Lsystem-Datei definieren zu müssen.

<BuildingArtInfo>

               <Type>ART_DEF_BUILDING_PALACE</Type>
               <LSystem>LSYSTEM_3x2</LSystem>
               <bAnimated>0</bAnimated>
               <fScale>1.15</fScale>
               <fInterfaceScale>0.43</fInterfaceScale>
               <NIF>Art/Structures/Buildings/Palace/Palace.nif</NIF>
               <KFM/>
               <Button>,Art/Interface/Buttons/Buildings/Palace.dds,Art/Interface/Buttons/Buildings_Atlas.dds,6,5</Button>
       </BuildingArtInfo>

Das war's schon. Das Spiel kümmert sich um den Rest.

2.0 Modulares XML

Schonmal vorgehabt, eine neue Einheit zu einer Mod hinzuzufügen, ohne auch nur eine der Originaldateien anzurühren? Oder neue Objekte zu ergänzt und dann veränderte sich die Grundmodifikation und du musstest deine ganze Arbeit nochmal machen? Modulares XML erlaubt dem Spiel, mehrere verschiedene XML-Dateien als eine einzige zu laden.
Damit kannst du eine neue Einheit, Einheitenklasse und Einheitendarstellungsklasse hinzufügen, die nur die Daten deiner neuen Einheit enthält. Verändert sich die Mod, betrifft das deine Dateien in keinster Weise und du musst deine Veränderungen nicht erneut vornehmen.
Das ist noch vielversprechender, wenn man die Möglichkeit bedenkt, mehrere XML-Mods zusammenzufügen. Du könntest 3 verschiedene Mods nutzen, die jeweils eine neue Zivilisation, einzigartige Einheiten und Gebäude hinzufügen, und sie zusammen spielen, allein indem du sie in den entsprechenden Ordner kopierst. Keine Notwendigkeit, PHP zusammenzupuzzlen und wenn die Modder ihre Dateien updaten, ist es leicht genug, das zu übernehmen, ohne alles andere in deinem Spiel zu verändern.
Für detailliertere Informationen über modulares XML siehe Anhang A.

3.0 Einheitendarstellungsarten

Eine Menge phantastischer Arbeit, neue Einheitenmodelle für CivIV zu erstellen, ist verrichtet worden. Viele dieser Einheiten wurden als „Gewürz-“einheiten implementiert, mit gleichen Eigenschaften, aber hinzugefügt, um das Aussehen verschiedener Zivilisationen zu variieren. Leider erfordert das, dass im Spiel eine neue Einheit ergänzt wird, beispielsweise ein Schwertkämpfer, der in jeder Hinsicht, außer der „art definition“, ein Duplikat ist.
BtS erlaubt uns, „unit art types“ zu definieren, ähnlich den „building art types“ in Warlords. Dadurch kann man eine Einheitendefinition haben, aber verschiedene Zivilisationen unterschiedliche Graphiken für diese Einheit benutzen lassen. SO kann der griechische Scout dazu gebracht werden, anders auszusehen als der atztekische, ohne dass eine neue Einheit hinzugefügt werden müsste.
Um das zu ermöglichen, sind 3 Schritte nötig

3.1 Schritt 1: CIV4CivilizationsInfos.xml

In dieser Datei müssen wir den „Unit Art Style“ der Zivilisationen wie folgt festlegen:

<CivilizationInfo>

               <Type>CIVILIZATION_AMERICA</Type>
               <Description>TXT_KEY_CIV_AMERICA_DESC</Description>
               <ShortDescription>TXT_KEY_CIV_AMERICA_SHORT_DESC</ShortDescription>
               <Adjective>TXT_KEY_CIV_AMERICA_ADJECTIVE</Adjective>
               <Civilopedia>TXT_KEY_CIV_AMERICA_PEDIA</Civilopedia>
               <DefaultPlayerColor>PLAYERCOLOR_BLUE</DefaultPlayerColor>
               <ArtDefineTag>ART_DEF_CIVILIZATION_AMERICA</ArtDefineTag>
               <ArtStyleType>ARTSTYLE_EUROPEAN</ArtStyleType>
               [B]<UnitArtStyleType>UNIT_ARTSTYLE_EUROPEAN</UnitArtStyleType>[/B]

Das ist der Art, auf die Stadtanzeigearten in Warlords festgelegt wurden, sehr ähnlich, aber als ein anderes Attribut festgelegt, sodass Modder unterschiedliche Einheiten- und Stadtbauten-Anzeigearten verwenden können. Ein Wert „NONE“ wird die Zivilisation dazu bringen, die Standardmodelle der Einheiten zu verwenden.

3.2 Schritt 2: CIV4UnitArtStyleTypeInfos.xml

Das ist eine neue XML-Datei in BtS. Sie enthält die Definitionen für die Einheitenanzeigearten und erlaubt es, neue Einheitenmeshes für eine festgelegte Einheit zu nutzen. Im Beispiel unten ist die ART_DEF_UNIT_ARCHER_EURASIAN die frühe Anzeigeeinstellung, die für einen Bogenschützen benutzt wird, ART_DEF_UNIT_ARCHER_EUROPEAN wird in den mittleren und späteren Perioden verwendet. Der Bogenschütze hat, wie die meisten Einheiten, nur ein einziges UnitMesh, wie in seinem CIV4UnitInfos.xml-Element festgelegt ist. Aber Einheiten können in der Tat beliebig viele Meshes(3D-Modelle) haben - die Siedlereinheiten sind die einzigen Einheiten im Originalspiel, die mehr als ein Mesh nutzen – und um diese zu verändern, führ die Ersetzungsmeshes einfach als <UnitMeshGroup>-Elemente auf und sie werden in der Reihenfolge mit den CIV4UnitInfos-Meshes passend gemacht und ersetzen diese nacheinander. Jede Anzahl an Meshes kann in einer Einheit vorhanden seinund alle können auf diese Art ersetzt werden.
Jede Einheit, für die in einem StyleType keine Ersetzungen angegeben werden werden, wird einfach das Aussehen aus der UnitInfos.xml-Datei als Standard übernehmen und alle ARTDEFs können beliebig oft und in beliebig vielen StyleTypes aufgerufen werden, indem sie Teilen und Erstellen von Styles , die sich nur zu bestimmten Zeiten unterscheiden, um Kulturaufsplittung und -zusammenwachsen darzustellen, erlauben.

<UnitArtStyleTypeInfo>

               <Type>UNIT_ARTSTYLE_EUROPEAN</Type>
               <StyleUnits>
                       <StyleUnit>
                               <UnitType>UNIT_ARCHER</UnitType>
                               <UnitMeshGroup>
                                       <EarlyArtDefineTag>ART_DEF_UNIT_ARCHER_EURASIAN</EarlyArtDefineTag>
                                       <LateArtDefineTag>ART_DEF_UNIT_ARCHER_EUROPEAN</LateArtDefineTag>
                                       <MiddleArtDefineTag> ART_DEF_UNIT_ARCHER_EUROPEAN </MiddleArtDefineTag>
                               </UnitMeshGroup>
                       </StyleUnit>
                       <StyleUnit>
                               <UnitType>UNIT_SETTLER</UnitType>
                               <UnitMeshGroup>
                                       <EarlyArtDefineTag>ART_DEF_SETTLER_MALE_EUROPEAN</EarlyArtDefineTag>
                                       <LateArtDefineTag> ART_DEF_SETTLER_MALE_EUROPEAN </LateArtDefineTag>
                                       <MiddleArtDefineTag> ART_DEF_SETTLER_MALE_EUROPEAN </MiddleArtDefineTag>
                               </UnitMeshGroup>
                               <UnitMeshGroup>
                                       <EarlyArtDefineTag>ART_DEF_SETTLER_FEMALE </EarlyArtDefineTag>
                                       <LateArtDefineTag>ART_DEF_SETTLER_FEMALE </LateArtDefineTag>
                                       <MiddleArtDefineTag>ART_DEF_SETTLER_FEMALE </MiddleArtDefineTag>
                               </UnitMeshGroup>
                       </StyleUnit>
               </StyleUnits>
       </UnitArtStyleTypeInfo>

3.3 Schritt 3: CIV4ArtDefines_Unit.xml

Genau wie in Civ IV muss Einheitendarstellungsinformation für die Einheit existieren. Aber anstatt die der Einheit in der Civ4UnitInfos.xml (ART_DEF_UNIT_ARCHER beispielsweise) zugewiesenen Standardaussehen zu verwenden, erlaubt uns Unit Art Styles ein anderes, so wie dieses, zu nutzen:

<UnitArtInfo>

               <Type>ART_DEF_UNIT_ARCHER_EUROPEAN</Type>
               <Button>,Art/Interface/Buttons/Units/Archer.dds,Art/Interface/Buttons/Unit_Resource_Atlas.dds,4,1</Button>
               <fScale>0.44</fScale>
               <fInterfaceScale>1.0</fInterfaceScale>
               <bActAsLand>0</bActAsLand>
               <bActAsAir>0</bActAsAir>
               <NIF>Art/Units/Archer_European/Archer_European.nif</NIF>
               <KFM>Art/Units/Archer_European/Archer.kfm</KFM>
               <SHADERNIF>Art/Units/Archer_European/Archer_European_fx.nif</SHADERNIF>
               <ShadowDef>
                       <ShadowNIF>Art/Units/01_UnitShadows/UnitShadow.nif</ShadowNIF>
                       <ShadowAttachNode>BIP Pelvis</ShadowAttachNode>
                       <fShadowScale>0.85</fShadowScale>
               </ShadowDef>
               <fBattleDistance>0.35</fBattleDistance>
               <fRangedDeathTime>0.31</fRangedDeathTime>
               <bActAsRanged>1</bActAsRanged>
               <TrainSound>AS2D_UNIT_BUILD_UNIT</TrainSound>
               <AudioRunSounds>
                       <AudioRunTypeLoop/>
                       <AudioRunTypeEnd/>
               </AudioRunSounds>
       </UnitArtInfo>

Beachte, dass die Graphik für den Einheitenbutton in der UnitArtInfo definiert wird, sie wird nicht länger in der CIV4UnitInfos.xml-Datei festgelegt. Das ermöglicht uns, verschiedene Buttons für verschiedene Einheitendarstellungsarten zu verwenden. Diese Änderung wird es auch notwendig machen, dass Modder, die ältere Mods zu BtS konvertieren, all ihre Buttoninfos in die Darstellungsdatei verschieben.

Durch Veränderung des SDK kannst du alternative Arten der Einheitendarstellungslogik mit ihren eigenen XML-Dateien und logischen Strukturen erstellen, wie zum Beispiel Einheiten, die unterschiedliches Aussehen zeigen, jenachdem, wie stark sie beschädigt sind, oder welche Beförderungen sie haben.

4.0 Mod-spezifische Anzeige

Das blaue Standardinterface von Firaxis ist recht schön, aber es ist nicht allen Mods angemessen. Es ist bereits in Vanilla und Warlords möglich, die Anzeige zu verändern, aber das ist eine Spieleinstellung und kann nicht gemoddet werden. BtS ändert das. Modder können Farbe der Anzeige, Schriftarten, Leisten, alles, was sie für ihre Mod wollen, verändern.
Alles in den Unterordnern von “..\Sid Meier's Civilization 4\Resource” kann durch passende Dateien im “..\Sid Meier's Civilization 4\Beyond the Sword\Mods\[ModName]\Resource”-Ordner überschrieben werden. Dieser Ordner muss eine Civ4.thm-Datei enthalten, die wie folgt zu den zugehörigen modspezifischen Ressourcen umleitet:
// *** Control Bitmap Theme file
// Set the resource resource_path "Mods/[ModName]/Resource";
// Setup common properties include "Mods/[ModName]/Resource/Themes/Civ4/Civ4Theme.thm";
Alle möglichen Optionen detailliert auszuführen, die sich so verändern lassen, ist nicht Ziel dieses Leitfadens, es handelt sich grundsätzlich um alles, das in den früheren Versionen getan werden konnte, aber jetzt können diese Themes in Mods eingebaut werden, anstatt auf das gesamte Spiel angewendet werden zu müssen. Wenn du vorhast, ein Theme für eine eigene Mod zu erstellen, kannst du jetzt damit anfangen, indem du es in dem Vanilla- oder Warlords- „Ressource“-Ordner erstellst (denke daran, eine Sicherungskopie des Originals anzufertigen). Sobald BtS rauskommt, kannst du es in deinen Mod-Ordner kopieren und anfangen, es zu benutzen.

5.0 Neue Python-Funktionen

Firaxis hat hart daran gearbeitet, neue Python-Funktionen hinzuzufügen, ebenso wie Stellen, an denen wir Funktionen unterbrechen und unsere eigene Logik, um Geschehnisse (wie es Einheiten unmöglich zu machen, bestimmte Orte zu betreten (in der Funktion unitCannotMoveInto)zu verhindern, anwendenoder die Aktionen (wie z.B. neue Erfahrungspunktanforderungen in getExperienceNeeded zu erstellen) verändern zu können

5.1 CvEventManager.py

Diese Pythonfunktionen machen das Spiel nicht von Natur aus besser. Aber sie bieten kreativen Moddern eine Möglichkeit, phantastische Dinge zu tun. Mit wenigen Zeilen Python wird es leicht, Atombombenexplosionen abzufangen und die Welt vor ihrem Gebrauch zu warnen, ihre Wirkung zu verstärken oder gar stärkste post-apokalyptische Effekte zu triggern.

plotFeatureRemoved - der Punkt, das entfernte Feature und die Stadt (wenn der Punkt eine Stadt war) werden übergeben

plotPicked - ? nicht vom SDK aus aufgerufen

nukeExplosion -der Punkt und die explosionsverursachende Einheit werden übergeben

gotoPlotSet - ? nicht vom SDK aus aufgerufen

cityHurry - Immer aufgerufen, wenn die Produktion in einer Stadt beschleunigt wird

unitSpreadReligionAttempt - Einheit, Religion und ob die Religionsverbreitung erfolgreich war, werden übergeben

UnitGifted - Übergibt die Einheit, den alten Besitzer der Einheit und den Ort, an dem die Einheit sich befindet

unitBuildImprovement - Einheit, Art der Geländemodernisierung und ob diese fertiggestellt ist, werden übergeben

corporationFounded - Unternehmen und gründender Spieler werden übergeben

corporationSpread - Unternehmen, das sich verbreitet, besitzender Spieler und Stadt werden übergeben

corporationRemove - Unternehmen, das entfernt wurde, besitzender Spieler und Stadt werden übergeben

playerChangeStateReligion - Spieler, neue und alte Religion werden übergeben

playerGoldTrade - Geld gebender Spieler, Geldempfänger und die Geldsumme werden übergeben

5.2 CvGameUtils.py

isVictory - Ermöglicht eine Überprüfung, ob es bereits einem Spieler erlaubt ist, zu gewinnen

canDeclareWar - Um es Moddern zu möglich zu machen, Kriegserklärungen dynamisch zu ermöglichen oder nicht

unitCannotMoveInto - Um Bewegungen an Orte nach irgendwelchen Kriterien zu verhindern

canBuild - Um Bauaufträge nach irgendwelchen Kriterien zu verhindern

cannotFoundCity - Spieler und Koordinaten werden übergeben

cannotSpreadReligion - Um die Fähigkeit zur Religionsverbreitung abzuschalten

citiesDestroyFeatures - Um das Feature der Zerstörung ein- oder auszuschalten, wenn Städte erzeugt werden

canFoundCitiesOnWater - Um Städten zu ermöglichen, auf Wasserfeldern erzeugt zu werden

doCombat - um die SDK-Kampffunktion durch einen Python-Prozess zu ersetzen

getConscriptUnitType - um den durch Einberufung bereitgestellten Einheitentyp zu liefern

getCityFoundValue - Um die KI-Vorlieben für Stadtstandorte zu verändern

canPickPlot - ? nicht vom SDK aus aufgerufen

getUnitCostMod - Um Einheitenkosten dynamisch anzupassen

getBuildingCostMod - Um Gebäudekosten dynamisch anzupassen

canUpgradeAnywhere - Damit eine Einheit überall modernisiert werden kann

getWidgetHelp - Um der Maus über Hilfe zusätzlichen Text hinzuzufügen

getUpgradePriceOverride - Um Upgradekosten durch einen neuen Wert zu ersetzen

getExperienceNeeded - Um das Erfahrungssystem durch andere Werte zu ersetzen

Dies ist zur Ergänzung für zusätzliche Informationen, die an andere Python-Funktionen gesandt werden. Beispielsweise bekommt die onUnitMove-Funktion nun auch den alten Ort übergeben. Wenn du also eine Python-Aktion durchführen willst, wenn eine Einheit die kulturellen Grenzen verlässt, ist das jetzt leichter.

6.0 Help-Attribut

Dies mag nach einer Kleinigkeit ausshen, ist aber so wirkungsvoll und leicht zu benutzen, dass es besondere Erwähnung verdient. Es gibt ein neues Schemenattribut „Help“ zu Eigenschaften, Einheiten, Beförderungen, Gelände, Gebäuden, Features und Technologien. Help ist dafür vorgesehen, eine Text-Zeichenkette wie TXT_KEY_UNIT_GIANT_DEATH_ROBOT_HELP zu enthalten und alles, was diese Zeichenkette enthält wird für dieses Objekt an der Maus als Hilfetext angezeigt. In früheren Versionen mussten Modder, um zusätzliche Hilfetexte anzuzeigen, das SDK verändern. So ist das viel einfacher.

7.0 Beförderungen können das Aussehen von Einheiten verändern

Ich möchte mich im Voraus für das Fehlen von Details in diesem Abschnitt entschuldigen. Ich bin kein Graphiker und habe dieses Feature nicht selbst benutzt. Aber ich habe mit manchen Einheiten herumgespielt, die es verwenden. Grundsätzlich ist es möglich, ein Modell in Abhängigkeit von den Beförderungen, die es hat, zu verändern.
Du könntest beispielsweise ein Bombermodell machen, das, wenn es die richtige Beförderung hat, eine Bombe an seiner Unterseite zeigt. Wenn dann die Beförderung entfernt wird, sagen wir, durch eine Bombardierungsaktion, würde sich das Modell verändern, sodass die Bombe nicht länger sichtbar ist. Das Selbe könnte man mit der Anzeige von Schwertern und Äxten in den Händen der Einheiten machen, mit ihren Rüstungen, Einheiten, die von Wolken fauligen Gases oder Radioaktivität umgeben werden...
Ich möchte betonen, dass das nicht so einfach ist wie eine Beförderung zu erstellen, sie auf die Graphik zeigen zu lassen und alles funktionieren zu sehen. Das Modell muss mit eingebautem „Anhang“ erstellt werden. Standardmäßig wird er nicht angezeigt, aber mit der Beförderung erscheint er. Es wird also bedeutende Modellierungsarbeit sein, diese Funktion zu benutzen, aber ich zweifele nicht daran, dass die phantastischen Künstler hier bei den civfanatics eine Menge Spaß mit diesem Feature haben werden.

8.0 Events

Zufallsereignisse, die von Zufriedenheits- und Diplomatieboni bis zu freien Beförderungen und technologischen Durchbrüchen reichen, sind eines der neuen Spielelemente in BtS. Das Ereignissystem stellt Moddern eine große Basis zur Verfügung, darauf zu bauen, da alle Events gemodded werden können und sich neue ergänzen lassen. Man kann ein großes Feld möglicher Ereignisse allein durch XML-Modden erzeugen, aber die Events können für größere Vielseitigkeit auch durch Python verbessert werden. Anhang B dieses Leitfadens enthält einige Beispiele für Ereignisse, die eingepflegt werden können. Die hier beschriebenen Events können, zusammen mit einigen anderen, in einer Event-Mod von Solver gefunden werden. Stell dir die Mod als eine Ergänzung zu diesem Leitfaden vor, wenn du willst. Sie kann unter: (mod wird nach BtS-Release verlinkt) gefunden werden.
Es ist wichtig, die beiden grundlegenden Blöcke des Event-Systems zu verstehen: Trigger und Events. „Trigger“ sind eine Sammlung von Parametern, die Bedingungen anzeigen, wenn sie auslösen können. Trigger überprüfen, ob du die nötige Technologie, Bevölkerung, etc. hast. Wenn die Bedingungen erfüllt sind, hat der Trigger eine Chance, auszulösen. Wenn ein Trigger auslöst, eröffnet er dem Spieler die Wahl zwischen ein oder mehreren Ereignissen („Events“) (nungut, wenn es lediglich ein Ereignis ist, gibt es keine Wahl). Events selbst sind das, was die zugehörigen Ergebnisse zur Verfügung stellt, die dann den Spieler betreffen.
Spieler mögen geneigt sein, das Eventsystem als aus Ereignissen und Wahlmöglichkeiten bestehend anzusehen – das ist nicht wirklich angebracht. Jede Wahlmöglichkeit ist ein eigenes Event und der Trigger ist das, was die Auswahl zur Verfügung stellt.
Wie die meisten anderen Dinge in Civ 4 werden Events in erster Linie im SDK behandelt. Events werden von der Klasse CvEventInfo beschrieben, die die XML-Beschreibung der Events imitiert. Anhang B enthält eine Beschreibung der Ereignis-Tags in der XML-Datei. Wenn du C++ lesen kannst, möchtest du vielleicht einen Blick auf die Definition von CvEventInfo werfen. Die Übereinstimmung der Member-Funktionen der Klasse mit den XML-Werten sollte geradezu offensichtlich sein.
Event-Trigger werden in Civ4EventTriggerInfos.xml gehalten und diese Datei wird, mit Triggern im Allgemeinen, nach der Ereignisbeschreibungserklärung beschrieben werden. Für mehr Details zu Events lies den Eventführer in Anhang B durch.

9.0 Die „Python Callback Defines“-Datei

BtS ist schnell. Eine der Maßnahmen, die Firaxis ergriffen hat, um das Spiel zu beschleunigen, war, eine PythonCallbackDefines.xml-Datei einzubauen. Diese Datei hat Einträge für viele rechenintensive Pythonfunktionen, wie z.B. die folgenden

<Define>

               <DefineName>USE_CANNOT_FOUND_CITY_CALLBACK</DefineName>
               <iDefineIntVal>0</iDefineIntVal>
       </Define>

Standardmäßig (wie oben eingestellt) wird die Pythonroutine „ Found City“ nie aufgerufen werden. Möchtest du diese Funktion in deiner Mod nutzen, musst du eine modifizierte Kopie der PythonCallbackDefines.xml mit dem auf 1 gesetzten iDefineIntVal beilegen, um diesen Pythonaufruf zu ermöglichen. Die folgenden Funktionen sind standardmäßig deaktiviert:

USE_CANNOT_FOUND_CITY_CALLBACK

USE_CAN_FOUND_CITIES_ON_WATER_CALLBACK

USE_IS_PLAYER_RESEARCH_CALLBACK

USE_CAN_RESEARCH_CALLBACK

USE_CANNOT_DO_CIVIC_CALLBACK

USE_CAN_DO_CIVIC_CALLBACK

USE_CANNOT_CONSTRUCT_CALLBACK

USE_CAN_CONSTRUCT_CALLBACK

USE_CAN_DECLARE_WAR_CALLBACK

USE_CANNOT_RESEARCH_CALLBACK

USE_GET_UNIT_COST_MOD_CALLBACK

USE_GET_BUILDING_COST_MOD_CALLBACK

USE_GET_CITY_FOUND_VALUE_CALLBACK

USE_CANNOT_HANDLE_ACTION_CALLBACK

USE_CAN_BUILD_CALLBACK

USE_CANNOT_TRAIN_CALLBACK

USE_CAN_TRAIN_CALLBACK

USE_UNIT_CANNOT_MOVE_INTO_CALLBACK

USE_CANNOT_SPREAD_RELIGION_CALLBACK

USE_FINISH_TEXT_CALLBACK

USE_ON_UNIT_SET_XY_CALLBACK

USE_ON_UNIT_SELECTED_CALLBACK

USE_ON_UPDATE_CALLBACK

USE_ON_UNIT_CREATED_CALLBACK

USE_ON_UNIT_LOST_CALLBACK

Denke daran, dass diese Pythonfunktionen ausgewählt wurden, weil sie oft genug aufgerufen wurden, um merklich Rechenleistung zu benötigen, wenn sie aktiviert sind. Wenn du sie also aktiviert, um sie in deiner Mod zu verwenden, erwarte einen Performanceeinbruch auf langsameren Rechnern.

Quelle

übertragen aus dem Civforum

Übersetzt von Swoon