easyRPGdebugparall.zip
In this sample game, there is a parallel common event displaying the text "1" and a parallel map event displaying "2".
Using RPG_RT.exe 1.8.0 / 1.9.1 / 1.1.0, you should read:
---- > "1, 2"
then
---- > "1, 1, 2, 1, 1, 2, 1, 1, 2, 1, 1, 2....."
Using player.exe:
---- > sometime it starts with 1, sometime it starts with 2. That's the first problem.
then
---- > "1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2.....". That's the second problem.
Parallel common event should maybe be prioritized?
Again many thanks for your work.
That's one of this tricky timing bugs in the interpreter.
We are currently trying to compare Player with RPG_RT directly by logging event execution using DynRPG an then comparing it.
See #646. This is a good candidate for a test, thanks.
This one won't be fixed as fast as your first one ;)
Parallel common events are now executed first, so it should now always start with "1".
The pattern "1,2,1,1,2,1..." is caused by the way RPG_RT deals with messages. 83d0f56e74d used to replicate this behaviour.
Just a curiosity. Have n parallel events displaying the numbers 1,2...n. If you've ever played around with Towers of Hanoi, you'll see that the pattern you get resembles the iterative solution of the Tower of Hanoi of n disks.
I didn't include a patch for this in #753. Please, reopen this.
Sorry, I interpreted the comment above incorrectly
I just tried this master and it looks to be fixed.
I get 1,2,1,1,2,1,1,2,1,1,2,...
Tested it with 4 message boxes: Works.
But for this one I'm actually curious why the result is matching the hanoi-solution as noticed by Zegeri. Adding this to my "stuff for long nights"-list. xD
Most helpful comment
Tested it with 4 message boxes: Works.
But for this one I'm actually curious why the result is matching the hanoi-solution as noticed by Zegeri. Adding this to my "stuff for long nights"-list. xD