Feedback Thread - D&D 5E (2024) Ruleset Updates

[rhagelstrom]

There isn't any documentation on this:

NPC Automation
Added "Summon" section to NPC sheets.
Setting spell Level/Attack/DC/Mod and Proficiency Bonus will adjust NPC stats when enabled.
New variables can be used in NPC action descriptions ([SLEVEL], [SATTACK], [SDC], [SMOD])

I haven't fired up test but I'm just reading code and trying to understand what you guys have done.
The second bullet it seems like what is in the code is related to summon not spell, or is this just verbiage? I don't know the new rule changes I don't have the book.
If summon and spell are two different things, maybe they aren't based on the intermixing on this change log, I'd suggest using SU instead of straight S as a prefix and here is why. It will conflict with BCE/G SDC, spell save DC, which is going to affect an entire grim press product line and cause everyone who is running Auras that isn't PF2 to change all their effects if BCE/G needs to yield to the conflict. Yes you don't cater to extensions but I'd argue the SDC tag is so prevalent with a lot of hardcore 5E FG fans it is going to leave a really bad taste in their mouth just for pets. Second I think S is more naturally thought of as a spell rather than summon so leaving S reserved for spell and SU for summons makes a lot of sense.

If spells and summons are now the same thing, BCE/G still conflicts but it should be expanded to PCs as well and just be done with it as it is desperatly needed and would be a great add. You can just have the code or if, because SW is so hyper-allergic to any 3rd party suggestions, I can tell you spots to do the work that has already been done.

I'd also suggest that instead of SLEVEL/SATTACK or SULEVEL/SUATTACK, it be SLVL/SULVL SATK/SUATK since ATK and LVL are already abbreviated in the effects and there is no good reason to mix.

All of this is an easy change now but after released is a nightmare.

Halfing luck, I don't know what 2024 says but 2014 it is a choice because of the word "may". I automate Halflng Luck in my game but I don't know if just blanket automating it is the right choice when it's not actually the rule. Maybe it is in 2024?

[Zacchaeus]

There isn't any documentation on this:

NPC Automation
Added "Summon" section to NPC sheets.
Setting spell Level/Attack/DC/Mod and Proficiency Bonus will adjust NPC stats when enabled.
New variables can be used in NPC action descriptions ([SLEVEL], [SATTACK], [SDC], [SMOD])

I haven't fired up test but I'm just reading code and trying to understand what you guys have done.
The second bullet it seems like what is in the code is related to summon not spell, or is this just verbiage? I don't know the new rule changes I don't have the book.
If summon and spell are two different things, maybe they aren't based on the intermixing on this change log, I'd suggest using SU instead of straight S as a prefix and here is why. It will conflict with BCE/G SDC, spell save DC, which is going to affect an entire grim press product line and cause everyone who is running Auras that isn't PF2 to change all their effects if BCE/G needs to yield to the conflict. Yes you don't cater to extensions but I'd argue the SDC tag is so prevalent with a lot of hardcore 5E FG fans it is going to leave a really bad taste in their mouth just for pets. Second I think S is more naturally thought of as a spell rather than summon so leaving S reserved for spell and SU for summons makes a lot of sense.

If spells and summons are now the same thing, BCE/G still conflicts but it should be expanded to PCs as well and just be done with it as it is desperatly needed and would be a great add. You can just have the code or if, because SW is so hyper-allergic to any 3rd party suggestions, I can tell you spots to do the work that has already been done.

I'd also suggest that instead of SLEVEL/SATTACK or SULEVEL/SUATTACK, it be SLVL/SULVL SATK/SUATK since ATK and LVL are already abbreviated in the effects and there is no good reason to mix.

All of this is an easy change now but after released is a nightmare.

Halfing luck, I don't know what 2024 says but 2014 it is a choice because of the word "may". I automate Halflng Luck in my game but I don't know if just blanket automating it is the right choice when it's not actually the rule. Maybe it is in 2024?

