Fair Strides

That's about as far as I've gotten too. The main issue isn't the conversion, but the sin and cos functions, and their opposites asin and acos. Mainly, I can't tell the difference between angles above 180 from angles below. My brain's frying out on it, but here's a breakdown of sin and cos: 0 degrees: sin = 0; cos = 1 90 degrees: sin = 1; cos = 0 180 degrees: sin = 0; cos = -1 270 degrees: sin = -1; cos = 0 360 degrees: sin = 0; cos = 1 If you'll allow me to think things through while typing... If the sin is between 0 and 1, and the cos is between 1 and 0, the angle is between 0 and 90. If the sin is between 1 and -1, and the cos is between 0 and -1, the angle is between 90 and 180. Currently, this all works fine, due to the asin and acos functions. However, I rely on those functions for the answer, and might have to do the math myself... If the sin is between 0 and -1, and the cos is between -1 and 0, the angle is between 180 and 270. Yet if the sin is between -1 and 0, and the cos is between 0 and 1, the angle is between 270 and 360/0. In the end, I might just have to do a bunch of manual math based on the difference in sin and cos between 1 degree and 2 degree(the rate of change for a single degree)... Okay, the rant's over...

The orientation for creatures involves rotations on the X and Y axes, which the engine handles in the form of radian rotations around a circle. When the game handles it, the X Orientation is calculated with the cosine of the angle's measure (most likely in degrees). The Y Orientation is handled with the sine of that same measure. That is all fine and dandy, except for one issue: Perl deals in radians, and I'm trying to let a user handle the orientation in degrees. You see, when one gets the X and Y Orientation via scripting within the game, they pass the facing of the object in question in degrees and use the sin(sine) and cos(cosine) functions on the facing. This means that the game handles and treats sin and cos in degrees. Example: void main() { // Get main PC object oPC = GetFirstPC(); // Set PC's facing to 180 degrees(calculated from the East in-game, which corresponds to the right on the area's map) AssignCommand(oPC, SetFacing(180)); // Now get the facing and store it int iFacing = GetFacing(oPC); // Here's where Perl and Aurora Engine diverge... float fXOrientation = cos(iFacing); float fYOrientation = sin(iFacing); } Notice that I just sent the degrees to the cos and sin functions... Unfortunately, Perl uses radians for the cos and sin functions, which means that it expects to get passed radians as an argument and will return radians as an answer. And with 1 Radian = Pi (3.1415926535897932384626433832795 and then some...), no matter what conversion or transformation I apply, I can only get answers that are at or below 180 degrees... .................................................. .................................................. .... I could modify the .utc and .utw(all that was said above applies to waypoints as well) section to allow for input of the X and Y Orientation, but that would also disable/screw up the circle above it that gives a visual indication of the rotation... So, what do you guys want me to do here? If anyone can do it, I'd like to talk to this guy, since he was able to do half of what I want/need to do...

That would depend on how those individual mods install, and how the installation affects any files that might already have been in the game... Which ones were you thinking of (with links, if possible)?

Currently, no. If someone who knows both really well wants to make a translation, then we'll implement it, otherwise, we really don't have the facilities for it...

I'll take a look at the file sometime. If I can figure out where Silveredge meant it to go, I'll just put it into that module's .mod file, instead of the override folder. As to the Duros on Taris, since his lines were Bith but his appearance Duros, do you guys think we should change the appearance or the audio? Either way doesn't involve much effort. Or should we just leave him as-is in vanilla?

It was decided recently (within the past week), that we will not make K1R compatible with BoS:SR or Recruitable Kay. Instead, I will make separate patches for both mods at a later date... However, that is assuming nothing goes wrong when one simply installs BoS:SR over K1R, which could happen due to scripts.

Not yet, but I'll send a PM to Magnus2 tomorrow.

Not really sure the dwk would help with that, I'm afraid... It's to do with the perimeter edges, which wasn't the focus of WalkSwitch... As to the last part, "Yay! Someone else likes Perl...:P"

Well, I uploaded a new version in the Modding Tools section in the Downloads area. That should fix it.