ATTN: Nanaki and Gremlin Wizard

[Aleksandar]

On a quick glance, I noticed this

function CanAddProperty(pilot, proper)

--proper = {100,{"Instructor", "Tactics"},{}}

prop_ = proper[2]; // {"Instructor, "Tactics"};
deprop_ = proper[3]; // {}
numProps = getn(proper[2]); //2
numDeProps = getn(proper[3]); //0

~for each prop in prop_
check to see if the pilot has the passed props arguments. return 1 if he does.

~for each deprop in deprop_
check to see if the pilot has the passed deprop arguments. return 0 if he does.

Long story short, the function CanAddProperty(pilot, property) has prerequisites and denials.

The first part of the code checks if you can actually get the property by checking for prereq skills. The second part of the code checks the third param (first is XP price, second is a list of all the prereqs and the third is a list of all denials) and if the pilot has that property (say, Gunnery_3) you cannot get the wanted property. This leads me to believe we can make Character Decisions so that if you get one skill, you cannot get some others.

This will work well in fleshing out the classes since I can put way more skills and interlace them in a mutually-exclusive tree, thus holding two classes in just one class. That way, I hope, I'll make some dummy "choice" perks and use them to limit the trees. So, say advancing gunnery 1 and 2 is ok, but picking Gunnery 3 forever locks you out of picking Missiles 3, which further locks you away from all the Missily goodness but opens the door to gunnery goodness perks.

This way, I believe, I can put all my 7-8 classes into four, rename them into Assault / Dogfighter / Commander / Support and have each one describe the opportunities found within. The original devs never seemed to used this, so it may not work. But it's a shot.