Mechanized Assault & eXploration Reloaded



#1 Jun 09, 2009 8:20 pm
alzi alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Posts: 339


Subject: Neue Einheiten XMLs
Ich habe gestern mit Eiko ein wenig darüber geredet, wie wir das mit der cUnit Sache neu umsetzten können, wo Hackar ja schon eine ganze weile dran ist. Wir sind zu dem Entschluss gekommen, dass dieser Monsterumbau auf einen Schlag wohl nicht durchzuführen sein wird. Unsere Idee war es erstmal langsam ein paar einzelne Dinge schon mal auf eine gemeinsame Unit Klasse vorzubereiten. Als erster Punkt standen dafür neue, mehr an das tatsächliche Spielverhalten angepasste Einheiten XMLs auf dem Plan. Wenn wir diese kompakt und passend hinbekommen, kann das die Arbeit für Hackar deutlich vereinfachen, da er dann genauer ablesen kann, was wir den exakt brauchen. Meine Meinung dazu ist, dass wir die XMLs dann so gestallten, dass man aus Ihnen möglichst alle Informationen so raus bekommt, wie man sie dann im Spiel braucht und nicht noch Unmengen zusätzlichen Schnickschnack für die Zukunft einplant. Sachen für die Zukunft können auch in Zukunft noch ergänzt werden. Das soll aber nicht heißen, dass die XMLs genau so aufgebaut werden sollen wie ganz früher die INIs! Besonders so Sachen wie "is_connector", "is_bridge" etc. sollten unbedingt nicht drin stehen, doch man muss die entsprechenden Fähigkeiten halt irgendwie anders verpacken und das möglichst ohne den halben Quellcode der damit arbeitet wieder umzuschreiben.

Ich bin mal durch eine momentane data.xml, und die temporäre Konverter Funktion im Code durchgegangen und habe raus geschrieben, welche Informationen im Spiel noch über die IDs der Einheiten dazugedichtet werden und welche Informationen meines Erachtens unnötig in der XML stehen.
Die Transporter data.xml habe ich als refernez genommen. Ich geh dann jetzt mal alle Punkte nacheinander Durch:

Sachen die noch Fehlen:

-> is_stealth_land - Der Infiltrator ist die einzige Einheit, die dieses Attribut besitzt. Bis jetzt wird dadurch konvertiert. Das sollte aber als extra Punkt in die XML

-> us_stealth_sea - für die Einheiten APC und Submarine. Bis jetzt gehts nach ID, sollte aber auch in die XML.

-> is_connector - hier brauchen wir Ersatz. So was sollte kein Attribut sein. Nur was gibts als Ersatz?! Ich denke wir bräuchten einmal ein Attribut "is_blocking" bzw. eher das Gegenteil, um sicherzustellen, dass Fahrzeuge auf das Feld Fahren können. Evtl. auch eher so etwas wie "surface_position" und da dann die Auswahl unter Einheiten ( für Straßen, Plattform, Brücke. Das würde heißen diese Einheit kann von anderen Einheiten überfahren werden), dann normal (für all das, was ein Feld blockiert) und dann eben noch über Einheiten (für den Connector). Das ganze wäre denke ich mittlerweile relativ gut umsetzbar, da Eiko ja mal die meisten Abfragen, die diese Sache verwenden in cMap::possiblePlace zusammengebracht hat.

-> is_road - selbe wie Connector. Zusätzlich bräuchten wir dann aber noch so was wie "makes_driving_faster".

-> is_bridge - müsste eigentlich nur über dieses position Attribut ersetzbar sein.

-> is_platform - hier bräuchten wir auch noch ein Attribut wie "can_be_overbuild". Ist evtl. auch interessant für die Connectoren. da müsste man da aber noch mal differenzieren ob die Einheit nach dem überbauen bestehen bleibt oder ersetzt wird.

-> is_pad - "can_be_landed_on" oder ähnlich...

->is_mine - hier sollte so was wie "can_mine_resources" her.

-> is_annimated - verwendet nur das Radar. Sollte auch in die XML. Am besten in das letzte Abteil "Graphics" zu dem zeug mit Overlay usw.

-> build_allien - ich würde sagen Aliens nehmen wir erstmal komplett aus dem Spiel und auch aus den XMLs. Wenn es soweit ist. ist das ganz schnell wieder drinnen. Außerdem würde ich das dann sowieso mit dem "can_build" Attribut zusammen nehmen. mehr dazu später.

-> build_on_water - so was brauchen wir auf jeden fall auch. Man muss ja wissen welche Einheiten auf Wasser gebaut werden müssen.

-> is_alien - würde ich vorerst raus nehmen.

-> can_work - hier ist die Frage ob wir dieses Attribut wirklich in der XMl brauchen. Im Moment holt sich das der Data Konverter dadurch, dass er schaut ob die Einheit Energie verbraucht oder produziert. Das deckt alle Einheiten ab, die einschaltbar sind. Evtl. ist das auch sinnvoll, das so zu lassen.

-> can_build - bis jetzt gibt es hier die Auswahl "BIG", "SMALL", "SEA", "AIR", "MAN", "NONE". In den XMLs ist es so drinnen, dass jede Einheit ein Attribut "Is_Produced_by" besitzt. Das wird aber vom Konverter nicht genutzt, da hier Konflikte entstehen könnten, wenn sowohl Flugzeuge als auch Schiffe die selbe Einheit bei Produced_by drin stehen hätten und außerdem könnte man die liste dann ja nur am Ende wenn alle Einheiten fertig geladen wurden erstellen und das war mir damals zu kompliziert, da ich dachte die Konverter Funktion wird sowieso nur sehr kurz bestehen (wie man sich doch irren kann ^^). Ansonnsten müsste Produced_by das ganz gut ersetzten können, aber ich fände dies Listen würden auch Nachteile mit sich bringen. Zum Beispiel wenn jemand eine neue Einheit entwickelt, die auch kleine Gebäude bauen kann. Dann müsste an diese Einheit wieder in ALLEN kleinen Gebäuden in die Produced_by Liste aufnehmen. Evtl wäre es also durchaus sinnvoll Einheiten in Gruppen wie LIGHT_TANK, HEAVY_TANK, PLANE, SHIP, LIGHT_BUILDING, etc. aufzuteilen und dannach die Baumöglichkeiten aufteilen. Man könnte zwar die Standardeinheiten nicht mehr so expliziet nur in einzelnen fabriken bauen lassen, aber die Frage ist ob das überhaupt wirklich wichtig ist. Für später könnten hier ja jederzeit vom Einheiten ersteller neue Gruppen hinzugefügt werden. Im code dann einfach ein string vergleich, was gebaut werden kann, und zu welcher Gruppe die zu bauende Einheit gehört.

-> build_by_big würde durch die obige Änderung wegfallen.

-> is_base würde durch diese "surface_position" Sache ersetzt werden.

