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
Aber die Flieger werden im Endspiel zu stark, weil der Commander diesen relativ hilflos ausgeliefert ist. Ich würde es besser, wenn man mehr Luftabwehr bauen könnte.
Die 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
Jetzt noch mal kurz von meiner Seite, weil ich ja mehrfach zitiert werde:
Es gibt Verbesserungspotential im PBP. Das gibts immer und überall. Auf der anderen Seite stört es ungemein, wenn Änderungen am Spielsystem die eigenen Taktiken kreuzen. Schon bei kleinen Unitänderungen gab es schon einige Aufschreie.
Deshalb sollte man meiner Meinung nach vermeintliche Verbesserungen nicht gleich im ganzen PBP einführen, sondern in einem separaten Bereich unbürokratisch ausprobieren, testen und feintunen können. Ich halte es für sinnvoll, diesen separaten Bereich im PBP-Universum mitlaufen zu lassen: - weil man dann einfacher hin und herwechseln kann - weil es nicht sonderlich motivierend ist, viel Zeit in den Aufbau von Armee und Stellung zu setzen, wenn der Planet sowieso bald gelöscht wird - weil wir die ganze Infrastruktur mit Raumflügen, Planetenkarten etc. nutzen können.
Man könnte diesen separaten Bereich jetzt 'PBP-Beta' nennen, oder 'Sonderwirtschaftszone', oder man verpackt das als role-play und macht eine Rebellion gegen das ISG-Imperium. Letzteres hat auch den Reiz, dass es auch den PBP-Teilnehmern eine Heimat geben kann, die mit den administrativen Prozessen des PBP-Universiums nicht ganz zufrieden sind und andere Formen der Planetenverwaltung ausprobieren wollen.
Auch dabei vertrete ich die These, dass derjenige, der Arbeit macht, auch darüber entscheidet, was und wie er es macht. Und diese Hoheit respektiere ich auch bei anderen. Deshalb: wer Sachen ändern will, der soll sie ändern! Aber er soll nicht erwarten, dass andere die Änderung für ihn machen. Dem Umsetzen und Ausprobieren solcher Änderungen sollte man einen Raum geben - um dann auch denjenigen, die nur motzen, aber keine konstruktive Arbeit machen wollen, klar verstehen geben zu können: mach's - oder halte die Klappe.
Die Aktionen für beide Varianten habe ich ganz normal gespielt, dann als Lua-Script abgespeichert ( Action / SaveScript ). Anschließend mit dem Texteditor kombiniert und die Meldungen eingefügt.
Ein Script ist eine Textdatei mit der Endung .lua , die in einem ASC Verzeichnis abgelegt wird und dann mittels File/RunScript im Karteneditor bzw. Action/RunScript in ASC ausgeführt wird.