Eventfenster soooo klein >.<

[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...