Efficient Way for Implementing Effects of Auras?

[night wyvern]

To start with for clarity, this post is not (directly) about the auras feature in MT (the visual effect). This post is about implementing effects like Paladin auras in 5e that provide a passive buff to other targets.

I am curious how people would approach the problem of implementing auras in MT. So, let's take for example a Paladin aura in 5e that gives a +2 to saving throws while within range. It is easy enough to implement for the Paladin, since the effect originates from the Paladin's token it can be easily "aware" of the feature granting the bonus. But for other tokens, it is not quite so easy. It requires the affected tokens to be somehow "aware" of the aura. I have though of a few ways to solve this issue:

1. Fairly sure this isn't possible, but worth mentioning in case I've missed something. The ideal solution would be for a token to detect when they are in an aura (the MT feature) and gather data about that aura. I don't think a function exists for this, though.

2. Use getTokens() and run though every token on the map to see if they have an aura feature, as well as if they're in range. The effect would be applied as it is needed - e.g. check for an aura when making the saving throw. This seems like it could get very slow to me - especially as the number of tokens increases - so a possible way of optimizing it a bit could be keeping track of the current maximum aura size active, and only using getTokens() for that distance. Would require more work to make sure the max distance is well kept up to date, though. Especially considering monsters would often get dropped in with auras already "active".

3. Similar to the above, but instead check for the aura when moving tokens, then apply/remove a state as appropriate if in range. Essentially shifts the processing time of using getTokens() to token movement, which I think would probably be worse.

Curious if there's ways to do this without using getTokens(), since that seems like the bottleneck here to me.

[vapid star]

I don't think you'll like this as much but it would be easy :). Also not sure how this would work for "circles".
place a "movedOverToken" token on the hidden layer, under the paladin. Anyone that steps on that auratoken, is "in range". The nice thing about this is you do one calc on the one token you're moving and you do not have to do any range, etc checks. Perhaps some challenges on aligning the aura token to the paladin centers

Pic for clarity:

One could maybe even put that on the object layer and use it to visibly show that the aura is active to "anyone" that steps on it . . .

Not that you don't have or aren't capable but I have some "lean" moved over code that tracks moveOver but also movedOff of (to save you some time 😉 )

I suppose to comply with all your "asks" though you'd almost need to make all your PC and NPC tokens "movedOver" as well. Not that it would be a bad thing as IMO you can do movedOver check rather quickly when all the values are known (as they would be here). I tend to see slowness when I'm doing generic token movedOver checks.

[jagged crater]

I used getTokens() for my Twilight Sanctuary macro, and it doesn't slow anything down.

[night wyvern]

I like it in concept - it most closely resembles option #1, which would be my ideal. Unfortunately, since most auras are circular mechanically, I'm not sure it would work for aura sizes >5. Perhaps this could be approximated with a large central square and smaller squares on the outside, but that seems quite clunky. Would also need to link the movement of the aura token with its creature - haven't done linked movement but pretty sure this is doable. Would your movedOver code be able to track when the aura moves off of other things?

[night wyvern]

Good to know - do you limit getTokens() by range when you do this? Part of my concern is large dungeon crawling maps with lots of creatures. Since if you're looking for Twilight Sanctuary in particular the range is known, but if you're just looking for anything the range is unknown

[vapid star]

I agree the circle / square nut is a tough one. Also as "code" is moving the aura, it wouldn't catch a pally moving to "help" an already stationary friend. With all the conditions, etc., I'd agree that a fine-tuned getTokens is your best bet.

[jagged crater]

Yeah, I get them by range.

[h:Light = json.set("{}" , "value" , 1 , "category" , "Special" , "name" , "Twilight" )]
[h:Range = json.set("{}" , "upto" , 6 , "distancePerCell" , 0 , "metric" , "ONE_TWO_ONE" , "token" , currentToken() )]

[h:cond = json.set("{}" , "Light" , Light , "Range" ,  Range )]

[h:NameList = getTokens("json", cond)]

When I was making the macro and doing testing, I had probably 50 token on the map. I don't know if that's the type of numbers you were thinking about or not, though.

[night wyvern]

Got it, thanks for the input though - what you suggested isn't something I generally do so it's good to be aware of other solutions! And sounds useful for traps and the like in the future.

[night wyvern]

Is that 50 tokens in range or just on the map?

[jagged crater]

Just on the map. Does that make a difference?

I would have thought MT still hd to look at all the tokens even if they don't fit the search criteria.

So I loaded 50 tokens and put them in the aura with the macro that it affects, and if I just move one token in amd out it's fine, but if I move all 50 it lags foe a few seconds.

I get no lag from moving 50 tokens when I remove the macro.

[night wyvern]

My concern was not necessarily that getTokens() itself would take a long time, but looping through all the tokens afterwards might take a while. Sounds like you might have run into that a bit? But good that a single token has minimal issues, I can't imagine moving that many tokens at once regularly

[jagged crater]

Lol I can't either.

[merry anchor]

Since no aura is going to be bigger than a certain radius, each token that exudes an aura should have a light aura set on it, then you just get tokens for neighbours within the range that have the appropriate light source.
Light source is an available condition in getTokens so I can’t see how you would be more efficient than that.

[night wyvern]

Can't believe I missed the light condition of getTokens - you're right, that should work perfectly. Can I limit it by size of the aura within getTokens? I know I can limit to aura names, but seems like there's not a way for ranges on the wiki.

[jagged crater]

Not directly (that I was able to find), but you can limit it by range.

[merry anchor]

You can search by the defined light name. Light definitions are accessible in getInfo I think, so you could set your range based on the aura definition after you extract it.

[night wyvern]

Thanks for the help everyone! I was going to use getInfo to get all light sources, then json.path.read to get the name all lights of the "aura" type to be used for getTokens. Then I realized that getTokens will only filter by a specific light, not check if any of a list are active. So I'll just have all of my auras be under the "Aura" group instead so it'll work with getTokens I guess 🤷‍♂️

[jagged crater]

Maybe I'm not understanding exactly what you're trying to do, but getToken() will look for any light source group.

[night wyvern]

Yeah, I'm using the group now - I was considering doing it by multiple names, so I can keep my GM and player auras in separate groups, but I can only do one group or one name at a time

[jagged crater]

Oh I see. You have multiple auras. I've only tried it with one. Does getToken() not handle more than one light source?