Eventfenster soooo klein >.<

[Engel der Furcht]

Ich bins schon wieder

Diesesmal gehts ums Eventfenster.

Ist es möglich,das Fenster nach rechts hin zu vergrößern? So dass ich den Rest des Codes sehen kann?

[Cepanks]

Das könnte was für dich sein.
Oder du benutzt den PicPointerPatch und sparst dir dann solche If-Monster.

[R.F.]

Evtl. ist es ganz nützlich das mit "call Event" zu machen.
Sprich du verteilst den Code über mehrere Seiten des Events und greifst dann auf eine bestimmte Seite mit diesem Befehl zu.

[Engel der Furcht]

das ganze ist ja eine einzige Bedingung.
Und dieser Goliath Patch ist nützlich,vielen Dank^^

[MagicMaker]

Ich wäre fast vom Stuhl gefallen als ich gesehen habe, dass jemand das
gleiche Problem zeigt wie ich eben zum xten mal hatte. In dem Fall mache
ich das mit Bedingungskategorien, zB kannst du alle 500 sowas einbauen:

Code:

<> Branch If Var [0029:CHAR1ATB] is 500 Less/Equal
 <> Alle Branches von 0 bis <500
 <>
: Else Handler
 <> Branch If Var [0029:CHAR1ATB] is 1000 Less/Equal
  <> Alle Branches von >500 bis <1000
  <>
 : Else Handler
  <> usw...

[Orange4]

Richtig witzig wird es, wenn man hier irgendwo einen Fehler finden muss




Aufziehen wäre wirklich nicht schlecht wenn das gehen würde. Naja ich hab irgendwann angefangen ab einem bestimmten Punkt das Event zu splitten und zu callen. Oder wie in diesem Fall ein einem anderen Eventfenster weiterbasteln und erst am Ende zusammenfügen ^^ (Und dann hoffen das alles geht und man keinen Fehler finden muss xD)

[Cherry]

Ich werde in den Ultimate eine horizontale Scrollbar einbauen.

[G-Brothers]

Else Handler ist in manchen fällen nicht mal nötig, es reicht auch, wenn man nach dem "end" erneut ein Branch macht. Die obere Bedingung wird sowieso ignoriert, wenn nicht das vorliegt, was gefordert wird, und wenn die Abfrage heisst "Greater then or Equal to" dann wird das untere Branch das obere sowieso überschreiben, vorausgesetzt es hat etwas mit Pictures oder mit Variablen zu tun.

[Morden]

Else Handler ist in manchen fällen nicht mal nötig, es reicht auch, wenn man nach dem "end" erneut ein Branch macht. Die obere Bedingung wird sowieso ignoriert, wenn nicht das vorliegt, was gefordert wird, und wenn die Abfrage heisst "Greater then or Equal to" dann wird das untere Branch das obere sowieso überschreiben, vorausgesetzt es hat etwas mit Pictures oder mit Variablen zu tun.

...

Man hat ja auch noch Labels en Masse zur Verfügung.
Desweiteren kann ich für solche Dinge eigentlich nur auf Cherrys PicPointer-Patch verweisen. Der erspart von vornherein solche "Bedingungs"-Türme =) Zumindest, wenn es mit Pictures zu tun hat.

Ansonsten kann ich nur empfehlen, dass man beim coden das Event zerlegt. Also immer, wenn solche Code-Türme an den Rand des Fensters kommen, einfach in einem neuen Event weiter machen. Dann kann man das ganze am Ende wieder zusammenfügen. Ist imo auch die einzige vernünftige Möglichkeit, um Fehler bei solchen Türmen schnell zu erkennen, da man ja sonst nich den Code sieht und es immer wieder heißt [Pfeil runter], [Leertaste), nachgucken ob alles stimmt und dann [Enter].

Btw.:
Stimmt es eigentlich, dass der "Else-Case" langsamer ist, als wenn man das ganze ohne Else und eventuell mit Labels zusammenbaut?

PeAcE
MorDen

[Das'O']

Ich verstehe sowieso nicht, was die ganzen Elsen da sollen. Wenn man mit der höchstmöglichen Zahl anfängt, und sich dann nach unten durcharbeitet, lässt sich das ganze doch auf einer Hierarchie-Ebene abhandeln, oder bin ich gerade zu dumm und sehe nicht, worum es geht?

Beispiel in Pseodocode: größtmögliche Zahl sei 5

Code:

If Variable Greater or Equal 5
  vorgesehene Aktion 5 ausführen
  EXIT Event
End
If Variable Greater or Equal 4
  vorgesehene Aktion 4 ausführen
  EXIT Event
End
If Variable Greater or Equal 3
  vorgesehene Aktion 3  ausführen
  EXIT Event
End

