Modderecke > Coding

Mehrere Abhängigkeiten für CommandButtons

(1/2) > >>

Marioverraeter:
Hallo zusammen,

ich habe da seit ein paar Tagen ein Problem beim Coden einer erweiterten Version der CRP Submod und wollte fragen, ob ihr mir da weiterhelfen könnt - ich weiß wirklich nicht mehr weiter und habe auch sonst im Internet nichts dazu gefunden. :(

Es geht darum, einen commandbutton von mehr als einem Upgrade abhängig zu machen.
In dem Block eines Commands in der Commandbutton.ini findet sich ja die Zeile

--- Code: ---Options = CANCELABLE NEED_UPGRADE
--- Ende Code ---
letzteres wenn eben ein Upgrade notwendig ist. Dann eine zusätzliche Zeile:

--- Code: ---NeededUpgrade = Upgrade_NameDesBenötigtenUpgrades
--- Ende Code ---
Aber was, wenn mehr als ein Upgrade als Voraussetzung erforderlich sein soll?

Ich habe schon folgendes probiert:

--- Code: ---Options = CANCELABLE NEED_UPGRADE
NeededUpgrade = Upgrade_Name1 Upgrade_Name2
--- Ende Code ---
und:

--- Code: ---Options = CANCELABLE NEED_UPGRADE
NeededUpgrade = Upgrade_Name1 AND Upgrade_Name2
--- Ende Code ---
und weiter auch, was manchmal sogar zu klappen schien aber sehr unzuverlässig war:

--- Code: ---Options = CANCELABLE NEED_UPGRADE NEED_UPGRADE ;hier den Tag doppelt
NeededUpgrade = Upgrade_Name1
NeededUpgrade = Upgrade_Name2
--- Ende Code ---

Alles ohne Erfolg. Im Internet habe ich folgendes gefunden: CommandButtons dependent on multiple upgrades - The 3rd Age

Er umgeht das Problem einfach damit, wenn etwas ein echtes Upgrade und ein Upgrade_StructureLevelX erfordern soll, das echte Upgrade in die Zeile NeededUpgrade zu setzen und dann statt Upgrade_StructureLevelX kommt eine Zeile dazu namens:

--- Code: ---RequireLevel = X ;X für das erforderliche Level, also 2 oder 3
--- Ende Code ---

Das hat bei mir aber erstens nicht funktioniert, zweitens, also unabhängig davon ob es klappt oder nicht, ist das nicht hinreichend da es dadurch immer noch nicht möglich ist, einen Befehl von mehr als einem Upgrade abhängig zu machen.

Dort wurde außerdem folgender Kommentar gepostet:

--- Zitat ---Illuvatar - Sunday April 25, 2010 - 2:06

Uh... to shorten this tutorial up to about two sentences: You only need to put both upgrades in the TriggeredBy field in the behavior block (most likely in the unit ini file). Then just add the following field:

--- Code: ---RequiresAllTriggers = Yes
--- Ende Code ---

--- Ende Zitat ---

Versteht jemand was er meint? Klar, jede unit hat in ihrem ini-Block Behavior Blocks, und da kann man in TriggeredBy mehrere Dinge einfügen, und Requires All Triggers, aber... inwiefern kann das auf die Rekrutierung der Einheit zurückgreifen? Ich sehe hier keinen Bezug zum CommandButton selbst! Außerdem, was wenn der CommandButton kein Button zum Unit Build ist? In meinem Problem geht es nämlich darum, ein eigenes Upgrade von mehreren vorangehenden Upgrades abhängig zu machen... und die Upgrades in der Upgrade.ini haben ja bekanntlich keine Behavior Blocks.

Somit habe ich darauf geantwortet:

--- Zitat ---Marioverraeter - Sunday May 16, 2010 - 11:01

Interesting. In deed, this is exactly one problem I am bothering with at the time.

The method you present here is okay for only one upgrade + structure level requirement. However, it is not sufficient for commandbuttons dependent on multiple upgrades in general, with more than only one actual upgrade required.

When I was fiddling about with this, it seemed to work on adding NEED_UPGRADE multiple times in the Options line and then adding multiple NeededUpgrade lines. It "seemed" to work... but sometimes, it seemed to fail again. I am not sure about that.

Are there other experiences with this multiple dependencies issue? Would be great.

--------

P.S.: Illuvatar, could you explain this method further? I didn't actually get the point; a unit always has multiple behavior blocks. which one do you mean?

--------

Okay, so far... testing my own approach has resulted in a complete fail. It does not work either. Maybe it seemed to work because the last upgrade I got was randomly the one of those which was taken as *the* needed upgrade, I dont't know.

Anyway, it would be nice if someone has another idea or method to bring this to work. The inability to set dependencies on multiple upgrades just made my whole work of two weeks, an upgrade system for all factions, useless. Help appreciated.
--- Ende Zitat ---

Bisher wie gesagt ohne Antwort, ohne weitere Erfolge oder Ideen... aber es muss doch irgendwie möglich sein, mehr als ein Upgrade vorauszusetzen! 8-|

Jedenfalls, wenn jemand eine Idee hat oder eine Methode, die dabei funktioniert oder wenigstens einen Ansatz, wäre ich froh und dankbar.

Mit freundlichen Grüßen,
Mario

Manuel2811:
Wenn du uns dein genaueres Vorhaben einmal erklären könntest ließe sich das Ganze besser eingrenzen. Möchtest du es für einen Helden haben? Für eine Horde? Ein Gebäude? Was genau? Dann könnte ich dir dementsprechend ein paar "umwege" vorschlagen, die aber später ingame zum erwünschten Erfolg führen.

Greez

Manuel2811
Elvenstar Mod

Marioverraeter:
Okay, also... mir ging es erstmal nur allgemein darum, da ich es für mehrere Anwendungsbereiche bräuchte. In der letzten Zeit hatte ich geplant, konzipiert und herumexperimentiert, ein Upgrade-System (also soetwas wie ein TechTree wie man ihn aus anderen, komplexeren Strategiespielen als SuM1 kennt) fraktionsspezifisch zu implementieren. Ich habe viel Zeit mit der genauen Planung dieser Entwicklungen, ihrer Abhängigkeiten und Effekte verbracht. Grundsätzlich ist das Upgradesystem, so wie ich es mir eigentlich gedacht hatte, dezentral und einerseits verzweigt, andererseits auch wieder zusammenfließend. Intention dahinter war vor allem, dem Gameplay mehr Tiefe zu verleihen durch eine wesentlichere Strukturierung des Spielablaufs zwischen EarlyGame, MidGame und EndGame, bzw. der Übergänge dazwischen, um mehr Abwechslung in das Spielgeschehen zu bringen. Außerdem war die fraktionsspezifische Auslegung bereits für Abwechslung ausgelegt und insbesondere zur Betonung des wesentlichen, grundeigenen Charakters jeder Fraktion. Zuletzt kommt noch der Zweck dazu, im späteren Spielverlauf das Spiel auf einem "höheren Niveau" in Bezug auf Wirtschafts- und Militär-Management ablaufen zu lassen.
Eigentlich habe ich damit ja nun nur das selbe Problem (um beim TechTree-Bild zu bleiben) wie bei einem echten Baum auch: Die Äste können sich nur verzweigen, aber nicht wieder zusammenwachsen, was ich aber wollte. Nebenbei, da einige der Upgrades in den Zitadellen gekauft werden sollten, habe ich die Zuweisungen von CommandSets zu Zitadellen-Gebäuden neugeordnet, sodass nicht ein Commandset wie zuvor von mehreren Fraktionen genutzt wird, und dann die Fraktions-Zita-CommandSets um die gewünschten Befehle ergänzt.
Die Wirkungen der Upgrades sind vor allem spezifische Rohstoffproduktionsbesch leuniger, Freischaltungen bestimmter Einheiten und Gebäude (selten), in der ursprünglichen Auslegung insbesondere auch die Freischaltung von Helden, spezifische Einheitenrekrutierungsbe schleuniger und die Freischaltung größerer/erweiterter Horden/Bataillone zur direkten Rekrutierung.
Meistens verzweigen sich die Upgrade-Stränge zunächst und haben mehrere Ausgangspunkte, laufen dann aber zu den richtig starken End-Spitzen wieder zusammen.

Nun werde ich konkreter, um das Problem in Einzelfällen zu veranschaulichen:
1) Beispiel Rohan:
Rohan hat im wesentlichen drei Gruppen von Upgrades (zwischen denen jedoch noch Verzweigungen bestehen): Gehöfte-Ups, Zitadellen (Tech)-Ups, Rüstkammer (Einheiten)-Ups, und separat die Militär-Ups von Infanterie (Kaserne/Schießstand, ich verwende Edain, sollte aber keinen großen Unterschied machen) und Kavallerie. In den Stallungen lassen sich nun also drei Ups erforschen (ich kürze die Namen jetzt ab): FastCavalry, AdvancedCavalry und Eilrekrutierung. FastCavalry gibt einen dezenten Bauzeit-Bonus, AdvCav aktualisiert das CommandSet zu Rekrutierungsbefehlen größerer Bataillone, Eilrekrutierung gibt speziell für Kavallerie einen deutlichen Beschleunigungsbonus. Bei der Infanterie ist das auch so aufgebaut, nur die Wirkungen sind dabei schwächer, dafür erfordern die genannten-Kavallerie-Upgrades zuvor die Gehöfte-Verbesserungen. Derer gibt es zwei, Fruchtfolge und Erntesegen (letzteres stärker). Diese Eilrekrutierung wäre also abhängig von a) Rang 3 der Stallungen, b) Erntesegen, c) FastCav + AdvCav und d) einem Zita-Upgrade, Ruf des Königs. Technisch ergibt sich aber diese Schwierigkeit sogar schon an Erntesegen: Es erfordert Gehöft Stufe 3 und Fruchtfolge. Auch die Infanterie-Eilrekrutierung hat ein ähnliches, wenn auch kleineres Problem: Kaserne Rang 3, FastInf, AdvInf und Ruf des Königs. Die jeweilige Abhängigkeit von AdvInf/Cav könnte man terminieren, indem der Upgrade-Befehl einfach nur im aktualisierten CommandSet zur Verfügung steht. Aber das schmälert das Problem nur geringfügig. Und Eilrekrutierung einfach nur von Stallungen Rang 3 oder nur von Ruf des Königs abhängig zu machen, wäre balancingtechnisch undenkbar, dann müsste der Effekt so stark abgemildert werden, dass man es sich gleich sparen kann.

