Show whole topic Jun 11, 2009 6:17 pm
alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Location: Ditzingen (nahe Stuttgart)


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