-
February 14th, 2018, 03:22 #11
@Moon Wizard: What is your opinion of making the default parameters optional?
Right now if the <defaulticon> and <defaulttooltip> (or <defaulttooltipres>) are not present, then the lua script throws errors.
But if I handled those issues....
(preliminary thinking is) In onInit() if the default parameters aren't in the XML set a flag. Then whenever the modular scoped variable cycleindex cycles to zero, bump it to one based on the no defaults flag==true.
The index would run from 1 to #icons, instead of 0 to #icons, which is fine.
All defined icons would have string values associated with the icons and numeric indexes.
The database I/O and data would be fine. The field and its value (""), for <defaulticon> is not written to the DB. If the field is missing in db.xml, then during DB read the missing data defaults to <defaulticon> for that data item (value="", cyclerindex=0).
Nothing in existence in any ruleset would have to change since (I assume) all current controls using <button_iconcycler> have <defaulticon>defined.
Going forward it would be okay not to use <defaulticon> and <defaulttooltip> (or <defaulttooltipres>)
[EDIT] Oops. It doesn't throw errors. The control appears to not initialize or be invisible. But that's not true, it's there just doesn't have an icon, so it looks invisible.Last edited by Minty23185Fresh; February 14th, 2018 at 14:46.
Current Projects:
Always...
Community Contributions:
Extensions: Bardic Inspiration, Druid Wild Shapes, Local Dice Tower, Library Field Filters
Tutorial Blog Series: "A Neophyte Tackles (coding) the FG Extension".
-
February 14th, 2018, 04:23 #12
Problems? See; How to Report Issues, Bugs & Problems
On Licensing & Distributing Community Content
Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
Note, I am not a SmiteWorks employee or representative, I'm just a user like you.
-
February 14th, 2018, 16:29 #13
This methodology looks great. It provided the functionality I desire. Works with old db.xml. Works with templates/controls that do have <defaulticon> defined. Yada, yada, yada.
One small function, and about six other code changes (e.g. XXX = 0; becomes XXX = myNewFunction(); )
I'll publish here for your perusal (and consumption, if desired), after a bit more testing.Current Projects:
Always...
Community Contributions:
Extensions: Bardic Inspiration, Druid Wild Shapes, Local Dice Tower, Library Field Filters
Tutorial Blog Series: "A Neophyte Tackles (coding) the FG Extension".
-
February 20th, 2018, 21:16 #14
Icon Cycler Button (Enhanced)
@Moon Wizard: As promised here is the code that I suggested earlier in this thread.
Recap: I complained that the control (template) does not have a "defaultvalue" parameter setting, that corresponds with the defaulticon and defaulttooltip parameters. The control falls back on a "defaultvalue" of "". Which I believe is a shortcoming. The developer should be able to set that value to something more meaningful to the control's context. An example: in the CoreRPG ruleset the button_iconrecycler template is employed by the button_effect_apply template. In that template there is a <defaulticon> of "button_toggle_all", with the <defaulttooltipres> of "effect_tooltip_applyall". The way the template is currently defined, the corresponding <value> for this icon is "". I believe the developer should be able to set the default <value> to a value they wish, for example, "all" in this context. (The other <values> employed in the control are "action", "roll" and "single".) Currently the developer defines n+1 icons (the <icons> + a <defaulticon>), n+1 tooltips (the <tooltips> + a <defaulttooltip>), but only n values (there is no <defaultvalue> parameter).
Remedy: I suggested that the control be modified to include a <defaultvalue> parameter. After looking at the lua code I decided to go a different route. Instead I suggest the <defaulticon> and consequently the <defaulttooltip> (or <defaulttooltipres>) be optional <parameters>. Right now they're mandatory and if the developer does not define them, when the form containing the icon cycler control comes up the control appears to be invisible (because there is no icon defined for that initial state). By allowing the "default" parameters to be optional, the developer can use a set of <icons>, a set of <values> and a set of <tooltips> that correspond one-to-one with what's presented on screen and in code.
Attached is the lua code (as text file ICC_button_iconcycler.txt) that I am submitting for replacement of the existing CoreRPG ruleset code. I have also attached the ruleset lua (as a text file) for convenience. If one diff's the two files, one sees that the new code employs one new function (bottom of the file) and 7 changes (typically setting the cycleindex equal to the value returned by the new function). The new function returns 1 if there is no <defaulticon> defined or 0 if there is. these two values correspond to the indexes into the icons[ ], values[ ], and tooltips[ ] tables. Without a <defaulticon> there is no [0]-th element in each of the tables.
Should this modification not adopted into the ruleset there is a tiny extension attached that defines and employs the modified .lua file. I release all copyright of the code to whomever may wish to employ it. The extension provides proof of concept using the CoreRPG Combat Tracker Faction iconcycler. As is, when dropped into a project the behavior of the Faction control in the Combat Tracker behaves exactly as if the extension were not being used. One can go in and uncomment the second <includefile> recitation in the extension.xml file and then the Faction control will cycle through "foe", "neutral" and "friend" because <defaulticon> is not used in the faction template in ICC_template_common.xml.
Thanks in advance for your consideration.Current Projects:
Always...
Community Contributions:
Extensions: Bardic Inspiration, Druid Wild Shapes, Local Dice Tower, Library Field Filters
Tutorial Blog Series: "A Neophyte Tackles (coding) the FG Extension".
-
February 20th, 2018, 23:23 #15
Archangel
- Join Date
- Apr 2008
- Location
- Virginia Beach
- Posts
- 3,096
Thanks, minty. Sounds like with a little testing this is backward compatible and forward excellent
-
February 21st, 2018, 04:01 #16
-
February 21st, 2018, 21:45 #17
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,570
Here's an alternate version that does what you were looking for, but addresses a couple minor items raised by the changes you wanted.
Also, the faction cycler deliberately has an empty option, so four states is correct for that control. I'm assuming that you used it as an easy example.
I'll plan to include this version in CoreRPG next release, unless you find an issue with it.
Regards,
JPG
-
February 24th, 2018, 00:31 #18
(1) alternative.... we're essentially doing the same thing, slightly different means. Your way is a little more efficient. One test in onInit() instead of retesting over and over.. I like it. Thanks.
(2) four states.. Yes I understand that. It was just, as you say, an easy test. No big lengthy setup. Bang open the CT and there it is.
(3) issues.... Looks great to me. Works just as I desired. Thank you very much. And I am pleased that you consider my work worth including in the ruleset.
(4) four... (MW: replies: "Four... wait.... what four? there isn't a fourth point in my reply" )
I apologize for neglecting to ask/include this in my code/questions. It slipped my mind until I was diff'ing your code against mine.
In your new code, the setIndex() ~line 165 and setStringValue() ~line 194, functions... In both of them the nCycleIndex is not set to a new value on "if srcnode" evaluating true. My question is: shouldn't it be set to a value consistent with the function's argument regardless of the presence of srcnode? I.e. setting nCycleIndex should be outside the if statement (and consequently so should be the declaration of nMatch)?
(5) .... which leads me to a fifth point... The concept of a <source> with type "number" seems wrong (to me) in this context. The whole concept behind this control is to cycle icons and use names to index the icons. To use numbers seems archaic and not worth consideration. But that's my two cents. Is it possible some quick copy/paste programming brought this numeric index support over from another control as an artifact? I searched the Core, 3.5E and 5E rulesets to find an instance of using numeric indexes in an iconcycler and didn't see one. Though I could have missed it.
W.R.T. points 4 and 5. Maybe I don't understand what's going on with those two functions. Maybe they're double duty, and I have failed to grasp it. In which case nevermind. :O
-
February 24th, 2018, 02:23 #19
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,570
4. When the template is linked to a database node, then whenever the srcnode is changed, the update function is called which synchs the internal variables to match the node's value. If we also tried to set the internal variables in setIndex/setStringValue, then they would be set twice and/or potentially need flags to prevent this scenario.
5. The original iconcycler control supported both number and string data sources, so any future versions also must. There's nothing wrong with either data source type being used for an icon cycler.
Regards,
JPG
-
February 24th, 2018, 19:39 #20
Moon Wizard, sorry to belabor this point. I suspect I didn't express myself well enough.
My concern is that if the nBaseIndex == 1 (no default icon) and for some reason the argument comes in equal to zero, the srcnode value will set to an invalid (in this particular instance) value of "".
I think if the argument, srcval, is pretested against nBaseIndex, the rest of the routine falls into line, almost without modification:
Code:function setIndex(srcval) if type(srcval) ~= "number" then return; end if srcval < nBaseIndex then srcval = nBaseIndex; end; if srcnode then ........
(I tend to be a bit of a defensive coder.)
Thanks for your patience.Current Projects:
Always...
Community Contributions:
Extensions: Bardic Inspiration, Druid Wild Shapes, Local Dice Tower, Library Field Filters
Tutorial Blog Series: "A Neophyte Tackles (coding) the FG Extension".
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks