DICE PACKS BUNDLE
  1. #1
    Minty23185Fresh's Avatar
    Join Date
    Dec 2015
    Location
    Goldstone, CA, USA
    Posts
    1,211
    Blog Entries
    29

    Employing the Function Renaming Technique for Registered Handlers

    We all know that every extension published has the potential in adversely interact with other extensions.

    One technique many of us use to help mitigate against possible poor inter-extension operation is to rename and thereby nest functions.
    (I am going to purposely being very simplistic, so that, should the neophyte extension writer, find their way to this thread, it might help them.)

    Here's an example from one of my extensions, in the onInit( ) function I am "renaming" the 5E ruleset's onDeathRoll( ) function. Then I am using my extension's function to replace it.
    Code:
    function onInit()
       ActionSave.LDT_onDeathRoll_helper = ActionSave.onDeathRoll;
       ActionSave.onDeathRoll = LDT_onDeathRoll;
    end
    
    function LDT_onDeathRoll(args)
       -- call the helper to utilize ruleset functionality then modify it
       ActionSave.LDT_onDeathRoll_helper(args);
       -- now do my extension's stuff
       ...
       ...
    end
    There! Now that the table has been set, here's my question: Is there a similar methodology that I can employ for the "registered" handler function?

    Please note that the code given above does not work, because the 5E ruleset function is a registered handler.
    What I have had to do is this:
    Code:
    function onInit()
       ActionsManager.unregisterResultHandler("death");
       ActionsManager.unregisterResultHandler("death_auto");
    
       ActionsManager.registerResultHandler("death", LDT_onDeathRoll);
       ActionsManager.registerResultHandler("death_auto", LDT_onDeathRoll);
    end
    And now for those who are really paying attention: "Okay Tom, you've figured it out, you have the solution. Why are you bringing this up?"

    Well, the above does not solve the inter-extension operability problem.

    With the renaming technique, one extension can rename the ruleset function, and drop the extension function in its stead. Then another extension can do the same, come after the first extension, rename the first extension's replacing function and substitute its own. All three functions coexist and by calling the "helpers" and a small bit of luck, interoperability can exist.

    But in the registering of handlers I'm a bit obtuse, and have yet to figure out a way to ensure the extension that registers a replacing function before mine can be called by mine. I need something like a "whoIsRegistered( ) function to save that tidbit of info before my extension registers my replacing function.
    (This is the first time I've run into this issue, so I have to admit my ignorance.)

    Thanks to all of those who read this thread, and of course real kudos to those who can drag me and my thick head into the light!
    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".

  2. #2
    This only works if the registrations happen later in the initialization process, and use indirect referencing. This methodology is fairly recent for FG coding (last couple years), so was only implemented as needed for a long time. In the last few months, I've been making a push to migrate all the CoreRPG global scripts to allow this methodology to be used. I plan to make further migrations as I work on various scripts, but it's work done on an as-needed basis.

    Regards,
    JPG

  3. #3
    Minty23185Fresh's Avatar
    Join Date
    Dec 2015
    Location
    Goldstone, CA, USA
    Posts
    1,211
    Blog Entries
    29
    Ummm. 'mmKay...

    Thanks Moon Wizard.

    But I am kinda missing what the answer is... Are you saying there is no technique for registered function substitution that's similar to the simple renaming technique? If that's the case, isn't making registered functions more common going to cause more inter-extension operability problems unless a technique is co-developed to assist community developers?

  4. #4
    If the original script is written such that the registration occurs during the onTabletopInit event and references the registered function indirectly, then you can still use the same method of functional replacement in an onInit call as in your first example. This is because your replacement function is swapped in before the registration occurs.

    (See TokenManager.onTabletopInit for an example.)

    Regards,
    JPG

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Starfinder Playlist

Log in

Log in