PDA

View Full Version : 3.5E/PFRPG - Size Changes



SoxMax
January 5th, 2022, 16:49
In both 3.5 and Pathfinder when you change size the damage your weapons do changes as well. I've added a few effects that allow that to happen automatically.

Additionally the SIZE effect will change the space a token takes up on the grid, and optionally the amount of reach a creature has. The reach is the best estimation I can come up with but may be wrong at times for NPCs since there's not great info on if a creature is Long or Tall in then NPC block.

I've tested compatibility with some extensions, but obviously not all. Let me know if you run into any problems.

The extension is here in the Forge: https://forge.fantasygrounds.com/shop/items/437/view

The code for the extension can always be found here: https://github.com/SoxMax/FG-Size-Changes

Svandal
January 7th, 2022, 22:20
The size increase and decrease do also need to take into account CMB and CMD for pathfinder. Any attack and AC bonuses apply to CMB and CMD also. For enlarge person in pathfinder the whole effect in fantasy grounds is:
Enlarge Person;STR:2 size;DEX:-2 size;AC:-1 size;ATK:-1 size;CMB:2 size;CMD:1 size;SKILL:-4 size,stealth;SKILL:-2 size,fly

So this extension does not calculate the following correctly: (This is for pathfinder 1st edition no other extensions)
CMB
CMD
Skills fly and stealth you just have mixed the + and - (SIZE: 1 gives us a positive number instead of a negative in your extension)
Nice thing about the size and reach change, but if I wield a reach weapon (which I mostly do when playing characters with enlarge) the reach does not update correctly.
The size modified my weapon damage, but only for normal hits. A critical hit gives me my modified weapon damage + critical hit damage of the "normal" unmodified weapon.

This section is with other extenions enabeled:
And when I used it with my extensions the weapon damage dice did not change at all, but I have not tried to locate which extension causes the issue (I use Kels extension together with several of bmos, aura extension, height extension and better combat effects)

SoxMax
January 7th, 2022, 23:46
Thanks for the bug report, I'll get the skills and CMB/CMD sorted out.

For crits, that's gonna be trickier and I'm kicking myself I overlooked it.

As far as with other extensions, the lack of damage modification is a conflict with Kel's extension. I did submit a bugfix for that, but Kel may be waiting to release that along with his updates from the big ruleset changes back in December. In that case sorry, my extension probably isn't super useful until then since Kel's is invaluable.

SoxMax
January 8th, 2022, 01:14
Uploaded a 1.1.0 version which fixes the CMB/CMD and inverted skill bonuses. I realized I thought the CMB/CMD were being cancelled by the ATK/AC bonuses, but that's not the case. I'll hopefully have a fix for the Crit Damage by tomorrow.

SoxMax
January 8th, 2022, 01:33
Sorry turned out fixing the Crit Damage was easier than I thought. Should be all set now.

For reach I'm not quite sure what the best solution is, by default the ruleset doesn't display reach either. I'm not sure that's a good answer though. Would it make sense to double the reach in situations where a character has an equipped reach weapon? Even though that weapon may not be what they're actively using?

Svandal
January 8th, 2022, 07:06
Sorry turned out fixing the Crit Damage was easier than I thought. Should be all set now.

For reach I'm not quite sure what the best solution is, by default the ruleset doesn't display reach either. I'm not sure that's a good answer though. Would it make sense to double the reach in situations where a character has an equipped reach weapon? Even though that weapon may not be what they're actively using?

If the code dont have access to reach there are no good answers I think.
Personally I think it is best that the reach doubles if a character has reach weapon equipped, but others might disagree.

SoxMax
January 11th, 2022, 15:33
With Kel's major update to his Extended Automation extension there shouldn't be compatibility problems between my Size extension and his anymore.

Zarestia
January 11th, 2022, 19:36
Just tested your extension and came upon two issues:
- When dragging the effect "Enlarge Person; SIZE: 1 size, melee; STR: 2 size; DEX: -2 size" on a PC the shown reach & space in the CT entry change. The reach on the map changes. The token size does not change. You need to redrag the token from the CT to change the token size.
- When removing the effect, the CT entries of the space & reach stay at changed size and need to manually be changed back to normal.

SoxMax
January 11th, 2022, 22:22
Just pushed a new build which should fix the problems you were seeing @Zarestia

Zarestia
January 11th, 2022, 23:14
Just pushed a new build which should fix the problems you were seeing @Zarestia

Thank you!
The second point works now.

The PC token size still doesn't get changed when activating/dragging the effect. If you need more information let me know :)

Svandal
January 12th, 2022, 05:29
Thank you!
The second point works now.

The PC token size still doesn't get changed when activating/dragging the effect. If you need more information let me know :)

The token size changed for me. Are you talking about the token, the picture? That did not change, but the actual area (the green squares it occupied) that changes.

