On my testing the issue with Melee range is resolved by the latest update. Many thanks again everyone involved in tracking this down and GKEnialb for releasing the new version and coding this superb Quality of life extension.
Printable View
On my testing the issue with Melee range is resolved by the latest update. Many thanks again everyone involved in tracking this down and GKEnialb for releasing the new version and coding this superb Quality of life extension.
Awesome - great to hear it's working.
Unfortunately, ActorCommonManager.getSpaceReach doesn't work as expected when adjusting space in the combat tracker for PCs - should have known that it wasn't intended like getTokenSpace(). Reverted back to using the DB and all should be fine. MeAndUnique is working on a change to have THI and Size Matters be compatible.
Overrides for specific record types would have to be registered with ActorCommonManager to change the behavior with specific record types, such as PCs (charsheet)
Regards,
JPG
Thanks - I wasn't try to override any behavior, but simply to read the values. They aren't being updated when the size changes, but the DB does get updated, so I'll revert to using that directly.Quote:
Originally Posted by Moon Wizard
Uploaded v5.3 to the Forge to fix an issue with SilentRuin's GM Assistant extension (was messing with the ownership of a token when taking / releasing control - there still is a bug which I can't do anything about where the height in that case will be reset to 0).
And made 5.4 to allow the aforementioned bug to be fixed, with help from SilentRuin. His extensions are udpated along with THI to hopefully be fully compatible now. And some optimizations thrown in for good measure.
Hello GKEnialb,
I have encountered an incompatibility in-between your "Token Height Indicator" and dogfisc's "Combat Modifier Calculation". There is no error message, but if the your extension is enabled (just enabled - you do not even need tokens on different "height"), the "Flanking" calculation from CMC is not applied. Both of you recently updated your corresponding extension - so the problem might also be on his side. I am therefore cross-posting the finding here.
Arnagus
Are all the tokens medium size? Which ruleset are you using? Are the grids square? Are the flanking tokens on the diagonals, north/south, or east/wes? Just trying to think of anything that may be incorrectly returning the distance between adjacent tokens (which presumably what the flanking is checking for).
This is 3.5e ruleset, and flanking is a simple line: attacker - defender - attacker. No difference if east/west or north/south, all tokens on the CT. Exact same setup with both modules fails, with only CMC works without problem. New campaign or existing makes no difference.
I loaded a 3.5 campaign, square grid, 5' squares, set to default measurements, and moved one token around the other the other in each of the 8 directions - the measurement from the pointer was always 5'. I did remove the tokens from the map first and re-add, just to reset everything. As such, I believe THI is working correctly, but happy to investigate if dogfisc believes otherwise.
I’ll download Token Height Indicator and take a look at this when I get time, probably tomorrow.Quote:
Originally Posted by GKEnialb
Excellent. Let me know if you have any questions (here, PM, or Discord) about what I override. Presumably it's something like Image.getDistanceBetween() that's causing the issue (the results shouldn't have changed, but there may have been some size calculations that changed in recent FGU updates that effect things (or things I changed for other compatibilities that made it seem like FGU changed).Quote:
Originally Posted by dogfisc
So I think I have a fix for this conflict, though I admit I don't entirely understand the cause. Working with token locations on images made my brain hurt when I was writing my extension and it's been a while since I've looked at this part of the code. Something to do with inversion of the Y coordinates vs the Y location of a token? (token is Y+ up, Y- down; coordinates are the opposite?) With both extensions enabled, if the tokens are more than one grid up or down from the center of the image, the result of Image.getDistanceBetween() is wrong--or at least, not what I had been expecting. I'll try to dig in more and figure it out fully.Quote:
Originally Posted by GKEnialb
I had been calculating the distance between the coordinate of the "threatning" token and the target token; changing that to calculate from the coordinate of the "threatning" token to the coordinate of the target token seems to have fixed it.
So far I've only tested with single-grid-square tokens. I'll need to make sure this continues to work as the critters get larger. I've a previous engagement to get to now, but I may have this done by tomorrow evening.
Interesting. With both extensions loaded, if you have two targets selecting each other, and move one around the other in all 8 directions, the arrow shows 5', and it calls getDistanceBetween(). I think there may have been a change on the FGU side on the last build for some of the underlying routines (but see my disclaimer - I could easily be wrong) - not sure why using THI would change anything, though. Oh, if you're using coordinates in getDistanceBetween instead of just two tokens, that may have something to do with it (that function allows all sorts of parameter combinations and I may have missed one in my testing, which is mostly focused on two tokens.
So that didn't work with larger tokens. For now I've gotten around the issue by checking to see if Token Height is loaded and doing a slightly different calculation if it is.
Okay, I see what's going on. I can fix it in Token Height, but of course I'll break what you just did if I push an update, so we should coordinate.
Many thanks for both of you digging into It together!
No worries (though dogfisc did all the work ��)
Arg matey - I'm coming for you!! ;)
Turns out after much pain and also getting Moon Wizard involved - I've found this problem is with this extension and not FGU. Basically Token.getDistanceBetween is returning the wrong distance when moving a 1/2 square away from target. Will show 5 returned instead of what the target pointer distance shows - 10ft.
This is the thread that has all the info under Question 2: and I include the 5E test ext Moon made to verify it was not his stuff which helped me determine it was your stuff. Without this extension the function returns the correct values - with it - it does not.
Version 5.5 in the Forge which should make everything internally consistent and consistent with all (2D) calculations from the base FGU. Note that as of FGU 4.3.1, the targeting arrow will not update automatically when changing the height of the tokens. The workaround is to move the token and move it back after adjusting the height. Trying to figure out if I can force the redraw of the arrow when I change height (the change in 4.3.1 was more clever than my kludge to force the update).
When I have a campaign with Token Height Extension and Aura Effect Extension loaded with no maps up - then when I key in the Wounds field in CT the map for that CT entry pops up. Also does when you add effects to the extension. It's completely weird. Especially if during startup something is coming up and modifies an effect or something in the CT - a blank map for that entry pops up. I'm posting to both of these extensions - suspect some sort of conflict as nothing happens if only one or the other is loaded.
Is the character in the CT on a map? I've seen the map load when I open the CT and actually kind of like it, but I never have anything in the CT not on a map - I can see why a blank map wouldn't be intended. Are there auras on anything in the CT?
I have things in the CT that are not on the map all the time. I keep npc entries for lair actions, area/room traps, I keep a GM PC for convenience as well. So in any given session, i'll have as many as half a dozen entries in the CT that are not on any map.Quote:
Originally Posted by GKEnialb
But do you see what what silentruin is seeing? I was just saying that I never see it, but I never have tokens not on a map, so was wondering if the tokens popping up a blank map weren't on any or if they were on a map but a blank one was still popping up. So not trying to downplay the scenario, but looking for info. :)
No, I have never observed what Silentruin described. I just created a test campaign with token h eight 5.5 and Aura effects 1.18hotfix3 and do not see that behavior with entries on maps or not on maps.Quote:
Originally Posted by GKEnialb
Excellent. Thanks for the info. @silentruin, do you have anything else loaded or just those two?
Create a new campaign.Quote:
Originally Posted by GKEnialb
Drop a wolf and a dire wolf in the CT.
Drop the CT tokens in a map.
Add an aura effect and have it close enough to trigger. I used the following turning the dire wolf into a mine for example only.
Incendiary Mine; IF: !DYING; IFT: !DYING; AURA: 15 foe; Incendiary Mine; IF: !DYING; SAVEE: 14 DEX (H); SAVEDMG: 2d8 fire
Move wolf close enough to trigger the FROMAURA.
Close the map.
Edit the wounds on the wolf - POOF map comes up.
It can also come up at the start of FGU with a black map (the correct one) if some code edits that CT entry in some way - for me it was death indicators realizing something was dead but did not have the Unconcious/prone set at startup. But really anything touched in CT entry seems to trigger it - add an effect edit the wounds etc.
ONLY when both of these extensions are loaded. Never with just one or the other.
Attachment 55493
You should be able to duplicate it easily given these steps. I did not bother to add BCEG so you may want to change effect to something generic - it won't matter.
I was able to replicate using these steps. I simplified the aura effect to just AURA: 15; DISATK; to eliminate any other extension.
The image window pops up when the HP changes wound categories. (Healthy, light, moderate, heavy, critical, dead)
With the wound categories set up to simple, it triggers when the hp changes from 0, goes over 50%, and hits 100%
With the wound categories set up to Detailed, it happens every 25%
Okay, I see what's happening and have pushed a fix to the Forge. Thanks for the debugging!
Pushed v5.7 to the Forge. I now pretend that the token is moving when height changes (calling onMove), which fixes Aura Effects, though still won't update the targeting arrows automatically.
Thanks! Bummer it didn't get the arrows working too.Quote:
Originally Posted by GKEnialb
Pushed v5.8 to the Forge, which forces the targeting arrows to update automatically when the height changes. It does this by shifting a pixel in the x axis (and back on the next update), but that's purely cosmetic - the distance calculations take that into account. Also, with help from SilentRuin, it works completely with Aura Effects again (well, once an update on that side is pushed, but once it is, a new version of this won't be necessary).
I should note during all this we found that if say I have a HUGE mine... and a HUGE land speeder.. and the mine has an aura effect of 15 ft - while the land speeder is 25ft in the air. Because size of token critter is assumed to extend down 12.5 ft above and below with token height, I was mistaken when I thought 25 ft was enough to safely cruise over the mine - it was really 30 ft... and of course resulted at 25 ft with a resounding... BOOM!!
Attachment 55521
Yeah, I should clarify that on the store page - Token Height makes squares into cubes and assumes the token fills them, so calculations are done from the middle of that cube and assume the bottom of the cube is where the height is set (so that 15' land mine with a height of 0 still extended upwards 15'). Makes more sense with creatures than with flat mines... :)
Yeah really only comes into play when you consider automation stuff. Because a DM would know that a flat mine even if it was really wide wouldn't reach over the 15ft area.Quote:
Originally Posted by GKEnialb
Exactly. Using an automated effect like Aura Effects, you'd want to push that mine into the ground a bit to account for that.
Catch 22 - if you do that will it still be 15ft when someone is on the ground?Quote:
Originally Posted by GKEnialb
Yes, however, if someone were to go under it, then it would be a problem lolQuote:
Originally Posted by SilentRuin
I love this extension and it works great except for one thing:
It causes a lot of lag whenever any arrows/cones/circles/squares are on the map as well as when they are being drawn.
This happens even when it is the only extension running.
Is there any way to fix that?
Thanks much!!