2) Beispiel Gondor
Das Gondor-Upgradesystem ist das komplexeste aller Fraktionen, Gondor kommt damit nur langsam in Fahrt, hat aber später die Möglichkeit, vergleichsweise weniger große aber dafür sehr starke Veteranen-Armeen ins Feld zu führen. Konkret ist da z.B. ein Problem: Merkantilismus. Ein finales Ökonomie-Up, das nochmal auf alle Einnahmen einen deutlichen Bonus errechnet, das aber zunächst recht teuer ist und für dessen Erforschung im Marktplatz zunächst alle anderen Öko-Ups (d.h. Erntesegen, Eisenerz, Belagerungsmaterial und evtl ein Stein-Up falls der Steinbruch ein AutoDeposit erhält) bereits gekauft sein müssen. Auch hier wird das so nicht funktionieren.
Ebenso bei "Militär-Akademie", einem Upgrade der Rang 3 Kaserne, das zur Rekrutierung größerer Armeen(-Bataillone) befähigt, hierzu aber erforschte Kenntnisse aus der Kaserne, dem Schießstand und der Zitadelle benötigt. Paralell dazu der Spezialfall "Kavallerie-Akademie" in den Stallungen Rang 3, er erfordert eine Freischaltung "Haferanbau" ohne sonstigen Effekt in den Gehöften, ebenso dieses Zitadellen-Up, wie gesagt Rang 3 des Gebäudes und die vorangehenden beiden (FastCav und AdvCav ähnlich wie bei Rohan aber mit schwächerer Wirkung). Dadurch sollte die Rekrutierung einer neuen Einheit (Schwanenritter, konnten in Edain sonst nur durch Imrahil beschworen werden) und größerer Ritterheere ermöglicht werden.

