Layered common events misbehave #3
Conversation
|
|
|
My latest changes on my branch fix this. Please check them and include them to main release, particularly the break and stack fixes are crucial to the interpreter. The easy interpreter is so solid after the changes that it can actually run the Escalar battle system fine. The only problem that I see is the frame rate that is low while the enemies are moving on the map. |
ghost
assigned 
|
Okay assigned this to me. |
|
Have you checked my changes? |
|
Try opening a pull request. To do this, go to your fork Lobomon/Player -> Pull requests -> Open a pull request -> Create pull requesst |
|
"Have you checked my changes?" He has unrelated changes (his high resolution stuff) in the branch, so a pull request is a bad idea. Will do a cherry pick. |
|
@Lobomon The following case fails for me in both cases (with and without your changes) CommonEvent 1: Message: 5 is not displayed. Maybe I triggered a different bug with this that is unrelated :P |
|
It works for me on my personal build , what did you pick as my changes ? |
|
May be you trigger an other bug with some event changes, do you have an example project ? Did you set several parallel process that may not work =/ check this sample http://www.2shared.com/file/vuCZ0syS/vs2010.html it works, and with out the code changes, you will never see anything after the events, nor break |
|
Several parallel process may not work because we have just one interpreter per map, and one child process per event call, so haven several parallel map events that calls to several system events probably wont work. |
on most of games. The stack calls works and also the break. Fixed the teleport to store location.
|
Now I know why it failed for me: When the message is multiline it is not displayed before the teleport... That is a different bug :/ |
…d the event called via "Call event" displayed a message the message directly after the "Call event" call was not displayed.
|
I cherry picked your commit and applied an extra fix that also fixes the multiline case for me. My branch: https://github.com/Ghabry/easyrpg-player/tree/events |
|
The Escalar Battle system still works, so you did not break anything and picked up my changes. |
|
GitHub feed says I opened the bug request. Is a github pull request API bug? |
|
Not sure if that fixes that bug. Hard to get the original test case... we only have a partly cropped screenshot. But it fixes something related to (Common) event calling ;). E.g. input message commands after event return were ignored when the message after the return had them. It reports "you opened" because you opened that issue but I attached my pull to that issue using curl and the github api. (and the feed uses the issue creator I guess?) |
|
OK, I just imported this bug for the old bug tracker, so I don't have more details about this. |
Layered common events misbehave
Multiplayer improvements
… "ControlVariables" method from a switch lookup to a "dispatch table"-style code structure
… "ConditionalBranch" method from a switch lookup to a "dispatch table"-style code structure
This is a bit of a difficult issue to work out, so I apologise if I am unclear.
I have a dialogue tree where one option leads to separate common events (this event itself is a common event) controlled by conditional branches and labels, another displays text and includes a label, and the last is to close the tree.
In the original player, the internal common event can be started, and will lead back to the original event like so:
Start if x, go to 1 -> label 1 -> inner event plays out -> go to 99 -> 99 is at the start again
However with EasyRPG player, the inner event will loop until the last command is executed: There’s a yes/no branch, an exp check, and then no events should follow after some effects and messages, or an “insufficient exp” alert, but it takes the last event in the list (outside the “<> End” of the branches) to actually return to the outer event – the message that plays via “No” that sits at the end of the code.
Secondly, this cancel instead leads onto the next dialogue option in the outer event, instead of the go to that proceeds the Call common event command.
This diagram may be of more assistance: