Wenn du andere fragen musst, warum etwas nicht funktioniert, hast du es gebaut ohne zu verstehen was du tust. Ich würde damit anfangen Dinge zu bauen, die du verstehst. Das geht am besten, in dem man den Zweck jeder Zeile versteht und wenn man eine Vorstellung hat, was passieren soll und nur Befehle anwendet, die auch Teil dieses Ablaufen sind, dann klappt das auch.
Dein Code da, was soll das? Du fragst viele Male pro Sekunde ab, ob deine drei Charaktere einen Schild haben. Wenn alle deine Helden einen Schild tragen, dann sollte das sogar funktionieren. Ansonsten wird der Switch doch im Millisekundentakt wechseln und dein Schildblockscript wird je nach dem wie viele deiner Charaktere gerade den Schild tragen entweder gar nicht, oder 33/66/100% der Zeit funktionieren, wechselnd im Takt von Millisekunden.
Das in verschiedenen CEs? Wie kommt man darauf?
Zitat
"Ich habe ein CE, dass im Millisekundentakt ein Switch wild und planlos an und aus schaltet! Woah, ich hab ne Idee! Anstatt nacheinander an-aus, nehme ich viele CEs und schalte die Switches ZEITGLEICH wild und planlos an und aus!"
...
Ich finds sowieso mutig, ein Action-Kampfsystem zu benutzen, wenn man nur sehr wenig bis gar nicht scripten kann, aber dann solltest du zumindest versuchen es zu lernen. Man lernt auch nicht kochen, wenn man immer nur eine Augenbinde tragend zufällige 25 Sachen in den Topf wirft und dann andere fragt, warum es scheisse schmeckt. Fang kleiner an. Bau es für einen Helden, wenn das funktioniert, bau es für zwei. Wenn es bei einem funktioniert und bei zweien nicht, weisst du wo du suchen musst. Wenn du erst ganz viel machst, dann fühlst du dich leichter überfordert und fragst lieber das Forum statt mal selbst zu überlegen.
Hilft da eine weitere Conditional Branch, die ich gleich 0 setze & dann den Schalter auf OFF stelle?
EDIT: @Corti Ich sehe das ein bisschen anders. Man muss Dinge wagen & viel rumexperimentieren, damit man überhaupt etwas lernt. Ich kann noch so oft die Standard-Maker-Battlesystems nachbauen & verstehen wie ich will, davon lern ich ja auch nicht, wie ich ein ABS baue. Stattdessen muss man sich halt das ABS von jemand anderem besorgen & damit rumexperimentieren & versuchen es Schritt für Schritt so zu verstehen. (:
Denk nach, du kommst drauf. Nicht raten. Überleg dir was passieren soll und unter welchen Umständen es passieren soll und dann überleg, wie es wohl am einfachsten ginge.
Norpoleon, ich finde, Corti hat schon recht. Indem du schrittweise kleine Dinge baust und genau verstehst lernst du sehr wohl wie man ein ABS baut. Im Sinne von: Wenn du dich mal mit der Materie auskennst, dann wird für dich total logisch erscheinen wie du ein ABS angehen müsstest, auch wenn du bis jetzt nur andere Dinge gebaut hast. Wenn du mal mit den Bausteinen und ihren Eigenheiten vertraut bist, kannst du fast alles bauen oder zumindest schon passende Lösungsansätze finden.
Andersherum wirst du aber wahrscheinlich Dinge eher falsch verstehen oder glauben zu verstehen und dann falsch einsetzen. (Und "Herumprobieren bis es zu funktionieren scheint", nach dem Motto "ich versteh nicht warum ich die Waits brauche, ober ohne sie funktionierts nicht", wird nur zu unerwarteten Bugs und späterem Haareraufen führen - und zu Spaghetticode den weder du noch jemand, der dir helfen will, durchschauen kann.) Das merkt man jetzt schon ganz deutlich wenn man sich deinen Code anschaut und die Fragen die du stellst. Und das ist überhaupt nicht böse gemeint.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!
Cherry und Corti haben Recht, du solltest lieber vorher eine Nummer kleiner anfangen und genau verinnerlichen wie jeder Befehl funktioniert und selber versuchen einen Lösungsansatz zu finden.
Versuche nicht wild drauf los zu skripten, sondern überlege dir erst einen "Pseudo-Algorithmus".
Dennoch:
Pass auf, ganz einfach, nach diesem Fall, kann es vier verschiedene Alternativen geben. Die Alternativen hintereinander so auszuführen würde zu einer Überschreibung einer wohlmöglich erfüllten Bedingung führen. Das heißt, dass immer das ausgerüstete Schild von der "WITCH" alles vorher nichtig macht, weil das immer als Letztes ausgeführt wird. Das heißt, wenn man diese Klasse spielt, sollte das eigentlich funktionieren, aber mit den anderen Klassen dann wiederum nicht. Stattdessen musst du dem Maker sagen, dass es Alternativen sind, indem du Bedingungen mit Else-Verzweigungen benutzt.
Hier wird die Shield ID je nachdem, wer gerade in der Party ist, nach dem aktuellen Helden zugewiesen. Allerdings geht das auch nur so, wenn du wirklich immernur einen einzigen Charakter in der Party hast! (Bei einem ABS üblich, es sei denn Du benutzt NPC-Mitstreiter, was allerdings für einen Amateur zu viel des Guten wäre)
EDIT: Trotzdem überlege dir bitte Mal, was es mit diesem Befehl @> Control Variables: [0001:Shield ID] = [CHARACTER]'s Shield ID GENAU auf sich hat.
Ja, ich weiß ja, dass ihr mir nur helfen wollt & dafür bin ich sehr dankbar. (:
Allerdings sind für Nicht-Mathematiker Programmiersprachen gar nicht so logisch aufgebaut, wie ihr denkt.
Z.B. wäre ich nie darauf gekommen, dass ich die Conditional Branches ineinander verschachteln muss, damit das Programm weiß, dass es sich um gleichrangige Alternativen handelt. Ich habe immer alles schön untereinander geschrieben & dachte: "Passt schon."
@ Drakee Nach einigen Fehlern, die darauf beruhten, dass ich deinen Code einfach nicht richtig gelesen habe, funktioniert dein Code prima. Danke.
Also, bei "@> Control Variables: [0001:Shield ID] = [CHARACTER]'s Shield ID" würde ich sagen, dass eine Variable, die "[0001:Shield ID]" heißt, gleich der Shield-ID des CHARAKTERs gesetzt wird, wahrscheinlich um in einem zweiten Schritt abfragen zu lassen, ob die Shield-ID einen bestimmten Wert erreicht hat.
Ich würde dir tatsächlich raten lieber alles untereinanderzuschreiben und weniger zu verschachteln. Ist natürlich immer persönliche Vorliebe. Ich mache dies eben am liebsten genauso, weil es für mich übersichtlicher ist und weniger Codezeilen benötigt. Zudem rutscht das ganze beim Verschachteln immer weiter nach rechts. Gerade bei sehr vielseitigen Abfragen wird das kritisch.
Das Problem mit dem Überschreiben von bereits erfüllten Bedingungen löst du ganz simpel mit Labeln.
1)
2)
Das sind nun zwei verschiedene Codes.
Wenn man nur einen Helden in der Party haben kann, dann nimm das erste, da es kürzer ist.
Wenn man mehrere Partymitglieder haben kann, dann nimm das zweite. Der Unterschied ist einfach, dass dort nicht nur gefragt wird, ob ein Held in der Party ist, sondern auch, ob dieser ein Schild trägt. Also die Variable größer als 0 ist, da 0 kein Schild bedeutet. Dadurch würde solange das Inventar deiner Party überprüft, bis du einen Schild gefunden hast oder eben bereits alle Partymitglieder dran waren.
Es geht dir ja darum, ob ein Held in der Party einen Schild ausgerüstet hat. Wenn du das mal mit "ja" beantworten kannst, dann interessiert dich der Rest der Party nicht und du überspringst die übrigen Abfragen.
Label sind sehr nützlich und leicht zu verstehen. Teste es einfach mal. Das wirst du sicher mal gut gebrauchen können.
So sieht alles gleich aus und habe damit einzelne Blöcke, die eben alles dasselbe machen. Jeder steht für sich und ich kann es so besser erkennen. Persönlich verschachtel ich in der Regel nur, wenn es nötig ist. Wenn z.B. mehrere Bedingungen gleichzeitig erfüllt sein müssen, wie, wenn bestimmte Helden in der Party sein müssen, andere aber nicht. Bei deinem Beispiel aber, ist es nicht nötig. Du möchtest es ja nur bei einem der Helden wissen und der Rest wird überflüssig.
Für mich funktioniert es so am besten. Ich habe ebenso eher wenig Erfahrung im Programmieren, daher kann ich dich in der Hinsicht schon verstehen. Aber du wirst für dich selbst rausfinden müssen, was dir am meisten liegt.
Labels sind cool, aber beim Copy und Paste kommts schnell mal vor, dass man ein Label doppelt hat und dann baut man schnell mal schleifen und Sachen, die so nicht sein sollen. Ich benutze Labels sehr gerne, die sind super. Nur wenn mal was nicht klappt, oder sich komisch verhält, schau dir auf jeden Fall deine Labels an.
Also, bei "@> Control Variables: [0001:Shield ID] = [CHARACTER]'s Shield ID" würde ich sagen, dass eine Variable, die "[0001:Shield ID]" heißt, gleich der Shield-ID des CHARAKTERs gesetzt wird, wahrscheinlich um in einem zweiten Schritt abfragen zu lassen, ob die Shield-ID einen bestimmten Wert erreicht hat.
...
Speziell auf deinen Code, der sich selbst überschrieben hat, heißt es, dass durch den Befehl die ID des ausgerüsteten Shields in der Variable gespeichert wird, AUCH WENN der Charakter sich nicht in der Party befindet.
Zitat
Zitieren
CherryShare
