5E - Token Height Indicator

[rhagelstrom]

Here is a patch extension for Pack Tactics/Flanking and Range/Sneak Attack to work with Token Height. If anyone wants to improve on this, be my guest and run with it.

FYI, you can find this in the forge so it won't get buried in this thread

[GKEnialb]

What's going on in token_height_indication.lua:202?
It appears to be getting a token from a CT node for no reason and there is a handler associated with it.

That's an excellent question. The placement between the other two functions is particularly odd. When I was first playing with taking height into account in the range arrow, I was trying different things with the tokens, so it may have been that. I've removed it now (but will wait until there's another reason to update for it to come through).

[GKEnialb]

FYI, you can find this in the forge so it won't get buried in this thread

Awesome. Thanks, Rhagelstrom!

[Svandal]

That's an excellent question. The placement between the other two functions is particularly odd. When I was first playing with taking height into account in the range arrow, I was trying different things with the tokens, so it may have been that. I've removed it now (but will wait until there's another reason to update for it to come through).

I am posting this here also, a bug report compatability between two extensions.
https://www.fantasygrounds.com/forum...l=1#post611803

These extensions where compatible before, and the other one did not update, only this.

It calls for the positions on each token to get the range between the tokens before each ranged attack, that is when the error occurs.

[bmos]

I am posting this here also, a bug report compatability between two extensions.
https://www.fantasygrounds.com/forum...l=1#post611803

These extensions where compatible before, and the other one did not update, only this.

It calls for the positions on each token to get the range between the tokens before each ranged attack, that is when the error occurs.

The error comes from getCTFromToken being supplied with a number rather than a token.
I'm assuming it could be due to using a token id rather than a real token?

[Zygmunt Molotch]

The error comes from getCTFromToken being supplied with a number rather than a token.
I'm assuming it could be due to using a token id rather than a real token?

That might explain something's I've moaned about

I regularly drop tokens for things like backpacks or torches or dancing lights, I guess they dont have a passable (to the functions) token-id if dropped in from art assets, and then it gets confused when trying to work out flanking/height/targetting (extension depending) etc?

[GKEnialb]

Yeah, when tokens on the image aren't also in the combat tracker, things don't necessarily work really well.

I imagine what's going is something like this::

• In version 4.5, I overrode the Token functions related to distance (before I just did the imagecontrol functions)
• Combat Modifier Calculation Extension uses Token.getTokensWithinDistance
• Token.getTokensWithinDistance only used to return tokens in the combat tracker (I'm speculating here) and Token Height returns all tokens within the distance on the map
• Combat Modifier Calculation Extension doesn't protect against non-combat tracker tokens

If that is what's going on, I can filter the tokens to only return tokens that are in the combat tracker. The big question is whether that's the expected behavior or not - I'd hate to break somebody that does want all tokens within range to be returned. I can run some tests to see what the core behavior is in the next few days, unless anybody knows off the top of their head.

[Svandal]

Yeah, when tokens on the image aren't also in the combat tracker, things don't necessarily work really well.

I imagine what's going is something like this::

• In version 4.5, I overrode the Token functions related to distance (before I just did the imagecontrol functions)
• Combat Modifier Calculation Extension uses Token.getTokensWithinDistance
• Token.getTokensWithinDistance only used to return tokens in the combat tracker (I'm speculating here) and Token Height returns all tokens within the distance on the map
• Combat Modifier Calculation Extension doesn't protect against non-combat tracker tokens

If that is what's going on, I can filter the tokens to only return tokens that are in the combat tracker. The big question is whether that's the expected behavior or not - I'd hate to break somebody that does want all tokens within range to be returned. I can run some tests to see what the core behavior is in the next few days, unless anybody knows off the top of their head.

For my bug report the tokens where in the combat tracker, and the tokens got dragged from the combat tracker to the map.

[GKEnialb]

That's really good to know. My new theory would be that I return a different type of token than expected - I should be able to track that down pretty easily.

[Zygmunt Molotch]

Yeah, when tokens on the image aren't also in the combat tracker, things don't necessarily work really well.

I imagine what's going is something like this::

• In version 4.5, I overrode the Token functions related to distance (before I just did the imagecontrol functions)
• Combat Modifier Calculation Extension uses Token.getTokensWithinDistance
• Token.getTokensWithinDistance only used to return tokens in the combat tracker (I'm speculating here) and Token Height returns all tokens within the distance on the map
• Combat Modifier Calculation Extension doesn't protect against non-combat tracker tokens

If that is what's going on, I can filter the tokens to only return tokens that are in the combat tracker. The big question is whether that's the expected behavior or not - I'd hate to break somebody that does want all tokens within range to be returned. I can run some tests to see what the core behavior is in the next few days, unless anybody knows off the top of their head.

interesting!

we should tell Dogfisc, about the Combat Tracker flanking ext too!