PDA

View Full Version : Modifying distance calculation



Ken L
December 15th, 2017, 04:42
Within gameelements.xml there's



<distance>
<base>5</base>
<diagmult>1.5</diagmult>
<suffix>'</suffix>
</distance>


Which allows simple modifications. I have the case where I want to do further modifications by adding a Z axis.

Use cases here are space campaigns to illustrate ship height, or in fantasy terms, flying. In those events, I want to calculate the hypotenuse by incorporating the Z axis (i have an extension that includes height).

I'm guessing this isn't possible?

Moon Wizard
December 15th, 2017, 04:52
Not really. The Z-position is not represented anywhere in the FG client; it's all 2D. So, all APIs use 2D space.

There are onMeasurePointer (targeting, pointers) and onMeasureVector (token momvement) function events that you can override in imagecontrol, but only the vector endpoints are passed as parameters. If you make the assumption that two tokens never share the same space, you could look up the token by the end point for onMeasurePointer; but that event function is also shared with the pointer measurement. But, it might be good enough for what you are looking for, depending on the kind of game you're running.

Regards,
JPG

Ken L
December 15th, 2017, 05:03
That actually works, I was worried about being limited to the XML entry as there's quite a bit of black box there similar to the dice. Thanks moon.

Ken L
December 15th, 2017, 17:20
I'm aiming to replicate the base measurements along the x,y, and from the parameters I may come with up with a close approximation. Rather than re-inventing the wheel here before tacking on the height logic, could I possibly get the equation/heuristic? A high level explanation is fine.

For the diagonal I'm suspecting it's a truncated increment multiplied by the scale-unit, but for non-clean 45 degree diagonals I'm not entirely sure how you mix them. I'm guessing it's a function of the amount of degrees from the orthogonal truncated but that's a blind guess.

Good food for thought for when I get back to crack at it this evening.

EDIT:

Is the pixel length the length of the visible pointer? For targeting distance, I assume it's center-point to center-point for the token vs the length of the conjoining line which is the edge of the square unit +/- some margin. Just need to know the difference in parameters from the base framework calculation vs what is given to the handler as if it is calculating from center-point to center-point, I'll need to account that the pixel line I'm given is instead edge-to-edge. If it's a direct override then it should be the same, it would also mean that I could see the direct framework implementation and just tack on to it rather than re-create it?

Moon Wizard
December 16th, 2017, 01:23
Here's some rough pseudo-code for square grids: (hex grids are more complex)



diagonals = 0;
straights = 0;
for (auto it = vectors.begin(); it != vectors.end(); ++it)
{
gx = math.abs(it->x /gridSize);
gy = math.abs(it->y /gridSize);
diagonals += min(gx, gy);
straights += math.abs(gx - gy);
}
distance = (straights + (diagonals * diagonalMultiplierSetting)) * baseUnitSetting;


Regards,
JPG

Moon Wizard
December 16th, 2017, 01:28
There's no mechanism to get the default measurement, because it's only provided if you don't override.

For the targeting measurement, it's a measure from the point in the center of the grid square that is closest for both the targeter and the target. (i.e. if targeter and target are both size 1, then it's the center point for each of them. If either are larger, all grid squares covered by the token (in a square region) are checked to see which one is closest and that one is used in the targeting calculation.)

Regards,
JPG

Ken L
December 16th, 2017, 02:05
Thats exactly what I needed moon, thanks!

Anoril
May 28th, 2020, 16:48
Hi!

I'm trying to get the distance calculation and I can't get the result from your algo.

My base settings are: base Unit = 1.5, and diagonal is 1.5 too.
For two tokens 1 square appart in diag, I got 1.5 as your computation goes.
But if I place the tokens 3 diags appart, I would have (3*1.5)*1.5, hence 6.75, but FG displays "6"!!!

EDIT: OK. Got it: you make a floor(3*1.5)... :)

By the way, I can get the diagmult factor by using Interface.getDistanceDiagMult(), but how to get base distance?

How possible?

Regards,
Paul

Kelrugem
May 28th, 2020, 23:41
Hi!

I'm trying to get the distance calculation and I can't get the result from your algo.

My base settings are: base Unit = 1.5, and diagonal is 1.5 too.
For two tokens 1 square appart in diag, I got 1.5 as your computation goes.
But if I place the tokens 3 diags appart, I would have (3*1.5)*1.5, hence 6.75, but FG displays "6"!!!

EDIT: OK. Got it: you make a floor(3*1.5)... :)

By the way, I can get the diagmult factor by using Interface.getDistanceDiagMult(), but how to get base distance?

How possible?

Regards,
Paul

You probably mean: GameSystem.getDistanceUnitsPerGrid()? :)

Anoril
May 29th, 2020, 09:46
Hi Kelrugem!

Yes, I mean that :P

By the way, this function does not make use of the xml settings. Whatever is stored in the "gamelements.xml", it is not returned by GameSystem.getDistanceUnitsPerGrid().
I had to create a new GameSystem with overrided function that returns "hard coded" value. :(

That is a pity a function get its value from an XML source and another could not :S

For those interested in the actual calculus, I found that code: (the rounding is the tricky part that was hard to identify)


local scale = window.image.getGridSize();
if scale ~= 0 then
local xTiles = math.floor(math.abs((c2x - c1x)/scale));
local yTiles = math.floor(math.abs((c2y - c1y)/scale));
local diagsTiles = math.min(xTiles, yTiles);
local straightTiles = math.abs(xTiles-yTiles);
local dist = (straightTiles + math.floor(diagsTiles * Interface.getDistanceDiagMult())) * GameSystem.getDistanceUnitsPerGrid();
return dist;
end


And I would be happy to get the hex grid calculation, and the stuff about token bigger than 1 :)

Thanks all!