Zarestia
January 12th, 2022, 13:37
The token size changed for me. Are you talking about the token, the picture? That did not change, but the actual area (the green squares it occupied) that changes.

Maybe I expressed myself badly.


Grey hover over token = Reach - This works
Green area occupied by token = Space - This works
The token itself - This doesn't work (Only when redragging from CT. The reduction from Large -> Medium does work though when deleting the effect)


In the end we both the same, the token itself not adjusting to the new space when adding the effect.

SoxMax
January 12th, 2022, 14:00
Ahh, yea token sizes are not dynamic based on the space. I've uploaded a new version to the forge which should update the Token as well based on the Grid Scaling option you have set (80%, 100%, off).

Currently it will only trigger as part of my size changing code, but if people are interested I could make token scaling its own extension which triggers anytime the space for a token changes.

Also thanks again for all the testing and reporting you guys are doing, I know its painful when an extension doesn't work as expected.

Svandal
January 12th, 2022, 21:26
Sorry turned out fixing the Crit Damage was easier than I thought. Should be all set now.

For reach I'm not quite sure what the best solution is, by default the ruleset doesn't display reach either. I'm not sure that's a good answer though. Would it make sense to double the reach in situations where a character has an equipped reach weapon? Even though that weapon may not be what they're actively using?

Would it be an option to have an effect that doubles the reach of a creature? Like "DREACH". So if I have a reach weapon and enlarge my size I would do:
SIZE: 1; DREACH

Or some kind of modifier in the size effect, like:
SIZE: 1 reach

Great extension now that Kel has updated its code. The weapon damage increase is really really neat.

SoxMax
January 13th, 2022, 15:51
I released an update with a few things:

Update options to allow for only spacing to be updated
When calculating reach for players check if they have a Reach weapon, if so, double their reach
Fix an error that occurs when there is no token on a grid

albertinizao
January 22nd, 2022, 13:39
I don't know why, but the damage dice didn't change :/

SoxMax
January 22nd, 2022, 13:55
Were you using an old version of Kelrugem's Extended Automation extension?

SoxMax
January 23rd, 2022, 13:48
Pushed an update today which adds compatibility with the Effect Builder: https://forge.fantasygrounds.com/shop/items/457/view

Now if you have the Effect Builder and the 3.5/PFRPG plugin enabled the new SIZE effects added by this extension will appear in the Misc category.

Zygmunt Molotch
April 24th, 2022, 10:08
Hey SoxMax

I presume, without trying this has interactions with https://www.fantasygrounds.com/forums/showthread.php?72100-CoreRPG-Size-Matters ?

Just wondered before I jump down the rabbit hole...

MeAndUnique
April 24th, 2022, 17:55
In broad terms, Size Changes is specialized for D&D3.5e/PFRPG, and so has much more complex support for things that are affect by size in those rulesets. Size Matters is generalized for CoreRPG, with a couple of extra features that conditionally function in D&D5e.

SoxMax
April 25th, 2022, 03:16
MeAndUnique beat me to it :P

I also haven't tested what happens if you use the two together.

timberbeast
May 13th, 2022, 00:50
I created an effect for the Animal Growth spell (3.5e):

Animal Growth; IF: TYPE(animal); SIZE: 1, melee; STR: 8 size; CON: 4 size; DEX: -2 size; AC: 2; DR: 10 magic; SAVE: 4 resistance

It works fine, except when I try it on a Medium sized creature, then I get an error: Handler error: [string "scripts/size change space.lua"]:52 attempt to index field '?' (a nil value). Works fine on others (Diminutive, Small, Large, Huge are the ones I tried).The effect still seems to get applied, and the icon changes size correctly - it just throws that error.

I'm also running the Aura Effects, BCE, Effect Builder and Extended Automation extensions (they were all installed the same day, so all the latest versions). However, I turned off all the other extension and still get the error. Any thoughts?

Asgurgolas
May 13th, 2022, 20:07
what's the "melee" on size for?

timberbeast
May 13th, 2022, 20:10
I was following this example from the Forge page:

Enlarge Person; SIZE: 1 size, melee; STR: 2 size; DEX: -2 size

Edit: Did some testing, and as I suspected the melee variable means that the size bonus is only added to melee attacks and not ranged. Suppose I didn't need that since I don't know any animals with a ranged attack. Still, I took it out and tested and still get the error.

timberbeast
May 13th, 2022, 20:30
I was able to get rid of the error. Changed the IF to an IFT, so the final effect looks like this:

Animal Growth; IFT: TYPE(animal); SIZE: 1; STR: 8 size; CON: 4 size; DEX: -2 size; AC: 2; DR: 10 magic; SAVE: 4 resistance

