Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
COMMON EVENT PROBLEM [SOLVED]
Posts
Pages:
1
Ravenite1
243
Ravenite1
View playlists
Close
I have a common event set up to decrease the hero's movement speed by -1 when the shift key is depressed. However, when I have this event active, I cannot use the trigger condition "touched by hero" on map events.
For example, if I set up a simple teleport event on a map, that is below the hero, and is triggered by "touched by hero," my hero is simply able to walk over the event without triggering the teleport command.
Any idea why this event would conflict with other events?
Avee
5794
The Parallel Process trigger means that when you press Shift, this event runs constantly. And the Move Event command overruns any simultaneous "Touched by Hero" event, preventing your character from activating teleports and the likes.
"Collision with Hero" events should work fine though.
If I may express a personal opinion, I think that holding an extra key to dash is one of the worst idea in video game history ever.
I would recommend you use a dash system similar to Starless Umbra's, or use my own "Double tap to dash" system: http://rpgmaker.net/tutorials/679/
"Collision with Hero" events should work fine though.
If I may express a personal opinion, I think that holding an extra key to dash is one of the worst idea in video game history ever.
I would recommend you use a dash system similar to Starless Umbra's, or use my own "Double tap to dash" system: http://rpgmaker.net/tutorials/679/
TheNecromancer
3160
it could be because when you are holding shift, and really even if you're not, it's constantly running the move hero command. there is no wait after the move hero. if you put a wait it will probably work.
but you should set this up in a way that will only run the move hero thing once. you could use a switch to indicate that the hero's speed has changed. then put the move hero commands in branches that check for HERO SPEED CHANGED switch is off. at the end of change hero speed, turn switch on. then when the parallel process runs through again the conditional branch will see the switch is on and not keep changing the hero's speed.
but you should set this up in a way that will only run the move hero thing once. you could use a switch to indicate that the hero's speed has changed. then put the move hero commands in branches that check for HERO SPEED CHANGED switch is off. at the end of change hero speed, turn switch on. then when the parallel process runs through again the conditional branch will see the switch is on and not keep changing the hero's speed.
Ravenite1
243
author=Avee
The Parallel Process trigger means that when you press Shift, this event runs constantly. And the Move Event command overruns any simultaneous "Touched by Hero" event, preventing your character from activating teleports and the likes.
"Collision with Hero" events should work fine though.
If I may express a personal opinion, I think that holding an extra key to dash is one of the worst idea in video game history ever.
I would recommend you use a dash system similar to Starless Umbra's, or use my own "Double tap to dash" system: http://rpgmaker.net/tutorials/679/
The reason I have an event like this is for when the hero is sneaking around avoiding detection, I thought a slow down button would be convenient, so the hero won't rush into incoming enemies so quickly. Otherwise I wouldn't see the point of having a dash feature either. Interesting tutorial though, you're using a variable for the timer instead of the actual timer. I might be able to use that for something else.
Ravenite1
243
author=Link_2112
it could be because when you are holding shift, and really even if you're not, it's constantly running the move hero command. there is no wait after the move hero. if you put a wait it will probably work.
but you should set this up in a way that will only run the move hero thing once. you could use a switch to indicate that the hero's speed has changed. then put the move hero commands in branches that check for HERO SPEED CHANGED switch is off. at the end of change hero speed, turn switch on. then when the parallel process runs through again the conditional branch will see the switch is on and not keep changing the hero's speed.
I tried putting a wait command after speeding and slowing down the hero, but that didn't make a difference. As for your other idea, I don't think using switches to turn off the event processing would work unless I were to toggle slowing down by hitting the shift key instead of depressing it, otherwise how would I turn the switches off after activating them? It would have to be linked to the shift input variable again, which would be substituting the problem for another. I'm pretty sure on this, however correct me if I'm totally overlooking something here.
Ravenite1
243
I understand the problem lies in the hero not responding to certain events because his event is constantly being changed by a parallel process. Also it seems to affect the "collision with hero" trigger too, because the hero will get stuck in the event if it is below or above him. This only seems to happen when there are event commands, but even if these event commands are set to a condition which is not met, the hero still gets stuck.
Try putting a longer "Wait" command inside the button-checking process. Players might not be able to tell the difference from a Wait of 0.1 and 0.2, or even a 0.5, in this case.
As a last resort, you can teleport using a coordinate-checking parallel process instead of a map event.
As a last resort, you can teleport using a coordinate-checking parallel process instead of a map event.
Ravenite1
243
author=Zachary_Braun
Try putting a longer "Wait" command inside the button-checking process. Players might not be able to tell the difference from a Wait of 0.1 and 0.2, or even a 0.5, in this case.
As a last resort, you can teleport using a coordinate-checking parallel process instead of a map event.
Fixed.
Putting in a longer wait command fixed the problem. Anything 0.2 or higher works. I originally had it for "0.1 sec." I guess 0.1 or below isn't long enough for the event to breath.
Cool, thanks for the advice everyone.
TheNecromancer
3160
author=Ravenite1
I don't think using switches to turn off the event processing would work unless I were to toggle slowing down by hitting the shift key instead of depressing it, otherwise how would I turn the switches off after activating them? It would have to be linked to the shift input variable again, which would be substituting the problem for another. I'm pretty sure on this, however correct me if I'm totally overlooking something here.
you have 2 branches. one for slowdown is 7 and one for slowdown is 0.
in the slowdown is 7 branch would be another branch that checks if HEROSPEEDCHANGED switch is OFF. inside that branch is the hero move command. in that hero move command, after the speed decreases, you would turn on HEROSPEEDCHANGED. since this is a parallel process it will run the event again, but since HEROSPEEDCHANGED is on now, it will skip doing the move hero command again.
in the slowdown is 0 branch would be another branch that checks if HEROSPEEDCHANGED is ON. inside that branch is the hero move command. in that hero move command, after the speed increases, you would turn off HEROSPEEDCHANGED.
if the system you have now works, in that holding the button slows you down and letting go speeds you back up. then this extra setup will not cause any other problems and will prevent the move hero commands from running endlessly. you would still want to put a wait.
another piece of advice, don't triple post >.>
Ravenite1
243
author=Link_2112author=Ravenite1you have 2 branches. one for slowdown is 7 and one for slowdown is 0.
I don't think using switches to turn off the event processing would work unless I were to toggle slowing down by hitting the shift key instead of depressing it, otherwise how would I turn the switches off after activating them? It would have to be linked to the shift input variable again, which would be substituting the problem for another. I'm pretty sure on this, however correct me if I'm totally overlooking something here.
in the slowdown is 7 branch would be another branch that checks if HEROSPEEDCHANGED switch is OFF. inside that branch is the hero move command. in that hero move command, after the speed decreases, you would turn on HEROSPEEDCHANGED. since this is a parallel process it will run the event again, but since HEROSPEEDCHANGED is on now, it will skip doing the move hero command again.
in the slowdown is 0 branch would be another branch that checks if HEROSPEEDCHANGED is ON. inside that branch is the hero move command. in that hero move command, after the speed increases, you would turn off HEROSPEEDCHANGED.
if the system you have now works, in that holding the button slows you down and letting go speeds you back up. then this extra setup will not cause any other problems and will prevent the move hero commands from running endlessly. you would still want to put a wait.
another piece of advice, don't triple post >.>
I understand now. I'll try using that, because even though my current event is working, if you step on a event at the wrong time, there is a slight delay before the hero triggers the event. I'm assuming that's because "slow down" is running through the speed changes at that moment, and not the "wait." Besides I'd rather not have a movement event running constantly the whole game.
Pages:
1