Auch für die bösen Fraktionen hätte ich Beispiele, z.B. die nachfolgende extreme Schnellrekrutierung in der Zitadelle von Mordor nach den einzelnen kleineren Beschleunigungen aus den einzelnen Gebäuden; auch das ist ein wichtiger Knotenpunkt, der sich so nicht umsetzen lässt.

Ganz kurz all das gesagt auf deine Nachfrage: Für PlayerUpgrades (im Code-Sinn). [ugly]

Ich möchte auch grundsätzlich nicht auf Abhängigkeiten verzichten und dafür Baukosten und -zeit nach oben ziehen, denn dann hätte ich bei dem Ziel versagt, den Spielablauf zu strukturieren, man könnte ja auch einfach gleich auf die besten sparen.


Und abschließend möchte ich noch anfügen, dass ich mir darüber im klaren bin, dass man einfach den Effekt des jeweiligen Upgrades von mehreren vorangegangenen Upgrades abhängig machen kann, statt den Erwerb dieses Upgrades selbst... das stimmt. Wäre mir aber nicht so lieb, weil die Verkettung wegfiele (man könnte die Wirkung ja schneller erreichen) und sich nochmal zusätzlicher Investitionsaufwand an Zeit und Geld bis zum Eintreten des Effektes ergeben sollte. Außerdem hat der Spieler dann ja keine Möglichkeit, im Spiel zu sehen, was das jetzt genau bewirkt und welche Folgen es hat, da das dazwischengeschaltete Upgrade (also der commandbutton mit Beschreibung usw., den man sonst ja i-wann mal drücken müsste) einfach entfällt.
Hättest du soetwas mit Umwegen gemeint?


