Can't move when using "Jump to Label"

[Helstern]

Hello!


I figure the answer to this is very simple, but I can't seem to find an answer after searching around for it.  I'm trying to play around with skills and common events and found that the "Jump to Label" function is causing my character to freeze in place.  Below are the screenshots of the code:


The skill I'm using to call the common event.





The common event code:





If I take out the "Jump to Label" command I am able to move around, but I was wanting for there to be a timed process and a Jump to Label seemed to be the easiest setup for that.  A loop with a break in the if statement prevented me from moving also.  It was my understanding that a "Jump to Label" process wouldn't freeze my character in place and that's why I figure I'm missing something very simple here.


Any help would be greatly appreciated!


Solution:

Spoiler

Both Ander and Orichalcum+'s solutions worked, but I'm a sucker for condensing code to a single event, so I went with Orichalcum+'s solution.





Below should be the change to the code to Orichalcum+'s edit, otherwise you'll get an undefined error for Phasing ("undefined" should not be capitalized).



typeof(Phasing) === "undefined" || Phasing == false


Thanks!

 

[bgillisp]

Try turning off the wait on the set movement routes. As it is, those will cause short pauses when they run, and if you are looping or jumping often enough, those pauses might prevent you from ever moving.


Also check to see if you used that label anywhere else in the game. I don't know if that matters, but if they did labels like the old coding goto's, you can easily break a game with jump to label if not used well.


Edit: NVM, I think the problem is that common events in skills run until they are done. Which means you may need another approach altogether. Maybe someone else can confirm if this is true, but from my experience they have always ran until they are done, which means you would not be able to move.

 

[Andar]

"Jump to label" is an internal command, as long as it is executed time does not continue.


Which means you created an eternal loop, because the timer can't continue to the next frame with your code - it never leaves that event to count the time farther.


You need to create a parallel process to check the timer, and the parallel process checking the timer must not be the same that starts the timer - that would simply restart the timer again and again.


Move the conditional branch (and only that part) into another common event, set that common event to parallel process and have it triggered by a switch.


in the first event, replace the label with a "control switch on" for exactly that switch.


In the parallel process, remove the "jump to label" (in fact, remove the entire else branch) and add a control switch OFF directly after the timer stop, for exactly the same switch (the parallel process doesn't need to run when the skill isn't active).

 

[Orichalcum+]

"Jump to label" is an internal command, as long as it is executed time does not continue.


Which means you created an eternal loop, because the timer can't continue to the next frame with your code - it never leaves that event to count the time farther.

I was gonna say something similar to this, but with a picture.





EDIT: "typeof(Phasing) === "Undefined" || false" Only worked the one time


So I also included "Phasing == false" and told it to to the exact same thing.


It's susposed to be "typeof(Phasing) === "Undefined" || Phasing == false"

 

[Andar]

@Orichalcum+ Your event cannot work for a lot of reasons, mainly that skills cannot call a parallel process so the player needs a second common event for the skill anyway.


Second problem is directly your first conditional branch - the parallel process will only run if the switch is ON, which means the condition siwtch off there will never be true and the entire first few lines never work.


@Helstern As explained above, the event like done by Orichalcum+ is not a solution because it can't work.


While there are several ways to make this work, they all need two different events, one for starting the process and one for checking its time. There is no other way to handle the time without massive modifications to the engine itself.

 

[Helstern]

@Orichalcum+ Your event cannot work for a lot of reasons, mainly that skills cannot call a parallel process so the player needs a second common event for the skill anyway.


Second problem is directly your first conditional branch - the parallel process will only run if the switch is ON, which means the condition siwtch off there will never be true and the entire first few lines never work.


@Helstern As explained above, the event like done by Orichalcum+ is not a solution because it can't work.


While there are several ways to make this work, they all need two different events, one for starting the process and one for checking its time. There is no other way to handle the time without massive modifications to the engine itself.

Well, it seems to be running fine while testing it:

 

[Orichalcum+]

skills cannot call a parallel process

Im not sure what you mean, the first image posted Helstern by shows the skill and what parallel process is being called by it.

the parallel process will only run if the switch is ON

The common event does indeed require a switch be turned on, but that's also the first thing I did.


The label and jump to said label doesn't actually need to be there, but it could be useful if you want to check other conditions before phasing starts.

 

[Andar]

Im not sure what you mean, the first image posted Helstern by shows the skill and what parallel process is being called by it.

check the screenshot - the trigger on that common event is "none", it never was a parallel process that got called there.


And if your event works that means that they changed the MV engine to enable calling of parallel processes - that was completely blocked in earlier makers, the engine simply did nothing if the common event called by a skill had a trigger different than "none".


And I'm not sure if that change is a good one. Yes, it does allow some special constructs (and then the part I mentioned as wrong is indeed neccessary), but it also means that the game loop got more complicated and there are more ways timing problems can be introduced. No, not a good change - it would have been better in my opinion if they had kept the requirement that skills can only call direct, single common events. Now bughunting will get more complex (as a moderator and support person here as well as someone with a master in computer engineering I see a lot of things from a different viewpoint).