[Solved] Events move route "range"?

[Alyon93]

Hi makers,

I searched throughtout the forums but I couldn't find informations about this.
I'm having troubles with some events and I think the problem reside in a sort of "range", a distance between you and the events, that, if is exceeded, deactivates the events or something, I believe to avoid memory usage.

In more detail:
I'm having this map 55x24 with some events with custom autonomous movement. I have these crates moving on a conveyor belt at a distance of 3 tiles between each of them.
The player starting position is approximately at a distance of 12 on the x and 18 on the y.

From here, when I reach the position in which I can see the crates, their positions are wrong as you can see in this picture:

https://ibb.co/9vPL69w

However if I put the player starting position near them, their positions are the expected:

https://ibb.co/XtSV85T

That is why I believe there's some range in which they follow the actual route and outside of it they skip part of it.

Unfortunately in doing so the needed pattern gets broken and I need a way to fix this.

If the fact that there's a range is true, is a known "issue"? Is there any workaround to this?

Thanks to whoever read thus far

P.S. I take this opportunity to wish you all fellow makers a good new year ;-)

 

[gstv87]

you mean, if you *enter* the area, the crates are off place, but if you *spawn in*, then the crates are in place.

do you *enter* the area *away* from the position where you would otherwise *spawn in* and are you required to *move into* position?
if that's the case, the time it takes you to *get into position*, that is time those events are already ticking through.

one solution you could use is put a proximity sensor kind of event, that when tripped would trigger those crates to move.
make each crate a two-page event, one by default, static, and the other with a variable condition, with the move route.
for the tripwire event, set it to player touch, and make it change the state of that variable condition.
upon change of that variable, the crates' event pages will change, and the move route will trigger.

another way could be, to have the tripwire event *set* the move route for each crate, but that might cause a slight timing issue because the processing of the whole thing isn't as fast: it's a first-in-first-out process, so the last crate would appear to lag behind the rest.

 

[Alyon93]

Thanks for answering gstv. Yeah I've thought about a solution like that, but I'm quite interested now to know if my impressions about this issue are true.
Also, I haven't understand what you meant by:

that is time those events are already ticking through.

Did you mean that in this time the events should already be moving according to their move routes? That's exactly what I want.
Point is that they do not seem to follow their move routes.
If I have to put a switch to make them start moving and it has to be inside the field of view of the player, I'm afraid the player will notice that they are starting later which is not the kind of feeling I want to send.

Also it doesn't seem to be an issue related to the time needed for the player to reach the point from which he can see them, since in the second situation...

However if I put the player starting position near them, their positions are the expected:

https://ibb.co/XtSV85T

...I tried to wait for some time to see if their timings got wrong after some cycles, but they are working as intended.

 

[gstv87]

can you paint the move routes they're supposed to take, in that picture?

 

[Alyon93]

The first one of them starts in the upright corner goes down by a couple of tiles and then all the way left until it reaches the upleft corner then it moves up by two tiles and jump back in the first position. The others do exactly the same route, but each of them is shifted 4 movements ahead of the previous one. Of course the skipped movements are put at the end of the move route so that after 1 cycle, the "crate" is in its right starting position.

For further explanations these are the move routes:

N.B. For the sake of simplicity in making these screen captures I've put their movement routes in a "Set movement route" command(since it's better to see the complete list of movements) but they're actually custom autonomous movements.

First(rightmost) crate:
https://ibb.co/199XYBz

Second crate:
https://ibb.co/kXXhk43

Third crate:
https://ibb.co/LQVqLgC

Fourth(leftmost) crate:
https://ibb.co/1MtrbpN

 

[gstv87]

if you're having a problem with possibly a wrong move route, *don't show me the move routes that are allegedly wrong*!
if we base the analysis on a wrong assumption, then the solution will be wrong as well!

take the picture of where the crates are supposed to start at, and paint the move routes they're *supposed* to take, THEN contrast that with the *ordered-to-be-taken* move routes, and SO, you'll find the problem.

if you can't find the problem on the set of instructions, throw the instructions out the window and go back to the drawing board (literally! draw the path to follow, and write the instructions again, based on that)

 

[bgillisp]

What I think is going on here is in MV they added a feature so that events don't run for too long offscreen. It's similar to how anti-lag scripts work in ACE. That is what is affecting those move routes, if you start offscreen from the crates, or if you go offscreen, the move routes will stop at some point as the engine says this is no longer onscreen, don't run it.

You might be able to get around it by putting the set move routes in a parallel process which runs when you enter the map, but you will have to tinker with it so that it runs right as parallel process == always runs, and you don't want the set move routes rerunning 60 times a second. Otherwise you may need a plug-in so you can designate events to always run even when offscreen.

 

[Alyon93]

if you're having a problem with possibly a wrong move route, *don't show me the move routes that are allegedly wrong*!
if we base the analysis on a wrong assumption, then the solution will be wrong as well!

take the picture of where the crates are supposed to start at, and paint the move routes they're *supposed* to take, THEN contrast that with the *ordered-to-be-taken* move routes, and SO, you'll find the problem.

