DICE PACKS BUNDLE
Page 2 of 7 First 1234 ... Last
  1. #11
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,362
    Quote Originally Posted by Elawyn View Post
    ...today i use nodeWin.GetParent().GetParent().GetChild("string") .getValue("number").
    Use relative DB paths - info on DB paths here: https://fantasygroundsunity.atlassia...Database-Paths

    So, you could use DB.getValue(nodeWin, "...string.number", "") would go two steps up in the DB hierarchy from nodeWin (the first "." is the same location as nodeWin) and then proceeds to the child string and from there returns the value of the child field called "number".
    Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!

  2. #12
    Thx a lot, will that try back at home!

  3. #13
    Quote Originally Posted by Moon Wizard View Post
    The gist of the change is that the original FG developers (before my time) chose to make databasenode objects (as well as a few others) into full-fledged scriptable objects with embedded APIs, even though those objects can not be assigned a script tag/file. This creates a lot of overhead in every object, since the entire global namespace and APIs need to be built for every object. So, when you have an object that is as prolific as databasenode (i.e. every possible node in the database), my theory is that this creates a massive amount of overhead for database operations which is completely unnecessary. Also, with the continued growth of the FG catalog, the size of the databases used by DLC and in campaigns continues to grow with every year.
    Hi Moon Wizard! This is a great theory and I think you are spot on here. I see a lot of slowness currently when using the API to copy large DB lists of DB nodes and children around, and perhaps this will be a great speed improvement. I have a few concerns though. Namely, there are a lot of unofficial rulesets (on the Forge) etc. that are probably not aware of such a change, and this would definitely break all of those rulesets. Additionally, we have a release coming up for Cyberpunk RED, which is coming along nicely, but we will need to do a lot of refactoring (immediately after release preferably) and then a full regression test, to ensure issues do not crop up as a result. It is a lot of work (and we are not full SW employees).

    If what I understand here is correct, each dbnode reference (a userdata object) is loading dependencies needed to be able to do those API calls, probably lots of XML libraries and such. Now, I am not a Lua expert by any means, but perhaps there is another way to do this refactor while ensuring cross-compatibility with older rulesets.

    Would something like this be possible?
    • Keep dbnode references a userdata object with .getChild, .getChildren, .getValue, and .setValue
    • Refactor the underlying userdata object (C++ I am assuming? C#?) to instead call a singleton that is managed by the application. The singleton is then responsible for loading all the XML packages/libraries needed, and then calls those needed for each call, with the values as specified by the userdata object.


    The idea here is then just one singleton class/userdata object is instantiated for the whole application that is responsible for doing XML lookups, setting values, etc., and each dbnode just points to that singleton wrapper.

    Again, apologies if this was already considered or is just not possible, I have never edited an application's Lua script engine, and my knowledge of the Lua interpreter is pretty limited.

  4. #14
    On the @Trenloe/@Elawyn discussion, one note is that the new method will be much more performant than the concatenation method, because you have less API calls that have to be translated between Lua to the core engine.

    nodeWin.GetParent().GetParent().GetChild("string") .getValue("number") = 4 API calls

    DB.getValue(nodeWin, "...string.number", "") = 1 API call.

    Regards,
    JPG

  5. #15
    @seansps,

    API references are actually tied to directly to each individual object, so that there is context for when an API is called. If it was a general function, there would be no context.

    Also, all the APIs have to be registered to each object in order to be linked to an object in order for Lua to work which is part of the overhead.

    I’ll definitely be looking at ways to possibly minimize disruption once I can verify whether the theory that performance will be affected is tested with a special client with the databasenode rewritten.

    Thanks,
    JPG

  6. #16
    Thank you and yes, it seems "smoother" and i hope your work will be fruitful! I tested the db. Method for string calls and number calls, both are working (for me such Things are exiting, sorry ) I am relieved so far. My nodeWin.getPath() i have struggle with but i will think about and if i unterstand the timeline right, its Not an instant encounter.

  7. #17
    Most single-call functions can usually be rewritten pretty easily nodeVar.fn(...) -> DB.fn(nodeVar, ...)

    The exception is DB.setValue which requires a type parameter, and chained calls which end up having to be nested.
    Also, most chained calls are of the form nodeVar.getParent().getParent()... or nodeVar.getChild(...).getChild(...). These are faster to implement as paths using the dots for going up/down tree.

    Regards,
    JPG

  8. #18
    Quote Originally Posted by Moon Wizard View Post
    @seansps,

    API references are actually tied to directly to each individual object, so that there is context for when an API is called. If it was a general function, there would be no context.

    Also, all the APIs have to be registered to each object in order to be linked to an object in order for Lua to work which is part of the overhead.

    I’ll definitely be looking at ways to possibly minimize disruption once I can verify whether the theory that performance will be affected is tested with a special client with the databasenode rewritten.

    Thanks,
    JPG
    Thanks for the response! That’s too bad if it can’t work with a singleton…

    I believe that when multiple instances of a userdata object are created in a Lua script, with pointers to a singleton, then they’d all just reference the same underlying object in memory. If the dbnode objects pointed to a singleton object it should only consume memory once, regardless of how many references to it exist in the Lua script (at least for the API portion.)

    But that’s just my theory. I’ve never implemented anything like this.
    Last edited by seansps; January 27th, 2023 at 04:42. Reason: Edit for clarity

  9. #19
    damned's Avatar
    Join Date
    Mar 2011
    Location
    Australia
    Posts
    26,649
    Blog Entries
    1
    How would you rewrite the second line here?

    Code:
    	local nodeRoll = window.getDatabaseNode();
    	local nodeChar = nodeRoll.getParent().getParent();

  10. #20
    local nodeChar = DB.getChild(nodeRoll, "...");
    Dominic Morta
    Ruleset Developer
    Smiteworks

    How to zip up your campaign if the Developers ask for it-How to zip up your campaign if the Developers ask for it

    How to provide an Unity Connection issue?-Connection Issues and What to Provide

    Unity Updater issue?-Updater Issues

    Classic and Unity Port Forwarding?-Fantasy Grounds Connections Explained

    Comcast or Cox ISP User?-Comcast XFinity and Cox Users

    Have a suggestion?-Feature Request

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
  •  
STAR TREK 2d20

Log in

Log in