.. und so weiter. Wenn Variable zB 4 ist, zieht das erste IF nicht, weil die Bedingung nicht erfülllt ist, und das dritte If kann gar nicht mehr ziehen, weil vorher schon aus dem Code ausgestiegen wurde.

[Cherry]

Der Code ist aber schon wieder unnötig kompliziert, denn nachdem du sowieso beim ersten Treffer aussteigst, hat das "Greater or Equal" keine Wirkung. Wenn du da "Equal" hinmachst, brauchst du dann wiederum kein "Exit Event".

[Das'O']

Der Code ist aber schon wieder unnötig kompliziert, denn nachdem du sowieso beim ersten Treffer aussteigst, hat das "Greater or Equal" keine Wirkung. Wenn du da "Equal" hinmachst, brauchst du dann wiederum kein "Exit Event".

...

Da hast du natürlich vollkommen Recht. "Greater or Equal" wäre eigentlich nur beim ersten If sinnvoll, um den Fall abzufangen, das plötzlich eine Zahl angeliefert wird, die den erwarteten maximalen Zahlenwert übersteigt. Oder aber wenn man von irgendwoher mitten in die Routine reinspringt - was aber ein sehr unsauberer Programmierstil wäre. Da meine Erfahrung mit der Programmierung im Maker aber nahezu Null ist, und ich nicht den vollständigen Code gesehen habe, habe ich das einfach mal übernommen.

[makenshi]

Du hast aber in sofern Recht das so ein Forkwald völliger Müll ist. Selbst im Maker gibt es per Werteabschätzung die Möglichkeit das ganze abzukürzen.

Und selbst wenn man (z.B. für ein ID System) exakte ID Vergleiche braucht, dann kann man das ganze auf mehrere CEs aufspalten und diese dann von einem vorangegangen CE callen lassen. So bleibt das ganze les- und wartbar.
So ein Ding würde ich persönlich nie wieder nach Code durchschauen wollen.

[Morden]

Ja, man sollte da, wo man wirklich auf eine Fork Condition verzichten kann, auch darauf verzichten. Das tut dann der Übersicht gut.

Was auch noch hilft sich im Code zurecht zu finden sind "Comments" - im RM2k3 sogar Farbig hervorgehoben, zumindest die erste Zeile <.<. Ich mache mir an wichtigen Stellen im Code immer ein Comment rein, dann finde ich diese Stelle schneller und finde allgemein auch im Code schneller den Überblick. Desweiteren vereinfacht es die Fehlersuche für dritte =)

PeAcE
MorDen

[CapSeb]

Ich erwähne in diesem Zusammenhang mal das Problem, dass so riesen Events, gerade im Common-Tab, ab einer bestimmten Größe anfangen zu ruckeln und unter Umständen auch erst nach Sekunden laden, falls man mal versucht, das Eventfenster zu öffnen. Und das Geniale daran ist: Man braucht für solche spaßigen Effekte nicht mal einen langsamen Rechner.

Aufsplitten ist toll.

[Morden]

Ja, aber wenn du ein Wait an den Anfang des CE's setzt, dann baut es sich auch wesentlich schneller im Maker auf (wenn du es öffnest). Das ist wirklich auch auf extrem schnellen PC's so xD

Besonders langsam ist es, wenn man eine Fork-Condition an den Anfang eines solchen CodeBlocks setzt, ohne Wait. Dann dauert das laden schon seine Zeit (im Editor, nich InGame)

PeAcE
MorDen

[Cherry]

Also dass sich das CE im Maker (nicht im Spiel, wohlgemerkt!) schneller aufbaut, wenn man ein Wait reinmacht, ist absoluter Nonsens. Das Event wird ja nur gelesen, und nicht ausgeführt - im Gegenteil, mit einem Wait wird es rein theoretisch sogar noch einen Tick langsamer, weil ja ein weiterer Befehl aus der Datei gelesen werden muss (was natürlich nicht heißen soll, dass man keine Waits verwenden soll).

[Morden]

JA Cherry, ich weiß, dass das eigentlich total unlogisch ist xDD
Eben, weil er es ja nicht ausführt, sondern nur einlesen tut.

Aber probier es aus. Es ist wirklich so.
Wenn du ein schön volles Event hast und das mit ner Fork Condition beginnst, dann brauch das ganz schön, um sich aufzubauen. Mit einem Wait am Anfang geht es wesentlich schneller. Woran das jetzt genau liegt, weiß ich aber auch nicht xD

PeAcE
MorDen

[Cherry]

Hm, im Vergleich zu einer Fork könnte ich mir das sogar irgendwie erklären. Aber ich dachte, du meinst es generell. Es müsste mit "Label" o.ä. (was auch nur 1 Parameter hat) auch funktionieren...