if you can't find the problem on the set of instructions, throw the instructions out the window and go back to the drawing board (literally! draw the path to follow, and write the instructions again, based on that)

I appreciate the attempt gstv, but apparently you haven't got the meaning of what I meant. The move routes are functioning well, or the creates won't move correctly even when I start right next to them. The point here is that they get messed up when I'm far from them. This has nothing to do with the way they are set, but more of some hidden computations the engine does.

What I think is going on here is in MV they added a feature so that events don't run for too long offscreen. It's similar to how anti-lag scripts work in ACE. That is what is affecting those move routes, if you start offscreen from the crates, or if you go offscreen, the move routes will stop at some point as the engine says this is no longer onscreen, don't run it.

You might be able to get around it by putting the set move routes in a parallel process which runs when you enter the map, but you will have to tinker with it so that it runs right as parallel process == always runs, and you don't want the set move routes rerunning 60 times a second. Otherwise you may need a plug-in so you can designate events to always run even when offscreen.

And I'm glad to know that my guess could be right. Thanks bgillisp.
While I understand and appreciate the need for this, this feature is kind of messed up right now.
Thanks also for the suggested approach but it seems a lot of work to do for something that should have been working by default.
I think I'm going to stick to gstv hint to use some kind of switch to make them move when they are within the "working" range. I just hope the maximum distance is at least a little bit larger than the screen size.

By the way I'm leaving this open to see if someone else has something else to say about this.

 

[gstv87]

The move routes are functioning well, or the creates won't move correctly even when I start right next to them. The point here is that they get messed up when I'm far from them.

if the move routes are ok, why won't the crates move when you start next to them?
if the move routes are ok, why will they move when you're far from them, and end up in an incorrect configuration?
can't end up messed up if they don't move, and if they end up messed up, then the route is messed up, or the path they follow is obstructed!
see that you have to establish which one is the case *first*? that's why I'm telling you, ditch the move route and lay out the movement on paper.
that's what I want to know: the actual movement you *planned*, not the one you *programmed*

 

[Alyon93]

Maybe it's better if I try to explain myself better:

if the move routes are ok, why won't the crates move when you start next to them?

The crates DO move when I start near them and they are actually moving according to the way I've planned them to, that's why I've stated that their move routes are ok.

if the move routes are ok, why will they move when you're far from them, and end up in an incorrect configuration?

That's exactly what I'd like to figure out. My guess is that they start within some kind of distance from the player(same guess as bgillisp) and since they start in different positions, those closer to the player start earlier than those farther and the distance between them gets broken. Their move routes keep on working as intended but since their original positions are different than as planned they mess up and end up overlap each other.

or the path they follow is obstructed!

Nope this is not the case or their path would be obstructed even when I'm near them.

see that you have to establish which one is the case *first*? that's why I'm telling you, ditch the move route and lay out the movement on paper.
that's what I want to know: the actual movement you *planned*, not the one you *programmed*

By the way I did tell you the *planned* movement:

The first one of them starts in the upright corner goes down by a couple of tiles and then all the way left until it reaches the upleft corner then it moves up by two tiles and jump back in the first position. The others do exactly the same route, but each of them is shifted 4 movements ahead of the previous one. Of course the skipped movements are put at the end of the move route so that after 1 cycle, the "crate" is in its right starting position.

Perhaps I should have used some conditional tense sentences instead of present ones, but I did that way exactly because they are moving according to my plans.

I hope you've understand better what's the problem now.

By the way I made some tests and said distance should be of 18 tiles on the X axis. I tested it taken as origin the upright corner of the conveyor belt, where they "spawn".
I'm still trying to understand if it's the same distance on the Y axis but it seems to be some sort of square 18x18 since even if I go up or down by 1 tile it's still ruined at 18 tiles of distance. Problem is that with a conveyor belt long 12 tiles and a screen size of 16x12(the number of tiles that fit in the screen) 2 tiles out of the "working" distance can still be seen, meaning that if the player stops in that position(unlikely, but possible) he will perceive that the crates are no longer moving.

EDIT:
I ended up using bgillisp solution:

You might be able to get around it by putting the set move routes in a parallel process which runs when you enter the map, but you will have to tinker with it so that it runs right as parallel process == always runs, and you don't want the set move routes rerunning 60 times a second. Otherwise you may need a plug-in so you can designate events to always run even when offscreen.

To make them work I had to put a controller parallel event for each crate(like 20 more parallel processes ) which I guess is highly demanding in resources, but at least now is working as intended.

 

[gstv87]

I just made a quick test, and I think I found the culprit: if you set the crates' move routes manually, at the event pages themselves, they won't start moving until you're in visual range.
if you set them through a relay event, they'll start moving after the relay event is done processing.

I don't know what your initial arrangement was, but that much is given: out of view, on self-defined routes, the events won't move.
by relayed definitions, they'll move regardless of range or view.

