JPRATT'S PROFILE

Autorun is dangerous. You should be able to achieve everything with parallel process what is turned on/off by switched.

My initial instinct here is to use a single button for opening and closing your menu, and to have that button be different from your interactive button.

For my CMS I use shift to open and close the menu system. However, I have a switch I can turn off if I want to disable the menu. For example, if I'm in a battle and the keys all need to do something different. So when a battle is called the first thing that happens is the option to use the menu is disabled. At the end of the battle, it's enabled again.

You'd want to use a switch for the same purpos for interaction. One switch says "this option is on/off in the menu system" and another switch activates interactive mode.

Lets use 3 switches and call them:

menu (runs CMS code)
interact opt (distinguishes if interact option is checked)
interact (runs interactive code)

---------
If menu on;
Turn interact off

If menu off:
If interact opt on;
Turn interact on.
---------

There are a number of ways the above could be put into your parallel processes but I would probably run this as it's own ongoing parallel process. It will only allow your menu or your interactive system to run at a time, not both.

All your key processing would exist inside your interact and menu systems. This way you coyld use the same button for both systems if you prefer.

I'm not a resource hacker user. However, if you're looking to change a lot of base content such as names, classes, etc, you might consider a custom menu system. Depends how much effort you want to put into the game though as the process is time consuming.

That being said, with the right design you could make the code for your menu transferrable to future games and just replace graphics to match various themes.

The text commands allow for instant text (sonit forsn't slow type out.) However, you still need to press enter to move through all text.

In rm2k3 you can get around all text limitstions using images. However, this is only recommended if you don't plan to have a substantial amount of text or dialog.

I ran into the same problem myself. My custom menu systems (menu, field, battle) could be entirely controlled on a keypad nicely, but players would need to use the enter key for dialog. I found this unintuitive and wanted all controls in thr game to be managed via the keypad, including all "action key" functions.

This is possible but thr downside is all my text is now images. This will allow for more text to be displayed at once, as well ad more player response options being displayed at once and chosen with a single button press. However, making graphics is slow and bulky, sonit drastically limits the overall content and conversation branches.

@Fee_Nicks, I love those nice clean graphics!

I'm loving this.