Modderecke > Coding
Mehrere Abhängigkeiten für CommandButtons
Marioverraeter:
In Sum II geht das? Hm, tja, vielleicht doch die falsche Plattfrom.^^ Nein nein, wir bleiben SuM I treu...
Die beschriebene Methode ist praktisch dieselbe wie ich schilderte: Schlichtweg die *Wirkung* eines Upgrades von mehreren abhängig zu machen, nicht das Upgrade selbst. Das wäre ein Kompromiss, der zumindest noch umsetzbar wäre, ich hoffte allerdings auf eine Möglichkeit, die den Erwerb dieses Upgrades selbst; mitsamt Erscheinung des Buttons, Baukosten und Bauzeit dazwischen; ermöglicht, statt es schlichtweg zu umgehen.
Deine Schilderung bringen mich jetzt allerdings auf eine Idee: Man könnte doch ein solches CommandsetUpdateBehavior (mit den entsprechenden required triggers) dem Gebäude beifügen, das den Button des Upgrades selbst einblendet. Damit wären alle Bedingungen erfüllt! Bis auf zwei Nachteile:
A) Der Spieler weiß zuvor nicht, dass er später die Möglichkeit haben wird, dieses Upgrade zu kaufen. Falls er also zu den vielen vielen Spielern gehört, die sich nicht die Texte (Readmes usw) einer Mod durchlesen, bevor sie sie spielen (und erstrecht nicht so ausführliche wie ich sie zu schreiben pflege), dann kann er eigentlich nur darüber stolpern. Das ist natürlich ungünstig... aber dieses Problem könnte man ebenfalls umgehen, indem man dem alten Commandset einen FakeButton beifügt, der die Informationen über das Upgrade enthält mit dem Verweis auf die Abhängigkeiten, der aber nicht benutzt werden kann. Durch das csUpdate wird er dann durch den echten Button ersetzt. Problem gelöst.
B) Die einzige echte Einschränkung, die verbleibt, liegt darin, dass pro Gebäude immer nur ein solches commandsetupgradebehavio r paralell angewandt werden kann. Zwar ließen sich diese verketten, aber da in einem csupdatebehavior immer ein vollständiges cs angegeben wird, und nicht einfach die Hinzufügung eines einzelnen commands, können nicht mehr als einer paralell laufen, da sonst bei Freischaltung des zweiten der Effekt des ersten wieder verschwinden oder der Effekt des anderen gleich auch ohne dessen Erwerb mitgeliefert würde. Nur eine eindeutige, einwegige Verkettung solcher Effekte ist möglich.
Dieses Problem hat mir in anderem Zusammenhang auch die Möglichkeit genommen, mehr als einen Helden an einen construct-Befehl statt revive slot zu koppeln und ihn dennoch wiederbelebbar zu machen: Das funktioniert normal, indem man als einen Effekt der Rekrutierung des Helden beifügt, dass das Commandset abermals aktualisiert wird, um den Rekrutierungsbefehl zu entfernen, und der Held somit später ja wieder einen Revive Slot füllt, aber nicht noch ein zweites Mal rekrutiert werden kann. So funktioniert es z.B. auch bei Edain I König Elessar und Sauron. Allerdings ist das aus genau diesem Grund nicht mit mehr als einem Helden möglich, weshalb ich wie vorhin geschildert zudem auch noch vor dem angesprochenen Helden-Problem stehe. Wahrscheinlich werde ich dafür aber noch einen separaten Thread aufmachen, es ist jedenfalls eine andere Geschichte.
Was die Auswirkung dieser Einschränkung auf dieses konkrete Problem an den Upgrade-Systemen betrifft, so bin ich nun doch beruhigt: Nur wenige Knotenpunkte in diesem Netzwerk haben ja noch dieses Problem, und in aller Regel sind es nie mehr als einer in einem Gebäude. Sollte doch eine Ausnahme verbleiben, so wird es mir doch möglich sein, ohne große Abstriche eine leichte Umplanung vorzunehmen, die die technischen Möglichkeiten berücksichtigt und trotzdem das gesetzte Ziel erfüllt. Das Problem ist damit praktisch und in seiner Dringlichkeit gelöst.
Also in diesem Sinne, vielen Dank euch beiden für die Impulse! :)
Ich kann mit den gesammelten Erkenntnissen meine Arbeit nun fortsetzen, und in der nächsten Version der Submod wird höchstwahrscheinlich das besagte Upgradesystem in praktisch vollem Umfang enthalten sein. Ich würde den Thread aber dennoch gerne offen lassen, falls jemand doch noch weitere Wege kennt, um dieses Problem zu bewältigen, oder ein eng verwandtes Problem vorbringen möchte.
Ich fasse nun zum Schluss die Ergebnisse zusammen:
Ziel: Gegenstand des Themas ist, ein Upgrade in SuMI von mehreren vorangestellt notwendigen Upgrades abhängig zu machen, um in dem Entwicklungssystem einer Fraktion "Knotenpunkte" zu ermöglichen.
Problem: In SuM I ist es nicht möglich, einem CommandButton mehrere NeededUpgrades zuzuweisen. So direkt lässt sich das gesetzte Ziel also nicht erreichen.
Lösungen: Während es offenbar nicht direkt möglich ist, den Erwerb eines Upgrades (also seinen commandbutton) von mehr als einem Upgrade abhängig zu machen, gibt es doch mehrere mögliche Methoden, dieses Problem zu umgehen und somit praktisch und näherungsweise zu lösen. Diese sind:
1) Kurzschluss des UpgradeButtons - Bei dieser Methode entfällt das Upgrade an sich und als CommandButton. Stattdessen werden dessen gewünschte Effekte (in Form von Behavior Blöcken in den entsprechenden INIs) direkt abhängig gemacht von allen notwendigen, gegebenen Upgrades durch die Zeile "RequiresAllTriggers = Yes" im Behavior Block und der Aufführung aller notwendigen Upgrades als Trigger dieses Behaviors. Dadurch wird das Upgrade selbst praktisch "kurzgeschlossen". Diese Methode funktioniert uneingeschränkt mit einer beliebigen Menge von Vor-Upgrades, aber es entfällt der tatsächliche Kauf (und somit Baukosten und Bauzeit) dieses Upgrades selbst. Die Information über das Upgrade sollte durch einen FakeButton angegeben werden.
2) Update des CommandSets des Upgradegebäudes - Bei dieser Methode kommt es sehr wohl zum Einsatz des CommandButtons jenes Upgrades, aber seine Abhängigkeit von vorangehenden Upgrades ist nicht direkt am Button, sondern wird indirekt dem Button vorausgesetzt: Das Gebäude, dessen CommandSet den Button enthält, erhält ein Behavior CommandSetUpdate, mit dem sein CommandSet von einer ursprünglichen Version mit einem FakeButton aktualisiert wird auf eines mit dem echten Button des Upgrades. Dieses Behavior CommandSetUpdate erfordert alle seine Trigger, und diese Trigger sind ebenso alle diese vorangehenden Upgrades. Somit ist die volle Funktionalität des Upgradeverhaltens gewährleistet. Nachteil bei dieser Methode ist, dass jedes Gebäude immer nur ein solches CommandSetUpdate Behavior erhalten kann, bzw. zumindest nur eine einsträngige, einwegige Verkettung solcher Behaviors, und nicht mehrere paralell. Das liegt daran, dass ein solches CommandSetUpdate immer das ganze CommandSet ersetzt, statt nur einen bestimmten Punkt hinzuzufügen, und die etwaige Vorhandenheit oder Nichtvorhandenheit eines anderen CSUpdates hierbei nicht berücksichtigt werden kann.
Fazit:Das Ziel kann zwar nicht generell direkt durch echte Lösung des Problems erfüllt werden, dennoch ist es möglich, dieses praktisch und näherungsweise zu erreichen. Um also mehrere Upgrades als allesamt notwendige Voraussetzungen für einen Upgrade-CommandButton einzusetzen, hat man die Möglichkeiten, entweder die Abhängigkeiten des Buttons durch ein CommandSetUpdate vorzuverlagern/vorwegzunehmen, oder den Button wo notwendig einfach gänzlich zu entfernen und stattdessen diese mehreren Abhängigkeiten direkt auf die gewünschte Wirkung des vormaligen Upgrades zu beziehen. In beiden Fällen ist es auch möglich, entfallene Buttons zwecks Bedienkomforts durch FakeButtons zu ersetzen, um dem Spieler die Informationen über diese Upgradefunktion zukommen zu lassen.
So, und das war es jetzt damit. Gute Nacht euch allen! 8)
PS: @Manuel: Tut mir leid, ging nicht kürzer.
Manuel2811:
Also wenn ich mir jetzt deinen letzten Post so durchlese, dann scheinst du ja eigentlich die Lösung schon zu kennen, oder lieg ich da jetzt falsch? Wenn dem so ist, was genau ist dann jetzt noch deine Frage? ^^
Marioverraeter:
Hm, ja, das ist jetzt so eine Sache. :D
Also ich war am Anfang tatsächlich total hilflos damit, aber durch eure Antworten habt ihr mir entscheidende Impulse gegeben, um so doch auf eine Lösung zu kommen - das hat sich dann aus dem Schreiben heraus ergeben.
Daher nochmal vielen Dank, denn ohne euch wäre ich darauf überhaupt nicht gekommen. :)
Meine Zusammenfassung gegen Ende des letzten Posts war Reproduktion der Ergebnisse dieses ziemlich langen, textumfangreichen Threads, um deiner Aufforderung gerecht zu werden, mich kürzer zu fassen. Damit wollte ich noch einmal "kurz und knapp", auf das Wesentliche reduziert, die Ergebnisse wiedergeben, die wir auf dem Weg erarbeitet haben, damit andere mit ähnlichen Problemen diese daraufhin direkt verwenden können.
Offen bleibt eigentlich nur die Frage nach weiteren Möglichkeiten, denn wie schon gesagt haben wir immer noch nichts, wenn mehrere paralelle Upgradestränge in einem Gebäude multiple Abhängigkeiten erhalten sollen. Außer für diesen Sonderfall ist das Problem jetzt also gelöst.
Liebe Grüße,
Mario
(Thx nochma ;) )
Manuel2811:
weiterhin gutes Gelingen wünsche ich
Navigation
[0] Themen-Index
[*] Vorherige Sete
Zur normalen Ansicht wechseln