Ruleset Automation

[LordEntrails]

There has been a fairly involved discussion regarding ruleset automation over in the 5E Bugs thread. It has been suggested that it be moved to a new thread. I've copied a little of the discussion below. Please continue the discussion here

No, the fact that things don't have effects attached has nothing to do with the way modules are constructed.

Included in the ruleset code is a parser which looks for certain words and phrases and then tries to create effects from that. So, for example, if the text of a spell or ability or whatever has the phrase 'and the target is paralyzed for 1 minute' then FG will recognise that phrase and create an effect of [Paralyzed][1 MIN] when that thing is dragged into the actions tab or if it's an NPC is put onto the Combat Tracker. This is true for pretty much everything, abilities, NPCs and spells.

Now this system generally works provided that the wording or phrases used are consistent. So, for example, in an NPC stat block the attack actions are almost always <type> Weapon Attack: +x to hit. Hit: ndn <type> damage. So FG can translate that into the necessary effects when the NPC is placed on the CT. Other examples include the skills choices for a class, saving throw types and damage from spells and many other things. All of these things generally are worded consistently. See the wiki here for more examples of what FG can pick out for NPCs specifically and this post for other things that FG can pick out of the wording used in backgrounds, classes and races.

A quick glance at magic items will tell you that there are a hundred ways that those are worded and each would need to have specific words looked for in order to create the effects. In the example we quoted earlier the Ring of Protection FG would need to interpret 'you get a +1 bonus to AC and saving throws whilst wearing this ring'. This is what I meant by automating everything given sufficient development time. This phrase and variations of this phrase would need to be programmed into FG so that the correct effect could be created - and only when the item is worn. You might find Celestian's extension here useful - you still need to create the effects yourself but it will apply the effect only if the item is equipped by the player.

I could be wrong here but I am pretty sure that FG doesn't look at the wording of items at all (apart from weapons and armour which are special cases); be they magic or otherwise simply because there is just too much uniqueness and variation in the wording to have any chance of creating proper effects.

As I said earlier the level of automation in 5e is unsurpassed although Celestian's 2e ruleset and Trenloe's Pathfinder 2 ruleset are very close rivals (and Starfinder is catching up too I think), but currently it is too much to ask that everything be automated given the hours that would need to be put into it in order to achieve that level.

Cool, that's all great info, and I'm glad this issue isn't limiting the automation. I agree that the language parsing and automation that does exist is spectacular, and is one of the biggest selling points of FG to me. Simply put, as HuseyinCinar said, it's disappointing that some of the coding that is clearly possible doesn't make it into the official product, but that is clearly a topic of conversation worthy of a thread of it's own, and I'll stop monopolizing this one . I just wanted to put in my 2c that I think the issue is worthy of discussion and further inspection. As much as I hate to be one of "those people" on the forums, I (and we all) want FG to be as incredibly awesome as possible. I think it's already great, FGU is going to make it amazing, and I can't wait to see what special projects are going on behind the scenes. The squeaky wheel gets the grease though, and I think this spot needs greasing . Despite the fact that I clearly don't know a whole lot about how the sausage gets made, I had noticed issues like this in the past and wanted to chime in that I thought it was worth fixing. If nothing else, I'll be happy to know that the next time it comes up, it will no longer be the case that "it's never been a problem before."

Thanks very much for your thoughtful responses! They are much appreciated.

[LordEntrails]

One point I wanted to add to the discussion of ruleset automation, and in particular adding phrases to the parser are the following 2 points that help to point out that automating a ruleset (in particular D&D 5E, but applies to any ruleset) is that adding more phrases to be parsed (such as for spell effects etc) has two major draw backs.

1) The more phrases that have to be parsed, the harder maintaining the code becomes. Things like conflicting phrases becomes a more challenging issue. Updates to the ruleset take longer, and therefore improvements to the software will come more slowly. In short, the more automation we have, the longer fixes and enhancements will take to roll out.

