Show whole topic Jul 10, 2009 4:51 pm
alzi Offline
Developer, Moderator
Registered since: Aug 12, 2007
Location: Ditzingen (nahe Stuttgart)


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.