-
June 29th, 2019, 22:36 #11If 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
-
June 29th, 2019, 22:40 #12
Archangel
- 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
-
June 29th, 2019, 23:13 #13If 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
-
June 30th, 2019, 01:09 #14
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
-
June 30th, 2019, 14:19 #15Just once I would like someone to call me "Sir," without adding "you're making a scene."
-
June 30th, 2019, 16:37 #16
Archangel
- 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.
-
July 1st, 2019, 05:15 #17
- Join Date
- Jan 2009
- Posts
- 141
-
July 1st, 2019, 05:27 #18
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