I am working on a custom battle system; and as a CBS it is populated by a-many pictures to display things.
Including menus listing skills.

In the CBS there is an event that checks if temporary variables are specific values for specific entries. There are five temporary variables - the number of skills a hero can learn, and the number that is displayed on-screen.

I have come across a problem though. Conditional branches can check if a hero knows a specific skill - but neither can be determined by variables. They're absolute, if that's the right term.

* * *

There are two ways I could get around this:

The first way is messy code-wise, but may be easy in the long run.
In my "temporary variable common event" - a common event that "dumps" hero data to a set of variables based on their ID, I check what ID is being checked, then for every  possible skill that hero can learn I have a conditional branch. The kind I mentioned earlier.

If [Temp ][/Temp] = 1
If [Hero ][/Hero] knows [Skill ][/Skill]
Set Var Temp Skill 1 = 1
end
If [Hero ][/Hero] knows [Skill ][/Skill]
Set Var Temp Skill 1 = 2
end
And so on.

Thankfully only certain skills can exist in a certain "slot" - thus reducing variance, but it is still incredibly messy. I can still use RM2k3's core skill system, and thus reducing code elsewhere.

* * *

The other option is much cleaner and smaller, but it doesn't quite... stick.
For each hero there are five variables, and these store what skills are known. With thirty characters planned in total (okay six, but each one has five characters they can use like equippable skill-sets... it's not that complicated... I think.) this would amount to 150 variables used.

Code-wise, I'd just need to create a loop that sets the temporary variables to the value of these variables - as set by another variable, thus meaning I only have to set about five variables code-wise, with a "starting variable" controlling the loop.

However this means I will be using 150 variables and ignoring the core database, as opposed to only 5 variables and using the database.

* * *

After the disaster of trying to dump everything to variables for hero data, then dumping it to another set for temporary use, I want to try and avoid using variables for individual heroes when the database provides for me.

Which method should I use? Or are there any tips or better ways I can go about this?

I say screw the database altogether, but that's just me.

It looks like you'll have to go with option 1 (which doesn't look or sound so messy to me, really; maybe you can elaborate?).  However, just because items are items doesn't mean you can't get creative and use them for something else (in this case, skills).  As long as you aren't using the DMS, then there should be no problem with popping special, unused items into the player's inventory (that the game will never look at for your CMS) and treating them as skills.

Dumping the database altogether - as I would in option 2 as far as skills are concerned - would be more flexible; but I am so fussy about the organisation of my custom systems. And with switches and variables - they're much harder to organise if you change something later or even forget something... as I have before.

Option 1 isn't so much messy, as needlessly bulky. Conditional branches for every hero (30), with every possible skill they can learn (about 8-12 I think, depends on the hero). If I could set it by variables, it would probably reduce it drastically.

I could've cemented character skills so that they always learn the same ones - this would avoid this problem because I'd just check IDs and levels - but I worried that players would feel like they don't have enough customisation, so I planned a "skill grid"-like system, resulting in the need to check specific skill knowledge.

EDIT: I'm going to go ahead with the second option and see how that goes. Because it's only the skills that will be managed this way it may be easier than my last CBS attempt disaster. = w=;
I'm not sure what using items like skills would do - my guess is that they'd be equipped in each of the five equipment slots to work as the five skills, then- oh! XD I see what you mean, I can actually check item IDs this way to check skills just like equipped items. Sounds like a good idea, but I am using equipment for... equipment. Maybe for another project... (Though after this game I think I'll probably be sick of RM. Way too many dead projects... Oh real life you scamp.)

Well basically, you dug a semi-deep hole by featuring 30 characters with customizable skills and a CBS.  I tried to think of a handful of ways to minimize the lag, none of them would be really good, so my conclusion is either...

a)  Have a zillion forks for all of the abilities and just deal with the induced lag and the programming monotony, or...
b)  Simplify the system by reducing the amount of characters, or the customization of skills, or the CBS.

If it were me, I might reduce the amount of characters and simplify the skill customization system.  But feel free to try option A and see how much lag is induced.  Just make sure you don't use the Wait 0.0 command to reduce lag, because it would hurt not help in this case (you might already know that, but I made that mistake).

I'm not sure what using items like skills would do - my guess is that they'd be equipped in each of the five equipment slots to work as the five skills, then- oh! XD I see what you mean, I can actually check item IDs this way to check skills just like equipped items. Sounds like a good idea, but I am using equipment for... equipment.

Actually, the suggestion was based on the fact that you can assign things like "number of X item in possession" to a variable for easy reading, whereas you cannot for skills.  I'm glad you've resolved your problem, though. 

@Mineyl:
Oh... let's go with that. Thank god I hadn't started on the tedious variable naming. XD Well, onto making... 150 items instead! XP
Let's see... that should make the code...
If [Temp ][/Temp] = [hero ][/hero]
Var [Temp ][/Temp] = [hero ][/hero]
Var [Temp ][/Temp] = [hero ][/hero]
etc.

Right?

@Lackeos:
Groups of six characters link up to learn the same skills, with a menu asking what skills to learn upon level up. Not learning some skills will obviously cut off others. This limits each "slot" to only a few possible skills, and the possible skills are checked by temporary variables. This means the player has to decide what characters in the same skill-class learn what skills.
The only lag that might be induced is either when the temporary variables are set (30 conditional branches being checked to set 10 to 15 variables) or if I have no Wait somewhere for picture display.
I might be missing something in relation to your post.

Well, to be quite direct...yes.  Exactly. 

The only lag that might be induced is either when the temporary variables are set (30 conditional branches being checked to set 10 to 15 variables) or if I have no Wait somewhere for picture display.
I might be missing something in relation to your post.

Well if you have 500 fork conditions, would it create more lag to check them all than it would take to check 30?  I'm under the impression that the answer is yes.  Although in my experiences, you can check a lot of fork conditions without hardly any lag, I don't know if that's also true of other commands like performing large amounts of variable math.

@Mineyl: Well, never mind that. I went back with my original idea because items are limited to 99, and I didn't want to mess around with the way I am formatting IDs to get around that. Plus "EXP to Next" has to be a variable too (along with Conditions! Jeez. D: ), so using some variables for individual heroes turned out to be unavoidable after all.
... and I got sick of naming items. (I cheated with the variables by only naming the first ones. I'll name the rest when the get directly edited later.)

@Lackeos: True. To avoid this possibility I have been using Labels in some other code to skip areas depending on variables. This mind you will be much more important with something like this where there are far more branches. Multiple event pages will work too.

Anyway.

This is the code I ended up with. I find the loop I've created kind of neat, because it cuts down branches drastically... I just have loads of branches to set the "starting point" for the variables to be set up.
The first variable being set - 0087 - is being set to 81 because 81 is the temporary skill ID 1. The following branches then tell where to get the value from to put into variable 0081, and then an loop sets and increases the values.
As long as variables are in the same order, this works very nicely. %D


So much for that then. If only there were more things that could be dumped/checked to/from variables. :<

You know what would be good right now though? Some sort of photoshop plugin that can turn a list or Access database into images automatically so I would be going through edit - save for web - check name - edit - save for web - check name ... my hands are sore only after 17 edits to the help/description and list image. D:

Sorry, Jaabi.  I wish I could have given you a more efficient way to do it, but no matter what, you're going to have a conditional branch for every character/skill somewhere. 

This isn't bad, though.  It's definitely the way to go for a large and complicated skill system. 

Oh I know I have to check every skill for the picture display. There's no way to create a code that 'builds' a filename to look for. (I've got filenames formatted like sk_1_2 meaning skill - level 1 - id 2) I was more concerned with getting the variables right. This code means I just have to grab a hero and it'll give me five variables for each skill the temporary hero data has, then use those in the picture menu.