FGU lua math and function wierdness

[SilentRuin]

I have two questions on how these things are possible, and how to resolve them (hopefully).

Question 1:
I have a lua file that does some math - then compares that to get a true false result....

  Debug.console(v.x*v.x + v.y*v.y);
  Debug.console(radius^2);
  Debug.console(v.x*v.x + v.y*v.y <= radius^2);  
  return v.x*v.x + v.y*v.y <= radius^2;

The results will be

#49760288
#49760288
bFALSE

Now I tried a bunch of stuff to get around this thinking "oh I'm just not seeing a truncated float number in the print" so I tried...

math.floor(v.x*v.x + v.y*v.y) <= math.floor(radius^2)

and also tried separating out each side into its own local variable and just doing "a <= b" - still it would appear the values printed were the same but would not come back true consistently (sometimes they would return true with same print values in other measurements of different map token distances - it was bizarre).

This seems less likely to happen on other maps with smaller grid sizes or with medium tokens. Any idea how to resolve this or why it happens?

Any ideas on what causes this or how to resolve it?

Question 2:

I have the following code:

	local nDistance = Token.getDistanceBetween(TokenInstanceA, TokenInstanceB);
	Debug.console(nDistance);

The results in both the below screen shots is

#5

The problem is that the results do NOT always match what is shown on the map target distance pointer.

Here is screen shot of match (don't get me started on the tiny distance text - it seems to vary and I have no pattern on why)

DistanceMatch.jpg

And here is screen shot of it not matching when I move the token slightly further away

DistanceNotMatch.jpg

This can be easily duplicated on any map when you have grid locking and move a 1/2 square away.

Thus endeth my questions. I await enlightenment.

[Moon Wizard]

Question 1: No idea. My guess would be floating point differences; though I would expect the math.floor to address as you mentioned. Sort of curious that the numbers you are working with are generating numbers with whole numbers greater than 49m, which means that v.x and v.y are around 5000 each. As far as I know, the numbers in the Debug output aren't rounded, so it looks like you're already getting rounded numbers.

Question 2: Not sure without a specific example/extension showing what you are trying to do. Perhaps the event you are triggering on is happening before the actual token movement?

Regards,
JPG

[SilentRuin]

Question 1: No idea. My guess would be floating point differences; though I would expect the math.floor to address as you mentioned. Sort of curious that the numbers you are working with are generating numbers with whole numbers greater than 49m, which means that v.x and v.y are around 5000 each. As far as I know, the numbers in the Debug output aren't rounded, so it looks like you're already getting rounded numbers.

Question 2: Not sure without a specific example/extension showing what you are trying to do. Perhaps the event you are triggering on is happening before the actual token movement?

Regards,
JPG

Yeah Question 1 is probably a lost cause - I just added a KLUDGE factor to the radius and force it to work. However, Question 2 if it worked would resolve anything outside of the expected range - except the half square issue.

To duplicate is super simple. Do the exact Token.getDistanceBetween call I made (or use the imagecontrol one its the same result) and simply see when you move one token next to another - it will be 5ft. And move it a 1/2 square away it will STILL be 5 ft. While the targeting indicator as shown in the images I gave shows it as 10ft. These are different values for a 1/2 square. There is something different between the Token.getDistanceBetween rounding (as its always to the nearest 5ft it appears) and whatever is used to do the target indicator distance. Only looking at your code (no access for me) would show you what that difference is. Any map/any extension that does this call and compares with the target indicator distance will show you the difference in nearest 5ft and they are different. Which is bad. I would expect the code function to do the same rounding up that the target indicator does.

And this has nothing to do with movement. The tokens are where they are shown - static.

[Moon Wizard]

For question #2, I just built an example extension, and it appears to work fine (attached). The extension triggers on token move, and spits out current position and position/distance of all targets. In the future, please provide a simple extension showing the issue with minimum number of steps; along with steps/pictures to show the exact steps to follow.

For question #1, I'm going to guess that the problem is that you are mixing operators. (i.e. x*x vs. radius^2) Try x*x and radius*radius instead. Otherwise, you'll need to provide the input values for any further investigation.

Regards,
JPG

[SilentRuin]

For question #2, I just built an example extension, and it appears to work fine (attached). The extension triggers on token move, and spits out current position and position/distance of all targets. In the future, please provide a simple extension showing the issue with minimum number of steps; along with steps/pictures to show the exact steps to follow.

I did give details in the screen shots. First I had to add the 5E ruleset or your test .ext did not show up in my list (or I missed it). Then I brought up the same project and it gave the EXACT same results in your output as I showed you. As I moved - the distance stated it was #5 and for the first 1/2 square etc. as I described away from target (see screenshots again) the target pointer distance was 10ft. This is NOT the same thing. And your .ext showed the same thing I saw. Not sure what else to tell you. You have no screen shot showing your stuff. Here is mine when I move it 1/2 square away from target. Your stuff says #5 - the target line says 10ft - not the same.

Before Move
BeforeMove.jpg

After Move
AferMove.jpg

It's incorrect with your extension. The rounding off is different they should not be. As I said you'd have to look at your internal code to see why that is as I can't see that.

For question #1, I'm going to guess that the problem is that you are mixing operators. (i.e. x*x vs. radius^2) Try x*x and radius*radius instead. Otherwise, you'll need to provide the input values for any further investigation.

Yeah trying this /test with the number gives it working - and as I said even I get it working sometimes. As I worked around this with a KLUDGE factor added in I'm just going to chalk this one up to a mystery as I'm not sure how me assigning each side to its only value then doing the comparison would somehow mix an operator (that was one thing I stated I tried).

[SilentRuin]

But I am using extensions... (sigh) - one of them is doing this I bet.

[SilentRuin]

Yep - not you guys my bad. I'll have to trial and error to see what is doing this. I have my suspicions.

[SilentRuin]

There was a time I never used anyone's extensions but mine so I always knew what was going on and how to resolve it fast... though now I use 3 external ones.

Token Height... I'm coming for you!

[LordEntrails]

There was a time I never used anyone's extensions but mine so I always knew what was going on and how to resolve it fast... though now I use 3 external ones.

Token Height... I'm coming for you!

Someone once told me; extensions = risk
*duck & cover!*

[SilentRuin]

Someone once told me; extensions = risk
*duck & cover!*

Yeah I was so buried in the Question 1 math part of this thread I just assumed (made an *** of myself) that the other was pure FGU. I mean it was a new function call I'd never seen before - who could be messing with it already in extension land? (sigh)

Never assume