Modulo Bug: 1.06a

[RPC]

Looong story short:
(modulo -20 360) does not return 340 in Transcendence, but instead returns -20.
Google search reveals: -20 mod 360.

Long story:
So yeah, I was thinking about Visible Damage and realized three things:
1. It is not possible to get the position of an armor segment on the ship in terms of a vector postion
2. the angle system feels odd when 0 is to the right of the ship
3. The angle system and the way that armorsegments are laid out are contradictory.

Ok, think about this problem: how can you create weaponfire at a certain armorsegment on a ship?

Since there is no function for finding the location of a specific armorsegment and that itmGetArmorInstalledLocation returns the segment # and NOT the location on the ship, I was forced to improvise.

Given that, I turned to this equation: (multiply i (divide 360 (shpGetArmorCount gSource))).
It basically multiplied i (which is the armorsegment #) by the value of a single armor segment when there are (shpGetArmorCount gSource) armorsegments and 360 degrees in a circle.

Now, I expected that to work, but then I had to factor in the facing of the ship as well.

This resulted in some more research.

I then incorporated (shpGetDirection gSource) to create (modulo (add (shpGetDirection gSource) (multiply i (divide 360 (shpGetArmorCount gSource)))) 360) so that I would take into account the playership's direction.

This was when it became apparent that 0 is to the right of the playership when at facing 0 (for the sapphire at least), making very awkward to approximate the angle of each armorsegment, after I had already given up on using sysVectorPolarOffset to approximate the distance of a specific armorsegment from the center of the ship. This resulted in a couple of problems:

1. My system and the angle system are not aligned, nor are they oriented similarly (my approximation using the armorsegment is clockwise, the Transcendence system is counterclockwise)
2. I had also realized that it was not possible (or at least, really, really hard) to use the armorsegment number to get the angle, as they are also numbered clockwise and against the counterclockwise nature of the angle system in T.

I then constructed a way to convert from my clockwise system to Transcendence's counterclockwise system, resulting in:

Code: Select all

(modulo (subtract 360 (multiply i (divide 360 (shpGetArmorCount gSource)))) 360)

This subtracted the armorsegment value from 360 and then converted that value to the counterclockwise system, which resulted in an accurate angle only when the Sapphire was at facing 0.

However, I still had to account for the ship direction.

After lots of testing, and furious sleepless nights, I came up with this monstrosity for approximating the angle of a specific armorsegment using its number:

Code: Select all

(modulo (add (subtract (modulo (subtract (shpGetDirection gSource) 90) 360) (multiply i (divide 360 (shpGetArmorCount gSource)))) 90) 360)

What it does is it converts the normal ship angle from Transcendence's counterclockwise system into my clockwise angle system, then adjusts for the ship angle, then converts it back to the counterclockwise angle system.

Then after further testing, it seems apparent that for armorsegment values such as 2-3 for when the ship is facing 0-90 in the counterclockwise system, my formula still wasn't right. It was then that I tested using

Code: Select all

(block Nil
				(dbglog(modulo -20 360))
				)

and now, instead if returning 340, Transcendence returns -20. :/

[alterecco]

If you have negative angles, then you have to subtract the value from 360. e.g.:

Code: Select all

(setq i -20)
(if (ls i 0)
  (setq i (add 360 i)) ; i use add because we are adding a negative number... that ends up subtracting
)
; i should now be 340, and 340 modulo 360 is... 340
(setq yay (modulo i 360))

[RPC]

Thank you alterecco!
It seems I am always one step away from perfection

[george moromisato]

The modulo operation is not well-defined, apparently: http://en.wikipedia.org/wiki/Modulo_operation

I'm doing whatever MS Visual C++ does, which is returning the remainder (and the sign is positive if both dividend and divisor are positive; negative otherwise).

Perhaps we need a new function that wraps around like Google does.

[RPC]

Ok, because I thought that the modulo function was the modular arithmetic.
I am okay with another function for modulo arithmetic that wraps around, that seems appropriate.

[alterecco]

I think part of the problem in this case is that one has to realize that there are no negative angles. As for a wraparound modulo... sure, why not :)

[RPC]

Ok, quick note:
Now I realize why I was confused about the angles. Although syscreateweaponfire starts out to the right, using the <Configuration> tag in a weapon starts instead to the front of the ship, and wraps around counterclockwise. I had expected it to be the same for sysCreateweaponfire, but it wasn't. I'll make a ticket about the new function, maybe call it

Code: Select all

(modularArithmetic number)

that wraps around.

[Vachtra]

I don't understand something it seems. What's wrong with -20 as an angle. In my experience with other applications an angle of -20 is the same as 340 or -380 or 700. The negative being only a description of the direction the angle is turning, negative to the left positive to the right. and anything past 360 merely wraps around again.
Please forgive any ignorance on my part here.

[ShaunWilkinson]

the problem at the minute as far as I can see is that it doesn't wrap around vachtra

[RPC]

Vachtra: With my limited knowledge, yes -20 is ok as an angle, but the issue was that if I plugged in into my equation, then the formula doesn't work, as I can't use negative angles for a function.

[Atarlost]

Code: Select all

(setq angleNormalize (lambda (angle)
			(block nil
				(loop (ls angle 0) (setq angle (add 360 angle)))
				(modulo (add 360 angle) 360)
			)
		))

[Star Weaver]

Dang, Atarlost, I was going to suggest normalize.

Or possibly just making all the angle-using functions normalize out of bounds angles properly instead of clipping them. How much overhead would something like atarlost's function done nativly add to the game? Possibly add a (if > 360) if that's cheaper than modding a number that doesn't need it.

[Amariithynar]

Vachra, the problem is that within a single arc, there exists only the degrees 0* through 360*. There are no negative angles- if you were at 0* and added -20 degrees, then you'd not get -20*, but 340*. While more basic arithmetic does allow negatives added to positives, and the existence of negative numbers, internal angles are always positive- And in our case, we're drawing a circle (the turret fire arc) from the inside.

best I can describe it, hope it helps.