-> can_drive_and_fire muss auch rein.
Albert Ziegenhagel
↑  ↓

#2 Jun 09, 2009 8:21 pm
alzi alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Posts: 339


Subject: Re: Neue Einheiten XMLs
Sachen die meiner Meinung nach raus können:

-> Is_Controllable es gibt im Code eigentlich nichts, dass bis jetzt auch nur annährend so etwas überprüft. Das ergibt sich eigentlich daraus, ob eine Einheit bauen, fahren, schießen, etc. kann und daraus ergeben sich dann auch die Menüunterpunkte. Um aber die dann richtig hin zu bekommen, bräuchte man z.B. noch so was wie "can_be_self_destroyed". z.b. für die explode-minen.

-> Size_Length/Widht ist finde ich nicht nötig. Wir sind weit davon entfernt verschiedene Gebäudegrößen zu unterstützen. Nur eben dieses "is_big" ist dann nötig.

-> Is_Target_ ... kann finde ich raus, weil es doppelt mir "Allowed_Targets" in der Waffen Sektion ist. Das macht finde ich kaum einen sinn zu definieren, von welchen Einheiten eine Einheit angegriffen werden kann und dann auch noch welche Einheiten eine Einheit überhaupt Angreifen kann. Also ich finde zumindest kaum ein Beispiel wo sich das mal unterscheiden sollte und außerdem ist unser Code im Moment noch gar nicht auf eine solche Doppelabfrage ausgelegt, daher würde ich es erstmal bei einem einfache "can_attack" Attribut belassen, wie es auch vom Code unterstützt wird.

-> Built_Costs(_Max) Ich weiß nicht genau, wie das mit dem maximalen Wert ist, aber mit kommt es so vor, als wenn er immer das Dreifache des normalen Werts ist. Wenn das der Fall ist, dann brauchen wir das ja nicht. Mal drei kann auch das Programm rechnen. Und zum Normalwert: Wenn man aus dem original die Attribute der Einheiten aus der Resdatei extrahiert, dann gibt es da nicht genau die Baukosten. Dafür steht da ein Wert drin, der immer die Hälfte der Baukosten bei Fahrzeugen oder ein drittel der Baukosten bei Gebäuden (oder auch umgekehrt, weiß nicht mehr genau) ist. Dieser Wert wird dann z.b. auch benötigt um zu berechnen wie teuer Reparaturen sind oder wie lange Einheiten außergefecht gesetzt bleiben. Evtl. sollten wir lieber diesen Originalwert reinschreiben als das alles zurückzurechnen?!?

-> Is_Produced_by Siehe "can_build"

-> Turret_Gfx kann raus finde ich. Noch zu sehr Zukunft und der Code ist weit entfernt von so was.

-> Shot_Trajectory selbes wie Turret_Gfx

-> Ammo_Type selbes wie Turret_Gfx & Shot_Trajectory

-> Allowed_Targets Siehe "Is_Target_ ..."

-> Destination_Area/Destination_Type Mit so speziellen Treffertypen kann unser Code noch lange nicht umgehen und das wird er auch lange nicht können. Von daher würde ich sagen das kommt raus und lieber ein einfaches "cluster_attack" für den Raketenwerfer.

-> Movement_Allowed Ist auch hier zu speziell. So was kann unser Code nicht. Es gibt hierfür die Regel can_attack_and_fire, die nicht mit einer Anzahl von Bewegungspunkten, die frei sind bis der Schuss verloren geht vereinbar sind. Von daher würde ich sagen auch das kommt raus.

-> Gets_Experience, Can_Dive, Landing_Type, Can_Upgrade, Is_Kamikaze, Is_Infrastructure alles raus.

-> Self_Repair_Type Gebäude machen dies generell. Evtl. bräuchte man dieses Attribut, da wir ja die Trennung zwischen Gebäuden und Fahrzeugen abschaffen. Aber ich denke die Sache mit dem "mit Material oder ohne" ist unnötig.

-> Can_Launch_SRBM, Energy_Shield_Strength, Energy_Shield_Size raus!

-> Range_ ... ist im Moment völlig unnötig da zu unterscheiden. Würde ich auf ein einziges "Scan" Attribut zusammenfassen.

-> Costs_ ... / Factor_ ... Raus! Das hängt von anderen spielinternen Regeln ab und wird sich vermutlich auch erstmal nicht ändern.

-> Capacity_ ... Das ist evtl. ganz gut, das zu differenzieren, aber im Moment im Code nicht vorgesehen und ist glaube ich auch ne menge Arbeit das zu ändern. Hier muss man überlegen ob man sich die Arbeit macht, oder ob wir doch nur die Aufteilung in "cargo" und "can_load" machen, so wie früher. Reicht nämlich eigentlich für alle bestehenden Sachen aus. Besonders Kompliziert wird das ganze mit dem Umbau nämlich wenn es darum geht das Laden der Einheiten auch auf "Can_Use_Unit_As_Garage" anzupassen.

So das wars dann erstmal mit meinem Megapost. Bitte Senf dazu abgeben Smiling
Albert Ziegenhagel
↑  ↓

#3 Jun 10, 2009 4:10 pm
Toranaga Toranaga Offline
Developer
Registered since: Dec 28, 2005
Posts: 232


Subject: Re: Neue Einheiten XMLs
Klingt sehr gut! Vor allem der Satz "Sachen für die Zukunft können auch in Zukunft noch ergänzt werden" gefällt mit sehr gut! Natürlich für die Zukunft offen sein, aber nicht schon alles für die Zukunft machen - das macht alles nur unnötig kompliziert.

Deine Vorschläge klingen für mich alle plausibel. Ob etwas fehlt oder zuviel ist, kann ich so ad hoc nicht sagen, aber das wird man dann sicher in der Umsetzung sehen.

Ein anderer Bereich zum Aufräumen und wo man nochmal sehen kann, was es alles für (zum großen Teil unbenutzte) Attribute gibt, ist sUnitData. Da kann dann auch fast alles raus. Aber das passiert ja durch die neue cUnit sowieso.
Paul Grathwohl (pagra)
↑  ↓

#4 Jun 11, 2009 3:14 pm
alzi alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Posts: 339


Subject: Re: Neue Einheiten XMLs
Habe vergessen, das Hackar im development forum nicht schreiben kann. deswegen hat er mir eine pm mit der antwort geschrieben, die ich jetzt hier poste. Wäre evtl. ganz gut wenn einer der Moderatoren das hier in den normalen M.A.X.R Bereich verschieben könnte Smiling

