5E Product Walkthrough Playlist
Page 3 of 7 First 12345 ... Last
  1. #21

  2. #22
    What about nested createChild calls?
    Code:
    DB.createChild(DB.createChild(nodeSpellLevel, 'spells'))
    Is there a way to do something like this with one API call?

  3. #23
    Also, here are two more string replacements I found useful

    Code:
    DB.getName\(DB.getParent\((.+)\)\)
    Code:
    DB.getName($1, '..')
    and

    Code:
    DB.getName\(DB.getChild\((.+), '(.+?)'\)\)
    Code:
    DB.getName($1, '$2')
    Last edited by bmos; January 29th, 2023 at 14:08.

  4. #24
    There's not going to be a way to be able to simplify this call any further, unless you are able to specify the inner child name completely (which doesn't seem like the right call for this example).
    Code:
    DB.createChild(DB.createChild(nodeSpellLevel, 'spells'))
    Regards,
    JPG

  5. #25
    I need clarification on this for when the Current TEST goes live - are these changes something we HAVE to do before it goes live or just some current thing SW is testing to see if its worth doing? As in do I have to rewrite everything to do these things this round or can I wait?
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  6. #26
    You can currently wait, as I'm still in the phase of getting everything set up to assess.

    However, in general, the DB functions are more concise, so should be preferred long-term.

    Regards,
    JPG

  7. #27
    Quote Originally Posted by SilentRuin View Post
    I need clarification on this for when the Current TEST goes live - are these changes something we HAVE to do before it goes live or just some current thing SW is testing to see if its worth doing? As in do I have to rewrite everything to do these things this round or can I wait?
    To clarify Moon Wizard's response:
    Only the rulesets need these changes currently. Once the rulesets are coded this way, Moon Wizard is going to make a private build of FGU that does not embed those functions in databasenode objects. This will allow him to verify his theory that it's responsible for some of the performance issues.
    Extensions will not be part of that testing, so their use of the embedded functions does not need to change. If the testing says it's worth pursuing, then the embedded functions will be officially deprecated (hopefully via a gradual process as has been done with other recent deprecations) or re-implemented to address the bottlenecks. This is when extension devs would really need to update their code.

    That being said, I've already started doing it because I maintain like 2 dozen extensions and I'd rather chip away on it over months than have to rush through it ahead of some breaking update.

  8. #28
    @Moon Wizard
    Do your concerns also extend to the embedded functions in other types of objects?
    I'm thinking of things like sString:gsub(pattern, replace) vs string.gsub(sString, pattern, replace)

  9. #29
    Quote Originally Posted by bmos View Post
    To clarify Moon Wizard's response:
    Only the rulesets need these changes currently. Once the rulesets are coded this way, Moon Wizard is going to make a private build of FGU that does not embed those functions in databasenode objects. This will allow him to verify his theory that it's responsible for some of the performance issues.
    Extensions will not be part of that testing, so their use of the embedded functions does not need to change. If the testing says it's worth pursuing, then the embedded functions will be officially deprecated (hopefully via a gradual process as has been done with other recent deprecations) or re-implemented to address the bottlenecks. This is when extension devs would really need to update their code.

    That being said, I've already started doing it because I maintain like 2 dozen extensions and I'd rather chip away on it over months than have to rush through it ahead of some breaking update.
    I'd really like to push back on deprecating any API currently attached to any `databasenode` userdata object.

    Even a gradual deprecation process would have to be spread out over the course of years (not months). Maybe 3 or 4. This would not only impact rulesets, it would impact every single extension ever made for FGU that also leverages this API. As a ruleset dev myself, it is a huge refactor (as we do use that API quite a bit) with an extensive regression test process to make sure we don't slip and introduce any bugs.

    If what I am suggesting previously is possible, and I do believe it is, a better refactor can be done that allows the `databasenode` userdata object to access an API exposed by one object maintained in memory, thus achieving the same, or at least nearly similar, level of optimization.

    Also, if I am understanding Moon Wizard correctly, it seems that they may have found a way to do something like that, so that a total refactor is not needed (though may still yield a performance boost.)

    I just want to state I (respectfully) disagree with deprecating these functions, I think it will be a huge mistake for the community.

  10. #30
    Quote Originally Posted by bmos View Post
    @Moon Wizard
    Do your concerns also extend to the embedded functions in other types of objects?
    I'm thinking of things like sString:gsub(pattern, replace) vs string.gsub(sString, pattern, replace)
    The example syntax here is actually 100% identical between the two under the hood in Lua. Arguably, leveraging this language feature could actually be a viable middle ground for database nodes, where they could support ":" notation that routes to DB API calls.
    My Forge creations: https://forge.fantasygrounds.com/crafter/9/view-profile
    My GitHub: https://github.com/MeAndUnique
    Buy me a coffee: https://ko-fi.com/meandunique
    Discord: MeAndUnique#6805

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
  •  
DICE PACKS BUNDLE

Log in

Log in