I don't see anything wrong with your code at first glance, but wouldn't a table be an easier way to get the modifier you need? It should be as simple as
...with no need to define functions or try to figure out JSON objects.
Either way, best of luck!Wiki: table()
Yeah, easier to a point, but I am looking at portability, and ease of upgrade in the future. Now if there was a way to modify tables from a macro, I'd be all over it. I know you can export the tables, unzip them, and edit them outside of the tool, but it is a pain from what I have seen so far of it. Unfortunately, looking at some, like Plothos spell manager, row 0 is to large to edit with XMLPad, and to cumbersome to edit with OpenOffice.Org Calc.
I have been using OOO to make template that I can fill out and then generate JSON data sets from. And I suppose I could then parse that and put it in the same format as the tables, but that is to much like work, when I can do this, and create functions to grab that data. Though, if tables could be modified from a macro, that would be another story.
For example, my class definitions are broken down to two different sets of data. One is the Class Ability Def's, the other is the Class Def. The Class Def has a header with information such as Class Name, Prime Attribute, HD type, etc. and some arrays for things like an XP chart, permitted weapons, permitted armor, and the list of class abilities. Note this last actually work like a relational db, in that the list is just the key field to pull information from the Class Abilities Def. There are cases where abilities overlap between classes, so they only need be entered once. Though for the C&C framework I am working on, I have duplicated them between the classes, and only use the references when setting up the multi-class options.
Now, each of the classes (or multi-classes in the way C&C handles them) have their own ClassDef macro. For example, the fighter class has a macro called "fighterClassDef", and the rogue, "rogueClassDef". This contains all the pertinent information to define the class. There is also another macro called "fighterClassAbilitiesDef", and one called "rogueClassAbilitiesDef". I then created two macro's "addClasses" and "addClassAbilities", these macros basically search for all macro's ending in either "ClassDef" or "ClassAbilitiesDef", and creates one JSON data set for each, and stores that in a property on the token. This way, if you want to add another class, you simply need to add the appropriate ClassDef and ClassAbilitiesDef macro's, then run the addClasses and addClassAbilities to recreate those JSON data sets. It also allows you (in the C&C method) to add a new "multi-class", by simply creating the ClassDef macro, and in the abilities list of that data object, referencing the abilities from the parent classes. You then only need to run the addClasses macro to have it be available as a new class. For example, the Thug, a Fighter/Rogue multi-class (using the C&C Class and a Half rules) would only need a new thugClassDef macro, since all of it's class abilities can be referenced from the existing abilities, like "fighterCombatDominance" or "rogueMoveSilently". You could also add a new class like "Sailor" which may have some of it's own special abilities like "Navigate", but also an ability like "Climb", well you would need to create a new class abilities def macro "sailorClassAbilities" and add "sailorNavigate" to it, but in the "sailorClassDef" macro, you can, in the class abilities list, reference both "sailorNavigate" and "rangerClimb". Why rangerClimb and not rogueClimb, well because rogueClimb includes scaling sheer surfaces like walls, where rangerClimb is not that, but ropes, trees, etc. You could, of course, make a new sailorClimb ability and define it more strictly to ropes and poles if you so desired.
My thought process for the way I am designing the framework is to have a large number of Library Tokens, with each having a smaller number of macros. Basically creating a Library Token for each different type of function, though some will be named similarly and really work as a group, so you can replace the tokens for bug fixes, or added functionality, and impact the smallest common component.
For example, my next generation character sheet will actually be it's own token (well it is now), but some of the pages of the sheet will be written to from other tokens. That is, I will have a Lib:Inventory token, and it will be responsible for managing the equipment a character possesses, and also filling in the inventory section of the character sheet. A separate but related token would be Lib:Encumbrance, which is obviously related to the former library, but has it's own set of functions, pulling data from the former to make those calculations. That way, if we change the encumbrance rules, only that token need be updated, and all of the components will be easy to find.
Now, since I am still learning this macro language, it's extents and limitations, my code isn't necessarily very pretty, nor at this point very large. Maybe a couple thousand lines, not including the data sets. Once I have something workable to start a campaign with, I will spend time rewriting to standardize my code, and to make sure the modular approach fits well. I know I will be freely plagiarizing from other peoples code, especially at the beginning, heck in many ways that is how I learn best! Now this won't be whole sale stealing of code, but most likely snippets, and lots of learning from reading it. And this forum has been invaluable so far...
Wow did this get long, must have needed a break... time to get back to coding!