The referred to variables are for specifically created summoned NPCs; such NPCs are already in 5e (see Tasha's, and other recent books) and various things like their AC, attacks, spellcasting etc are tied to either the casters proficiency, spell attack modifier, level, or spell DC. The variables aren't effects as such but can be included in attack or other strings to signify the figures that should be used (For example Melee weapon attack: +[SATTACK] to hit. Hit: 1d8+3 +[SLEVEL] slashing damage). The figures themselves (that is spell level, spell attack, Spell DC, etc) can be added to the NPC in a new 'Summon' section of the NPC sheet.

[ddavison]

Yeah, there is a checkbox now to indicate that an NPC is a summoned creature. It's stats are then derived. See the example below from the PHB.

Summoned-NPC.jpg

[SilentRuin]

Here is a perfect example of being broken for "new naming". Previously I added generic actions subwindow and buttons to bottom of PC/NPC sheets. Previously all FGU code did this by columnanchor - but now they have changed all that to be based on a new template that invovles sub_content_top. Is there any clue to this? No - you have to see the error and then find it in the windiff listings (tons) and then go "now what?".

You then have to drill down into the actual template and figure out how can use this new anchor point without having to change all your internal references to the sheet by following them down their new rabbit hole of coding and renaming? Digging in and trial and erroring you find "contentanchor" is the new bottom of the sheets - or was always there and they never used it before - who knows as I followed them down their columnanchor definitions before.

Does any of this actually gain me anything besides breaking me for not bothering to try and preserve previous anchoring point naming? No it does not. Just wastes more of my time trying to keep my code working for changes that simply keep trying to make things "simpler" by disrupting all their previous "simpler" rules. I'm sure they will blow away this latest template fad as they have so often in the past.

THIS is why I'm frustrated. Changes for the sake of change. Anchor point servers no new "ability" or anything else. Just a new supposed shuffling of naming and functionality to make things easier.

Why is I have to insure I always play nice with other extensions by calling the original code on any overrides, insure I tack on to generically available anchor points, and all the other things to minimize my impact on others code - and SW simply does not bother?

If you don't need to change something - DO NOT. IF you want to change it to provide a more "simple" version PROVIDE legacy calls to keep previous things working.

I'm just starting digging into this so I'm sure I have lots more to find - and some things I simply won't find till they fail for someone. Things keep getting more and more complex for keeping extensions working and I have to assume for rulesets also.

Nutshell for other suffering my first discovery in TEST - if you used columnanchor to place things at bottom of page as SW did in the past - they tossed it out the airlock and used new templates which in the end use contentanchor. So replace columnanchor references with contentanchor and you might, might get lucky like I did on this first but likely not last of busted changes for what I consider unnecessary disruption of extension code.

[SilentRuin]

And I don't even know how to recover the actext anchor point reference that I used to attach to. I mean what is this logic here? The actext is still under some 2014 newly named thing - but I can't even fathom this if logic here. How am I supposed to attach to the previous anchor point "actext" in order to place my stuff?

actext_notfound.png

	<windowclass name="npc_combat">
		<script>
			function onInit()
				self.update();
			end
			function onVersionChanged()
				self.update();
			end
			function update()
				local nodeRecord = getDatabaseNode();
				local bIs2024 = (DB.getValue(nodeRecord, "version", "") == "2024");
				if bIs2024 then
					sub_content.setValue("npc_combat_2024", nodeRecord);
				else
					sub_content.setValue("npc_combat_2014", nodeRecord);
				end
				WindowManager.callSafeControlUpdate(self, "sub_content", bReadOnly);
			end
		</script>

I mean how to I reference actext here?

	<windowclass name="npc_combat_top_2014">
		<margins control="0,0,0,2" />
		<script file="campaign/scripts/npc_main_top.lua" />
		<sheetdata>
			<anchor_content_top />
			
			<sub_content_hidden_top name="sub_summary_fields">
				<class>npc_combat_summary_fields</class>
			</sub_content_hidden_top>
			<summary_content_column name="summary" />
			
			<line_content_top />
			
			<label_content_column name="ac_label">
				<static textres="armorclass" />
			</label_content_column>
			<number_content_column name="ac" />
			<string_content_column_remainder name="actext">
				<anchored to="ac" />
			</string_content_column_remainder>
...

I'm not even sure its the same place it used to be - I hope it is - but I'm at a loss to know what this does. It used to be defined directly under "npc_combat" but now this wierd scripting logic has it going to 2014 version no matter what.

[superteddy57]

The control would have to be placed within the npc_combat_top_2014 windowclass for it to display. You can do a merge="join" to add controls to an already established windowclass. Using the insertafter or insertbefore flags will load the control at that point. An example below.

	<windowclass name="npc_combat_top_2014" merge="join">
		<sheetdata>
			<templatename name="somecontrol" insertafter="actext" />
...

[SilentRuin]

What a shock that all parsePower calls or overrides are broken.

Previous code that is overriden and called in FGU 5E...

function parsePower(sPowerName, sPowerDesc, bPC, bMagic)

new call that breaks everything

function parsePower(tData)

I can't wait for an explanation on the pressing need to change arguments on something known to be used by 3rd parties. It must have been a truly pressing vital requirement of some kind - I'd like to know what it was and how to repair this to work.

[SilentRuin]

The control would have to be placed within the npc_combat_top_2014 windowclass for it to display. You can do a merge="join" to add controls to an already established windowclass. Using the insertafter or insertbefore flags will load the control at that point. An example below.

	<windowclass name="npc_combat_top_2014" merge="join">
		<sheetdata>
			<templatename name="somecontrol" insertafter="actext" />
...

And the highlighted if statement that essentially does the same thing in the if and the else? That was more concerning to me. As if I do what you suggest and that else suddenly changes - I'm burned again.

[superteddy57]

It checks the version of the NPC to display. The version cycler at the bottom of the NPC will change the contents of the subwindow and that windowclass is set based on that boolean.

npc_combat_top_2014 = 2014 rules
npc_combat_top_2024 = 2024 rules

[SilentRuin]

It checks the version of the NPC to display. The version cycler at the bottom of the NPC will change the contents of the subwindow and that windowclass is set based on that boolean.

npc_combat_top_2014 = 2014 rules
npc_combat_top_2024 = 2024 rules

That's the exact same result - why do an else if you plan to only have one result? See that's my worry - that you plan on burning me in the else later down the line if I do this.

local bIs2024 = (DB.getValue(nodeRecord, "version", "") == "2024");
				if bIs2024 then
					sub_content.setValue("npc_combat_2024", nodeRecord);
				else
					sub_content.setValue("npc_combat_2014", nodeRecord);
				end

Am missing something above? That looks like exact same result no matter what the boolean value is. And if you have it there - I suspect you plan to change it and burn me again - or else why have it at all?

Why check boolean at all? Now if you are saying its some unfathomable logic embedded in your cycler that requires it to have this written this way (I can't imagine what that could be) and it will not suddenly change

<windowclass name="npc_combat_top_2014" merge="join">

to some other name yet again - then fine I'll trust you and use this newly named windowclass.