Yep, looks like that fixed it. Thank you!
Printable View
Yep, looks like that fixed it. Thank you!
Hi there! I seem to be having issues with my SF2e Aura. I have been using them for a while and just last night the Aura we had set up for our Envoy won't work. I've tried using other wording for Get'Em in case the ' was causing an issue, but it's not working still.
The aura is working. When an ally is in it, they all get the proper effect, but on the combat tracker, the additional atk and dmg bonus are not showing up. I'm 90% certain the syntax is correct.
It looks like the Aura extension is working like it is supposed to. (i.e. applying the all the tags after AURA to the other allies)
I can't see from your picture whether the target of the attack (Unidentified 7) has the "Get'Em" effect on them; which would be required to trigger the bonuses.
Also, I tried this on PF2 ruleset using "IFT: CUSTOM(Get'Em); ATK: 1 status" effect on an attacker and "Get'Em" effect on a defender; and it was working.
Make sure no other extensions are enabled as well.
Regards,
JPG
Yes, the creature has Get'Em. I removed all extensions and retried. Re-typed in all of the syntax as well. It is not working on PeopleSkills, but because Get'Em adds the ATK 1 Status to Scritch as a secondary line, it works for him. Not sure if this is a SF2e issue. I'll test it on my Pathfinder as well and see.
If you can make a copy of campaign, and start removing pieces; you may find where the issue is. (i.e. remove all but ally granting aura, creature attacking and creature defending from the combat tracker; remove all other effects other than the Get'Em aura and Get'Em custom; etc.)
Regards,
JPG
Moon Wizard, so SR said he submitted an update to AURAs. Which I'm testing his version and it's just not right.
Major issue is that it's not detecting the edge of a creature enter the affected areas.
Now in 5E default, you have soon as a creature enters the area, lets take a cube, it should be affected.
I understand that maybe there is limits on which this can be and not start exactly when 1% of the creature is in the area. But at least it should be when the creature is at least 1/2 of a grid square in it. It shouldn't need to fully be in that grid square to be affected.
Next issue is that with the removal of the options for AURAs (not sure when this was removed but we used to have 2 options for AURAs), we no longer can set how we like AURA (AOEs) to be detected on a diagonal.
I would say most people play 5E with the default setting of 1x. However, I would also say most people do not use 1x for circles, spheres. They use 1.5 or maybe even RAW. So in a since most people do not have fireballs doing damage in cubes. They have them doing damage in a 20 radius sphere, even though the 1x default would say that can't be, it would need to be a 40ft cube.
So I think this option should be put back in if you can.
I'm not sure where else to post this, or how to go about it to bring up the topic. As this ext is not controlled by anyone well right now. I'm not sure where to bring it up.
I have no idea either; because I don't have any knowledge of the "measurement" code that SR provided. It's very dense; so not something I feel comfortable messing with.
If I were to handle this, I would pare this back to a simpler set of options, which is probably not what you want.
So, I suggest working with SR to have him adjust his code to make that all work how you want.
Regards,
JPG
After testing SR's version, he gave me of what he was planning to deliver, it is very close to the rules but not exact, it does still effect a few targets on corners that it should not.
If you want the Aura's to work with the exact templates laid out in the 2024 5e DMG then Aura's simply needs to use the method of 1.5x for diagonals and it works perfectly according to the templates.
I think SR is now using the targeting arrow logic to determine if something is within range, that is why we get different results based on what the GM has set for diagonal distance.
While the current delivery may be the best compromise at the moment, a long term solution would be to give the GM a toggle option to set how they want diagonals counted within Aura's if possible but this may be coding that SR doesn't feel like he needs to do to make his game work the way he wants it to.
I think the templates were in 2014. In 2024 DMG the only discussion of AoE is:Quote:
Originally Posted by bwatford
Areas of Effect
p44
An area of effect must be translated onto squares or hexes to determine which potential targets are in the area. If the area has a point of origin, choose an intersection of squares or hexes to be the point of origin, then follow its rules as normal. If an area of effect covers at least half a square or hex, the entire square or hex is affected.
The PHB has each shape in the glossary but mainly is telling you the point of origin and how to draw it.
Sphere [Area of Effect]
PHB'24
p374
Core Rule
A Sphere is an area of effect that extends in straight lines from a point of origin outward in all directions. The effect that creates a Sphere specifies the distance it extends as the radius of the Sphere.
A Sphere's point of origin is included in the Sphere's area of effect.
I agree it would align if the diagonal distance is 1.5x.
@bwatford, (and/or those asking for a separate aura diagonals option)
I'm curious, Why should diagonals within auras be counted different than diagonals for movement/targeting? Shouldn't they be treated the same for consistency?
(i.e. If I run 20' away from a creature with a 20' aura (based on the rules for movement, then I should always be outside the aura (assuming I wasn't standing on top of the creature with the aura).)
EDIT: I "think" the reason that SR chose targeting arrow distance is because I told him that the targeting arrow measures the center of the closest grid squares of two different tokens to determine targeting distance, which should technically measure whether a creature should be affected by an aura (base on the distance settings defined in the campaign/ruleset).
EDIT 2: Note that the targeting distance solution only works if you tell API to measure distance between tokens, not measure distance between two points (i.e. token center points).
Thanks,
JPG