Advice modifying feats functionality

[GrimmSpector]

Looking at the 3.5e implementation for Feats, from what I can gather, it looks like when you drag a feat over, it just creates a link, and a string with the value of the name field from the link; I'm not sure where the "value" tag in the database comes from that is storing that name in the list.

I'm looking at implementing Traits for Battletech through a similar method. Like everything else in Battletech the numerical value of a trait depends on the XP a player puts in it, so the intended layout/implementation is something like this:


Drag & Drop a Trait from the Library
Item appears just like in the feats list, but the windowlist has extra controls; one indicates the current Level of the trait, and the other is editable, and indicates the XP spent on the trait
Traits have maximums and minimums, that can have a significant range, anywhere from -15 to +15 in some cases, others can only have specific values like "3 or 7", or just "1", and some have prerequisites.
The trait needs to only increase the score when sufficient XP is spent to reach a valid level, this is easy coding, however I'm not sure what values I can add to the library module for feats, or more importantly how to access them.
The traits cannot be added manually, only dragged, so only edit not add functionality will be included in the list
Some traits impact how XP is calculated on other things, so some traits need to modify a global value in the DB for that character, I'm thinking of setting this up with a comparison of the "name" field for the trait, and if the name fits certain values having a boolean type setup in the characters database entry, i.e. if the trait was called "Green" and it was one I was tracking for, it would put a database "number" with the value "1" called "green". Again this should be fairly easy to implement, but I'm unsure the best approach for building an xml structure to extend feat entries to make this work well


I think that's it for now; I've included the XML from the library module for a feat entry below, and would love to hear some suggestions. I'm aware that the "class" entry in the "windowreference" items is used when the link is dragged to allow the Drag event handlers to identify the data structure being dragged and dropped, and to tell fg what sort of window class to construct when opened.

This puts the "feats" listing into the library module itself:


<feats>
<librarylink type="windowreference">
<class>referenceindex</class>
<recordname>lists.feats@PFRPG Basic Rules</recordname>
</librarylink>
<name type="string">Feats</name>
</feats>
[CODE]

The xml above allows this type of entry in a list with links:
[CODE]
<feats>
<name type="string">Feats</name>
<index>
<acrobatic>
<listlink type="windowreference">
<class>referencefeat</class>
<recordname>reference.feats.acrobatic@PFRPG Basic Rules</recordname>
</listlink>
<name type="string">Acrobatic</name>
</acrobatic>


And this link, links to this entry:


<feats>
<acrobatic>
<name type="string">Acrobatic</name>
<type type="string">General</type>
<mult type="number">0</mult>
<stack type="number">0</stack>
<benefit type="formattedtext">
<p>You get a +2 bonus on all Acrobatics and Fly skill checks. If you have 10 or more ranks in one of these skills, the bonus increases to +4 for that skill.</p>
</benefit>
</acrobatic>


Some of the feats have entries of other types, such as "prerequisites", or "special", etc., either as strings or as formattedtext elements; but I've been unsuccesful in finding in the xml how these are being structured into the feats reference windows. I imagine knowing this might help me significantly on pursuing a data structure, and deciding how much information to store in the character DB, and what to leave purely in the library, per item.

[Moon Wizard]

Take a look at the "list_charabilities" template in the 3.5E ruleset inside the campaign/template_char.xml file (Line 797). This is where the feat reference drop creates an entry on the character sheet with the "value" field being set to the name, and a link to the feat reference record.

I would think that you would want something different. When you add the trait to the PC sheet, you'll have to decide how much you want to copy over from the source record, as well as what values you want to set for the initial trait level and trait XP.

Regards,
JPG

[GrimmSpector]

Take a look at the "list_charabilities" template in the 3.5E ruleset inside the campaign/template_char.xml file (Line 797). This is where the feat reference drop creates an entry on the character sheet with the "value" field being set to the name, and a link to the feat reference record.

I would think that you would want something different. When you add the trait to the PC sheet, you'll have to decide how much you want to copy over from the source record, as well as what values you want to set for the initial trait level and trait XP.

Regards,
JPG

Traits have a given functionality, and I may be able code some of that in; and strict levels, but they gain them by spending XP on them, in increments of 100, but some feats start at a given level, for instance one starts at 3, so you have to have 300 XP before you gain any benefit or negative.

I'm considering setting them up in a way that the player can just click up or down "buttons" that will allow them to pan through the available levels and it takes away their earned XP or grants new XP for flaws, easy enough just using positives and negatives for each. Displaying more information from the record should be relatively easy. New columns with whatever controls I define, in some ways very similar to the way I was doing attribute scores previously.

I'm not sure I understand how it's defining the data structure for the windows, it seems like I could add any "formatted" text set, and it would add a section for it automatically; is this the case?

Modules only pass information types, from what I see they don't build controls, but I haven't found any xml that I can identify as building out the window controls, or I'd know what to copy to make a new window with the appropriate fields (which I can simply hide when not appropriate).

I feel like the simplest way to do levels of traits is to treat them as string sequences and parse them in script; for instance if it goes from level 1 to 10, I can have a string 1-10; or if it comes in just levels 3 and 7 I could have a string 3,7; string functions could split it up into a table of number values to walk through if we find one or more commas, if we instead find dashes indicating ranges we can setup a for loop to build the table of values, have them built when the window is open, so it's only done once, and held while the window is open for quick response.

Does this sound reasonable? And can you point me to the right location for the feat reference window instance xml?

[GrimmSpector]

I've examined in more depth, looks like the lua that's working here just basically looks for xml tags that match ft_column objects, and adds the resource there, as a control of whatever type, and that's all. Unless I'm reading the ref_feats.xml and ref_filter.lua wrong. So I could add whatever sections/controls with appropriate names here, and matching xml tags in a module library, with whatever class name I want to use for the window linking and dropping, and code for that.

The only thing I'm not seeing yet is how I can access some of these during the drop operation, the intention is to store the data locally in the character sheet (the table of levels the trait can take), then I can stop the trait from being added again, and not need to look in the module when players are adding levels of things to their sheets.

Does this sound right?

[Moon Wizard]

There are 2 different ways to look at this. You can look at this from the window/control perspective, or from the database perspective.

Every window either has a data source path or is sourceless. Whenever a window is opened, then the appropriate database nodes specified in the source path will be linked to the fields defined in the window (or created in the database if they do not exist) as long as the path and data type match. If the window is sourceless, then no database nodes are automatically created or linked. This is what you are defining in your XML. At the basis of every control after you resolve all the templates, there are only a handful of control/field types (stringcontrol/stringfield, numbercontrol/numberfield, etc.). Field controls will generate and/or link to an underlying database node if the window has a source path, and "control" controls do not interact with the database at all. (usually labels, derived values, etc.) These are all documented in the Ruleset Reference document in the Developer section of the wiki.

When you are reading/writing data from the database perspective (DB.setValue, DB.getValue, databasenode.getValue, databasenode.setValue), the layout of any window viewing the record is irrelevant. (other than the fact that the data will update visually in any linked controls).

Regards,
JPG

[GrimmSpector]

Ok, so the reference window will be linked to a datasource (the library module), and should not create and new database nodes.

Long story short, I just need to design a window layout I like for the traits, (which will likely be quite similar to a feat window), and use that class. I must be missing how it's hiding the sections that aren't present, for instance if there's no "special" field, it doesn't draw a separator, doesn't draw the Special heading, same is true for all the formattedtext field.