CHANGE/FIX: token facing

[wolph42]

In that case: (good name btw) make sure that an angle is returned when facing is NOT set. Irc when facing is not set its angle is 180, but not sure, so check first.

[aliasmask]

Maybe there shouldn't be a null facing. Just an internal show facing. I think the default facing is 90 or -90 I don't recall.

[JamzTheMan]

Could just return 0 (or 360) if not set, you still get a 'valid' setting but also know it's not set, if needed.

[aliasmask]

Well, if the facing is null, it does returns "" but the actual token facing is -90. My point is the token is always facing somewhere. Just the little arrow may or may not be showing up.

[wolph42]

Well, if the facing is null, it does returns "" but the actual token facing is -90. My point is the token is always facing somewhere. Just the little arrow may or may not be showing up.

Indeed, and -90 is 180, so no facing should return 180

[Jagged]

assume someone at sometime had a reason to go -180 to 180.

I suspect because its suitable for Swing

[aliasmask]

I think you can put any number for facing and it will be converted. But when getting the facing back I don't think -180 is included.

[d4rkAlf]

I went and had a look at the current code in the master branch. If a token does not have a facing then getFacing will return null. The macro function getTokenFacing interprets this has having no facing and will return the empty string "".

I have updated my tokenfacing branch to include the latest batch of improvements:
https://github.com/DarkAlf/maptool/tree/tokenfacing

[Jagged]

Git Hubs gone down! Did you break it?

[d4rkAlf]

I finally figured out how it should be done using modulo.

Code: Select all

public void setFacingInDegrees(float facing) {
		facing %= 360;
		if (facing < 0) {
			facing += 360;
		}
		this.facing = facing;
}

I've also made a new pull request. Please have a look at Github.

[RPTroll]

This didn't seem to make it into the 00 build. Was it added or no?

[Jagged]

No. At the point of DarkAlf's last change, it was still producing some errors in token facing when loading pre-existing maps. I think when you had stamps that were flipped as well as rotated, but not 100% sure.

Plus I am not sure this approach is the right one. All we wanted was a new set of functions to return facing in radians. Making an additional step of changing the way facing is represented in the underlying data seems to risk bugs for little actual benefit.