Quote:
meine gedanken zu xml sachen (da ich auf dein post iwie nicht antworten kann:
Zitat:
is_road - selbe wie Connector. Zusätzlich bräuchten wir dann aber noch so was wie "makes_driving_faster".
schlage gleich modifies_speed vor, angabe in %
Zitat:
is_platform
"überbaubar" ist gute idee. wird dann auch für connectoren gelten
Zitat:
is_bridge
hier schlafe ich "überfahrbar" vor, passt auch zu connectoren und ggf minen.
Zitat:
is_mine
habe bei mir generell als "generating" drin, für alle ressourcen, incl. energie und credits
Zitat:
can_work
das sollte nicht von dem energieverbrauch abhängen. könnte ja jede beliebige ressource verbrauchen. und power stations sind ja auch abschaltbar. habe bei mir als "activable" drin.
Zitat:
can_build
ich habe das so gelöst, dass die einheit, die etwas bauen kann, die liste mit den einheiten bekommt, die sie bauen kann.
Zitat:
is_base
bei mir ConnectToBase. bestimmt zb auch ob connectoren zu den benachbarten units gezeichnet werden sollen.
Zitat:
can_drive_and_fire
aufgesplittet drin (klar)
Zitat:
Is_Controllable
ich ggf für die alien-gebäude interessant, die man nicht auswählen kann. konnte man im original die straße auswählen?
Zitat:
Allowed_Targets
die frage ist hier auch, ob man nicht wie bei der produktion die einzelne einheiten speichern soll, oder 3-4 kategorien ausreichen
Zitat:
Movement_Allowed
da die bewegung von den schüßen getrennt sind, bräuchte man ein attribut, der sagt, ob die sich gegenseitig beeinflüßen ( )
Zitat:
Gets_Experience, Can_Dive, Can_Upgrade, Is_Kamikaze
warum soll es raus?
Zitat:
Self_Repair_Type
ich denke generelles 'selfRepairRate' und 'selfRepairCost' wäre sinnvoll.
Zitat:
Factor
ich weiß nicht welches factor hier gemeint ist, aber bei fabriken brauchen wir sowas. zB die trainingshalle hat nur den Factor x1.
dazu kommt noch der ressourcen verbrauch pro runde. die trainingshalle hat hier auch nur 1. (bei mir ProducingMaxMult und ProducingMPR)
Zitat:
Capacity
bei mir drin. für ressourcen (für je ein) und fürs beladen. da gibts auch die liste mit den einheiten, die geladen werden können.

noch was aus eigener Sache:
bin gerade ziemlich in der zeitnot in der uni und bei der arbeit. komme letzte zeit nur noch wenig zum programmieren 'privater' projekte. daher bitte ich um entschuldigung, dass es sich hinzieht

Albert Ziegenhagel
↑  ↓

#5 Jun 11, 2009 5:17 pm
alzi alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Posts: 339


Subject: Re: Neue Einheiten XMLs
Und dann gehts auch gleich weiter mit Kommentaren von mir:

Ersteinmal habe ich weiter nach Dingen gesucht die noch fehlen und mir dazu mal die draw bzw. render methoden nochmal genau angeschaut. Uns fehlen da noch ein paar Sachen, die wiedermal von "is_road" etc. abhängen.

-> sowas wie show_demage_effect. Soll heißen, Straßen, Plattformen, etc. zeigen nicht diesen Raucheffekt, wenn sie beschädigt sind. Das muss der Code ja irgendwo her nehmen.

-> has_beton der Zeichencode muss unterscheiden können ob unter ein Gebäude der Betonboden gemalt werden muss.

-> has_player_color der Zeichencode muss unterscheiden können ob die Spielerfarbe für diese Einheit geblittet werden muss.

so und nun zu Hackars Antwort:

Quote:
schlage gleich modifies_speed vor, angabe in %
jup das ist durchaus sinnvoll und umzusetzen Smiling

Quote:
Zitat:
is_bridge
hier schlafe ich "überfahrbar" vor, passt auch zu connectoren und ggf minen.
jo überfahrbar, wäre auch eine möglichkeit. Wäre so ziemlich das gleiche wie mein "is_blocking". Nur würde ich halt wirklich noch die extra unterscheidung über "surface_position" machen, in der festgelegt wird ob die einheit unter, über oder auf gleichem level mit anderen einheiten steht. Das ist wichtig fürs zeichnen! Da fällt mir grade aber auch ein, dass wir noch einen zwischenschritt brauchen. Für Brücken, die sowohl über Fahrzeugen (wenn ein Schiff drunter steht) als auch unter Einheiten gemalt werden müssen können.

Quote:
Zitat:
is_mine
habe bei mir generell als "generating" drin, für alle ressourcen, incl. energie und credits
jo, das ist auch eine Möglichkeit. Bringt etwas mehr Umbauaktionen im Code mit sich, aber die dürften überschaubar sein.

Quote:
can_work
das sollte nicht von dem energieverbrauch abhängen. könnte ja jede beliebige ressource verbrauchen. und power stations sind ja auch abschaltbar. habe bei mir als "activable" drin.
Sofern wir irgendwann Einheiten haben, die auch andere Resourcen als Energie verbrauchen, wäre das villt wirklich sinnvoll, aber ich denke das System von MAX ist, dass jede Einheit die andere Resourcen außer Energie verwertet immer dazu auch Energie benötigt. Aber eigentlich weiß man ja wirklich nie was noch so kommt und prinzipiel kann der Code das schon jetzt.
Das nach dem bestehenden Modell übrigens Power-Stations auch ein- und ausschaltbar sind, liegt daran, dass nicht nur geprüft wird ob die Einheit Energie verbraucht, sondern auch ob sie welche produziert.

Quote:
can_build
ich habe das so gelöst, dass die einheit, die etwas bauen kann, die liste mit den einheiten bekommt, die sie bauen kann.
In meinem Text habe ich ja erläutert, wieso das evtl. nicht das Sinnvollste ist. Da muss man jetzt halt abwägen Wink

Quote:
is_base
bei mir ConnectToBase. bestimmt zb auch ob connectoren zu den benachbarten units gezeichnet werden sollen.
"is_base" hat momentan eine ganz andere Funktion. Es bedeutet, dass eine Einheit unter anderen Gebäuden ist. Ist z.b. gesetzt bei Straßen, Brücken, Minen, usw. Deswegen habe ich ja geschrieben, dass es durch die "surface_position" ersetzt werden soll.

Quote:
can_drive_and_fire
aufgesplittet drin (klar)
dieses Attribut, hat nicht einfach zu bedeuten, dass die Einheit sowohl can_attack und auch can_drive hat, sondern dass die Einheit, nachdem sie gefahren ist, immernoch Schießen kann, also nur langsam mit den Bewegungspunkten die Schüsse verliert und nicht sofort nach dem ersten Schritt. Das ersetzt also quasi das Movement_Allowed. Aber nur quasi, denn Movement_allowed will vorgeben, dass eine bestimmte Anzahl von Bewgungspunkten frei ist, bis nicht mehr geschossen werden kann. Diese Anzahl kann aber nicht von Beginn an fest angeben werden. Sie wird vom Code berechnet und ändert sich z.b. auch durch Forschung.

Quote:
Is_Controllable
ich ggf für die alien-gebäude interessant, die man nicht auswählen kann. konnte man im original die straße auswählen?
Allien Gebäude würde ich erstmal nur im Hinterkopf behalten. Jetzt für die schon Dinge in die XMLs aufzunehmen würde ich unbedingt vermeiden. Machts nur unnötig kompliziert. Das dauert sowieso noch bis wir sie implementieren.

Quote:
Gets_Experience, Can_Dive, Can_Upgrade, Is_Kamikaze
warum soll es raus?
Weil es im Moment einfach noch überhaupt keine Funktion hat und in anher Zukunft auch erstmal keine haben wird.

Quote:
Self_Repair_Type
ich denke generelles 'selfRepairRate' und 'selfRepairCost' wäre sinnvoll.
wozu brauchen wir das? Es gibt noch nirgends verschiedene Raten und feste Kosten. Wie Gebäude sich selbst reparieren errechnet sich aus Ihren Baukosten, so wie im Original. Was anderes wird es auch hier in naher Zukunft denke ich nicht geben.

Quote:
Factor
ich weiß nicht welches factor hier gemeint ist, aber bei fabriken brauchen wir sowas. zB die trainingshalle hat nur den Factor x1.
dazu kommt noch der ressourcen verbrauch pro runde. die trainingshalle hat hier auch nur 1. (bei mir ProducingMaxMult und ProducingMPR)
Ich meine ein anderes Factor. z.b. "Factor_Water" oder "Factor_Coast". Das soll dazu dienen um welchen Faktor sich der Wegpunkteverbrauch von Einheiten ändert, je nachdem auf welchem Gelände sie sich bewegen. Macht Ihmo keinen sinn. Eher sollte das Gelände die Eigenschaft besitzen die Kosten zu ändern (wie die straße) als dass es bei der Einheit drin steht. Und wie gesagt, kann unser Code sowas auch noch garnicht.
Aber du hast recht, den anderen Faktor Wert brauchen wir auch. Im Moment hängt das glaub einfach davon ob, ob die Fabrik Menschen herstellen kann.

Quote:
Capacity
bei mir drin. für ressourcen (für je ein) und fürs beladen. da gibts auch die liste mit den einheiten, die geladen werden können.
Habe hier ja beschrieben warum das evtl nicht das sinnvollste ist.

MFG
alzi
Albert Ziegenhagel
↑  ↓

#6 Jun 13, 2009 2:51 pm
HackAR Offline
Developer
Registered since: Mar 01, 2009
Posts: 37


Subject: Re: Neue Einheiten XMLs
Quote:
show_demage_effect
bei mir: showDamage
Quote:
has_beton
bei mir: drawUnderground
Quote:
Movement_allowed will vorgeben, dass eine bestimmte Anzahl von Bewgungspunkten frei ist, bis nicht mehr geschossen werden kann.
Soweit ich weiß wird es im Original über Prozente berechnet. Wenn Unit x % der Bewegungspunkte übrig hat, so hat sie auch x % der schüße übrig (abgerundet)
Quote:
Jetzt für die schon Dinge in die XMLs aufzunehmen würde ich unbedingt vermeiden.
Ich schlage vor die boolean sachen nur dann in die xml reinzuschreiben, wenn sie wahr sind.
Quote:
Gets_Experience, Can_Dive, Can_Upgrade, Is_Kamikaze
Wenn wir Einheiten einheitlich behaldeln wollen, brauchen wir sowas...
Quote:
Wie Gebäude sich selbst reparieren errechnet sich aus Ihren Baukosten, so wie im Original.
Komisch. ich dachte die Gebäude reparieren sich immer 2hp/round unabhängig von den Kosten...
Quote:
Eher sollte das Gelände die Eigenschaft besitzen die Kosten zu ändern (wie die straße) als dass es bei der Einheit drin steht.
dann haben wir noch die sonderfälle scout, geolog, ...
Quote:
Capacity
wie ist Can_Use_Unit_As_Garage zu verstehen?
↑  ↓

#7 Jul 07, 2009 12:19 pm
alzi alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Posts: 339


Subject: Re: Neue Einheiten XMLs
So, ich habe dann mal einen Prototyp einer neuen data.xml zusammengestellt um mir das ganze vor Augen führen zu können:

DownloadSource code (XML):
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <Unit ID="0 1" name="air_transport">
  3.   <!-- ID ist eine einmalige Nummer, über die dieser Einheitentyp identifiziert wird-->
  4.   <!-- name ist der Einheitenname, der benutzt wird, wenn keine Übersetzung für die ID gefunden wird-->
  5.    
  6.   <Header>
  7.  
  8.     <Author name="Someone">
  9.     <Editor name="Someone" time="2007-09-30 13:05:00"/>
  10.     </Author>
  11.     <!-- "Author" ist der ursprüngliche Ersteller. Wichtiger sind die Einträge in "Editor". Der letzte Editor wird vom Spiel genannt, wenn es die XML-Datei nicht auswerten kann. Dadurch hat man einen Ansprechpartner als DAU. -->
  12.  
  13.     <Game_Version text="0.2.5"/>
  14.     <!--"Game_Version" gibt die Spiel-Version an, ab der die Einheit im Spiel funktioniert.-->
  15.   </Header>
  16.   <Description lang="ENG">
  17.     Air Transport\
  18. \
  19. Heavy aircraft capable of holding up to three ground units.
  20.   </Description>
  21.   <!-- Der "Description"-Block dient der spiel-internen Erklärung, wenn keine Übersetzung gefunden wurde. -->
  22.  
  23.   <Weapon>
  24.       <Muzzle_Type Const="None"/>
  25.       <!-- Typ des Geschosses -->
  26.       <!-- None: Kein Geschoss -->
  27.       <!-- Big: Ein großes Geschoss -->
  28.       <!-- Rocket: Eine normale Rackete -->
  29.       <!-- Small: Ein kleines Geschoss -->
  30.       <!-- Med: Ein mittleres Geschoss -->
  31.       <!-- Med_Long: Ein mittelgroßes aber langes Geschoss -->
  32.       <!-- Rocket_Cluster: Eine Clusterrackete -->
  33.       <!-- Torpedo: Ein Torpedo -->
  34.       <!-- Sniper: Eine Gewehrkugel -->
  35.        
  36.       <Ammo_Quantity Num="0"/>
  37.       <!-- Wieviel Schuss hat diese Einheit bevor sie aufmunitioniert werden muss -->
  38.        
  39.       <Can_Attack Num=""/>
  40.       <!-- Welche Einheiten kann diese Einheit angreifen -->
  41.       <!-- - None: 0 -->
  42.       <!-- - Air: 1 -->
  43.       <!-- - Sea: 2 -->
  44.       <!-- - Ground: 4 -->
  45.       <!-- - Sub: 8 -->
  46.       <!-- Kombinationen sind möglich. Z.b. 3 für Air+Sea oder 10 für Ground+Sub -->
  47.  
  48.       <Shots Num="0"/>
  49.       <!-- Wieviel Schuss hat die Einheit mit dieser Waffe bei Stillstand -->
  50.  
  51.       <Range Num="0"/>
  52.       <!-- Wie groß ist die Reichweite der Einheit? -->
  53.  
  54.       <Cluster_Attack YN="No"/>
  55.       <!-- Verursacht die Einheit Flächenschaden? -->
  56.        
  57.       <Can_Drive_And_Fire YN="No"/>
  58.       <!-- Verliert die Einheit alle Schüsse mit der ersten Bewegung oder nehmen diese erst langsam mit den Bewegungspunkten ab? -->
  59.        
  60.   </Weapon>
  61.  
  62.   <Production>
  63.  
  64.     <Built_Costs Num="18"/>
  65.     <!-- Baukosten bei einfacher Baugeschwindigkeit -->
  66.  
  67.     <Produces_Units>
  68.       <Unit ID="xx yy"/>
  69.       <!-- Liste der Einheiten die diese Einheit herstellen kann-->
  70.     </Produces_Units>
  71.    
  72.     <Max_Build_Factor Num="0"/>
  73.     <!-- Der maximale Bau-Beschläunigungs-Faktor (Bei der Kaserne nur 1) -->
  74.  
  75.   </Production>
  76.  
  77.   <Abilities>
  78.  
  79.     <Armor Num="4"/>
  80.     <!-- Wieviel Schaden absorbiert die Panzerung -->
  81.  
  82.     <Hitpoints Num="18"/>
  83.     <!-- Wieviel Schaden kann die Struktur einstecken -->
  84.  
  85.     <Scan_Range Num="5"/>
  86.     <!--Wie weit guckt die Einheit mit normalen "Kameraaugen"-->
  87.  
  88.     <Movement_Sum Num="18"/>
  89.     <!-- Wie weit kann diese Einehit sich unter normalen Umständen maximal bewegen-->
  90.  
  91.     <Can_Move_On Num="1"/>
  92.     <!-- Auf welchen Untergründen kann sich diese Einheit bewegen -->
  93.     <!-- - Air: 1 -->
  94.     <!-- - Sea: 2 -->
  95.     <!-- - Ground: 4 -->
  96.     <!-- Kombinationen sind möglich. Z.b. 3 für Air+Sea oder 6 für Ground+Sea -->
  97.  
  98.     <Makes_Tracks YN="No"/>
  99.     <!-- Werden Spuren hinterlassen -->
  100.  
  101.     <Modifies_Speed Num="0"/>
  102.     <!-- In Prozent -->
  103.  
  104.     <No_Water_Deceleration YN="No"/>
  105.     <!-- Fährt die Einheit auf Wasser genau so schnell wie auf Land (Gutachter) -->
  106.      
  107.     <Can_Clear_Area YN="No"/>
  108.     <!--Kann die Einheit Wracks und Bäume beseitigen? (Später eventuell auch Gelände modifizieren) -->
  109.  
  110.     <Can_Be_Captured YN="Yes"/>
  111.     <!-- Kann die Einheit gefangen genommen werden? Gebäude z.B. Nein -->
  112.  
  113.     <Can_Be_Disabled YN="Yes"/>
  114.     <!-- Kann die Einheit durch Infiltratoren abgeschaltet werden. Trifft auf die meisten Einheiten zu -->
  115.    
  116.     <Can_Disable YN="No"/>
  117.     <!--Kann die Einheit Gegner abschalten-->
  118.      
  119.     <Can_Capture YN="No"/>
  120.     <!--Kann die Einheit Gegner erobern-->
  121.      
  122.     <Can_Repair YN="No"/>
  123.     <!--Kann sie andere reparieren-->
  124.    
  125.     <Can_Rearm YN="No"/>
  126.     <!--Kann sie andere aufladen (Munition)-->
  127.      
  128.     <Can_Research YN="No"/>
  129.     <!--Kann sie Forschung betreiben-->
  130.      
  131.     <Can_Place_Mines YN="No"/>
  132.     <!--Könne Minen ausgelegt werden-->
  133.      
  134.     <Does_Self_Repair YN="No"/>
  135.     <!-- Repariert sich die Einheit selber mit Metall? -->
  136.      
  137.     <Converts_Gold Num="0"/>
  138.     <!-- Wird hier Gold raffiniert. Wenn ja wie viel pro Runde? -->
  139.  
  140.     <Can_Mine_Resources YN="No"/>
  141.     <!-- Kann diese Einheit Material fördern -->
  142.    
  143.     <Needs_Energy Num="0"/>
  144.     <!-- Negativ für Erzeugung -->
  145.     <!-- Verbraucht bzw. erzeugt die Einheit Energie-->
  146.      
  147.     <Needs_Oil Num="0"/>
  148.     <!--Braucht die Einheit Öl-->
  149.      
  150.     <Needs_Humans Num="0"/>
  151.     <!-- Negativ für Erzeugung -->
  152.     <!-- Stellt die Einheit Arebiter zur Verfügung bzw. benötigt sie Arbeiter -->
  153.  
  154.     <Is_Stealth_On Num="0"/>
  155.     <!-- Auf welchen Untergründen ist die Einheit unsichtbar -->
  156.     <!-- - Air: 1 -->
  157.     <!-- - Sea: 2 -->
  158.     <!-- - Ground: 4 -->
  159.     <!-- Kombinationen sind möglich. Z.b. 3 für Air+Sea oder 6 für Ground+Sea -->
  160.    
  161.     <Surface_Position Const="Normal"/>
  162.     <!-- Auf welcher Höhe befindet sich die Einheit -->
  163.     <!-- - Normal (Blockiert auf eigener Ebene[Flugzeuge blockieren Flugzeuge, Boden/Wassereinheiten untereinander])-->
  164.     <!-- - Beneath -->
  165.     <!-- - Above -->
  166.     <!-- - BeneathNAbove (Für Brücken die sowohl über als auch unter Standard(Normal)-einheiten sein können)-->
  167.    
  168.     <Can_Be_Overbuild Const="No"/>
  169.     <!-- - No -->
  170.     <!-- - Yes -->
  171.     <!-- - YesNRemove -->
  172.  
  173.     <Can_Be_Landed_On YN="No"/>
  174.     <!-- Können Flugzeuge hier landen -->
  175.  
  176.     <Build_On_Water YN="No"/>
  177.     <!-- Kann diese Einheit nur auf Wasser errichtet werden -->
  178.  
  179.     <Is_Activatable YN="No"/>
  180.     <!-- Kann diese Einheit aktiviert werden -->
  181.   </Abilities>
  182.  
  183.   <Storage>
  184.     <!--Lagerung-->
  185.  
  186.     <Capacity_Metal Num="0"/>
  187.     <!--Wieviel Metall kann diese Einheit speichern-->
  188.  
  189.     <Capacity_Oil Num="0"/>
  190.     <!--Wieviel Öl kann diese Einheit speichern-->
  191.  
  192.     <Capacity_Gold Num="0"/>
  193.     <!--Wieviel Gold kann diese Einheit speichern-->
  194.  
  195.     <Capacity_Units Num="3"/>
  196.     <!--Wieviele andere Einheiten kann diese Einheit speichern-->
  197.  
  198.     <Capacity_Units_Type Num="12"/>
  199.     <!-- - Air: 1 -->
  200.     <!-- - Sea: 2 -->
  201.     <!-- - Ground: 4 -->
  202.     <!-- - Human: 8 -->
  203.     <!-- Kombinationen sind möglich. -->
  204.  
  205.   </Storage>
  206.  
  207.   <Graphic>
  208.     <Has_Damage_Effect YN="No"/>
  209.     <!-- Zeigt die Einheit Rauchwolken bei beschädigung an -->
  210.     <Has_Beton_Underground YN="No"/>
  211.     <!-- Hat die Einheit Betonuntergrund -->
  212.     <Has_Player_Color YN="No"/>
  213.     <!-- Muss für diese Einheit die Spielerfarbe geblittet werden -->
  214.     <Has_Overlay YN="No"/>
  215.     <!-- Gibt an ob eine overlay.pcx geladen werden soll -->
  216.     <Animations>
  217.       <Build_Up YN="No"/>
  218.       <!-- Gibt an ob baugrafiken geladen werden sollen -->
  219.       <Movement YN="No"/>
  220.       <!-- Gibt für die Bewegung speziele Animationsgrafiken benötigt werden. (Bodentruppen) -->
  221.       <Power_On YN="No"/>
  222.       <!-- Gibt bei Gebäuden an, ob sie eine speziele Grafik bei eingesaltetem Status haben. (effect.pcx) -->
  223.       <Is_Animated YN="No"/>
  224.       <!-- Gibt bei Gebäuden an, ob sie animiert ist.(Radar) -->
  225.     </Animations>
  226.   </Graphic>
  227. </Unit>

Albert Ziegenhagel
↑  ↓

#8 Jul 07, 2009 12:51 pm
alzi alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Posts: 339


Subject: Re: Neue Einheiten XMLs
Ein paar Dinge möchte ich dazu dann noch erklären:

- Waffentechnisch habe ich diese "Mehrere-Waffen-In-Einer-Einheit" Funktion erstmal rausgenommen. Ist noch zu früh für solche Späße ^^

- Bei der Auswahl der baumöglichen Einheiten habe ich mich für eine Produces_Units-Liste entschieden. Es ist zwar nicht die optimalste Lösung aber ich denke es ist denoch der besste Kompromis. Die Entscheidung warum ich Produces_Units und nicht Is_Producted_By_Units genommen habe ist eigenltich ganz simpel: Es ist im code einfach einzubauen. Zuerst dachte ich es wäre anders sinnvoller, da man bei einer is_produced_by-Liste nicht wenn man ein neues Fahrzeug hinzufügt auch die data.xmls der Fabriken ändern muss, aber in diesem Fall müsste man z.b. wenn man eine neue Einheit erstellt, die kleine Fahrzeuge herstellt die xmls aller kleinen Einheiten ändern und von daher schenkt sich beides nicht viel.

- Dann habe ich des öfftern sowas wie Kombinationsauswahlen Eingebaut. Ein Beispiel hierfür wäre Can_Move_On. So sparen wir uns extra Abfragen wie früher DRIVE_LANDnSEA. Im code lässt sich das mit einzelnen bits und bitweisen und/oder ganz einfach umsetzten.

- is_generating habe ich jetzt erstmal doch nicht für die Resourcen Metal, Öl und Gold so übernommen. Undzwar weil ich glaube, dass hier ein bestimmter Wert keinen Sinn macht. Wieviel resourcen eine Mine letztendlich fördert hängt von den vorkommen unter ihr ab und auch von den Einstellungen. Wenn es hier einen Wert zu setzten gäbe, wäre es denke ich der Maximalwert, der meines Wissens immer bei 16 insgesamt für alle Resourcen liegt. Ob das so stimmt und in wiefern das modifizierbar wäre, muss Eiko beantworten, da er vor kurzem den Resourcen-Förder-Algo neu geschrieben hat.

- Die Ladung habe ich nur teilweise Aufgeteilt. Hier habe ich einen Kompromis zwischen Freiheit und Codeänderungsaufwand gewählt. Für die Resourcen kann einzeln jeweils festgelegt werden wieviel von welchem Rohstoff geladen werden kann. Wobei mir gerade einfällt das der Codeänderungsaufwand hierfür auch riesig wäre, weil man alle Statusanzeigen ändern müsste und z.b. die transfermenüs. ich glaub das sollte man doch zusammenfassen. Ansonnsten habe ich noch die Einheitenlademöglichkeit abgetrennt aber nicht komplett auf einheitenids ausgeweitet sondern einfach nur auf gruppen.

So das wars erstmal. Senf ist wiedermal erwünscht Smiling
Albert Ziegenhagel
↑  ↓

#9 Jul 09, 2009 8:05 pm
Eiko Eiko Offline
Moderator, Developer
Registered since: Aug 03, 2007
Posts: 604


Subject: Re: Neue Einheiten XMLs
So, mein Senf dazu:

Erstmal, super Arbeit! Hab auch nur noch ein paar Kleinigkeiten dazu.

DownloadSource code (XML):
  1.  <Unit ID="0 1" name="air_transport">
  2. .
Brauchen wir die ID eigentlich noch? Wenn nein,hätten wir kein Problem mehr mit möglicherweise doppelten IDs.

DownloadSource code (XML):
  1.  
  2.   <Weapon>
  3.       <Muzzle_Type Const="None"/>
  4.       <!-- Typ des Geschosses -->
  5.       <!-- None: Kein Geschoss -->
  6.       <!-- Big: Ein großes Geschoss -->
  7.       <!-- Rocket: Eine normale Rackete -->
  8.       <!-- Small: Ein kleines Geschoss -->
  9.       <!-- Med: Ein mittleres Geschoss -->
  10.       <!-- Med_Long: Ein mittelgroßes aber langes Geschoss -->
  11.       <!-- Rocket_Cluster: Eine Clusterrackete -->
  12.       <!-- Torpedo: Ein Torpedo -->
  13.       <!-- Sniper: Eine Gewehrkugel -->
  14.  

Rocket_Cluster würde ich raus nehmen, da es das Attribut Cluster_Attack gibt.

DownloadSource code (XML):
  1.       <Can_Drive_And_Fire YN="No"/>
  2.       <!-- Verliert die Einheit alle Schüsse mit der ersten Bewegung oder nehmen diese erst langsam mit den Bewegungspunkten ab? -->
Hier würde ich als zusätzliche Flexibilität einen Num nehmen, der angibt, ab wie viel Bewegung ein Schuss verloren geht. Das is im Code mit einer Zeile behandelt, also sollten wir das einbauen Smiling

DownloadSource code (XML):
  1.      
  2.   </Weapon>
  3.  
  4.   <Production>
  5.  
  6.     <Produces_Units>
  7.       <Unit ID="xx yy"/>
  8.       <!-- Liste der Einheiten die diese Einheit herstellen kann-->
  9.     </Produces_Units>
Hier würde ich, wie im IRC erwähnt die Attribute Can_Build und Build_By nehmen. Wenn die beiden von 2 Einheiten zueinander passen, kann die Einheit von der anderen gebaut werden. Vorteil: keine Referenzierung von anderen Einheiten per ID notwendig. Dadurch braucht man beim Hinzufügen von neuen Einheiten nie zusätzlich eine andere XML editieren müssen.

DownloadSource code (XML):
  1.    
  2.   </Production>
  3.  
  4.   <Abilities>
  5.  
  6.     <Can_Move_On Num="1"/>
  7.     <!-- Auf welchen Untergründen kann sich diese Einheit bewegen -->
  8.     <!-- - Air: 1 -->
  9.     <!-- - Sea: 2 -->
  10.     <!-- - Ground: 4 -->
  11.     <!-- Kombinationen sind möglich. Z.b. 3 für Air+Sea oder 6 für Ground+Sea -->
Coast wäre dann 8

DownloadSource code (XML):
  1.  <No_Water_Deceleration YN="No"/>
  2.     <!-- Fährt die Einheit auf Wasser genau so schnell wie auf Land (Gutachter) -->
Ich würde vorschlagen, Faktoren für verschiedene Terrains zu benutzen, die angeben, wie schnell sich eine Einheit auf einem bestimmten Terrain bewegen kann. Eine 0 würde bedeuten gar nicht, eine 0.5 halbe Geschwindigkeit, eine 1 normal schnell, usw.
Damit hätten wir festgelegt, auf welchen Terrains sich Einheiten bewegen dürfen und wie das Terrain die Geschwindigkeit Beeinflusst. Das macht die Sache flexibler, als wenn nur "No_water_deceleration" benutzt wird.

DownloadSource code (XML):
  1.     <Makes_Tracks YN="No"/>
  2.     <!-- Werden Spuren hinterlassen -->

Das sollte in die Grafik-Sektion.

DownloadSource code (XML):
  1.     <Can_Clear_Area YN="No"/>
  2.     <!--Kann die Einheit Wracks und Bäume beseitigen? (Später eventuell auch Gelände modifizieren) -->
Bäume?^^ Ich bin mir ziemlich sicher, dass der Bulldozer das nicht kann Wink

DownloadSource code (XML):
  1.     <Can_Mine_Resources YN="No"/>
  2.     <!-- Kann diese Einheit Material fördern -->
Hier würd ich ein Num nehmen, der die maximalanzahl angibt. Der Code kann, seitdem ich ihn überarbeitet hab bereits mit Variablem Maximalwert umgehen.

DownloadSource code (XML):
  1.     <Is_Stealth_On Num="0"/>
  2.     <!-- Auf welchen Untergründen ist die Einheit unsichtbar -->
  3.     <!-- - Air: 1 -->
  4.     <!-- - Sea: 2 -->
  5.     <!-- - Ground: 4 -->
  6.     <!-- Kombinationen sind möglich. Z.b. 3 für Air+Sea oder 6 für Ground+Sea -->
  7.    
+ Coast

DownloadSource code (XML):
  1.     <Surface_Position Const="Normal"/>
  2.     <!-- Auf welcher Höhe befindet sich die Einheit -->
  3.     <!-- - Normal (Blockiert auf eigener Ebene[Flugzeuge blockieren Flugzeuge, Boden/Wassereinheiten untereinander])-->
  4.     <!-- - Beneath -->
  5.     <!-- - Above -->
  6.     <!-- - BeneathNAbove (Für Brücken die sowohl über als auch unter Standard(Normal)-einheiten sein können)-->
  7.    
Hm, ich bin mir gerade nicht sicher, ob das ausreicht. Was ist zum Beispiel mit See-Mine und Brücke auf einem Feld? Das is möglich, wäre aber beides "Beneath" oder?

DownloadSource code (XML):
  1.     <Build_On_Water YN="No"/>
  2.     <!-- Kann diese Einheit nur auf Wasser errichtet werden -->
Würde ich erweitern auf "Build_On" und wieder eine Bitkombination für Wasser, Küste, Land, da sonst nicht alle Fälle abgedeckt werden können.

DownloadSource code (XML):
  1.     <Is_Activatable YN="No"/>
  2.     <!-- Kann diese Einheit aktiviert werden -->
Welche Bedeutung hat das?

DownloadSource code (XML):
  1.   </Abilities>
  2.  
  3.   <Storage>
  4.     <!--Lagerung-->
  5.  
  6.     <Capacity_Metal Num="0"/>
  7.     <!--Wieviel Metall kann diese Einheit speichern-->
  8.     <Capacity_Oil Num="0"/>
  9.     <!--Wieviel Öl kann diese Einheit speichern-->
  10.     <Capacity_Gold Num="0"/>
  11.     <!--Wieviel Gold kann diese Einheit speichern-->
würde ich zusammenfassen, zu "Capacity" und "Type". Ansonsten würde das zu kompiliert, da man ja auswählen können müsste was nun geladen werden soll, also umfangreiche Änderungen am Userinterface nötig wären.

DownloadSource code (XML):
  1.     <Capacity_Units Num="3"/>
  2.     <!--Wieviele andere Einheiten kann diese Einheit speichern-->
  3.  
  4.     <Capacity_Units_Type Num="12"/>
  5.     <!-- - Air: 1 -->
  6.     <!-- - Sea: 2 -->
  7.     <!-- - Ground: 4 -->
  8.     <!-- - Human: 8 -->
  9.     <!-- Kombinationen sind möglich. -->
Wie werden die Attribute Air, See, Ground, Human einer Einheit bestimmt? Das steht ja nicht explizit in der XML drin. Air, See, Ground könne man anhand "Can_Move_On" bestimmen. Und Human?

DownloadSource code (XML):
  1.  
  2.   <Graphic>
  3.    
  4.   </Graphic>
Ich finde die Abtrennung aller rein grafischen Eigenschaften sehr gut! Ich würde sogar noch einen Schritt weiter gehen und das in eine Extra Datei auslagern. So dass Verhalten und Aussehen der Einheit komplett getrennt sind. Dadurch kann zum Beispiel das freie Grafikset unabhängig von den originalen Grafikeigenschaften gestaltet werden. Der resinstaller kann dann die Grafik-XML einfach ersetzen.

Was ist mit der Eigenschaft "ConnectToBase", woraus wird das abgeleitet, oder muss das noch zusätzlich rein?

So, das wars erstmal, da ich gerad nicht allzuviel Zeit hab. Smiling
↑  ↓

#10 Jul 10, 2009 4:51 pm
alzi alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Posts: 339


Subject: Re: Neue Einheiten XMLs
So ich geb wiedermal Komentare ab. Zu allem wo ich das nicht tue stimme ich Kommentarlos zu Smiling

Quote:
Brauchen wir die ID eigentlich noch? Wenn nein,hätten wir kein Problem mehr mit möglicherweise doppelten IDs.
Ich dachte auch zuerst daran, die ids weg zu lassen, aber das Problem worauf ich keine Lösung finden konnte, war das sich Server und Client dann nicht mehr auf Einheiten einigen könnten. Klar soll der Server später mal die clienten synchronisieren, so dass er theoretisch beim Spielstart einfach seinen Datensatz zu den Clienten schicken könnte, aber das problem wäre dann immernoch die Zuordnung der Grafiken. Mir ist aber auch eingefallen, dass wir theoretisch schon eine kleine Sicherung für doppelte IDs haben. Nämlich die vehicles.xml bzw. buildings.xml wo alle Einheiten mit ihren IDs aufgeführt sind. Wir hatten diese Dateien damals extra behalten um so alle IDs übersichtlich sammeln zu können.

Quote:
Rocket_Cluster würde ich raus nehmen, da es das Attribut Cluster_Attack gibt.
Ich hätte das eher getrennt, da für mich der "Muzzle_Type" eigentlich nur als grafisches Attribut galt und "Cluster_Attack" eben dann tatsächlich bedeutet, dass Flächenschaden entstehen soll.

Quote:
Hier [,Can_Drive_And_Fire,]würde ich als zusätzliche Flexibilität einen Num nehmen, der angibt, ab wie viel Bewegung ein Schuss verloren geht. Das is im Code mit einer Zeile behandelt, also sollten wir das einbauen
Das war in den alten XMLs so drinnen und ich habe es absichtlich rausgenommen, da ich denke, das die "ab bestimmten bewegungspunkten sache" nicht wirklich dem tatsächlichen verhalten entspricht. Tatsächlich verliert die Einheit die Schüsse immer proportional zu den Bewgungspunkten, also Hälfte der Bewgungspunkte auch nur Hälfte der Schüsse, bzw. beim Schiesen entsrpechend umgekehrt. Die Bewegungspunkte können aber z.b. durch Forschung veriieren, weshalb ich einen festen Wert in der data.xml nicht für wirklich sinnvoll halten. Evtl ein proportionalitätsfaktor. Das dürfte glaube ich auch ganz gut umzustetzen sein.

Quote:
Ich würde vorschlagen, Faktoren für verschiedene Terrains zu benutzen, die angeben, wie schnell sich eine Einheit auf einem bestimmten Terrain bewegen kann. Eine 0 würde bedeuten gar nicht, eine 0.5 halbe Geschwindigkeit, eine 1 normal schnell, usw.
Damit hätten wir festgelegt, auf welchen Terrains sich Einheiten bewegen dürfen und wie das Terrain die Geschwindigkeit Beeinflusst. Das macht die Sache flexibler, als wenn nur "No_water_deceleration" benutzt wird.
Ok, das wäre auch eine relativ gut umsetzbare Möglichkeit, wenn ich nochmal drüber nachdenke. War in den alten Xmls bereits so vorgesehen, nur waren da eben auch Faktoren für z.b. die Straße drinnen und das macht ihmo keinen sinn. Ich denke hier wäre dann wieder nur WATER, AIR, SEA und COAST nötig. Und durch die Sache würde mann dann auch Can_Move_On unnötig machen.

Quote:
Bäume?^^ Ich bin mir ziemlich sicher, dass der Bulldozer das nicht kann
Grinning habe ich aus der alten Xml übernommen und vergessen das Kommentar zu ändern. Soll natürlich nur für das räumen von normalem Schutt gelten.

Quote:
Hier würd ich ein Num nehmen, der die maximalanzahl angibt. Der Code kann, seitdem ich ihn überarbeitet hab bereits mit Variablem Maximalwert umgehen.
Ok, perfekt. Wenn er das kann, dann kommt das auch rein Smiling
Edit: kann er das auch pro Resource extra oder nur für alle gemeinsam?

Quote:
Hm, ich bin mir gerade nicht sicher, ob das ausreicht. Was ist zum Beispiel mit See-Mine und Brücke auf einem Feld? Das is möglich, wäre aber beides "Beneath" oder?
Jo ich hatte mir vorgestellt, dass das dann beides Beneath wäre. Theoretisch müsste das auch reichen, wenn man "Beneath" Einheiten nicht untereinander blockierbar macht und für z.b. Brücken gibt es dann ja das Attribut "Can_Be_Overbuild". Bin mir grad aber auch nicht sicher ob ich da nicht etwas vergessen habe zu bedenken.

Quote:
Welche Bedeutung hat das? [Is_Activatable]
Das soll steuern ob man die Einheit starten kann. Bahausungen z.b. produzieren zwar etwas (Menschen) aber sind nicht ein- oder ausschaltbar.

Quote:
Wie werden die Attribute Air, See, Ground, Human einer Einheit bestimmt? Das steht ja nicht explizit in der XML drin. Air, See, Ground könne man anhand "Can_Move_On" bestimmen. Und Human?
Stimmt Human habe ich da auch vergessen. Da müsste ein Attribut "Is_Human" rein ^^ oder wir machen das wie beim Bauen mit Stringabgleich.

Quote:
Ich finde die Abtrennung aller rein grafischen Eigenschaften sehr gut! Ich würde sogar noch einen Schritt weiter gehen und das in eine Extra Datei auslagern. So dass Verhalten und Aussehen der Einheit komplett getrennt sind. Dadurch kann zum Beispiel das freie Grafikset unabhängig von den originalen Grafikeigenschaften gestaltet werden. Der resinstaller kann dann die Grafik-XML einfach ersetzen.
Jup wäre ne idee überall nochmal "graphics.xml" dazu zu packen.

Quote:
Was ist mit der Eigenschaft "ConnectToBase", woraus wird das abgeleitet, oder muss das noch zusätzlich rein?
Jup hab ich vergessen, sollte auch rein.

MFG
alzi
Albert Ziegenhagel
This post has been edited 1 times. Last edit on Jul 10, 2009 4:57 pm by alzi. ↑  ↓

Pages (2): 1, 2


All times are GMT +01:00. Current time: 9:51 pm.