Das Forum ist read-only und nur noch zu Archivzwecken vorhanden. Neue Benutzer werden nicht mehr freigeschalten.
Benutzt bitte unser aktuelles Forum: http://www.battle-planet.de/pbp/main/forum_neu.php
Tora is the latest generation of stationary defence guns. Three large main guns are fitted into this heavily fortified artillery position. This guarantees a high firing rate. The range of the guns surpasses the range of any other gun the Rehans possess and is only matched by the Rotos rail gun and the main artillery of the Homer class battleships. The combination of armor, fire rate and range makes tora to the ultimate weapon to stop a ground attack or sea landing operation from a distance. On the downside, this artillery position has no protection against air strikes or troops that broke trough the front.
Vielleicht waere es gut irgendwo die Lizenzen zentral aufzulisten, wenn z.B. Autor und Quelle angegeben werden muessen. Das koennte eine separate Textdatei sein. Oder man gibt es im Description Abschnitt mit an.
Public Domain ist am unkompliziertesten, doch auch CC ist pk.
Theoretisch muesste bei allen ins Internet gestellten Dateien sichergestellt sein, dass die Copyrightangaben ok sind.
Zitat von GromJpg ist immer mit Verlusten verbunden daher sind png auch für die Infoimages das bessere Format.
Ich glaube der Verlust ist nicht so wichtig.
Zitat von GAMERFür die Infoimages benutzen wir jpg 640x480. Theoretisch kann auch jedes andere Format verwendet werden, aber andere Auflösungen als 4:3 verzerren im Moment.
Nun mir scheint, dass es hier ein bisschen um eine Geschmackfrage geht. Jede Waffenkombination (hier jammer/cm) erfordert eine bestimmte Taktik. Vorteile oder Nachteile fuer einzelne Spieler gibt es (wohl) an sich nicht, die werden ueber das Balancieren der Unitsets ausgeglichen. Nur die Taktik wird gewissermassen von den Waffen vorgegeben. Das ist ja auch in der Realitaet so. Ich persoenlich bin kein Fan von Waffen mit zu grosser Reichweite.
Man muss aber vielleicht nicht alles einheitlich machen. Warum nicht "parallelwelten" in denen die Unitsets keine CM und jammer haben? Dadurch das ASC auch ein KI hat, kann ich mich bspw. voellig "anarchistisch" verhalten und meine eigenen Units bauen, die ich mit niemand abstimmen muss. Das finde ich geil. Sobald ich was mit Anderen machen will muss ich mich abstimmen ist doch klar. Doch durch die Schaffung von Parallelwelten kann man beides haben: CM und keine CM je nach dem was wem besser gefaellt. Man muss ja nicht alle unter einen Hut bringen. Macht man eben zwei Huete. Die Konfigurierbarkeit von einheiten und objekten laesst doch irre viel zu: etwa Planeten mit 18Jh Technik, Segelschiffen (das ware cool!) und so. Sciene-fiction ansaetze mit Raumschiffen (angelehnt an Star Trek, Star Wars oder Babylon V), oder irgendwelche Phanatsiewelten wo Zwerge gegen Trolle Kaempfen. Und das geht alles ohne den Programmcode selbst zu veraendern, nur ueber einheiten- und objektdefinitionen. Und man kann natuerlich Welten mit und ohne CM haben.
Das geile an ASC/PBP ist doch gerade, dass es so konfigurierbar ist und viele Moeglichkeiten zulaesst und das man (zumindest potentiell) die Moeglichkeit hat auf das Programm selbst einfluss zu nehmen. Gamer hat natuerlich recht, wenn er sagt, wer was vorschlaegt soll sich auch mit ran machen. Doch die vorhanden Moeglichkeit auch gar nicht richtig ausgeschoepft. Mehrere parallelwelten einzurichten waere ein Weg das zu aendern. Man kann dann auch die definitionen von sets anderen ueberlassen. Wenn schief geht, gibts dann eben wieder eine welt weniger. Es ist aber klar, funktionieren kann es nur wenn es in jeder welt Leute gibt, die das Ganze zusammenhalten.
Warum nicht einfach zu den "Rebellen" sagen: Hier ihr kriegt Eure Welt, Euren ID Bereich, da koennt ihr Euch austoben. Wenn's gut geht prima und wenn nicht auch nicht schlimm.
Na, es gibt keinen verschiedenen TerrainAccess fuer ground_level und floating, oder? Wenn eine Einheit bspw. auf hoehe floating einen Fluss betreten kann, kann sie das auf ground_level auch? TerrainAccess macht keinen Unterschied zwischen ground_level und floating?
Weil ich gerade dabei bin bloede Fragen zu stellen. Was ist eigentlich der zusammenhang zwischen TerrainAccess und Height? Gilt TerrainAccess nur fuer Height ground_level und tiefer und ist oberhalb alles erlaubt, oder ist es ein bisschen komplizierter?
Zitat von ValHarisDie Secondary ID ist eigentlich für das fortenwickeln von Unitsets. Mal ein Beispiel:
Es gibt im MK1 die Baueinheiten: - Vesuvius (ID 12) - Ant (ID 26) - MBV (ID 85)
Wenn der Unitset-Maintainer zum Schluss käme, dass sich das nicht bewährt hat und man auch mit 1 Baueinheit auskäme, dann könnte er: - eine neue Baueinheit 'OberBauer' erstellen (ID 123) - bei diesem die SecondaryIDs 12, 26, 85 eintragen - die Einheiten Vesuvius, Ant, MBV löschen.
Wird nun eine Karte oder ein Savegame geladen, die eine der gelöschten Einheiten erhält, wird stattdessen ein 'OberBauer' auf die Karte gesetzt. Speichert man die Karte ab, wird dort der SuperBauer abgespeichert und man kann nicht mehr erkenne, dass es ursprünglich unterschiedliche EinheitenTypen waren.
Damit hat man einen Mechanismus, Einheitentypen zusammenzufassen. Für ObjektTypen, Bodentypen und GebäudeTypen funktioniert das genauso.
Es gibt nun noch eine weitere Technik, um Einheiten auszutauschen: die UnitSet-Transformation bzw. MapTranslation (die beide funktionieren ähnlich).
Wieder ein Beispiel:
Gegeben ist eine Karte mit MK1-Einheiten. Darunter ein Follow (ID 83) Weil man eine andere Spielweise mal ausprobieren will, definiert jemand neue Einheiten, nennen wir sie MK1ha Dort gibt es statt des Follow die Einheit 'Kastrierter Follow' (ID 6083) Nun schreibt man in die Map-Transformation:
VehicleTranslation = [ 83 6083 ]
Lässt man diese MapTransformation über die Karte laufen, werden alle Follows gegen kastrierte Follows ausgetauscht. Den alten Follow gibts aber weiterhin und er kann auf den anderen Karten benutzt werden. Man kann natürlich auch nach der Transformation wieder alte Follows auf die Karte setzen und die alten gegen die kastrierten kämpfen lassen.
Auch das gilt für Objekte, Gebäude und Bodentypen genauso
Naja, mir scheint der zweite Weg, der etwas bessere zu sein, obwohl sie beide Nachteile haben: - Die secondaryID muesste in die neuen Einheiten rein, wo sie aber eigentlich nichts zu suchen hat, da der alte ID-Bereich evakuiert werden soll. Fossilien in Form von secondaryID sind da nicht so toll. - Die Maptransformation hat den Vorteil das sie in einer separaten Datei steht, also nach Bedarf benutzt werden kann. Der Nachteil ist, dass das alte Set geladen sein muss. Sonst oeffnet der Mapeditor die Karte erst gar nicht, was beabsichtigt ist, wie mir mbickel versichert hat.
Steigen eigentlich die Kosten (fuer jamming, view und waffen) linear mit der Reichweite? Wenn ja, sollten sie vielleicht linear mit der bestrichenen Flaeche steigen, d.h. quadratisch mit der Reichweite. Das macht insbesondere fuer view und jamming sind, da hier der Aufwand tatsaechlich quadratisch steigen wuerden.
Na ich habe eher das Problem, dass ich die IDs der Einheiten in einen anderen ID Bereich verschiebe und Karten habe in denen die Einheiten noch im alten ID Bereich sind. Kann ich diese Karten mit Hilfe von secondaryID konvertieren? D.h. - Id = neue ID - secondaryID = alte ID - Karte mit alten ID laden - Karte neu speichern => Karte wird mit neuen IDs gespeichert?
Wie waere es denn fuer Einheit Unterhaltskosten einzufuehren? Etwa einen Prozentsatz der Baukosten? Wenn die Kosten bei 5% liegen, dann sind 20 Runden Unterhalt so teuer wie ein Neubau. Man koennte den Unterhalt auch mit der Erfahrung steigern, so dass erfahrene Einheiten mehr kosten als Novizeneinheiten [ Kosten fuer die Orden :) ].
Zitat von ProphetNenene Flieger sind wirklich stark genug!
Wenn die Jagdflieger funktionieren wuerden, wie sie sollten, dann wuerde nicht staendig der Ruf nach mehr Flak aufkommen. Die Staerke der Angriffsflieger ist gerade die Schwaeche der Verteidigungsflieger!
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
16.06.2009 11:44
