NetExalted/XNEPTraitClass

• NetExalted/XeriarProposal - Back to Proposal

Trait Class

The Trait Class is the second main workhorse of this proposal, the first being the Character class. It has two modes, after a fashion. The first is inside the Core class, where it is actually relatively inert. It's there to potentially be read into a Character class, and not much more.

Inside a Character, it has a lot more power. Primarily, it throws around strings and/or numbers as they are requested of it, and can be quite flexible.

Data Members

• Value Array - A special, fixed-size Array containing a few members that all Traits will posess
  • Name - The name of the Trait
  • Type - The type of the Trait
  • Value - The value of the Trait
  • Multiplicity - "Single" Means that the Trait may only be 'taken' once, though its value may be modifiable. "Multiple" Means that it may be taken multiple times, its Value being set to the number of times it's taken ('owns eight Marukani swifts' or somesuch). An equation (even if it's only a number) specifies that it may be taken up to a certain number of times, and that number is stored in Value (Ox-Body and so on).
  • Editable - A specialized Value, if its Value is 0, then the Base Value cannot be directly changed by the User (it's a Derived Trait, such as Health Levels, Peripheral Essence, etc). If 1, than it can be.
• Character Parent - a pointer to the parent character. If null, we're residing in the Core class.
• (Value Array) - The remaining necessary values the Trait may have. This will vary wildly - the Name Trait, for the Character's Name, will have none of these. A Charm Trait will have several.
  • Values with names beginning with the word 'Minimum', 'Maximum', 'Cost', 'Equals', 'Override' and perhaps several others will need to be recognized specifically, so that Traits may govern their own limits, costs and prerequisites.
    • 'Prerequisites' will probably be an alias specifying a comma-delimited list of Traits, all of which get interpreted as 'Minimum(Trait), 1' entries.

Private Functions

• int Parse (String) - parses one of the Trait's Value.Data elements.
  • Must be able to handle addition, subtraction, multiplication, division, if-else statements, conditional and boolean operations.
  • Must be able to reference other values and parse them. For example, "Backgrounds->Breeding.Maximum" Would typically return a 5, or a 6 if the character has Legendary Breeding. The order goes (Type) -> (Trait).(Value), where the default is simply putting in (Trait) will return the Trait's basic Value.
  • "String:" - should return the following as just a plaintext string, or, getting fancy, use quotes and allow concatenation as such.
  • "None" Should return 0

Public Functions

• boolean IsPrerequisite (String) - Searches for the input word in the Prerequisites in the various 'Minimum', 'Maximum', and 'Equals' fields. Returns True if so, False otherwise.
• String Verify (String New Value) - verifies whether the new value the Trait has received can be legally set. It returns either a null string (success) or an error message explaining why the setting failed.
  • This is a public, rather than private, function because it will need to be called by the character when a value gets changed.
• boolean SetValue (String New Value) - Sets the Trait's value if it ends up being legal.
• String GetValue (ValueName) - Retrieves the parsed (if necessary) value. If no name is given, return the Trait's base Value.
• boolean Override (value, string) - Attempts to override one given value with another (typically because someone purchased a Merit or Flaw)
  • Stuff like this is going to have to be handled carefulle and perhaps reconsidered, maybe frequently.

• String[] GetPrequisites() - Returns a list of Traits used as prerequisites

Comments

Are you deliberately avoiding exception handling for some reason? Why a doubly linked list? This is the perfect case for using Hashtable? --flymolo

I'm a C++ junky, sorry, I tend to think exception handling is for unexpected errors rather than those predicted and user-caused. It's the results that are needed, though, and the trait, if it picks up the action, needs to be the one to send the appropriate message, whether through the exception handler or a return value.

A Hash table should be fine, I haven't built one in awhile. I'll need to update this to have Traits handle multiples of themselves (for now, since that only really matters for equipment, and the Hash is going to have to be pretty complex, as some Traits will have the same name, but different types, requiring a two-dimensional setup. That will be the Character class' problem to translate, although it does mean the data junkies aren't going to get away with specifying 'Sword' but almost always 'Weapon->Sword'

Shouldn't GetPrerequisites return a Value array (I ought to rename that Data array to keep from confusing).-Xeriar

Flip through the Java API if you get a chance specifically java.util , That has all the data structure classes including hashtable. Now this involves casting on the way out, because generics are java 5(1.5) only.

I was thinking the insert would look like

if (!hash.exists(swordobj.shortname)){

hash.put(swordobj.shortname,swordobj);

hash.put(swordobj.longname,swordobj);

}

else {

hash.delete(swordobj.shortname);

hash.put(swordobj.longname,swordobj);

}

But that's because I'm ok with scripts breaking if someone creates an artifact called Strength.

GetPrequisites I was thinking would return the list of Traits that the skill required, but creating all the Traits seemed too heavy so I settled for skill names. We could return String[][] so we get skill value pairs. --flymolo