THENECROMANCER'S PROFILE

Pretty sure that's the only way to do it. I wouldn't even call that a lot of code heh It's about average or low for this kind of custom system. That's why DynRPG is so powerful. It does with 1 line of code, what pages do.

DynRPG has the ability to draw variables on screen as numbers, which is the only way to make this code smaller, I believe.

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.

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 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.

If you google "tellfunnyjokes.com" something about the results seem odd. They are rarely that uniform haha