Also, falls das der einzige Weg ist, dann werde ich diese Upgrade-Systeme wohl noch einmal reformieren, sodass ich eine bestmögliche Mitte finde, wie das Umgehen mehrerer Abhängigkeiten wo notwendig durch direkte Wirkungsauslösung vereinbar ist mit den Prinzipien des Systems, und diese dabei gewahrt bleiben.
Aber falls du doch Vorschläge hättest, wie ich das hinkriege, wäre ich dir überaus dankbar. :)

Liebe Grüße,
~Mario

PS: Zu Helden, ja das ist auch etwas; die sollen zwar nie von mehreren, aber eigentlich doch von genau einem Upgrade abhängig werden. Die einzige Möglichkeit die ich bisher dafür hatte, war, sie aus den BuildableHeroesMP der Playertemplate.ini zu entfernen, aus den CSs der Keeps die GenericReviveSlots rauszuhauen und durch eigene Command_ConstructXXX Befehle zu ersetzen, diese in der commandbutton.ini entsprechend zu definieren und in der object-ini des Helden im DESIGN Block die Zeile "MaxSimultaneousOfType = 1" (ohne "") hinzuzufügen. (Evtl die Buttons durch eine CommandSetUpgrade-Funktion erst erscheinen zu lassen, ändert daran aber nichts). Der wesentliche Nachteil: Man kann Helden nicht mehr wiederbeleben, sondern nur noch erneut rekrutieren. D.h., sie haben wieder dieselbe BuildTime und Cost (keine besonderen ReviveTime und ReviveCost Werte, was ja ein überaus sinnvoller Balancing-Faktor ist) und sie verlieren unwiderruflich ihren Rang.  Ich musste auf diese Technik ausweichen, da diese spieleigene Regelung mit reviveslots usw. keine feste Definition von NeededUpgrade für einen commandbutton der Heldenrekrutierung zulies, und mir außer dieser Technik keine weitere bekannt ist, wie man die mögliche Rekrutierung eines Helden von einem Upgrade abhängig machen kann. Gibt es da noch etwas anderes, direkteres? Danke schön schonmal. Falls es darauf jetzt aber so leicht keine Antwort gibt würde ich einen anderen Thread aufmachen, das hat nämlich nichts mit diesem Thema hier direkt zu tun, sondern ist ein eigenständiges Problem.

Vielen Dank nochmal für die Hilfe. :)

Ealendril der Dunkle:
Ich kann dir dazu nur sagen, dass man in SuMII mehrere Upgrades im Commandbutton-Parameter: NeededUpgrade = blabla angeben kann. In SuMI scheint dies scheinbar nicht zu funktionieren, deshalb wüsste ich nicht, wie man das anders lösen könnte.
Die einzige andere Lösung, die mir hierbei einfallen würde, wäre das Commandset des zuständigen Gebäudes mit jedem weiteren Upgrade switchen zu lassen. So könntest du in  dem Commandsetupgradebehavio ur per RequiredAllTriggers eben dort jene Upgrades angeben, die bewirken: Sobald diese Upgrades erhalten wurden, switcht das Commandset des Gebäudes und ermöglicht somit die Rekrutierung neuer Einheiten.

Manuel2811:
Ich hatte gerade das Gefühl einen zähen Politik-Artikel ausm Spiegel oder Stern Zeitung durchzulesen und habe in der Mitte abgebrochen zu lesen....und da werd ich wohl nicht der Einzige sein.

Beschränk dich bitte mal aufs Wesentliche.....

Navigation

[0] Themen-Index

[#] Nächste Seite