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] IS IT POSSIBLE TO DISABLE BUTTONS?
Posts
Pages:
1
JustRob
30
JustRob
View playlists
CloseHi,
So I'm making a custom menu. When the cancel key is pressed, the game pauses and my menu slides into the screen (a common event).
Anyway, now I have it set up so that the cancel key both opens and closes the menu. It works fine, but there's one problem. If you spam the button, it will just move the menu in and out of the screen rapidly and it looks kinda fucked up.
I kinda need a way so that the player isn't allowed to press anything until the menu is fully in position. Because otherwise I'm also gonna get into trouble later on when I'm making the actual menu functions. I don't want players to be able to navigate the menu when it's still moving.
As far as I know there's no event command for simply disabling buttons. Anyone know a clever trick to pull this off?
Edit: Wait, can you just do a "Wait" event command that stops the player from doing anything while it's running? If so I'm a fucking moron lol. Will try this out later
So I'm making a custom menu. When the cancel key is pressed, the game pauses and my menu slides into the screen (a common event).
Anyway, now I have it set up so that the cancel key both opens and closes the menu. It works fine, but there's one problem. If you spam the button, it will just move the menu in and out of the screen rapidly and it looks kinda fucked up.
I kinda need a way so that the player isn't allowed to press anything until the menu is fully in position. Because otherwise I'm also gonna get into trouble later on when I'm making the actual menu functions. I don't want players to be able to navigate the menu when it's still moving.
As far as I know there's no event command for simply disabling buttons. Anyone know a clever trick to pull this off?
Edit: Wait, can you just do a "Wait" event command that stops the player from doing anything while it's running? If so I'm a fucking moron lol. Will try this out later
TheNecromancer
3160
It has to do with how you code it, using switches and conditional branches.
Your code for checking if you can press B to bring up the menu should be inside a branch. The condition for that branch should be a switch, oh let's say, MENU OPEN is OFF. It's off by default, so the player will be able to press B and it runs that code.
As part of that code, first thing, it should turn ON that switch MENU OPEN. This will not allow the open menu code to run again until that switch is turned off. Which you would add at the end of the code that hides the menu.
This is the basic idea and is actually something you should do with most code. By turning on a switch when you do any action, you can then use it to tell other code what is happening. For example, if you didn't want the player to be able to press SHIFT to swing their sword(assuming that is possible), then you would put all the code for swinging the sword inside a branch that checks if MENU OPEN is OFF. That way, if the menu is open(because the switch is on) then without doing anything extra your sword will be disabled while the menu is open.
Your code for checking if you can press B to bring up the menu should be inside a branch. The condition for that branch should be a switch, oh let's say, MENU OPEN is OFF. It's off by default, so the player will be able to press B and it runs that code.
As part of that code, first thing, it should turn ON that switch MENU OPEN. This will not allow the open menu code to run again until that switch is turned off. Which you would add at the end of the code that hides the menu.
This is the basic idea and is actually something you should do with most code. By turning on a switch when you do any action, you can then use it to tell other code what is happening. For example, if you didn't want the player to be able to press SHIFT to swing their sword(assuming that is possible), then you would put all the code for swinging the sword inside a branch that checks if MENU OPEN is OFF. That way, if the menu is open(because the switch is on) then without doing anything extra your sword will be disabled while the menu is open.
JustRob
30
I have that, but the problem is that there's two separate events: One for the menu key, that is Parallel Process (so it constantly checks if a key is pressed), and one that is Autorun. If a key is pressed the Menu switch is triggered, but because that happens immediately, and the Conditional Branch checks if the Menu switch is on or off, you can still spam it.
Inserting a wait didn't help btw.
Maybe it's easier if I show you:
Edit: Nevermind, I figured it out. I made a new switch called Menu Open below Label 2, after the menu is initialized, that turns on. Then in the Menu Key event I inserted another Conditional Branch inside the Else of the original Conditional Branch, and made it so you can only press the menu key again if the switch Menu Open is on.
Now it works.
Inserting a wait didn't help btw.
Maybe it's easier if I show you:
Edit: Nevermind, I figured it out. I made a new switch called Menu Open below Label 2, after the menu is initialized, that turns on. Then in the Menu Key event I inserted another Conditional Branch inside the Else of the original Conditional Branch, and made it so you can only press the menu key again if the switch Menu Open is on.
Now it works.
TheNecromancer
3160
I don't quite follow your solution, but it sounds unnecessary. But hey, at least it works.
I would like to make a few comments and suggestions on what I see here, if you're interested.
Most importantly, for every parallel process you should have at least a 0.0 wait at the bottom, or 0.1. Having no wait means that parallel process runs more often than is needed and after a while of adding more events running alongside, you will end up with lag. It's much easier to plan for that, instead of waiting until your game lags then searching for the reason why. Form the habit early and save yourself the headache, trust me. Those kinds of waits won't have any noticeable effect on the response time of the player pressing that key. If you start to go higher it would.
When you are checking for key input, there should be a wait after the code it triggers. To ensure that holding the button, or pressing it again quickly, isn't registered. Less than a second should do. *The reason it didn't change anything here is because you structured your code wrong*
The best way to structure this kind of thing(to avoid the issue you have) is to separate the key input code from the action. You want it parallel process so it's always checking if the player pressed the button, but you only need the action to happen once. If you take all that picture code and put it on another common event that is NOT parallel/autorun, you can use the call event command in place of all that code. Ensuring that it will only run once per button press. It really cuts down on bugs and problems like this.
It looks like you are setting the key variable to 0. That happens when the player lets go of the button and I don't think setting it to 0 will really help anything. The key input event itself has a check box for 'wait for button', or whatever, that handles it.
What you're doing here is...wait a minute. I'm just realizing something is wrong. Let me show you the proper way to do key input checks.
Here is the most basic example of how to set it up.
The key input comes first. But before you do anything else, it needs to be followed by a conditional branch that checks the variable you selected. So that the code will only trigger if you press the right button.
So going down line by line, the logic of my code is like this:
Check key input, and store the value of whatever key the player pressed in variable 401.
Check what is in variable 401.
.\If it's 11, meaning the player pressed number 1, then do something.
..\ If it's not 11, do nothing. (you don't need an else branch for this to be true)
Wait 0.1 before checking again.
Here is how the logic of your code goes:
Disable the menu (this shouldn't be here as it only needs to happen once)
Check if the menu is already open
.\If it's not, check if the player is pressing cancel.
.\I have no idea what key the player pressed, but I'm turning the menu switch on anyways
This starts the code for the second common event
NOW I'll check which key the player pressed, but the menu is already turned on so it doesn't really matter what it is
And I'll just go ahead and show the menu pictures now
So, you only need one common event, structured the way I have it in my example. You only need one key input process for all of this. It goes at the top. Followed by the branch to check which button was pressed, if it's 6. Then inside that you would put a branch to check if menu switch is ON. Under yes part, put code for opening menu. In the else part, put the code for closing the menu. That will do it.
Oh, and all the stuff you did with labels actually does nothing at all. A label is useless without a matching jump to label command. So label 1 isn't needed. And you are telling the code to jump to label 2, but it was going to do that anyways. I won't get into how to use labels, unless you really want to know.
I would like to make a few comments and suggestions on what I see here, if you're interested.
Most importantly, for every parallel process you should have at least a 0.0 wait at the bottom, or 0.1. Having no wait means that parallel process runs more often than is needed and after a while of adding more events running alongside, you will end up with lag. It's much easier to plan for that, instead of waiting until your game lags then searching for the reason why. Form the habit early and save yourself the headache, trust me. Those kinds of waits won't have any noticeable effect on the response time of the player pressing that key. If you start to go higher it would.
When you are checking for key input, there should be a wait after the code it triggers. To ensure that holding the button, or pressing it again quickly, isn't registered. Less than a second should do. *The reason it didn't change anything here is because you structured your code wrong*
The best way to structure this kind of thing(to avoid the issue you have) is to separate the key input code from the action. You want it parallel process so it's always checking if the player pressed the button, but you only need the action to happen once. If you take all that picture code and put it on another common event that is NOT parallel/autorun, you can use the call event command in place of all that code. Ensuring that it will only run once per button press. It really cuts down on bugs and problems like this.
It looks like you are setting the key variable to 0. That happens when the player lets go of the button and I don't think setting it to 0 will really help anything. The key input event itself has a check box for 'wait for button', or whatever, that handles it.
What you're doing here is...wait a minute. I'm just realizing something is wrong. Let me show you the proper way to do key input checks.
Here is the most basic example of how to set it up.
The key input comes first. But before you do anything else, it needs to be followed by a conditional branch that checks the variable you selected. So that the code will only trigger if you press the right button.
So going down line by line, the logic of my code is like this:
Check key input, and store the value of whatever key the player pressed in variable 401.
Check what is in variable 401.
.\If it's 11, meaning the player pressed number 1, then do something.
..\ If it's not 11, do nothing. (you don't need an else branch for this to be true)
Wait 0.1 before checking again.
Here is how the logic of your code goes:
Disable the menu (this shouldn't be here as it only needs to happen once)
Check if the menu is already open
.\If it's not, check if the player is pressing cancel.
.\I have no idea what key the player pressed, but I'm turning the menu switch on anyways
This starts the code for the second common event
NOW I'll check which key the player pressed, but the menu is already turned on so it doesn't really matter what it is
And I'll just go ahead and show the menu pictures now
So, you only need one common event, structured the way I have it in my example. You only need one key input process for all of this. It goes at the top. Followed by the branch to check which button was pressed, if it's 6. Then inside that you would put a branch to check if menu switch is ON. Under yes part, put code for opening menu. In the else part, put the code for closing the menu. That will do it.
Oh, and all the stuff you did with labels actually does nothing at all. A label is useless without a matching jump to label command. So label 1 isn't needed. And you are telling the code to jump to label 2, but it was going to do that anyways. I won't get into how to use labels, unless you really want to know.
JustRob
30
Okay, after posting several walls of text and reading your post a couple more times I think I finally understand what you mean. So now it looks like this:
Is that what you meant? The menu doesn't fuck up even if you spam the menu key, and it actually works.
Is that what you meant? The menu doesn't fuck up even if you spam the menu key, and it actually works.
TheNecromancer
3160
Yeah, that looks good.
I'm not sure how your menu works though. I assume you have another event that handles interacting with the menu. Something that checks key inputs and move a cursor?
The first event you have here, is something that runs all the time during the game. Once you call the menu, it should turn on another event that contains the menu stuff. And it's in THAT event that you should have the code to close the menu, as that is another function along the lines of moving the cursor and selecting a menu item. The first event is no longer used, until you close the menu, turn off the switch, and you are back to the game again. I didn't think of that earlier. So you can remove the else branch from event 1 and relocate that code.
The second event you are showing here is unnecessary(unless this is actually where you will be building your custom menu, which I suppose it is since your Common event list is empty). You should have the show menu picture code in the first event, right after you turn on the menu switch. The idea is that when you press 6, it turns on the menu switch and shows pics/menu, preventing the show menu code from running again until you activate the code that does it in reverse. It should remove the pics/menu, and then turn off the menu switch.
The menu should be a self contained system. With all functions relating to it all inside the same event(except showing it, of course).
Looks like you are on the right track now. Swap the code in those events, remove the else branch in event 1, and build your menu in event 2.
I'm not sure how your menu works though. I assume you have another event that handles interacting with the menu. Something that checks key inputs and move a cursor?
The first event you have here, is something that runs all the time during the game. Once you call the menu, it should turn on another event that contains the menu stuff. And it's in THAT event that you should have the code to close the menu, as that is another function along the lines of moving the cursor and selecting a menu item. The first event is no longer used, until you close the menu, turn off the switch, and you are back to the game again. I didn't think of that earlier. So you can remove the else branch from event 1 and relocate that code.
The second event you are showing here is unnecessary(unless this is actually where you will be building your custom menu, which I suppose it is since your Common event list is empty). You should have the show menu picture code in the first event, right after you turn on the menu switch. The idea is that when you press 6, it turns on the menu switch and shows pics/menu, preventing the show menu code from running again until you activate the code that does it in reverse. It should remove the pics/menu, and then turn off the menu switch.
The menu should be a self contained system. With all functions relating to it all inside the same event(except showing it, of course).
Looks like you are on the right track now. Swap the code in those events, remove the else branch in event 1, and build your menu in event 2.
JustRob
30
To be honest I don't have anything that handles interacting with the menu yet. I have the visuals ready, but no functionality yet. That's going to be the hardest part.
Took your advice, now it looks like this. I even don't need the separate Wait command anymore after showing the menu, it just works without being able to spam. Feels better this way.
While doing this I realized that making a custom menu in Rm2k3 is not that difficult. What's difficult is doing it in the most optimal way without using unnecessary clutter. I think that's going to be the biggest challenge.
Took your advice, now it looks like this. I even don't need the separate Wait command anymore after showing the menu, it just works without being able to spam. Feels better this way.
While doing this I realized that making a custom menu in Rm2k3 is not that difficult. What's difficult is doing it in the most optimal way without using unnecessary clutter. I think that's going to be the biggest challenge.
TheNecromancer
3160
Right, because you have it inside a branch for a switch being off and then you turn on that same switch at the end, so it can't repeat. For situations other than that, use waits.
I recommend using a variable to track menu positions. If you go into a subsection of the menu, like items. Change that variable to 1. Equipment is 2. And so on. 0 being the first menu screen.
Then use a branch that checks that var, and anything that is different from the usual menu stuff can go in there. That compartmentalizes it and helps keep things in order. For example, if you are looking at items you may want cancel button to cause it to go back to the main menu instead of closing the menu. That menu position variable and it's matching branches can do that easily. The code for what the buttons do sit in those branches, which change for each section of the menu you're in.
I recommend using a variable to track menu positions. If you go into a subsection of the menu, like items. Change that variable to 1. Equipment is 2. And so on. 0 being the first menu screen.
Then use a branch that checks that var, and anything that is different from the usual menu stuff can go in there. That compartmentalizes it and helps keep things in order. For example, if you are looking at items you may want cancel button to cause it to go back to the main menu instead of closing the menu. That menu position variable and it's matching branches can do that easily. The code for what the buttons do sit in those branches, which change for each section of the menu you're in.
JustRob
30
Link_2112, if I give players the option to name the heroes in my game, do you know if it's possible to store whatever name they entered inside a variable? I know there's a textbox command to display the name of a certain hero, but as far as I know you can't put that in a variable.
I'm kinda debating if I want to allow people to change the hero names. I'm leaning towards no, mainly because it's a linear story with pre-written characters, and because it's either impossible to combine with a CMS or a ton of work.
I'm kinda debating if I want to allow people to change the hero names. I'm leaning towards no, mainly because it's a linear story with pre-written characters, and because it's either impossible to combine with a CMS or a ton of work.
TheNecromancer
3160
I don't think so. There might be some DynRPG plugin, but you would have to have the pirated 2k3. And that plugin would need to exist, which I don't know if it does.
The only way I can think of to make anything useful for what names the player picks would be this:
In your custom menu, when you pick something that requires a choice. Like equipment, which hero do you want to change equip for? You could do a show choice where each choice is a party member, using the message command to show the name of the hero.
Build your menu design around the position of that message, which would have a transparent message box. That way the words would appear to be part of the menu system, by blending into the surroundings.
But that hardly seems worth it. Just like, give them last names that the player can't change and reference those in the menu. Or call them hero 1 and 2. Something generic. Just show their charset image.
The only way I can think of to make anything useful for what names the player picks would be this:
In your custom menu, when you pick something that requires a choice. Like equipment, which hero do you want to change equip for? You could do a show choice where each choice is a party member, using the message command to show the name of the hero.
Build your menu design around the position of that message, which would have a transparent message box. That way the words would appear to be part of the menu system, by blending into the surroundings.
But that hardly seems worth it. Just like, give them last names that the player can't change and reference those in the menu. Or call them hero 1 and 2. Something generic. Just show their charset image.
Pages:
1