2) Performance. The more phrases that have to be parsed when a creature is added to the Combat Tracker, the longer it will take FG to parse and prepare the CT. I believe their are already reports in the Pathfinder Ruleset of measurable delays when a significant number of NPCs are added to the CT. As the software has to do more processing, the slower the software will become.

Neither of these are things that are hard lines. They are incremental costs that will be incurred as automation increases.

[celestian]

I've danced around this myself for a while. There are ways to make it a bit more user friendly (I find string parsing not very user friendly myself) but to do that you give up performance by adding various and many nested nodes in the data.

The more nodes you have the slower things load into the CT. It's one reason I had to re-write the DM side of the CT for the AD&D ruleset. Without the re-write the load times were very dramatic.

With the extra bits I was able to add new effects and automation features I wanted. All of the spells and bulk of the items have effects, attacks/powers pre-configured. I was also able to automate equipped items/effects and racial/class effects.

Outside of that there are some other things that can be automated. Improved AC versus ranged or melee. Flat ability score change. Mirror image, stoneskin and specific types of damage absorb/temp hps (tho I am not sure 5e has temp hp for something like fire).

What type of additional automation are you looking for?

[Trenloe]

The 5E ruleset does a lot with word parsing - which has a good success rate as WotC products generally use repeatable wording. For some of the base entries that don't work, there has been some hard coded automation in the base ruleset to carry out automation based on the name of the record.

For Pathfinder Second Edition we don't have the luxury of repeatable wording in most cases - feats, spells, class abilities. Some things (initial class data) is fairly repeatable and basic string parsing can be used, but it's rare.

So, for PFRPG2, I've started experimenting with an automation field in certain records. This is hidden by default, which can be changed through the campaign options. Some information on what I've done so far: https://www.fantasygrounds.com/wiki/...2_Experimental which basically allows for database fields in the PC charsheet to be directly modified/set - of use only for static DB fields, but it's a start. Release 12 tomorrow will add defense proficiency automation and a base special automation handler. I plan to expand these over time. The issue with this is that it adds a lot of time to creating DLC content - having to write and test the automation field for every ability/feat. And, as usual, it will probably be impossible to cover all possibilities. I doubt I'll ever do this for every single record in DLC, but will probably keep to common feats/abilities - where I go and how successful it will be remains to be seen...

[Moon Wizard]

The approach that Trenloe is taking is one of the things I've been keeping in my head for quite a while. Basically, you come up with a way to provide extra fields that allow you to automate attacks/damage/effects and more, and move away from trying to read the text. By allowing people to fill out those fields, it gives finer grained control, easier to maintain and less conflicts.

However, increasing the number of fields to be copied and instantiated actually increases the UI complexity and database overhead. This is the fine line that celestian has been walking, since his automation is arguably even more detailed than 5E. The cost is in the UI performance overhead and database node copying overhead. (Parsing some text in Lua is fairly tame in comparison for performance.) Thus, why celestian has been having to reconfigure UI (among other reasons).

If we had time to actually redo this (which we don't); I'd probably move to some sort of coding system similar to effects where you can have a single database field lay out all the "automation actions" for each power/spell/ability/attack. Then, we could build the fields dynamically as needed in the UI without even tying to the database. But, this is just a prototype concept that I've been bouncing around in my head, since we're so focused on FGU right now.

One of the challenges with changing anything (especially in 5E) is that you have to update the entire catalog of DLC to work with your changes. So, it's actually easier to change this assumption earlier in the ruleset coding process.

Cheers,
JPG

[esmdev]

I find the word parsing for 5E to be cool and fairly easy to read. The only real problem that I have with it is the lack of specifics on how to format the statement to get what result. I asked once, long ago if there was a list and the answer was basically no. I think it would do some good if there was a master list.

I resisted creating new entries in the NPC section for months because using the PC sheet was easier than trying to figure out exactly how to format special features and such. I've gotten better at it but I'm no master. I just last week figured out that I needed to have a separate entry for innate spellcasting in addition to spellcasting.

It would be nice if miscellaneous items could apply various effects. Like gauntlets of ogre power adjusting strength on equip and unequip.

Trenloe I like your setup but it, like effects, is arcane to the point it is a barrier to some. I think it is a solid direction but please give lots of examples of how to format stuff.

One thing that would also help 5E (and 2E and really every ruleset) is a stop before applying effect or damage in the CT like the one found in SWADE. It would help when people accidentally double roll damage, have feats that let them reroll damage on 1 or 2, accidentally stack sneak attack effects, etc. It wouldn't be a big deal if 5E didn't stop at 0 and recorded the full damage so you could reverse the damage and just apply but if you don't happen to know exactly how many hits something had when an accidental double roll takes place it's super hard to undo. That sort of feature would help with automating a lot of conditionals that show up here and there.

[Zacchaeus]

I find the word parsing for 5E to be cool and fairly easy to read. The only real problem that I have with it is the lack of specifics on how to format the statement to get what result. I asked once, long ago if there was a list and the answer was basically no. I think it would do some good if there was a master list.

For NPC's see here https://www.fantasygrounds.com/wiki/...ffects_on_NPCs
For classes, backgrounds, feats, and races see here https://www.fantasygrounds.com/forum...preted-strings
For other information on effects see here https://www.fantasygrounds.com/forum...-Videos-for-5E and here https://www.fantasygrounds.com/wiki/...php/5E_Effects

Also you can reverse damage by holding CTRL and dragging the damage from chat back onto the creature that took the damage.

[esmdev]

Thanks, I had figured most of it out from the wiki, but that section on class, race, background should really be in the wiki. That would make it much easier to find.

I will definitely try the control-drag. That will help a lot.

[Neovirtus]

Thanks for making the thread, LordEntrails.

Anyone who's unclear of what is being discussed can follow the link back to the original thread, but suffice to say we got into the weeds a little bit on why some items don't quite "work out of the box." Zacchaeus made some very illustrative posts about how the par5e parser and the limitations it has, which I won't mangle trying to simplify here for discussion. In the end though, I think I'm still unclear on exactly why the two cases we discussed are different: a suit of Mithril Plate Armor and a Ring of Protection.

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.

Alternatively, a Ring of Protection +1 is basically delivered in the module as an item, with the text copied from the module. It does nothing when equipped to a character without player/DM intervention. But this is not a limitation of the module creation process (as above) but rather the fact that item descriptions are not parsed for effects at all, and if they were (and the parser were "taught" how to read the most common effect phrasings) it would significantly increase the calculation load.

So... It is certainly a slippery slope of where to draw the line as far as expectations for parsing text. I try to view these things as a collaborator, and be understanding that there are technical limitations that prevent things from being perfect. And that if these things were included, developer time would increase, updates would come slower, things would likely cost more, etc. I get it.

But as a customer who prior to yesterday didn't understand how a module is made (and still has a rudimentary understanding at best!) it is frustrating when a simple magic item that's been around for decades isn't coded. My customer brain thinks: "I'm paying for module X, I paid for FG, the module should include everything in the physical book, coded for FG." To me that includes automation, as automation is part of FG... I know that might be unreasonable, but it is what it is. I still think FG is great in it's current form, but this is a point of pain for me. Whenever my current party in Curse of Strahd, or in a homebrew with items from the PHB and DMG (which I paid for), gets a parcel, there is then a 5 minute discussion of how to get it coded. It sucks. I think the bar should be higher for a published module/handbook. Please discuss.

[Trenloe]

Let's look at a little bit of FG history... Once upon a time, FG provided the tools for players and GMs to automate their characters and creatures up to the level that they wanted. It was up to them to apply the effects, data, etc. as their characters were created and evolved over time. Any Smiteworks provided data that was available (OGL or commercial) was pretty much informational (with the odd exception) and players and GMs had to set things up how they wanted - depending on the level of automation they were looking for.

Then, with the advent of D&D 5E (even before FG got the license) someone decided it would be cool to code for more automatic automation - helped by the repeatable text used by WotC. This was great and a lot of people use it and enjoy it, but there will always be exceptions and how these are handled is up for discussion. As a RPG product matures and brings out more material the number of these exceptions increases. Fantasy Grounds has, quite sensibly, gone for the 80/20 rule - trying to provide some level of automation for 80% of cases, the other 20% of cases need to be handled manually. In some RPG system, with non-repeatable data, even 80% is a big challenge (see PFRPG2, for example). This is a realistic approach as the 80/20 rule is usually reversed - i.e. to do the last 20% will take 80% of the work. If this final 20% was tackled, then there would be a lot of other things FG users are asking for that won't be done. Smiteworks is a small company - everything is a balancing act of effort vs. reward.

As an outsider to the background, code and FG development processes, would I want to see near 100% automation of abilities, feats, items etc. within FG? Yes, of course I would!

However, being an insider, and being realistic (that's what we need to be here, realistic), there has to be a line drawn somewhere as it is not commercially viable for Smiteworks to provide a very high level of automation. This is a niche, within a niche and even for D&D, which far outsells and is played more than any other RPG system on FG, spending 80% more time on 5E products (that have a lot of data needing automation) to provide a high level of automation is simply not financially viable. And trying to do the same for other FG, non 5E D&D products, would lead to the development of these products (done by community developers) to pretty much dry up.

Like I say, in a perfect world I'd love to see it, but I imagine most of us want Smiteworks to be successful and continue to get licenses for, and develop products for, all sorts of RPG systems - not just the massively popular one. So, like I say, there needs to be an accepted level. Sure, there will always be exceptions to these - like the couple of items mentioned above, maybe the ring of protection should be coded, and maybe mithril plate should be (just an example).

In the end, if it takes 5 mins for everyone to get FG setup the way they want it when they get a bunch of new items, is this such a big hassle? I'm sure to some it is. But for most, spending this time to save more than this time in future is worth it. And all of use like different levels of automation - there's been threads in the past asking "how much automation do you want" and the results were widely spread out, so what is hard coded for most, might not work for others. I agree that some automation would be simple enough (ring of protection, for example) - unless there's another item, or some ability, that affects the base effects of that item - then we have an exception that needs to be coded manually. And if just one thing needs to be coded manually, then we encounter this expectation of "I'm paying for module X, I paid for FG, the module should include everything in the physical book, coded for FG." I agree that there is this expectation there - and this maybe needs to be managed better.

It's good to see that various devs (both Smiteworks and community) are looking at options - a lot of these are in the conceptual or experimental stage and may change or may not go anywhere. Even with these, the 80/20 rule would be a good level to aim for, with improvements to options and application of effects being made within the rulesets themselves. Some of this I'm already developing in the PFRPG2 ruleset, and some of this is already available in the SWADE ruleset. With the stuff I'm working on I'm very conscious of runtime performance - PFRPG2 PCs are a lot more complex than SWADE ones, so I don't think I can use a similar approach. Which is why I'm looking at things like the experimental features I liked in a previous post. Arcane? - probably, but this is the most efficient I've thought of (for now) and maybe if it takes off I'll look into providing a more user friendly interface to create the base automation code...

It's good to have a discussion, and there will always be widely different expectations and desires across the board. That may result in some people being disappointed, and that's unavoidable. RPG systems continue to evolve and trying to keep a high level of automation with moving goalposts is impossible for a small company that has limited developer resources and that relies on many community developers. I think it's doing a great job so far. Is there room for improvement? Yes, there is - and many devs are looking at doing this. But all of us should keep that 80/20 rule in mind - because we're never going to get to 100%, not even 95% IMO...