set your scene with the crates set to fixed position, and use a relay.
you might still experience a slight delay, because everything is sequential, despite the label of "parallel".... they aren't parallel, they just ping the main process after each instruction, instead of running through their own code first and then returning control to the main program; that's what you need: a full declaration of the whole thing first, and a unified instruction to begin.
you don't have that unified instruction to begin if you move into visual range, because the movement will start (and, play through) as you spot crates.

(I still insist on the same: if the movement isn't what you expect, throw the programming out the window, and do it manually. *From* the knowledge you'd get by doing it manually, you build the programming.... programming is just repetition of the manual action. By *manually* I mean, be there, in visual range, and send commands to the events through relays.)

 

[Alyon93]

set your scene with the crates set to fixed position, and use a relay.

That's exactly how I solved the problem. Is bad though since I had to resort to a much greater memory usage(with 20 more parallel events) for doing something that should have been there by default. At least now everything is working as intended.

if you set the crates' move routes manually, at the event pages themselves, they won't start moving until you're in visual range.

By the way it is slightly larger than visual range. It would have been really stupid if it was actual visual range since the player would see the events start right when they enter their visual range. Still is too small though at least for my kind of situation.

 

[gstv87]

but why do you need the parallel events then?
once set, you don't need to reset the route unless you're planning a sort of loop.
if that's the case, then make it conditional, or use a generic template based on coordinates, or regions.
(each event's own movement routine is already running on parallel! you're doing the work twice!)

 

[Alyon93]

They have to cycle many times in the same route. Arriving at the end and starting again from the beginning. Without the parallel processes controlling their movements if I exit the range and then re-enter the problem shows up again.

I think I will stick to this solution but if you can explain better this thing...

if that's the case, then make it conditional, or use a generic template based on coordinates, or regions.

...someone might find it useful and I might be use it in other situations.

 

[Silva]

I'm not going to pretend I understand exactly what's going on but it might be worth looking at Yanfly's move route core. The specific use I'm considering is:

Event Notetags:

<Always Update Movement>
- Most events don't update unless they're close to the screen. But any
event with this notetag will always be updating regardless of whether they
are close to the screen or not.

http://yanfly.moe/2017/01/21/yep-124-move-route-core-rpg-maker-mv/

 

[gstv87]

turn_random if $game_map.region_id(x,y) == *integer*
set_direction(*dir*) if $game_map.region_id(x,y) == *dir*
move_forward if $game_map.region_id($game_map.x_with_direction(x,direction),$game_map.y_with_direction(y,direction)).between?(2,8)

basically:
move forward if square in front of self has ID between 2 and 8
set direction to direction equal to region ID number under self
(another version is set as 'move in direction specified by square in front of self', no condition)
otherwise,
turn until direction found.

the last one with the two separate regions is my personal favorite.
in the actual game, it solves the scene in such an elegant way.
(move if region ID, turn if square obstructed, turn if no region forward)

I bet you can even squeeze a teleport in there, if you lay it out correctly.

 

[Alyon93]

I'm not going to pretend I understand exactly what's going on but it might be worth looking at Yanfly's move route core. The specific use I'm considering is:

Event Notetags:

<Always Update Movement>
- Most events don't update unless they're close to the screen. But any
event with this notetag will always be updating regardless of whether they
are close to the screen or not.

http://yanfly.moe/2017/01/21/yep-124-move-route-core-rpg-maker-mv/

Yep that's exactly the problem. I'm glad that someone found the problem and provided a script to fix it. It's also aimed to specific events, so that you don't completely mess up this feature (which can be useful in many situations).
Thanks for sharing Silva

View attachment 106169

View attachment 106168

View attachment 106170

View attachment 106167

turn_random if $game_map.region_id(x,y) == *integer*
set_direction(*dir*) if $game_map.region_id(x,y) == *dir*
move_forward if $game_map.region_id($game_map.x_with_direction(x,direction),$game_map.y_with_direction(y,direction)).between?(2,8)

basically:
move forward if square in front of self has ID between 2 and 8
set direction to direction equal to region ID number under self
(another version is set as 'move in direction specified by square in front of self', no condition)
otherwise,
turn until direction found.

the last one with the two separate regions is my personal favorite.
in the actual game, it solves the scene in such an elegant way.
(move if region ID, turn if square obstructed, turn if no region forward)

I bet you can even squeeze a teleport in there, if you lay it out correctly.

I haven't quite understand how this all works, but it seems a little bit off the point imho. Perhaps it does what we want, but can do a lot more and I find it too generic and rather confusing.

Anyway we now have a way to solve this problem through eventing:
by creating a parallel process to move the event, instead of using its own custom autonomous movement;

We also have a way to solve it with a script provided by Yanfly's Move Route Core(which does have a lot more of interesting features).

I think we can mark it solved.

Thanks to all of you fellow makers who spent some of their time following and answering to this.

See you ;-)

 

[slimmmeiske2]

This thread is being closed, due to being solved. If for some reason you would like this thread re-opened, please report this post and leave a message why. Thank you.