removed
RPG Maker MV bug: "Autorun" events running at wrong time can break/prevent "Player Touch" event
● ARCHIVED · READ-ONLY
-
-
You know there is a forum, and a template, for reporting bugs:
https://forums.rpgmakerweb.com/index.php?forums/rpg-maker-mv-improvement-boards.167/ -
Honestly why would an Autorun run as you step on an event? Autorun means ALWAYS RUN, so you should never have it kick in then step on a player touch. That's not a bug, that's intended behavior, as while an event is always running other events cannot run, so the player touch doesn't kick in now due to another event running.
-
removed
-
What you describe sounds like you want a parallel process not an autorun. Remember, autorun means always run, and that is at the cost of everything else. Besides, how would you suggest to resolve it? Any 'fix' I've seen will break more things in the long run.
Try describing in detail what you want to accomplish with this autorun. And don't say see sample project, I'm at work and cannot download files (and those on phones or tablets cannot either, so describe in detail what this event is doing and why you think it needs an autorun). -
Usually, you don't provide sample projects unless people request them. I personally don't like having to download stuff unless all other avenues have been investigated. Explanations of what you're trying to do, why you're trying to do it that way, and screenshots of events are things I'd much rather work with.
In this case, a screenshot of your autorun event, your player touch event, and an explanation of why you have the event set to autorun (as that's meant to stop player control for its duration). It'd have to be pretty bad timing for an autorun event to be activated right at the very moment you step on a player touch event. -
removed
-
removed
-
removed
-
Honestly, that is just bad eventing. You can just put that text you want to run inside the parallel process. There's no need for that autorun or a switch to be turned on, and you are just adding redundancy to the code. Now maybe you got a more complicated case than this example, but that example you'd never make that second autorun, you'd just put the code inside the parallel process and run when the if condition is met, then you'd make sure that condition is no longer true so it doesn't run forever. No turning switches on or off.
But I'd say if you got code that fixes it, use it for your project. But I'm just saying there is a reason it is the way it is, and it is this way as changing that breaks more than it fixes long term. For example, a change to autorun would break 99.9% of cutscenes that are made in the maker, as during a cutscene the *last* thing you want is a touch event running either during or after (at least in all cases I can come up with).
But if you think you have a bug post it in the proper forum and follow the posting guidelines. -
removed
-
Maybe there isn't one anymore, I don't see it either. I'll ask the staff where they want this to go.
Barge in cutscenes? How are you doing your cutscenes? Most use an autorun for those and last time I checked autoruns wouldn't allow that. But granted the only time I tried that was to play an SE via a parallel process during an autorun, and it didn't work.
As for how it is set up, I think that depends on what you are trying to do, which I've never been clear on here. Though I thought you once mentioned a thirst system, but I'm not sure if that was just an example or not. Anyways, for really complicated things like say hunger and thirst, most script those into a plug-in, as inside the plug-in they can add code to check if in a battle, or if you are in a scene, etc. For example, in my game, anytime a cutscene is running, I turn on switch 21 first thing. Then I can tell the engine if switch 21 is on, don't do x, or stop all enemy movement, or hide all enemies, or whatever I don't want messing up the cutscene.
Another solution is to do the entire cutscene on another map, then transfer back, but that will require 2 versions of the same map. Still, I do that for major cutscenes, just so I don't have to worry about where the sprites for everyone else in the cutscene will be as you don't want them visible outside of it. -
removed
-
I think you misunderstood the suggestion. My suggestion is to move your regular cutscenes (the ones you don't want the events barging in on) to another map, not the one that is with the parallel process/autorun. That's what most do, as if you use say visual encounters you can get weridness from that in your cutscenes too (ever have a monster chase you and do a weird dance next to you as it was moving during your cutscene, then when it ends you get an instant fight? Yep, that can and will happen, so must move the main game cutscene to another map so the monsters just don't show).
Or if you used my idea about a switch, you can set it up on page 2 of the parallel process to a blank event that does nothing while that switch is active. Then when you turn it off, it will go back to page 1. That will stop a parallel process from barging into cutscenes at all then. And remember, the engine runs the highest numbered page that is active, which is why that will work.
But granted, most script thirst/hunger systems, so they can in the internal code decide when it runs. After all, your system will have issues in battle too, not sure if you have noticed that yet, but if you go into battle and just sit for 20 minutes, the parallel process will keep applying thrist, which you might not want. And I'm not sure how it works with menus, but it might even be applying it when the menu is open*
*: Check this and see for sure though. I'm not sure about the menu part as I've never had to test it, but I do remember a parallel process messing up a battle and even interrupting it when I did that once. So that would mean thirst is still applying in battle too (as the rest of the code is running), but what if you have long animations? Should the player be penalized for that? So that is why must script it instead. -
removed
-
Yeah, it might not work with that info mentioned. But what I was saying is your parallel process is still running in battle. So say you start the battle with no thrist, then sit for 20 minutes, it will trigger your event when battle ends (assuming you have it set to trigger in under 20 minutes). Do you really want that? That's why I suggest the scripting solution.
Though there is a a Javascript code you can use to check if you are in battle, that could help too. -
removed
-
Ok, so that might work. What I was saying is if you did this:
Increase variable by 1
Wait (60)
If that is a parallel process, that will increase by 1 even in battle every second. Can lead to really inflated stats just by sitting in a battle because RL occurs and you have to step away for 30 minutes.
However, I do have a concern...how fluid is your movement? Why I ask that is you having an autorun run every second to advance the stats, which will halt movement of the player while it runs (as Autorun means that always runs at the cost of everything else). So it either needs to be really fast running, or it will cause a stutter-step effect (especially if it runs at the end of your step, you won't be able to move until it is done). And even if you don't see it, slower computers will. -
removed
-
No, because you didn't post it in the right spot.