Ruleset Automation

[Zacchaeus]

An item of Mithril Plate armor, or really any other variant-type item is simply reskinned by the parsing process, so you get Plate armor that's called Mithril Plate, and a note that it shouldn't cause disadvantage on stealth checks. In order for a different, "correct" Mithril Plate item to be included in a module, there would have to be a separate, Plate armor base item that had that correct property built into it. I guess Mithril plate isn't in the SRD so it can't be the "base item"? I'm still confused by this, but I take Zacchaeus at face value that this is the way it must be.

The images below might help in explaining the idea of templates. Although I'm using the Forge this illustrates exactly how magic items are par5ed.

In the first image the left hand item is the magic item template. As you can see all it has is some text, a value and the rarity as well as some information on the type of armour that the template can be applied to. Next to it is the standard Plate armour from the PHB. You can see that it has all of the properties of the armour according to the table of Amours in the PHB. At the bottom is the combination of the Template and the Plate Armour item and as you can see it has the combined properties of both the template and the mundane item.

The second image is basically the same except that I have created a new Plate Armour called Plate (M), which strips out the disadvantage on stealth and the strength requirement and then combined this with the same magic item template.

So, Mithral armour can be made with the correct properties either in par5e on within FG but it requires the creation of a new mundane armour type in order to do so.

[esmdev]

As I am the person who started the initial conversation about the Mithral Chain Armor in the bug forum, I'd like to add my thoughts.

My current position on the subject is that modules should be C L E A R in the pre-sale and in the module itself that some magical items will require the DM to make adjustments and that some magical items will require active player/DM intervention during play. Some class, race and background features also require intervention to make work without using modules from a third-party website.

While you know, and I know, and most people who've been on the forums for awhile know, that FG isn't a fully automated one-stop does everything new people, or people who don't do forums, might find this difficult to fathom (as some of my players turning DMs that don't read the forums often have problems with).

My original point with the Mithral Chain Armor was that it is part of the module which is released with the D&D Essentials Kit and that the D&D Essentials Kit is aimed at the beginner to D&D. Since it is aimed at the beginner my thinking was that everything possible within the module should function as it is intended in the module. Obviously with the current system this is hard at best and in some cases totally impossible. Still, my feeling was whatever could be done should be done.

Once I decided that the system wasn't really going to work to accomplish that objective, I suggested that something be put in place within the module itself to explain the situation, the limitations, and how to correct them. Maybe even an early story listing of the magical items contained within the module and which function correctly, which need to be edited, and which will never work. That gives the DM an understanding of what is going on out the gate.

One solid change would be...

In the DMG you say: * Optional Game Rules are described but not implemented within Fantasy Grounds. They may require manual implementation
It should say: Some class features, spells, magic items and all optional game rules are described but not implemented within Fantasy Grounds. They may require manual implementation

This should also be added to all of the for-sale systems, modules and supplements to which it is applicable.

[Neovirtus]

That all is VERY reasonable, especially the 80/20 logic. And the fact that not everyone wants/needs that level of automation.

Regarding the "Smiteworks is a small company" line of conversation... it's just strange to me. I would like to point out that many of these effects have already been coded. Third party people sell effects packages for spells, magic items, etc. for associated official modules... which is great I guess? I could go buy them if it were worth it to me. But I do take issue with the idea that it's an unreasonable burden to want (much less expect) Smiteworks to provide the integration for a paid module they produce to work with the software they develop? Especially when someone else goes and sells that integration for $5 on a third party site? I know that's a gross simplification of the issue, but that's the way it looks from the outside.

In the end I get the effort vs. reward logic from a development standpoint. FG is a great product and I will happily continue to use it in its current form and further evolutions. I have no doubt that the development team works very hard and many community developers contribute a lot to the functionality of the software and I do appreciate that. I've personally paid to have the privilege to beta test FGU; I believe in the product. But do I wish that 80% included a bit more? Absolutely.

[Zacchaeus]

That all is VERY reasonable, especially the 80/20 logic. And the fact that not everyone wants/needs that level of automation.

Regarding the "Smiteworks is a small company" line of conversation... it's just strange to me. I would like to point out that many of these effects have already been coded. Third party people sell effects packages for spells, magic items, etc. for associated official modules... which is great I guess? I could go buy them if it were worth it to me. But I do take issue with the idea that it's an unreasonable burden to want (much less expect) Smiteworks to provide the integration for a paid module they produce to work with the software they develop? Especially when someone else goes and sells that integration for $5 on a third party site? I know that's a gross simplification of the issue, but that's the way it looks from the outside.

In the end I get the effort vs. reward logic from a development standpoint. FG is a great product and I will happily continue to use it in its current form and further evolutions. I have no doubt that the development team works very hard and many community developers contribute a lot to the functionality of the software and I do appreciate that. I've personally paid to have the privilege to beta test FGU; I believe in the product. But do I wish that 80% included a bit more? Absolutely.

The third party packages aren't 'coded' as such. The effects are created in a PC actions tab and then dragged to the spells window and exported. They exist only in a module; not within the ruleset itself.

