Event processing range

[Kurisu]

Hello,

I have a map with two events purely for decoration (player doesn't get to interact with them). They have a very specific custom move route (loop). The problem is, player needs to get within a certain range for them to trigger and start moving. How could I keep those events active all the time no matter what the distance from player is?

I could use parallel processing I guess, but I'd like to avoid that so if there is another way to do it, please give me some advice

I do not use any anti-lag scripts (yet).

 

[EtphTheElephant]

I suppose parallel process is the only way to go. I can't think of any other way at the moment.

 

[Alexander Amnell]

What's your problem with using parallel processes? I mean they can be finicky at first but they are the only way to do a lot of cool stuff in your games. I generally have between 5-12 parallel processes running at any given time in my game... so many custom systems and it still handles fine.

 

[Tsukihime]

Parallel processes are powerful, but a lot of people use them just because they don't want to have to think about how to accomplish the same thing WITHOUT constantly checking whether the conditions are met or not. Some things can only be done with something like a parallel process, but there are plenty of things that could, but don't.


If something can be done without using a parallel process, that would always be more desirable than having your event constantly running in the background running the same checks forever.

 

[Kurisu]

I see. I guess I will just use a parallel process then

Alexander: I agree with Tsukihime. I tend to avoid parallel processes until it's really necessary. I used to work with one of the older makers where a fair amount of parallel processes running at the same time caused your game to lag badly. I do not want to use up precious resources for decoration

 

[Liak]

# Put [update] in the event's name and the move route will always update.## ~Kreadclass Game_Event < Game_Character  #--------------------------------------------------------------------------  # * Determine if Near Visible Area of Screen  #--------------------------------------------------------------------------  alias_methodkrx_alfix_ge_nts?, :near_the_screen?)  def near_the_screen?(dx = 12, dy = 8)    # YEA compatibility    if $imported && $imported["YEA-CoreEngine"]      dx = dy = nil    end # YEA compatibility    return true if @event.name.include?('[update]')    return krx_alfix_ge_nts?(dx, dy)  endend
Does this help?

 

[kerbonklin]

^ Isn't that the exact same result since it still has to check for the event (and process it) every frame?

 

[Tsukihime]

^ Isn't that the exact same result since it still has to check for the event (and process it) every frame?

By default, all events are checked at every update regardless whether they have a parallel process trigger or not. The difference is that the event commands themselves are not executed. When people say "parallel process" they explicitly refer to the event interpreter running in the background.


Autonomous movement does not occur if an event is outside of the screen, and a parallel process movement would actually solve the problem, but may not be desirable (isn't the whole point of autonomous movement supposed to be just that?)

 

[Kurisu]

It does indeed work so I might use it instead of parallel process, Liak. Thank you

What are the terms of use?

 

[Liak]

http://divisionheaven.wordpress.com/tutorials/rmvxace-workarounds/

I found it here, at the bottom of the page. It doesn't say anything about terms of use. But since Archeia runs the site, I think it's just free to use as a part of the unofficial bugfix snippets.

 

[Alexander Amnell]

I see. I guess I will just use a parallel process then

Alexander: I agree with Tsukihime. I tend to avoid parallel processes until it's really necessary. I used to work with one of the older makers where a fair amount of parallel processes running at the same time caused your game to lag badly. I do not want to use up precious resources for decoration

I wasn't really saying use them for everything, I agree with Tsukihime as well, but in this case it seemed a parallel process would be the way to go, as I wasn't aware of Kred's script at the time I posted it.

 

[Kurisu]

It is ok, Alexander. I actually did use a parallel process before Liak posted a script. Both solutions work perfectly so I guess my problem is now solved

 

[Shaz]

Parallel processes are not quite as bad if you remember to add a wait for a few frames with each iteration.


If you were still searching for a solution, I'd ask you more about the actual move route on your event. But since you've got it working in a way you're happy with now, I'll go ahead and close this.


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.