Help on my Evented Battle System.

My battle system is comprised of being able to input directional buttons that if you pressed enter after a certain combination, you'd cause some moves to happen. Ignore the "Meditation" function as the problem from healing from that might be because the amount healed is a decimal.

The problem is the input. For now, having the moves happen and stuff is not important. I'm sure that will work out pretty easily. The entering of the combination is actually not that important, either. All that's important is that the directional buttons come out and the variables work.

Attached is what I have so far. It's... slightly messy...

I don't really know what the problem is. From what I can tell, this would be easier to do with Key Input Processing than with conditional branches, but Key Input Processing isn't in VX. So, that's kind of shitty. I think Zeriab wrote something restoring the function, but I can't find it.

But I think you have the right idea here. 5 frame wait is a bit too long perhaps, but you can reduce it a little bit. But yeah, the loop and wait is a good combo. You shouldn't have the 60 frame wait there at the start though IMO.

Yeah, it's a tad too long. It was just put in because without a wait, it would automatically check for the use of the "C" button and would set you back to the menu.

My original idea was to go with switches (if you look at the list of switches, you'll see) but that was waaaay too inefficient.

Also, what's Key Input Processing ?_? I don't really remember anything by that name.

EDIT: I reduced all wait frames to 2 frames and LOL. I found that a majority of the input things weren't in loops. That may have been a problem. >_>

EDIT 2: Okay, the first wait frame needs to be 4 in order to make sure the first loop doesn't check for the C when you try to go past the text message. Also, I'll need to increase the wait frames by quite a bit on the loops because some times, when you press the keys, they overlap and come up twice.

The first wait need to been long enough for the player to release the C button. How long that is depends on the person and specific situation.
You can instead make a loop to start with which waits until the C button is released.
Alternatively you can use Key Input Processing as Modern explain. It would work excellent for your case.
Since it's VX you first need to implement this script: http://zeriab.plesk3.freepgs.com/root/scripts/VX/Snippets/button_input_process.txt
After you have added this all you got to do is to make a script call with this: (Note: The script call must only be ONE line)

Code: [Select]

button_input_process(4)

The 4 I have placed there means that it will use variable 4. You can change it to whatever variable you want to use. (Remember no leading zeros, i.e. 12 is fine, 0012 is not)
The way it works is that it halts execution until a key is trigger. A number identifying the key is then saved into the specified variable and execution proceeds.
Which number means which key then? From the script header:

Here are what the different numbers mean: (Defaults in ())
2 - down
4 - left
6 - right
8 - up
11 - A (Shift)
12 - B (Esc, Num 0, X)
13 - C (Space, Enter, Z)
14 - X (A)
15 - Y (Y)
16 - Z (Z)
17 - L (L)
18 - R (W)

Note that you have to press a key down for the event to proceed. It won't proceed if you hold a key down when you come to it. Thus removing your problem of immediately going back to the menu.
Also note that you put a one frame wait into the loop somewhere so the Input module can be updated.

Additionally you have some problems with control flow.
Instead of letting the control flow back again you keep calling common events which eventually give you a Common event call has exceeded maximum limit. error.
You must make sure you don't have a situation where you have common events call common events which in turn calls common events and so on.

I have changed your project so you can get a feeling as to how the input part can be carried out.
I have been lazy and made a script call for setting the right variable for each button press. You can do this by having 8 conditional branches. It's easy and simple, it's just slower.

*hugs*
 - Zeriab

CRAP, my method involved calling other common events to reduce clutter won't work. I guess, in the end, I'll just compile it all into one common event and use labels. XP

EDIT: Wait, if I use a common event and I make that link all the common events together (for example, my common event will be mostly made up of "Call Common Event", would that work? Also, I don't get how your Key Input part works. Does that basically make it work for all the inputs? O_O

And "exit event processing" wouldn't help with the maximum limit thing, right?

EDIT 2: Okay, problem. When I use escape, I called the script

Code: [Select]

@battle_window = Window_BattleStatus.new
@battle_window.dispose


The window goes away and then, when the screen fades in, it comes back! Why?


EDIT 3: Lol lots of edits. HUZZAH! I think I managed to compile it all into one common event plus the initialization for remembering where you are (which is completely independant)

EDIT 4: Attachment is gay so it's gone.

The way you split parts of the battle system into different was a very good idea and you made some good choices on how to split it up.
I am saddened that you compiled it into one common event ;_;

I complained about the control flow being problematic. The idea is great. The problem lay in its execution.
Having the key input part in a common event for itself... you should have kept that.
Just make sure you don't call the menu or execution from the key input part, but instead lets the key input part run out or in other way let the control return to the common event calling it.

I am afraid you don't understand what Exit Event Processing does. (Why your comment otherwise?)
What it does when a common event is called is that it exits that common event and returns control to the event calling it. (If any)
Therefore you will reduce the amount of common event calls by 1 when using it.

You can have one control common event which makes sure the right common events are called in the right order. You don't have to definitely have that order.
I would suggest you build a hierarchy of common events. Make it so common events only can call common events that are lower in the hierarchy, never higher nor on the same level in the hierarchy. That is one way to ensure no cycles are present and you won't get the limit problem unless you have at least 100 common events. More practical it will be unlikely to be a problem except you use several hundreds of common events.

On a side note: Is the Status window still a problem or have you fixed it? I am a bit unsure when considering your third edit.

*hugs*
 - Zeriab

Okay, well, I guess my attachment in the last post is useless, lol. I didn't know that "Exit Event Processing" did that.

And the reason I compiled it into one common event was because I thought there was no way to fix it at the moment. >_> It seems like this system is way beyond me.

EDIT: Okay, I don't get it. You said that I shouldn't call something of a higher heirarchy and, it's kinda easy to tell, the order of the common events are pretty much in their heirarchy. But when you used the "Exit Event Processing" you called the Menu common event (which called the event that was currently occuring) before it so...?

The purpose of me using the Exit Event Processing in that situation was simply to end the event. I could just as well have used break loop. There just was something after the loop when I placed it there.
Basically I didn't fix nor look very much into the problem. I just noted that there was a problem.

Note that I have very little experience with VX. Chances are you have more experience than me, so be sure to take anything I say with a grain of salt. You should do that in general, but in this case take it with a bigger grain of salt

The system may not be beyond you at all. You may not make it an as efficient nor dynamic version as I might have done, but I am sure you can do it. Even if you have to use way more elbow grease.

*hugs*
 - Zeriab

Haha, VX is basically the same as XP, Zeriab. Just things are organized differently and stuff. Plus, I just started using VX because I recently had my computer fixed to not have RM programs corrupted upon loading. >_>

So how would I go about calling something of higher heirarchy? Exit Event Processing?

You wouldn't call something of higher heirarchy. That is the whole idea.
When the lower heirarchy calls are finished then the higher heirarchy common event continues its processing. You can signal stuff with switch, variables and so, but you don't call anything of higher heirarchy.
You can use Exit Event Processing to prematurely end the current common event's procressing. If it is being called by another event then that event continues its processing. If you only call common events of lower order then naturally it's a higher order event which continues its processing.

This is naturally not the only way of structuring your event code. I suggested it because I believe it's a natural way of representing the problem at hand.

P.s. I believe you are right in it being basically the same. That was the feeling I got.
*hugs*
 - Zeriab

Hmm. This is going to take some thinking. Plus, it's not in my original plan so I need to look for what I need to change.

Also, if I have a common event that acts as the control and the highest in the heirarchy, if I put all the common events it calls in a loop, it would go through it normally, right?

It would indeed ^^

How's this coming along Moo?

Idk, I started school so I'm a little more limited on time. Also, I've been thinking (not too hard Just a little free thinking time usage) and I haven't thought of a way to make it work through a control common event.

I mean, I know how to do it. The problem lies in just setting it up correctly.

Also, grafikal, I see your avatar's changed And if you could use your pro graphic-making skills, could you make some directional icons (like the ones I have) that are better and more suited for RMVX? If not, it's aiite.