From the posts by Celestian, Trenloe and Mood Wizard (who know more about this than anyone else) including all of that stuff in the ruleset would bog it down to a crawl. At least as the ruleset is currently designed. As Celestian pointed out he had to re-write large parts of his code in order to avoid this; and Trenloe is taking a different approach as well. Both of those authors have in a way the luxury of having a new ruleset to work on rather than an existing one (although the 2e ruleset is based on 5e). So, again, it kinda comes down to development time (it seems to me at any rate). Moon Wizard has been extremely busy with Unity for several years now, and if that hadn't been the case perhaps the 5e ruleset would have been re-written to include more stuff.

Moon Wizard also makes a very valid point as well. A major re-write of the ruleset impacts on the DLC; and that is done mainly by community developers who may not have the time (or possibly the inclination) to re-write the modules.

[LordEntrails]

A possible solution on the mithril armor issue itself is not to create a new template item, but to allow the forge to merge negative properties from the secondary objects. So that when you add Mithral to ppl late armor, the Mithral item has a negative value for stealth disadvantage and therefore removes stealth Dis from the plate template.

Of course, this would require a re write of the forge and the content...

Edit: wishlist item
https://fg2app.idea.informer.com/proj/fg2app?ia=130918

[Neovirtus]

The third party packages aren't 'coded' as such. The effects are created in a PC actions tab and then dragged to the spells window and exported. They exist only in a module; not within the ruleset itself.

So the problem is the method of distribution? Effects can be distributed in "player" modules but not in Official Modules? Or in Spells but not Items? I don't get it.

I think I'm going to stop beating this dead horse and just summarize my position and move on. This started with the Mithril Armor issue, simply as: The item in the module doesn't work as it should, because of the way the coding has to work for distribution of the module (roughly summarized). Fine. My thought was, that shouldn't be the case. And at the same time while we're making items work as intended directly from the module; It would be nice if a simple magical item, with a purely mechanical effect, would have that effect built into it in some way, or at least provided to the player. This could take a number of forms...

All the way from:
1)Full ruleset integration. You equip the item, it applies the necessary effect. Sounds impossible. Ok, moving on.
2)Halfway integration. The item doesn't apply the effect, but it's provided. Either in the item description or elsewhere. Third party software seems to do this in one form or another, seems more reasonable.
3)No integration. The module provides the text of what the item does, but it does not interact with the software in any way.

Currently we are all over this map. Armor +1 is at #1. Ring of protection is at #3. I'd like to see the standard be at least #2, in whatever way it's possible.

Thanks for all the great discussion on the topic, hopefully we get more people's thoughts on the issue over time.

[damned]

I would like there to be some way for FG to indicate to the GM/user - even if its a check mark or text line - that tells us that the particular item/spell/rule needs to be handled manually.

[Zacchaeus]

So the problem is the method of distribution? Effects can be distributed in "player" modules but not in Official Modules? Or in Spells but not Items? I don't get it.

No, Rob2e's packages are created modules. In order to include every effect in the ruleset would require extensive work on the ruleset and as noted above slow it down to a crawl. Effects are provided by the ruleset in order to allow the user to do what the Rob2e packages do. All he's doing is using the ruleset to create the effects, and catering for people who have no interest in creating the effects themselves.

[dulux-oz]

Late to this thread (sorry - that's what I get for being asleep when everyone(?) else is awake)

Serious questions to Moon and my fellow Devs: there seems to be two constraints on "automation" - either complexity of (parse) data, leading to longer load times, etc, or complexity of data-structure, leading to larger "databases" (if you're generous with calling a flat-file a database) and thus longer load times, etc.

From a CompSci POV, the solutions to each of these problems (when constrained by "reasonable" commercial limits) is to reduce the size of your flat-file-DB, hence a lot of operations moving away from an XML-based flat-file to something like JSON or YAML; or moving the flat-file to a true DB-System (like MariaDB/MySQL, etc).

OK, so, what are the downs-de of each of these approaches? Well, XML-to-JSON (or YAML) converters are relatively easy to write, so doing the conversions moving forward is (relativitly) not too difficult, and during the transition it wouldn't be too hard for FGU (with its larger memory store) to be able to read both formats. Trouble is, it still means you have to load *ALL* of the data into memory.

The other approach (using a "proper" DB) means more complexity in set-up (you need to include the DB-Engine), but arguments about "more tech-support calls", while once valid a few years ago, have generally disappeared with the modern iteration of "in-app" or "on-CD" versions of modern DB-Engines. The benefit of using a proper DB is that, while the base memory load is slightkly higher, you're not loading all of the data at once, hence the system should run faster overall. The downside, of course, is that its a lot more work to get an XML-DB translater (although it can and has been done). And again, during transition FGU could use both methods.

In fact, if its done correctly, gently, and with careful planning, the end users would never know the difference - only the FG Coders and the Community Devs.

So, a (potentially) radical set of ideas; what do SW and my fellow Devs think - discuss.

Cheers

[Trenloe]

I would like there to be some way for FG to indicate to the GM/user - even if its a check mark or text line - that tells us that the particular item/spell/rule needs to be handled manually.

Or maybe the other way around - indicating that automation *will* be applied?