This is a change the author and Moonwizard made. You now need to add a second affect if you want the bearer to have the effect also.
Printable View
This is a change the author and Moonwizard made. You now need to add a second affect if you want the bearer to have the effect also.
I'll look at seeing if I can get auto-apply to work. As far as I could tell, it didn't apply when I helped migrate the original code.
Also, I'm going to look at adding a "self" descriptor for AURA to auto-apply aura to self as well as any other targets.
Regards,
JPG
Try with !allyQuote:
Originally Posted by Romanus
Just pushed new version of Aura Effects.
- Effects will now consider the actor originating the aura again; so if you want all allies, but not the originator, use "AURA: ally,!self"
- Effects will now apply automatically when added to a token, instead of requiring "jiggle" to apply the actual aura.
Regards,
JPG
SAVEA and DMGA (immediate die rolls) are not being applied still. Aura effects are correct on what is placed on things that are with aura - just not being applied in case of immediate effects.Quote:
Originally Posted by Moon Wizard
Thank you!Quote:
Originally Posted by Moon Wizard
That's not technically Auras, but an interaction with BCEG that will have to be tracked down separately. My focus was on getting Auras to apply on effect add.
Regards,
JPG
Couple of questions... Is there a doc or place/repository most standard auro effects coding can be found? Is there an updated video on how to implement auras and their effects? Never got around to learning this but I think it's time for me to do so now. Thank you in advance for your time
Quote:
Originally Posted by SmackDaddy
This is the best info you got.
Also there is a video there a little.
FG Forge - View Item
Just pushed a new version of Auras that should handle application of initial auras for "single" aura types.
Regards,
JPG
SAVEA and DMGA are the only two things I know of that should execute immediately on a drop within range of something - however this seems to roll all the SAVES type of things also. I sent you a DM in discord with details.Quote:
Originally Posted by Moon Wizard
Since you are talking about BCEG.Quote:
Originally Posted by SilentRuin
DMGA
REGENA
SAVEA
TREGENA
Are all processed in the same way DMGA and SAVEA do.
Was wrong on the SAVES being processed. It was the SAVEA being processed twice - the 2nd should not be happening for the actual Moonbeam NPC which has an Object named effect. Works when manually dropping the NPC onto the map in range of something with aura. Fails with GAL. Only diff is programmatically creating NPC on top of dire wolf instead of manually dropping it on him from CT.
The IF: !CUSTOM(Object) should have stopped that from processing SAVEA on moonbeam NPC - it for sure did when I dropped it manually.
Is the same code not processing this stuff? (as in drag from CT and drop vs creating the NPC literally in that spot through code?)
I guess I can test by putting the new !self in there.
That would at least prove its not processing the IF on the SAVEA for some reason.
Yep - that is it. Adding the !self prevents it from rolling the SAVEA for the moonbeam NPC. Which implies any IF logic after the AURA but before the SAVEA is being ignored. When the NPC with that moonbeam effect I gave you in DM discord is programmatically created instead of drag dropped from CT.
Unfortunately, that video doesn't exist any longer: "This video isn't available anymore"Quote:
Originally Posted by MrDDT
Another aura effect bug in the new rewritten world of effects. When a CT entry's aura effect is deleted - and it was applying to itself - all other affected CT entries will be removed for their effects but not the local CT entry where it had it applied to itself.
Responded to you in Discord. Not seeing this with just Auras loaded; sent you a video.
Regards,
JPG
Hello there.
I think something is wrong with your recent change to how self-auras work, or I'm missing something obvious here...
In a test 5e campaign with only the Auras extension added, if I add: "AURA: 10; Paladin Effect; SAVE: 10;" to a character, it adds the Paladin Effect to the source of the aura as well. Which, seem to be intended. And when the DM rolls, as expected they get a +10 bonus to the saving throw.
However, when a player makes the roll, it's applying the effect twice for a +20 bonus to the save.
Or, if I add !self to the aura, then the DM rolls, they don't get any bonus as expected. But when the player rolls, they still get a +10 bonus.
Basically, it looks like the effect of the aura is properly blocked for the DM, but not the player.
I'll take a look. Do you have any other extensions running?
Regards,
JPG
Nope, this was tested with just the Auras extension.
Top roll was the GM rolling, bottom roll was the player rolling.
Attachment 67553
@jimlad42,
I just pushed an update that fixed this issue in my local multiplayer testing. Can you please run a new Check for Updates, and try again?
Regards,
JPG
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
Also, just so there are no surprises.
Until there is consensus between all of you (including SR) about how the Auras should work; I'm not planning to integrate any further changes to Auras except what is in Live. Basically, I don't want to be the judge for this whole debate; but I also don't want to let a single person drive this without owning the extension 100%.
As I alluded to above, if/when we do something official with Auras, it will be something that works in 95+% of scenarios using official, consistent rules with little to no options.
Regards,
JPG
Not directly about diagonals but an issue around how Auras work. Adding for context:
In the case of S1 and S2, in the current AURAs ext, these do not trigger the effect but it could be argued they should based on 5.5e rules.
In S3, the aura triggers in the current version of the AURAs ext.
@nephranka,
I'm sure I tested that scenario originally; but might have gotten lost in integrating SR code or I never checked Large+ creatures.
At any rate, I've rewritten the sphere aura handling logic to be vastly simpler; and provided the code to SR as well.
The latest is in the FG Forge now.
Regards,
JPG
The new version is better but it requires like in the S1 to be a full grid covered to trigger. I believe it should have fired at the halfway mark (S2).Quote:
Originally Posted by Moon Wizard
That is correct; and how the rules work.
The "distance" measure between two tokens is used to determine if a creature is "within" an aura (i.e. they are X distance away, so within X distance aura.).
The desire to have some sort of "touching" option is not part of the official rules.
Is that what the whole discussion with SR has been about? Wanting a "touching aura" option?
Regards,
JPG
I get that. S2 is a half grid covered and not touching case. I assume if half a grid is covered then it should trigger and it does not. Unless I misunderstand the touching case.Quote:
Originally Posted by Moon Wizard
Areas of Effect
DMG
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.
I'm pretty frustrated with the conflicting "what is wanted" that seems to change on the fly from my perspective. I've spent WAY to much time on this so I'm going to just go on finishing up my "touching" AURA targeting as I've already completed it on the AdvantagesPA.ext for pointer shape selections. Both AURA and PA were doing center point target interceptions and I won't get into the "blocky" world argument where diagonals determine what is really in or out of things like circles. I was on one side of the argument then convinced to implement the "touching" targets then everyone seemed to switch sides again. I'm confused and frustrated. So...Quote:
Originally Posted by Moon Wizard
Unless you guys want my version to add options into or not I'm going my own way with my own version. Here is what "touching" intercepts look like - the left huge critter intercepts to an aura are on the left with red blocks showing why they triggered - and the right side is a pointer shape example (the worst and hardest one) with the red block showing why it was triggered. Anyway going to just see if I can't debug out some of the things that have bugged me with aura filtering of when to process something for years and see if I can resolve it without any lag hits. [This image campaign was done with grid lock on and 1x diagonal like crazy people do - I play grid lock off and raw like the sane ;) I want my distances to make sense not blocky weird distances. ]
https://www.fantasygrounds.com/forum...0&d=1780520424
@nephranka,
Are you using "Raw" distance option? I noticed the "15.1'" distance in your picture.
I think rounding will be an issue in raw; so may need to add a small error range to the range check in Auras if set measure distance set to Raw.
Regards,
JPG
My understanding is that the current FG targeting figures are based on this.
Center of source's edge grid space to center of targets edge grid space.
So if there are 3 grids between edges of creatures spaces. It should list as 20ft away. If there is 10 grid squares between creatures, it should be 55ft away from each other.
This always adds a 2.5ft buffer (assuming grids are 5ft) between the 2.
Using RAW it's the same concept only rounding is different for final output, and diagonal calcs.
If you use 1.5x this would just change diagonal calcs of the "center of a grid space" and distance "between"
So final output is always
1/2 a gridspace based on setting of diagonal calc to the center of that space from target. We will call that (SourceDist)
1/2 a gridspace based on setting of diagonal calc to the center of that space from the source. We will call that (TargetDist)
Distanced between edges of creatures based on settings of diagonal calcs from source to target. We will call that (Between)
Output is : SourceDist + TargetDist + Between = Distance.
The problem with AURA is that SourceDist, should be the exact edge of the source creature not SourceDist, when using POINT, it should be centered on the center of the space. Or you could say 1/2 SourceSpace.
Using the FG normal distance calc should not be used for AOEs or AURAs. Because it's adding in the extra SourceDist, plus it's not triggering on the edge of TargetSpace.
This would also be a problem for anyone wanting to use a normal looking distance for circles/spheres even when using a 1x (default 5E) grid distances as we all know going at a diagonal will then make Fireballs into CubeBalls.
So having an option for people (which in my opinion is the way most people play) is to use a more visual AURA/AOE calc for circles/spheres where its based on the 1.5x or RAW (RAW likely best) to trigger if something is in the area or not.
If you need more pictures or something to explain this I can, but I think I've explained it well.
Questions are
1) How can we make this happen without lagging the system.
2) What are the options
3) What is really going to be played in what options.
Personally, I think there should be a distance option outside of the "house rules" distance option just for AOEs/Auras. This allows people to play with Cubeballs or Fireballs. Even when using 1x (default) for house rules.
I also think this will give people options for how it's triggered closer to what they expect, like SR's version where he wants RAW, no Snap, when a creature looks like its in the area, it's affected.
According to rulebooks (which @bwatford and I just went over); it requires half the grid space to be affected (which we take as center point of a grid sqaure included in AoE).
So, a creature must be half a grid inside to be affected; not touching.
However, also in discussion with @bwatford, we determined that the Internet is split on how circular AoE should be measured; so considering an option for how circular auras should be handled (Shaped vs. Squared).
Given that I've been given two competing fixes and nobody agreeing or wanting to own or work with the others; I'm pretty close to just saying "good enough" or shutting it down...
I don't have the time budget to cater to all the different desires; and this is not my primary focus. It's actually taking away from getting other features done...
Regards,
JPG