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)
[RM2K3] HOW CAN I TERMINATE A PARALLEL PROCESS COMMON EVENT WHEN TELEPORTING THE PLAYER?
Posts
Pages:
1
Mitsuhide_The_Vagrant
View playlists
CloseI feel like the solution here is simple, but what I'm trying is not working.
I'm creating a game where enemies walk on the map. When the player touches these enemies, a battle starts. Normally, once the player leaves a dungeon the enemies will be prompted to respawn. However in some dungeons, I want the enemies to respawn after the player teleports to a different map screen (like, after 10 screen transitions, the dungeon's enemies respawn). I'm using a common event and the individual map teleport events to try and achieve this. See below:
This is the common event, which handles the showing of a picture to tell the player how many screen transitions are left until the enemies respawn:
What happens is the animated picture scrolls onto the screen, waits a few seconds, then scrolls back off. Then, the switch that turns on this picture to alert the player is turned off by the common event itself at the very end. The conditional branches you see are simply reading how many screens are left and showing the corresponding picture (it goes all the way to "10," but that's off-screen, each conditional branch has the exact same event commands).
This is each map's teleport event:
What this does is immediately turn off the common event and erase the picture, then it changes the variable of the respawn countdown. Then, it teleports the player before turning the common event back on.
PS: The call events you see at the beginning and end of the map events above are simply disallowing the player to hit the "cancel" button to open-up the custom menu system my game uses. Every single map teleport event in my game has them. The custom menu system, once the player has access to it, is a parallel process common event that waits until the player hits the "cancel" button to appear. It has nothing to do with this respawn problem, from what I can see.
What I'm trying to achieve is this: If the player enters a map, and then quickly enters another map again, I want the common event to alert the player as it should. But, what's happening, I believe, is the common event is still processing and not showing any pictures (because it already showed a picture earlier in the event commands) because the player entered a new map before the common event ended, even though the map events turn off the switch that activates the common event (which I thought should immediately terminate the common event's processing, but apparently I was wrong).
How can I get the events to work properly? I simply want the picture to get erased--if it's still on screen--when the player teleports to a new map before the common event ends, and display the new picture after teleporting. Instead, it doesn't show the new picture, but the map event still changes the variable (which I want it to do no matter what because the player is entering a new map.)
Help me, please! I'm dying' over here!
I'm creating a game where enemies walk on the map. When the player touches these enemies, a battle starts. Normally, once the player leaves a dungeon the enemies will be prompted to respawn. However in some dungeons, I want the enemies to respawn after the player teleports to a different map screen (like, after 10 screen transitions, the dungeon's enemies respawn). I'm using a common event and the individual map teleport events to try and achieve this. See below:
This is the common event, which handles the showing of a picture to tell the player how many screen transitions are left until the enemies respawn:
What happens is the animated picture scrolls onto the screen, waits a few seconds, then scrolls back off. Then, the switch that turns on this picture to alert the player is turned off by the common event itself at the very end. The conditional branches you see are simply reading how many screens are left and showing the corresponding picture (it goes all the way to "10," but that's off-screen, each conditional branch has the exact same event commands).
This is each map's teleport event:
What this does is immediately turn off the common event and erase the picture, then it changes the variable of the respawn countdown. Then, it teleports the player before turning the common event back on.
PS: The call events you see at the beginning and end of the map events above are simply disallowing the player to hit the "cancel" button to open-up the custom menu system my game uses. Every single map teleport event in my game has them. The custom menu system, once the player has access to it, is a parallel process common event that waits until the player hits the "cancel" button to appear. It has nothing to do with this respawn problem, from what I can see.
What I'm trying to achieve is this: If the player enters a map, and then quickly enters another map again, I want the common event to alert the player as it should. But, what's happening, I believe, is the common event is still processing and not showing any pictures (because it already showed a picture earlier in the event commands) because the player entered a new map before the common event ended, even though the map events turn off the switch that activates the common event (which I thought should immediately terminate the common event's processing, but apparently I was wrong).
How can I get the events to work properly? I simply want the picture to get erased--if it's still on screen--when the player teleports to a new map before the common event ends, and display the new picture after teleporting. Instead, it doesn't show the new picture, but the map event still changes the variable (which I want it to do no matter what because the player is entering a new map.)
Help me, please! I'm dying' over here!
I offer this at the risk of undermining your design choices, but is the picture pop-up really necessary? What value is that knowledge to the player, the exact moment when enemy parties respawn? Can they not just move back and forth between maps quickly to make them reappear anyway?
I just feel as though an elaborate process like this doesn't add much, and may even break immersion to an extent.
I just feel as though an elaborate process like this doesn't add much, and may even break immersion to an extent.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
Instead of using Show Picture and Move Picture, create a battle animation that does all of it at once. Then you can do the entire animation in one event command, and therefore you won't need the 3.5 second wait in the parallel process. Without that wait, your problem is solved.
If your respawns happen after a specific number of screen transitions, rather than after every screen transition, then I actually disagree with halibabica, because that's a pretty unintuitive way of handling respawns and the player might have a lot of trouble figuring it out without the messages. It's the sort of thing that the player would need a counter to keep track of.
If your respawns happen after a specific number of screen transitions, rather than after every screen transition, then I actually disagree with halibabica, because that's a pretty unintuitive way of handling respawns and the player might have a lot of trouble figuring it out without the messages. It's the sort of thing that the player would need a counter to keep track of.
author=halibabica
I offer this at the risk of undermining your design choices, but is the picture pop-up really necessary? What value is that knowledge to the player, the exact moment when enemy parties respawn? Can they not just move back and forth between maps quickly to make them reappear anyway
That's exactly what I don't want. That's why in other dungeons where I don't want this feature, the only way the monsters respawn in dungeons is re-entering the game's overworld.
What I'm shooting for in this game is the elimination of grinding as a necessity for progression. But, because I want dungeons and enemy troops to be challenging, too, I want the player to have the option of grinding if they want to make fighting them a little easier.
This respawning feature I'm trying to implement is a way to make grinding easier in longer dungeons, as well as making these larger, "main" dungeons a little more challenging. Smaller dungeons, or dungeons you won't have to return to very often are the ones that won't have this respawning feature.
I'm not sure if I answered the question very well, but that was my thought process.
author=LockeZ
Instead of using Show Picture and Move Picture, create a battle animation that does all of it at once. Then you can do the entire animation in one event command, and therefore you won't need the 3.5 second wait in the parallel process. Without that wait, your problem is solved.
I was thinking of using a battle animation at first, but I wanted the animation to be a bit smoother than battle animations generally are. But, I may just go with this method to make the creation process easier.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
Well the parallel process does actually stop running after the switch turns off, like you thought. The one thing it does before ending, though, is complete the event command that's currently happening. So if you turn the switch off during the 3.5 second wait, it doesn't continue on to the rest of the event after the wait, but I guess it's refusing to run the same common event again until that wait command finishes.
I think if you replace that 3.5 second wait with nine 0.4 second waits, you might solve your problem. Since you have a 0.5 second wait in your map teleport event, the wait commands in the parallel process just need to be shorter than that. Maybe. I'm guessing here since this is a problem I haven't seen before.
The battle animation thing will definitely work though, if this idea doesn't.
I think if you replace that 3.5 second wait with nine 0.4 second waits, you might solve your problem. Since you have a 0.5 second wait in your map teleport event, the wait commands in the parallel process just need to be shorter than that. Maybe. I'm guessing here since this is a problem I haven't seen before.
The battle animation thing will definitely work though, if this idea doesn't.
from Mitsuhide_The_Vagrantfrom meThat's exactly what I don't want. That's why in other dungeons where I don't want this feature, the only way the monsters respawn in dungeons is re-entering the game's overworld.
I offer this at the risk of undermining your design choices, but is the picture pop-up really necessary? What value is that knowledge to the player, the exact moment when enemy parties respawn? Can they not just move back and forth between maps quickly to make them reappear anyway
What I'm shooting for in this game is the elimination of grinding as a necessity for progression. But, because I want dungeons and enemy troops to be challenging, too, I want the player to have the option of grinding if they want to make fighting them a little easier.
This respawning feature I'm trying to implement is a way to make grinding easier in longer dungeons, as well as making these larger, "main" dungeons a little more challenging. Smaller dungeons, or dungeons you won't have to return to very often are the ones that won't have this respawning feature.
Hmm...you sound well-intentioned. I just wonder if this solution is suitable for the problem. Far as I can tell, you want to discourage grinding, but still have it be possible if the player really wants to. Having the encounters respawn after a big delay may not be conducive to that end, and may carry other problems with it. Suppose the player does want to grind, and they have to make this certain number of map transitions to find more enemies. Doesn't that just make grinding even grindier? And what about a player who didn't want to grind? Would they not be discouraged from changing maps too frequently if they know the enemies will come back when they do?
Sorry to turn this into a game design talk. I just have some hangups about why the feature's needed. I don't know enough about the project as a whole to really say.
BadLuck
2270
If I'm understanding this (and I'm not sure I am), one thing you could do is have a loop
This allows you to break your wait 3.5 up and jump to a part of the code (like the first move picture part). Like I said, I'm not totally sure I'm following this, but this strikes me as a possible solution, since the wait 3.5 is causing the problem.
That being said, I'd totally just go with battle animations if I were you. Pictures are not inherently smoother.
VAR = 0
loop
wait 0.1
VAR += 1
if VAR == 35
break loop
end
if CHANGE_MAP_DETECTED
jump to label 1
end
end
This allows you to break your wait 3.5 up and jump to a part of the code (like the first move picture part). Like I said, I'm not totally sure I'm following this, but this strikes me as a possible solution, since the wait 3.5 is causing the problem.
That being said, I'd totally just go with battle animations if I were you. Pictures are not inherently smoother.
Sooz
They told me I was mad when I said I was going to create a spidertable. Who’s laughing now!!!
5354
Try talking to Skynet.
author=SoozThis is a good option until it tries talking you into helping it take over the world
Try talking to Skynet.
I decided to go with battle animations and now it works perfectly as intended. The animation isn't as smooth, as I thought, but that's okay.
Thanks for all the input and advice, folks!
Thanks for all the input and advice, folks!
BadLuck
2270
If it doesn't seem as smooth, are you sure it's not just needing more frames in your tweening? Battle animations take some more fussing to get as nice as pictures, but otherwise, there's no intrinsic difference.
Pages:
1
