FGU lua math and function wierdness

[GKEnialb]

@Moon Wizard, is there any chance you could share the equation FGU uses to determine the endx, endy coordinates passed into onMeasurePointer? It's not the midpoint of the target and it's not the closest coordinates to the origin based upon the bounding box containing the target depending upon its size, but seemingly something in between. Unsuccessfully trying to replicate that so I could take the third dimension into account is what led to Token Height causing SilentRuin's question 2.

As an example, if I have a medium sized origin at 675,275 and a large sized target (space = 15) at 800,275, the endx,endy sent to onMeasurePointer is 750,275 (with a grid size of 50 and units of 5). I would have expected the x coordinate of the target to either be 800 (the midpoint and have onMeasurePointer figure it out) or 725 (the closest point to the target, using midpoint X - space * gridsize / units / 2 = 800 - 15 * 50 / 5 / 2 = 725).

[Moon Wizard]

Every token has a "grid size" characteristic (1x1, 2x2, 3x3, ...). When calculating the distance between a token and another point/token; the token's "distance point" is calculated as the center of the nearest grid square in the grid size of the token where the grid size is centered on the token center point. All of this calculation is done in the the client, not in Lua; so I don't have a Lua implementation of it.

Regards,
JPG

[GKEnialb]

Awesome - thanks for the quick response. I'm pretty sure I understand that and can recreate. Hopefully I can implement before silentruin catches up to me...

[SilentRuin]

Awesome - thanks for the quick response. I'm pretty sure I understand that and can recreate. Hopefully I can implement before silentruin catches up to me...

To slow to catch up, I think I've made a release (sometimes 2) for almost all my extensions this week - plus debugged token height by accident and added stuff I wanted to auras... I kick Moon with some false claim then he leaps in to chase

Now I have one more death indicators thing to figure out and I'm done. All these things came up to annoy me in my Monday night SW5E game with an assistant GM controlling a bunch of hostile NPCS against a bunch of players controlling a bunch of friendly NPCs - and then mines and insuring when a vehicle blows up at end of its turn near a mine (but foot soldiers don't) that it turns into a flaming wreck icon and the mine turns into a crater and... point being... NO CHASING

[GKEnialb]

Whew, I can stop running then.

@Moon Wizard, one more question. The reduction of calls to onMeasurePointer in 4.3.1 was great (and means I can probably delete a lot of code that silentruin helped write to do that manually). But now I have a problem where I can't get the measurement arrow to update programmatically. I used to jiggle the coordinates by one pixel after adjusting the height, which forced onMeasurePointer to be called and the arrow was updated. That doesn't work anymore. Do you know of any way I can force onMeasurePointer to be called programmatically?

[SilentRuin]

Whew, I can stop running then.

@Moon Wizard, one more question. The reduction of calls to onMeasurePointer in 4.3.1 was great (and means I can probably delete a lot of code that silentruin helped write to do that manually). But now I have a problem where I can't get the measurement arrow to update programmatically. I used to jiggle the coordinates by one pixel after adjusting the height, which forced onMeasurePointer to be called and the arrow was updated. That doesn't work anymore. Do you know of any way I can force onMeasurePointer to be called programmatically?

I complained about onMeasurepointer spamming to much and it was fixed. Likely jiggling 1 pixel is not enough - I'd experiment with more than that. Maybe

local nDU = GameSystem.getDistanceUnitsPerGrid() * 0.5;

That way its 1/2 a block - as most of this stuff is per block on displayed measurement I'd start with that.

[GKEnialb]

I complained about onMeasurepointer spamming to much and it was fixed. Likely jiggling 1 pixel is not enough - I'd experiment with more than that.

I did +/-50 with no luck as well. But I have to move it right back, of course, so maybe it's smart enough to recognize that as not actually moving...

[GKEnialb]

Whew, I can stop running then.

@Moon Wizard, one more question. The reduction of calls to onMeasurePointer in 4.3.1 was great (and means I can probably delete a lot of code that silentruin helped write to do that manually). But now I have a problem where I can't get the measurement arrow to update programmatically. I used to jiggle the coordinates by one pixel after adjusting the height, which forced onMeasurePointer to be called and the arrow was updated. That doesn't work anymore. Do you know of any way I can force onMeasurePointer to be called programmatically?

To follow up on this, I can call onMeasurePointer manually and get the right answer, but it doesn't update the text of the pointer (presumably whatever calls onMeasurePointer in real life is what sets the pointer text with whatever value gets returned by onMeasurePointer). So it goes back to whether I can trigger a refresh of the pointers programmatically or if some other trick may work. Any suggestions?

[GKEnialb]

To follow up on this, I can call onMeasurePointer manually and get the right answer, but it doesn't update the text of the pointer (presumably whatever calls onMeasurePointer in real life is what sets the pointer text with whatever value gets returned by onMeasurePointer). So it goes back to whether I can trigger a refresh of the pointers programmatically or if some other trick may work. Any suggestions?

@Moon Wizard, I also tried calling Token.onMove when I adjust the height, to no avail. Any other possible way to trigger a targeting arrow update after 4.3.1? Sorry for being a pest about this...

[Moon Wizard]

There is no mechanism to tell the client to update like that. Potentially a jiggle (move 1 pixel and then back)?

JPG