FGU: The interface

[Zacchaeus]

Your last point is correct, but it's more complicated. Things are stored in the module database as an id number. Each items, NPC, etc etc is given an ID number in the order they are created. Thus in the PHB a longsword could be id-00056 and in another module it could be id-00234 and in another a longsword +1 could be another id altogether or it could be a duplicated of the one in the PHB or in the other module. So filtering out what isn't wanted would not be an easy task.

[Moon Wizard]

Also, to complicate the situation,
* Each data module can be loaded individually (and thus the data needs to be always available for that book) (i.e. there is no master data module; it's per book.)
* The records within each module can actually be slightly different data depending on what is published with the book.
* The records within each adventure can be customized by the GM running the adventure.

I think we're all agreeing that the interface could be improved to more gracefully handle multiple items with the same name, but there's no easy way to "consolidate" data across books without taking away capability. I have a couple items on my feature request list to help, but they haven't bubbled to the top as the list is very long and there are only 2.5 ruleset/framework developers on staff (including new system support and ongoing maintenance).

I'll be parsing your feedback from earlier in the thread more closely after I get the beta going next month, and see if there is any small stuff we can do short term.

Regards,
JPG

[Morenu]

And one thing I will add about the FGU user base (at least on the forums). this thread just about anywhere else would've been reduced to poo throwing monkeys by page 3. the users on FGU are some of the best I have encountered on the internet. wonderfully non confrontational discussion everyone. this is how ideas grow.

and from the guy that almost never RtFM, since its not how I can learn/retain new info, Thanks to all that have responded with helpful ideas.

[Metlore]

And one thing I will add about the FGU user base (at least on the forums). this thread just about anywhere else would've been reduced to poo throwing monkeys by page 3. the users on FGU are some of the best I have encountered on the internet. wonderfully non confrontational discussion everyone. this is how ideas grow.

and from the guy that almost never RtFM, since its not how I can learn/retain new info, Thanks to all that have responded with helpful ideas.

Fantasy Grounds users AND STAFF are fantastic at helping people with questions. Once you get used to FGU, I feel like a lot of the design decisions make sense. It's just the initial hump. I do agree that the GUI feels a dash outdated, but honestly, i can't fully put my finger on why. I do hear a lot of the same initial complaints from new people to my games though, such as:

Why can't we just click on empty map and drag it around?
Why did my token just rotate?
Why did I just heal the enemy too? (because they didn't untarget them)

Something that has not come up that I think is a major problem is uniformity among the adventure modules. I think old modules need updated to be consistent with new. For example, off the top of my head, a new DM would encounter the following 2 major points of confusion:

Why do some modules have story entries and some don't because they're supposed to be ran off the Reference Manual?
Why do some modules contain everything in the DM version and others require me to load both the DM and player version to have access to everything?

Just my two cents....

[Zacchaeus]

Why do some modules have story entries and some don't because they're supposed to be ran off the Reference Manual?
Why do some modules contain everything in the DM version and others require me to load both the DM and player version to have access to everything?

Just my two cents....

Because Fantasy Grounds evolves. Adventure modules were never written with reference manuals originally. Originally reference manuals were simply story entries in a different format so there wasn't any point in including them in an Adventure. Reference Manuals were for just that; reference modules, like the PHB, DMG etc.

Then Fantasy Grounds evolved and images could be embedded into reference pages; as well as text could be broken out into sidebars with different coloured backgrounds and text columns. So, now, reference pages became a lot different from stories; they were more colourful and useable as reading material. So adventures started to be developed with reference manuals. Initially they were an adjunct; not meant to be used to run the adventure but as another method that DMs could use to read the story as if it were something close to a PDF. Using an extension created by a community developer older modules were revisited and reference manusl were added based on the story entries. The result wasn't as good as could be produced from scratch but they were more than passable.

Many early modules (at least for 5e) were created using an internal tool called par5e which took text files and converted them into xml files which FG could read. In many respects it was easier to create modules using this tool because it was a bit laborious typing all the text for, say, an NPC into FG. FG evolved again; an NPC importer was introduced; a table importer; copy/pasting text from one source to another preserved formatting; class specialisations became a separate window class as did subraces; it was now possible to create and link spell lists for specific classes within FG. It also became possible to combine player and DM layers in the same map. It therefore became much easier to create modules inside of FG and so there was shift away from the internal tool and modules started to be developed directly in FG. And since reference pages were much better looking than story entries the latter were dropped in favour of the former in the most recent modules.

Now, I'm using another internally developed tool to convert earlier modules into campaigns so that modules can be updated with more up to date image formats and prepare for forthcoming features.

So FG is always evolving; it's a completely different beast than it was 8 years ago when I started producing modules for the store.

Earlier modules did not split DM and player information all that well; but then player modules became the norm containing the player facing data such as classes; races etc. Over time more and more such books were produced and so more and more data became available. In order to cut down on duplication player facing material was dropped from the DM version of the books. However going back and removing such data from earlier modules isn't an option since any characters created using that data will break; and that will cause too many issues for too many people (not to mention a significant increase in support); and there is no easy solution to fixing those character other than recreating them. People who have been playing a character for years would be desperately unhappy if their character suddenly became unplayable.

So, in short, fantasy grounds evolves and improves. Whilst every effort is made to keep everything as uniform as possible sometimes it just isn't an option and indeed not even desirable.

[Metlore]

Because Fantasy Grounds evolves. Adventure modules were never written with reference manuals originally. Originally reference manuals were simply story entries in a different format so there wasn't any point in including them in an Adventure. Reference Manuals were for just that; reference modules, like the PHB, DMG etc.

Then Fantasy Grounds evolved and images could be embedded into reference pages; as well as text could be broken out into sidebars with different coloured backgrounds and text columns. So, now, reference pages became a lot different from stories; they were more colourful and useable as reading material. So adventures started to be developed with reference manuals. Initially they were an adjunct; not meant to be used to run the adventure but as another method that DMs could use to read the story as if it were something close to a PDF. Using an extension created by a community developer older modules were revisited and reference manusl were added based on the story entries. The result wasn't as good as could be produced from scratch but they were more than passable.

Many early modules (at least for 5e) were created using an internal tool called par5e which took text files and converted them into xml files which FG could read. In many respects it was easier to create modules using this tool because it was a bit laborious typing all the text for, say, an NPC into FG. FG evolved again; an NPC importer was introduced; a table importer; copy/pasting text from one source to another preserved formatting; class specialisations became a separate window class as did subraces; it was now possible to create and link spell lists for specific classes within FG. It also became possible to combine player and DM layers in the same map. It therefore became much easier to create modules inside of FG and so there was shift away from the internal tool and modules started to be developed directly in FG. And since reference pages were much better looking than story entries the latter were dropped in favour of the former in the most recent modules.

Now, I'm using another internally developed tool to convert earlier modules into campaigns so that modules can be updated with more up to date image formats and prepare for forthcoming features.

So FG is always evolving; it's a completely different beast than it was 8 years ago when I started producing modules for the store.

Earlier modules did not split DM and player information all that well; but then player modules became the norm containing the player facing data such as classes; races etc. Over time more and more such books were produced and so more and more data became available. In order to cut down on duplication player facing material was dropped from the DM version of the books. However going back and removing such data from earlier modules isn't an option since any characters created using that data will break; and that will cause too many issues for too many people (not to mention a significant increase in support); and there is no easy solution to fixing those character other than recreating them. People who have been playing a character for years would be desperately unhappy if their character suddenly became unplayable.

So, in short, fantasy grounds evolves and improves. Whilst every effort is made to keep everything as uniform as possible sometimes it just isn't an option and indeed not even desirable.

I know the reasons why. My questions are on behalf of newcomers that aren't steeped in the lore and evolution of Fantasy Grounds. All products (of a specific ruleset) should be uniform and behave identically. Joe Smith, the hypothetical new FGU buyer, isn't going to understand why things are different between his 5E modules. He's going to wonder if something is wrong with some modules because his story entries are missing. He's going to wonder why layers on some images behave different than others. He doesn't want to dive through forums to find all the reasons why things change or look up the release dates of all the 5e products so he can figure out which modules use which methods. Instead, he's just going to go to roll20 or some other competitor where things operate identically across the board. Things need to behave consistently. That's a pillar of user interfaces: consistency. I want Joe Smith to have a good experience and stay.

[Morenu]

I know the reasons why. My questions are on behalf of newcomers that aren't steeped in the lore and evolution of Fantasy Grounds. All products (of a specific ruleset) should be uniform and behave identically. Joe Smith, the hypothetical new FGU buyer, isn't going to understand why things are different between his 5E modules. He's going to wonder if something is wrong with some modules because his story entries are missing. He's going to wonder why layers on some images behave different than others. He doesn't want to dive through forums to find all the reasons why things change or look up the release dates of all the 5e products so he can figure out which modules use which methods. Instead, he's just going to go to roll20 or some other competitor where things operate identically across the board. Things need to behave consistently. That's a pillar of user interfaces: consistency. I want Joe Smith to have a good experience and stay.

Its no different than many versions of older D&D. (think TSR days) modules had similarities within the same D&D Version and the same publisher but yet they were typically setup somewhat different and evolved every 6 months or so. things were tried and hopefully the good things were kept. but unless the modules were SO good that a reprint was called for with the intention of getting existing owners to buy the updated version (think temple of elemental evil), monetarily it makes no sense. Smiteworks is a small company. A rewrite would be a ton of work hours without any return on investment.

perhaps a labeling system like the LOS FG FGU type or even a "title or web" page explaining the version differences?

[Zacchaeus]

I know the reasons why. My questions are on behalf of newcomers that aren't steeped in the lore and evolution of Fantasy Grounds. All products (of a specific ruleset) should be uniform and behave identically. Joe Smith, the hypothetical new FGU buyer, isn't going to understand why things are different between his 5E modules. He's going to wonder if something is wrong with some modules because his story entries are missing. He's going to wonder why layers on some images behave different than others. He doesn't want to dive through forums to find all the reasons why things change or look up the release dates of all the 5e products so he can figure out which modules use which methods. Instead, he's just going to go to roll20 or some other competitor where things operate identically across the board. Things need to behave consistently. That's a pillar of user interfaces: consistency. I want Joe Smith to have a good experience and stay.

I’m interested in your solution then.

The original post in this thread is about changes the user would like to see; but your view seems to be that nothing should change and modules produced today should be the same as those produced 10 years ago and not take advantage of any new features added to FG. Am I being unfair in that assessment?

[Metlore]

I’m interested in your solution then.

The original post in this thread is about changes the user would like to see; but your view seems to be that nothing should change and modules produced today should be the same as those produced 10 years ago and not take advantage of any new features added to FG. Am I being unfair in that assessment?

Yes that is an unfair assessment. My view is quite the opposite: older modules of a specific ruleset (the current, popular ruleset) should be updated to function the same as newer releases.

5E is the current D&D edition. It has also already been stated by WOTC that all existing 5E adventure modules will not be redone for 5.5/One D&D. That means all 5E modules, including early releases, are going to continue to be popular for new FGU users. It doesn't make sense for these earlier modules to function differently because they are still very relevant among players and buyers. Since older modules are already being updated to support the new first person view, LOS, etc... Why not update them to all function consistently with new releases? Smiteworks has already been offering rewards to its user base to assist with these updates. I think this should be achievable at not a high cost to the company.

Two changes that would make a tremendous stride in this area:
1. Ensure all modules have a reference manual and then remove the separate story entries from older modules.
2. Remove player content from older modules that were the whole book so module information is consistent. (DM specific example: Loading the regular Xanathar's module contained both the DM and Player material. If I load a newer book, the player information will be missing because it is now only in the player version.)

Video game parallel:
World of Warcraft adds new features all the time. They also change the level cap, skills, standards, GUI, etc. It would be quite confusing for a player if their GUI, skills, map, etc changed based on the release date of the area they were playing in because it wasn't updated to match the new standard.


Now obviously when a full new edition comes out it doesn't make sense to keep updating the previous edition modules, but I think within the same edition, there should be uniformity. All 5E modules should behave the same. All 4E modules should behave the same. All 6E modules should behave the same. What we have now is 5E modules that all behave differently simply on the standard at the given time.

[Zacchaeus]

Two changes that would make a tremendous stride in this area:
1. Ensure all modules have a reference manual and then remove the separate story entries from older modules.
2. Remove player content from older modules that were the whole book so module information is consistent. (DM specific example: Loading the regular Xanathar's module contained both the DM and Player material. If I load a newer book, the player information will be missing because it is now only in the player version.)
.

But given that I explained above why that can’t be done; or at least it can’t be done without breaking existing ongoing campaigns isn’t that not going to make a lot more people angry and frustrated for no material gain?