Unter Info kommt 1.85Zitat von Cherry1
Die .exe müsste auf meinem Uralt-Rechner noch die mit Gnafs Picturebetrug sein, du weißt besser als ich von welcher Edition die war (ich weiß es nämlich nicht XD)
Unter Info kommt 1.85
Die .exe müsste auf meinem Uralt-Rechner noch die mit Gnafs Picturebetrug sein, du weißt besser als ich von welcher Edition die war (ich weiß es nämlich nicht XD)
Das ist "VALUE!", die aktuellste RPG2000-Version 1.51
(http://tkool.jp/support/download/rpg2000/rpg2000up.exe)
Parallele Events tun jedenfalls auch bei mir weiterführen, was nach einem
Mapwechsel kommt, aber wiederholen sich nicht wie ein Autostart und darum
gings ja nicht.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
*GRUMMEL*
Wieso sich diese Frage auf Map-Events beziehen sollte:
Weil bei Common-Events so gut wie ALLE Event-Methoden diese Eigenschaft erfüllen.
- Parallele Common Events laufen Map-Unabhängig
- AutoStart Common Events ebenso
- Call Common Events übernehmen die Eigenschaften von dem Event, das sie aufgerufen hat.
Wie es bei Map-Events ist:
ALLE Event Start Conditions BIS AUF "Parallel Process" verhalten sich in der Hinsicht gleich:
- Sie laufen unabhängig von Teleport und Map wechsel weiter
- Sie wiederholen sich nicht, wenn man sich am Ende des Events nicht auf
der Map des Events befindet
Bei Parallel Events ist dies anders:
- Nach einem Map-Wechsel brechen Parallel Events ab.
- Dies passiert nichtauf der Stelle - einige Befehle werden direkt nach dem Teleport noch ausgeführt, etwa Change Switch.
- Sobald aber eine Wartezeit nach dem Teleport integriert wird werden die Befehle dahinter nicht mehr ausgeführt
- Auch andere Befehle, wie etwa Show Message, werden selbst direkt nach dem Teleport nichtmehr ausgeführt.
Dies gilt Sowohl bei der ungepatchten RPG-Maker 2000, als auch dem mit Gnarf-Picture-Patch. Es wäre eine ziemlich Dummheit, eine solch grundliegendes Verhalten durch einen Patch zu ändern, zumal verschiedene Skripte auf sowas basieren können und es überhaupt keinen Vorteil bringt, dieses Verhalten zu ändern - da es Sinn macht.
Und bevor hier Leute mit dem Argument kommen "Bei meinem Menu/KS/SkriptXY ist das aber so und so". Nehmt euch doch mal bitte 2-3 Minuten Zeit und bastelt euch ein kleines Projekt, das diese Eigenschaft isoliert und unabhängig von anderen Kram überprüft. Denn nur so kann man zu einer klaren Aussage kommen.
Das sind hier wirklich tolle Experten°
C ya
Lachsen
Geändert von Lachsen (26.04.2008 um 16:25 Uhr)
so~ hab das jetzt mal getestet....
Und es stimmt, ich hab mich geirrt XD
naja, werd mir merken.
Jetzt fallen mir auch einige fehler in Phönix ein XD
mfg R.D.
--
XD
Genau damit wollte ich gerade kommen ^^"
Aber ich denke, dass die Sache mit dem Menü dann hier drunter fällt. Nach dem Teleport wird wie gesagt nur noch die Tranzparenz geändert und die Grafik des Helden aktualisiert - und ein oder zwei Switches abgestellt.
Werde es aber auch bei Gelgenheit mal testen, finde das sehr interessant.
LG,
Orange4
Okay... um die Sache mal wieder etwas aufzulockern stell ich mal ne Frage (ist ja sowieso eine Freirunde)
Frage: Welcher Move-Event-Befehl kann ein ungewolltes Pan-Screen-Verhalten bewirken?
C ya
Lachsen
Edit: Okay... Streng genommen hat elvissteinjr die nächste Frage, da er die Frage zuerst richtig beantwortet hat - aber ihm fiel ja schon zuletzt keine Frage ein... öhm... Naja, wenn er will, kann ich meine Frage auch zurücknehmen o_°
ne mach ruhig weiter^^
Kenn die Antwort trotzdem nich.....
auf ein normales Event oder?
Das wüsst ich jetzt auch nich o.o'''
Wär aber sehr interessant zu wissen, vllt kann ich dann einen kleinen Bug beseitigen^^
Wärs aufn Hero, wärs auch ne dumme Frage, weil es dann alle Step Befehle wären XD
mfg R.D.
--
Start Jump / End Jump.
Dabei bewegt sich nämlich der Bildschirm nicht mit - äußerst ärgerlich wenn der Hero aus dem sichtbaren Bereich springt XD
Die Antwort ist richtig.
Das beschriebene Verhalten leider falsch.
Ich lass es dennoch mal durchgehen.
Genauer gesagt läuft es so ab:
Bei Sprüngen des Heldens bewegt sich der Bildschirm mit. Dummerweise auch dann, wenn er es nicht soll. Beispiel: Held steht am linken Rand der Map und springt nach rechts. In dem Fall bewegt sich der Bildschirm mit nach rechts, womit der Held weiterhin am linken Rand des Bildschirms bleibt, was unerwünscht ist, weil er nicht mehr am Rand der Map ist.
Dieses Verhalten kann man u.a. bei den Sprungevents von Tara's Adventure betrachten.
(sofern GSandSDS das jetzt nicht behoben hat - ich glaube das hat er nicht - wüsste gerade auch nicht, wie man das einfach machen kann ... gut eventuell schon, durch Scene X und Scene Y Coordinaten Abfragen und Fix Screen Befehl - benötigt aber je nach Sprungweitere verschiedene Fälle, sollte sehr umständlich sein...)
Joa, Orange4, du bist dran o_°
C ya
Lachsen
Geändert von Lachsen (27.04.2008 um 14:44 Uhr)
Hm, so ähnlich wars gemeint XD
Ausrede such ^^
Ok, nächste Frage:
Ein PushKey Event und ein AutoStart Event starten gleichzeitig. Was passiert?
Sie laufen jedenfalls nicht gleichzeitig, sondern hintereinander.
Es ist nicht möglich, dass zwei Nicht-Parallel-Events parallel laufen.
Welches zuerst startet hängt davon ab, welches zuerst gestart wird, denke ich. Bei RPG-Maker gibt es kein wirkliches "gleichzeitig", nur stark abwechselnd sequentiell.
Wie willst du es schaffen, dass beide Events gleichzeitig starten? oO
vll willst du aber auch nur das hier wissen: wenn du ein autostart-Event aus einem PushKey-Event aus aufrufst, so wird das pushkey-event erst zu Ende ausgeführt, bevor das autostart ausgelöst wird.
(kann uach sein, dass das puskey-event bei einem wait abbricht, das müsst ich erst testen)
edit: @Lachsen: natürlich hast du recht mit dem "jenachdem was zuerst gestartet wird"^^ gleichzeitig geht eben schlecht
--
XD
Nehmt doch nicht alles so genau
Ihr habt beide Recht, gemeint war einfach die Tatsache, dass ein AutoStart Event nicht ausgeführt wird, bevor nicht das komplette PushKey/HeroTouch Event durch ist.
War vlt doof formuliert ^^"
Ok, wer von euch beiden will als nächstes? ^^
Allerdings laufen auch parallele Prozesse nicht parallel, zumindest nicht für die CPU.
Ja, Kelven, wir wissen's.Allerdings laufen auch parallele Prozesse nicht parallel, zumindest nicht für die CPU.
Da ja nichts kommt, stell ich mal wieder ne Frage und zwar diesmal eine ziemlich fiese.
Frage: Wie schafft man es, alle Wartezeiten von einem Map-Event mit Parallel-Process zur Laufzeit zu halbieren. (D.h. ohne den Code zu verändern oder irgendwelche Forks einzubauen, die dies ermöglichen)
Noch eine Anmerkung dazu: Hierbei handelt es sich mehr um einen RPG-Maker Bug, als um irgendein Feature.
Tipp: Die Map-Präsenz des Heldens spielt eine Rolle.
Geändert von Lachsen (29.04.2008 um 10:48 Uhr)
Okay... da nichts kommt geb ich nochmal nen kleinen Hinweis, wie man den Fehler finden kann:
Erstellt euch ein Map-Event mit einer Seite auf parallel Process. Stellt es auf "Same Level As Hero" ... und versucht mit dem Event zu interagieren (Held-Figur). Achtet dann darauf, was mit dem Inhalt des parallel Events passiert.
C ya
Lachsen
Lachsen, könntest du bitte mal auflösen?
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
Nagut, scheint ja niemand zu antworten.
Lösung: Ein paralleles Map-Event mit "Same Level As Hero" spielt den Inhalt mit halbierten Wartezeiten ab, wenn man das Event mit der Helden-Figur berührt (d.h. dagegen läuft). Das kann in einigen Situationen zu sehr verwirrenden verhalten führen. Von daher sind Parallele Events mit "Same Level As Hero" besser zu vermeiden.
Naja... ich schätze mal dann ist Freirunde.
Hrmpf...
Wie kann es passieren, dass ein Event seine Move Route mit der HALBEN Frequency ausführt?
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:
Berechtigungen
Zitieren
