CHANGE/FIX: token facing

[wolph42]

concerning Wiki: getTokenFacing() and Wiki: setTokenFacing()
currently Wiki: getTokenFacing() returns a value between -180 and 180. This is really really really really annoying. I guess there were thoughts about it initially of why to do it that way, but it results in continuous headaches whenever tokenfacing is required in a macro.
IRC it also turns in the wrong direction IRC 90 degrees in java is a positive vector parallel to the x axis, 180 y-positive, 270 x-negative and 0/360 y-negative. While in maptool it has an offset and goes in the wrong direction.

Although this would break compatibility I still *strongly* opt for this function to be fixed so it uses and returns 'normal' coordinates.

If people find it really vital to keep compatibility I would opt for adding a boolean parameter: 1='use normal coordinates system' 0='use old MT coordinate system', defaulting to 0. That way you have backwards compatibility AND a normal acting function.
O and IF 1 (bool parameter) is used then it returns 0 when facing is not set (instead of "" which messes things up).

[JamzTheMan]

And here I thought I could put that part of my life forever out of my mind. That drove me nuts during our DungeonBuilder/VBL project.

And +1. Adding a bool and defaulting to original mechanic on 0 or null should be easy enough and not break anything that I can think of. Should be a quick hit as well, just doing the translation in the macro function class itself and not touch the inner class(es).

[wolph42]

And here I thought I could put that part of my life forever out of my mind. That drove me nuts during our DungeonBuilder/VBL project.

that was indeed the ultimate case. i still have nightmares.

[Jagged]

IRC it also turns in the wrong direction IRC 90 degrees in java is a positive vector parallel to the x axis, 180 y-positive, 270 x-negative and 0/360 y-negative. While in maptool it has an offset and goes in the wrong direction.

Is part of the issue that MapTool's map coordinates also go in the "wrong" direction? i.e. increasing positive values of X progress downwards, while increasing positive values of Y progress (correctly?) to the right?

[d4rkAlf]

I've decided to make a proposal implementation of this. Ultimately I decided that the convenience of those that in the future will use the facing outweighs the inconvenience of those that will have to update their macros. In other words I decided to break backwards compatibility.

Please have a look and tell me what you think.

https://github.com/DarkAlf/maptool/tree/tokenfacing

[wolph42]

I decided to break backwards compatibility

what now

[d4rkAlf]

I decided to break backwards compatibility

what now

I'm not sure what you are trying to communicate? But maybe I wasn't clear enough.

If we fix token facing in the way I propose getTokenFacing will always return values between 0 and 359 (inclusive) degrees. A facing of 0 means the token is facing towards east, 90 means north, 180 is west and 270 is south. It's the standard mathematical way to represent angles.

This means that macros that rely on the old non-standard way of representing degrees will break. The reason as to why I chose to suggest this proposal is that whenever people write new macros they won't need to type getTokenFacing(true) and will instead be able to write cleaner macros by simply typing getTokenFacing() (assuming a token has been impersonated).

But as I've said, this is just a suggestion.

Here's the relevant code:

Code: Select all

public void setFacing(Integer facing) {
/*
* Only one or zero of these while loops will be executed each time the
* method is called.
*/
while (facing < 0) {
    facing += 360;
}
while (facing >= 360) {
    facing -= 360;
}
this.facing = facing;
}

[Jagged]

If we are going to do this we definitely need to do what Wolf suggested above and have old and new versions available, and for it to default to the old method.

We can't just break every framework that uses token facing.

I'd also be inclined to use the mod function

Code: Select all

facing = Math.abs(facing + 180 % 360)

[d4rkAlf]

If we are going to do this we definitely need to do what Wolf suggested above and have old and new versions available, and for it to default to the old method.

We can't just break every framework that uses token facing.

I'd also be inclined to use the mod function

Code: Select all

facing = Math.abs(facing + 180 % 360)

Yeah, after thinking about it some more I'm just going to make new macros that return correct values and let the old ones keep using the old values.

[d4rkAlf]

Ok, I have updated the branch. For the time being I'm just calling the new macro getTrueTokenFacing. Not really happy with that name though, any suggestions?

I'd also be inclined to use the mod function

Code: Select all

facing = Math.abs(facing + 180 % 360)

Yeah, using modulo was my first instinct as well. Unfortunately it doesn't work that well for negative numbers.

[Jagged]

That code snippet turns any numbers to a number in the range of 0 to 360.

[d4rkAlf]

That code snippet turns any numbers to a number in the range of 0 to 360.

Perhaps, but for input -90 it will output 90 instead of 270.

[wolph42]

If we are going to do this we definitely need to do what Wolf suggested above and have old and new versions available, and for it to default to the old method.

We can't just break every framework that uses token facing.

I'd also be inclined to use the mod function

Code: Select all

facing = Math.abs(facing + 180 % 360)

Yeah, after thinking about it some more I'm just going to make new macros that return correct values and let the old ones keep using the old values.

Very Good! This is in the line of what I tried to communicate. It really is a bad idea to break compatibility , when it's not necesary.

[JamzTheMan]

Ok, I have updated the branch. For the time being I'm just calling the new macro getTrueTokenFacing. Not really happy with that name though, any suggestions?

Since "Facing" may mean what ever it meant before (assume someone at sometime had a reason to go -180 to 180).

And since degree's is the measure of an angle, getTokenAngle() ?

[d4rkAlf]

Ok, I have updated the branch. For the time being I'm just calling the new macro getTrueTokenFacing. Not really happy with that name though, any suggestions?

Since "Facing" may mean what ever it meant before (assume someone at sometime had a reason to go -180 to 180).

And since degree's is the measure of an angle, getTokenAngle() ?

Yeah, that makes a lot of sense.