STAR TREK 2d20
Page 2 of 2 First 12
  1. #11
    Zacchaeus's Avatar
    Join Date
    Dec 2014
    Location
    Scotland
    Posts
    20,736
    Quote Originally Posted by Bidmaron View Post
    Anyone know if this problem is fixed in FGU?
    Which problem? The memory limits of a 32 bit application? If so, yes, since Unity is 64 bit.
    If there is something that you would like to see in Fantasy Grounds that isn't currently part of the software or if there is something you think would improve a ruleset then add your idea here https://www.fantasygrounds.com/featu...rerequests.php

  2. #12

    Join Date
    Apr 2008
    Location
    Virginia Beach
    Posts
    3,096
    Give me some credit, Zach. The load time problem, of course. Guess I should have been more proscriptive

  3. #13
    Zacchaeus's Avatar
    Join Date
    Dec 2014
    Location
    Scotland
    Posts
    20,736
    Quote Originally Posted by Bidmaron View Post
    Give me some credit, Zach. The load time problem, of course. Guess I should have been more proscriptive
    I did wonder if that really was the question

    I seem to remember Moon Wizard saying that load times would not change that much. Something to do with XML nodes or some such. I don’t know the technical details.
    If there is something that you would like to see in Fantasy Grounds that isn't currently part of the software or if there is something you think would improve a ruleset then add your idea here https://www.fantasygrounds.com/featu...rerequests.php

  4. #14
    Mortar's Avatar
    Join Date
    May 2014
    Location
    New Brunswick, Canada
    Posts
    1,127
    Blog Entries
    18
    Pretty sure the way it works in the XML that a node gets loaded, then all child nodes get loaded before moving onto the next. Every ability, stat, attack, action, trait, drawbacks, and piece of gear just adds more nodes to load. All of them individually which is why Celestian was experimenting with the json objects for the CT.
    Ultimate License Holder

  5. #15
    Quote Originally Posted by Mortar View Post
    Pretty sure the way it works in the XML that a node gets loaded, then all child nodes get loaded before moving onto the next. Every ability, stat, attack, action, trait, drawbacks, and piece of gear just adds more nodes to load. All of them individually which is why Celestian was experimenting with the json objects for the CT.
    Yeah XML is notoriously inefficient. Very simple structure and extremely easy to work with, but inefficient once it gets large. Most industries have moved to JSON as mentioned above for internal data transmission.
    Just once I would like someone to call me "Sir," without adding "you're making a scene."

  6. #16

    Join Date
    Apr 2008
    Location
    Virginia Beach
    Posts
    3,096
    This is a library implementation problem. There is no inherent inefficiency with XML (well, anymore than any text-based database is storage inefficient). I am no fan of Microsoft, but if you use their actual .NET libraries, you don't have to import an entire XML tree at a time, you can control exactly what gets loaded.

    If FGU ever recognizes its potential as a campaign data manager, SW will have to adopt a better library for XML. Intelligent, on-demand node loading is non-trivial, however, and will require a significant effort beyond just switching to a different XML library. Multi-threading in the background will be a part of this solution, and it appears that SW has, for the time-being, decided to keep FGU single-threaded. This is a great solution in the short-term for a small development team coming from an inherently single-threaded platform, but they will eventually have to revisit this decision if they ever decide to make FG a more capable campaign manager (just go look at how RealmWorks is struggling with scaling issues associated with large campaign databases). This will be FG Beyond Ulimate because it is likely that the reason for their single-thread decision is because many of the libraries they are using are not compatible with multi-threading.

  7. #17
    Quote Originally Posted by Bidmaron View Post
    This is a library implementation problem. There is no inherent inefficiency with XML (well, anymore than any text-based database is storage inefficient). I am no fan of Microsoft, but if you use their actual .NET libraries, you don't have to import an entire XML tree at a time, you can control exactly what gets loaded.

    If FGU ever recognizes its potential as a campaign data manager, SW will have to adopt a better library for XML. Intelligent, on-demand node loading is non-trivial, however, and will require a significant effort beyond just switching to a different XML library. Multi-threading in the background will be a part of this solution, and it appears that SW has, for the time-being, decided to keep FGU single-threaded. This is a great solution in the short-term for a small development team coming from an inherently single-threaded platform, but they will eventually have to revisit this decision if they ever decide to make FG a more capable campaign manager (just go look at how RealmWorks is struggling with scaling issues associated with large campaign databases). This will be FG Beyond Ulimate because it is likely that the reason for their single-thread decision is because many of the libraries they are using are not compatible with multi-threading.
    Thats really interesting. I guess the solution for world building in the current software is to create a series of modules for a larger campaign or world and open/close them as the game progresses?

  8. #18
    LordEntrails's Avatar
    Join Date
    May 2015
    Location
    -7 UTC
    Posts
    17,148
    Blog Entries
    9
    Quote Originally Posted by Thete View Post
    Thats really interesting. I guess the solution for world building in the current software is to create a series of modules for a larger campaign or world and open/close them as the game progresses?
    It depends upon how large your world database is. I mean if your world database is for all accumulated knowledge of mankind on the planet earth, well then no database, and certainly not a flat xml one, is going to be something you are going to want to use *G*

    But, if your world database is equivalent to something like a typical RPG setting book, a single FG module is fine.

    To me, it's more about organizing the data lists. How many objects and pages of stuff do you want? How many groups do you want in the group list? Separate modules is just one more way to divvy it up and control not just how much gets loaded, but how big the lists etc are.

    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.

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