Verständlich ausgedrückt.
Ich habe jetzt nach dieser Art alle Maps umgebaut und es funktioniert noch tadellos!
Danke für diese gute Lösung!! :)
Druckbare Version
Verständlich ausgedrückt.
Ich habe jetzt nach dieser Art alle Maps umgebaut und es funktioniert noch tadellos!
Danke für diese gute Lösung!! :)
Das stimmt nur bedingt. Man kann keine Befehle mehr Rechts auswählen, da alles ausgegraut ist - aber mit Copy & Paste (also Strg + C und Strg + V) funktioniert das immer noch. So können Move Events auch mehr als 200 Befehle habe. Und ja, die funktionieren auch ohne Probleme. Hab in meinem Spiel einige Verfolgungen und Routen die mehr als die besagten 200 Befehle haben.Zitat:
Zitat von JasonWeal
200 Befehle? Wer braucht'n so viel? :D Aber selbst wenn ichs in mehrere MEs aufteil, die durch Waits getrennt werden, funktionierts doch auch.
Mache ein Event was ne bestimmte Route abläuft. Z.B: eine Wache die eine komplette Stadtmauer abläuft. Da reichen 200 Befehle wahrscheinlich nicht aus, wenn die Stadt 50x50 groß ist oder noch größer und die Stadtmauer einmal quasi ganz rumgeht.Zitat:
Zitat von TwoFace
Es wäre nun aber auch kein Problem mehrere move events zu nutzen. Sollte es sich hierbei um einen NPC handeln, der alleine läuft, könnte man auch einen PP nutzen.Zitat:
Das stimmt nur bedingt. Man kann keine Befehle mehr Rechts auswählen, da alles ausgegraut ist - aber mit Copy & Paste (also Strg + C und Strg + V) funktioniert das immer noch. So können Move Events auch mehr als 200 Befehle habe. Und ja, die funktionieren auch ohne Probleme. Hab in meinem Spiel einige Verfolgungen und Routen die mehr als die besagten 200 Befehle haben.
Im 2k sollte das kein Problem sein.
Kommt halt drauf an was man macht. Ich hab z.B. ne Verfolgungsjagd über ne größere Map, da reichen die 200 Befehle nicht aus. Ich könnte mit mehreren Moveevents arbeiten, aber dann müsste ich entweder mehrere Switches oder Variablen nehmen oder die Position abforken - alles viel zu kompliziert. xD
Wieso Position abforken? So wie ich das hier versteh tackerst du einfach die Moveevents hintereinander, machst dein ersten Moveevent mit meinetwegen 200 Befehlen / Schritten und n Wait dahinter. Der Wait berechnet sich auf Movespeed Normal in dem Fall mit 200 x (8 x 0,0 Sek.). Dann machst du den nächsten Movebefehl etc.pp.
Wozu mit Waitbefehlen unnötig kompliziert machen?
Um eine Bewegung abzuwarten, gibt es den Befehl, der sich direkt unter MoveEvent befindet.
In jedem Fall ist aber Austricksen dieses Limits im Ergebnis verlässlicher als mehrere solche Anweisungskollektoren
nacheinander einzubauen, ausser es gibt irgendwo eine Abzweigung nach bestimmten Voraussetzungen, dann muss
es eh unterbrochen werden.
Jo, "proceed with Movement" benutz ich persönlich nie. Hat bei mir irgendwie auch nie so recht funktioniert. Aber kompliziert sind Waits jetz ja als Ersatz auch nicht.
Wird bei "Proceed with Movement" nicht darauf gewartet, bis ALLE Move-Events auf der Karte fertig sind? So habe ich das nämlich in Erinnerung.
PeAcE
MorDen
Ja, aber nur die, die du auch per EventBefehl "MoveEvent" steuerst.
Also das "Move Route" zählt nicht dazu.
LG
MajinSonic
Ah, Move Route. Davon red ich eigentlich die ganze Zeit. Das hat nämlich auch 200 Befehle als Begrenzung und da lässt sich nicht mal eben mit Waits und so arbeiten. xDZitat:
Zitat von MajinSonic
Wenn man ein längeres Movement hat, würde ich die Bewegung nicht über "move route" steuern. Sondern einfach, wie ich sagte, einen Parallel Process machen:
Move Event 200 Befehle
proceed with movement (im 2k: move all)
Move Event 200 Befehle
proceed with movement (im 2k: move all)
Es kann nichts schief gehen, solange du nichts in den weg donnerst. Sprich nen Stein oder so. Dann blockiert natürlich alles.
Und solange du drauf achtest, dass auf der map auch jedes moving funzt, kann mit "proceed with movement" nichts schief gehen
ich habs immer benutzt und klappt gut.
@MajinSonic:
Und was machst du bei mehreren sich bewegenden events mit unterschiedlicher geschwindigkeit und unterschiedlichem timing/waits/richtungswechsel in ihren bewegungsabläufen? dann hackt das Movement nach den 200 befehlen bei einigen events. Wie das ist, wenn du jedem der sich bewegenden events seine route vorgibst in einem eigenen Parallel-Process weiß ich grad nicht aussem kopf.
Dann musst du die Bewegungsabläufe anpassen. Und zwar so, dass sie alle gleich groß sind, oder aber, dass du den Events mit weniger als 200 Befehlen eine Move Route gibst.
Proceed with movement bezieht sich auf ALLE Events. Da ist es völlig egal aus welchem Event der Move Befehl kommt.
Also wenn du jedem seinen eigenen PP gibst, so kann es passieren, dass da einiges durcheinander kommt. Muss aber nicht. Das ist alles eine Frage der Abstimmung.
Du solltest es dann mit Bewegungsabläufen nicht übertreiben.
Und wieder mal ein tolles Beispiel, wo sich der maker einfach nur dämlich verhält...
Also die 200-Befehle-Grenze ist eine künstliche Grenze, oder? Weil reinkopieren kann man die Befehle ja noch, es werden nur die Buttons deaktiviert.
Könnte man also nicht die Deaktivierung der Buttons aushebeln im Maker?
Geht mit Sicherheit per hexhex ;)
Könnte man das nicht auch irgendwie per .ini beim RM2k9 - Cherry's »Aufsatz« - wegzaubern? Das wäre doch dann fast das gleiche, wie'n HexHack in dem Falle, nicht oder?^^
PeAcE
MorDen
Ich seh da jetzt nichts, was man in dem Dialogboxskript umschreiben könnte. Das ist schon tiefer im Code vergraben.