Edit: Never mind, that didn't work either - now the effect doesn't get applied (it gets added to the animal's list of effects, but none of the effects get applied. I guess it has to be an IF to get applied.

MeAndUnique
May 13th, 2022, 22:18
I was able to get rid of the error. Changed the IF to an IFT, so the final effect looks like this:

Animal Growth; IFT: TYPE(animal); SIZE: 1; STR: 8 size; CON: 4 size; DEX: -2 size; AC: 2; DR: 10 magic; SAVE: 4 resistance

Edit: Never mind, that didn't work either - now the effect doesn't get applied (it gets added to the animal's list of effects, but none of the effects get applied. I guess it has to be an IF to get applied.

Yeah, IFT can loosely be thought of in terms of "When attacking or dealing damage, if the target is [conditional], do everything else in this effect", which is especially odd to conceptualize for SIZE effects. Note: There are other scenarios than attacking or dealing damage, those are just the most common and easiest to describe, though the same principle generally holds.

SoxMax
May 17th, 2022, 18:42
what's the "melee" on size for?

Melee & Ranged are to control if the size bonus affects melee damage, ranged damage, or both if not specified. Pathfinder has some very odd handling with enlarge/reduce person and their interaction with ranged damage.

SoxMax
May 17th, 2022, 18:47
I created an effect for the Animal Growth spell (3.5e):

Animal Growth; IF: TYPE(animal); SIZE: 1, melee; STR: 8 size; CON: 4 size; DEX: -2 size; AC: 2; DR: 10 magic; SAVE: 4 resistance

It works fine, except when I try it on a Medium sized creature, then I get an error: Handler error: [string "scripts/size change space.lua"]:52 attempt to index field '?' (a nil value). Works fine on others (Diminutive, Small, Large, Huge are the ones I tried).The effect still seems to get applied, and the icon changes size correctly - it just throws that error.

I'm also running the Aura Effects, BCE, Effect Builder and Extended Automation extensions (they were all installed the same day, so all the latest versions). However, I turned off all the other extension and still get the error. Any thoughts?

Sorry I meant to look at this over the weekend but ended up busy. I honestly didn't test SIZE with IF statements though as I think all size changes in 3.5/PFRPG are just applied, not conditional based on your target. There may be some Effective Size Changes which are conditional however. For Animal Growth I would just drop the IF: TYPE(animal); since by the spell description you cannot cast it on non-animals anyway, and as a GM just tell them if they try and cast on a person or other non-animal that its not a valid target.

That does give me an idea for an extension though where spells could have targeting criteria that is programmatically enforced by the ruleset. I think may target criteria in 3.5/PFRPG can get esoteric though.

Edit:
I got a chance to look into this and I think whatever you're running into might be creature specific. What monster are you trying to make bigger? I did some testing with wolves which are medium animals and it seems to work on my end. The bit of code that's throwing an error is where I check if the creature has a bonus to its CMD vs trip, which indicates that the creature has more than 2 legs allowing me to assume its a "long" rather than "tall" creature which as you saw is mostly only important for detecting Medium -> Large size changes

SoxMax
May 17th, 2022, 20:02
I think I found the problem, I forgot to test my leg detection code in 3.5 and it blows up against those kinds of creatures. I've added a flag to check for PFRPG before checking how many legs a creature has. This of course does mean that Long creature detection in 3.5 is worse but I don't see anything I can latch on to like CMD bonus vs trip in Pathfinder.

I'll push the release shortly. Expect to see the fix in version 1.5.3, and sorry about that.

I'd still recommend not using conditionals with sizes, especially IFT but I do have rudimentary support for them.

Arnagus
November 6th, 2022, 13:43
Hello SoxMax,

We were encountering a bug with your Size Changes extension when negative sizes (tiny = -2, or smaller) are applied. The token remains at 5 ft. size, but the health bar grows and the threatening range bumps up:
55024

This is caused by setting the actual token size to 0 in scripts/size_change_data.lua (which is well documented and explained in the comments):

-- 3.5/PF space occupied based on size, FG doesn't support sizes below 5, so set to 0
sizeSpace = {
[-4]=0,
[-3]=0,
[-2]=0,
[-1]=5,
[0]=5,
[1]=10,
[2]=15,
[3]=20,
[4]=30
}


While the comment is right (no support for tokens with a size below 5 ft., smaller creatures are placed with token size of 5 ft. as well) - a zero does not fix it. Interestingly, FGU does (in the meantime?) cope with sizes smaller than 5 ft. so I changed the sizes to the ones documented in the ruleset, see Big and Little Creatures in Combat (https://www.d20srd.org/srd/combat/movementPositionAndDistance.htm).

-- 3.5/PF space occupied based on size, FG now supports sizes below 5 - do not set to 0 anymore
sizeSpace = {
[-4]=0.5,
[-3]=1,
[-2]=2.5,
[-1]=5,
[0]=5,
[1]=10,
[2]=15,
[3]=20,
[4]=30
}

With this change, the token will remain 5 ft. size (like for all tiny and smaller creatures), but the health bar and threatening rage behave normally:
55027
Most important, the threat range remains 0 (following the rules) without further code changes required.
For comparison, a "normal" M sized token would threaten the adjusted boxes (like in the following example):
55026

Please test if there are any other side effects from my code change (which I might have missed) and update your code accordingly. Many thanks!

SoxMax
November 7th, 2022, 21:12
Hey thanks for the super detailed report and fix! I did some digging and it looks like the token drawing always defaults smaller spaces to the whatever the ruleset's 1 Unit space. So this change not only fixes a bug but makes it more ruleset accurate!


In the future also don't be afraid to open a pull request directly for your fix so you can flex on others with your contribution :p

EndingPop
January 16th, 2023, 03:26
Hi there! This is great and super helpful for my PF1e group. Would it be possible to add the REACH and ADDREACH parameters that the Size Matters extension has? I'm wary about installing both since they share effect syntax.

SoxMax
January 16th, 2023, 12:59
Oh right, I had intended to add reach effects and completely forgot about it. I should have some time this week to get to it.

EndingPop
January 17th, 2023, 13:02
That is amazing! Thank you for being so responsive.

SoxMax
January 21st, 2023, 22:51
I've added `REACH` and `SREACH` effects.

REACH: n
Change reach by n

SREACH: n
Sets reach to n. The largest takes precedence, other reach effects are ignored.

Dark_Soul
August 13th, 2023, 00:33
Space and Reach changes were incorrect for me when using a SIZE: 1 size effect on a large creature with space and reach 10. Changed both values to 5. Using a lot of extensions, including Kelrugem's Advanced Automation but I have a game in a couple hours so I don't have time to extensively test interactions. I'll update when I get a chance to toggle the extensions.

SoxMax
August 13th, 2023, 16:30
Hrm, I don't think there's much that should interact with the size and reach calculations. Is the monster you were using the effect on a standard monster I could test against?

EndingPop
October 8th, 2023, 21:42
Correct me if I'm wrong, but I think we technically need a way to increase the damage die by one step separate from increasing the effective size. Per this FAQ (https://paizo.com/paizo/faq/v5748nruor1fm#v5748eaic9t3f) a +1 size increase will make the damage die increase by 2 steps on the table. However, there's at least one situation I've found where a spell doesn't increase the effective size by 1 step, but just the damage die by 1 step (kind of a 1/2 effective size increase). Animal Aspect (https://www.d20pfsrd.com/magic/all-spells/a/animal-aspect/), gorilla. The spell in FGU is incorrectly using the ESIZE option when it needs to use the 1 step on the damage die table. In the follow up FAQ (https://paizo.com/paizo/faq/v5748nruor1fm#v5748eaic9t5u), it says these two things shouldn't stack either, but I don't know if there's a simple way to manage that.

SoxMax
October 9th, 2023, 00:13
Of course there's a spell that specifically interacts with damage progression and not size. The best fix for this is probably to a a new effect for capturing “your damage die type increases by one step”. I can ensure this extension then takes the largest effective dice increase between ESIZE and this new effect.

Maybe the new effect could be called DMGPROG.

rmilmine
November 14th, 2023, 00:11
I have two campaigns that have differing results to the use of this extension. One when SIZE: 1 size, melee is applied the icon changes in size/space as does the reach. In another campaign it doesn't. In the one that doesn't I removed all the extensions but this one and it still isn't changing the icon or the reach. I'm at a loss as to why this is.

rmilmine
November 14th, 2023, 01:53
Never mind. I found the switch for it. Not sure how it was turned on in one campaign and not in the other.

Morenu
January 27th, 2024, 00:10
There are 2 size extensions that have some overlap but both have things I would like to use.

Size Matters (https://forge.fantasygrounds.com/shop/items/455/view) & 3.5E & Pathfinder Size Changes (https://forge.fantasygrounds.com/shop/items/437/view)

when both are used with no other extensions, it throws the following error: 59766

I am posting this in both extensions' forums. I was hoping both authors might be able to make them play nice together.

Thanks!

SoxMax
January 27th, 2024, 18:47
It looks like the issue is a collision in script namespaces. Out of curiosity what features from Size Matters are you missing? I can probably just add those to 3.5/Pathfinder Size Changes.

Morenu
January 27th, 2024, 23:19
It looks like the issue is a collision in script namespaces. Out of curiosity what features from Size Matters are you missing? I can probably just add those to 3.5/Pathfinder Size Changes.

hmm.. comparing them now and I guess nothing, I thought there was something it added that yours did not. looks like I was wrong. so yours it is..