GITEdit: What do you guys want?:)

[Fair Strides 509]

Well, as the title says, this is about GITEdit.

 

GITEdit is a program I'm making to give a visual interface to edit the file, as opposed to the tree view of K-GFF that I despise(not the program, just the layout)...

 

Currently, the program can:

 

• Load .git files from the .rims, .mods, and override
• Parse TLK references
• Count the number of each type of file
• Provide an interface to each file type
• Allows you to input degrees for the bearing and orientation
• Compiles each file type into a list
• Can delete items from the lists

 

But I'm at a loss as to what functionality to add to it. I will add the ability to copy and paste item types as soon as I look up the XML parsing. Adding new items of a specific type will be implemented shortly.

 

Currently, as the program stands, here's what I've got for you:

 

 

 

 

 

So, if anyone has any requests, please feel free to share.

[Hassat Hunter 571]

Sure, NOW someone makes a tool that doesn't make custom camera-points a total pain in the butt that took more time than anything else :/

Probably should add the warning NEVER to place .GIT files in override except for testing purposes. Before modders go all dropping them there in their mod releases.

 

Also, while we all understand UTC, UTW, UTP, UTS and stuff for the laymen editor it's probably nice to add stuff like "NPC's, waypoints, doors, sounds" to it.

Aside from that; can't think of anything.

 

Maybe also add support for the other area files (ARE and IFO).

[Fair Strides 509]

Well, HH, would you like to be a beta tester for it?

Also, The "extended" file purposes are implemented as tool-tips when you hover over the section.

 

And...

 

Just so you know, KT's Module Editor also does the camera angles, you just need a map texture in .jpeg format and rename the extension to .map...

[Hassat Hunter 571]

Never really use KOTORTool much except to check out what to change with KGFF and add inventories to NPC's (which works so weird, and manually adding them in KGFF does nothing).

Zbyl already tires of me... let's not start forcing him to re-add .tlk entries or translations to my files

[Fair Strides 509]

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...

[Malkior 476]

Is this what you mean?

 

http://www.java2s.com/Code/Perl/System-Functions/Convertsfromdegreestoradians.htm

 

Basic script to convert degrees to radians in perl.

 

 

Personally not a fan of radians. (Except you get to write pi all the time :& )

[Fair Strides 509]

Is this what you mean?

 

http://www.java2s.com/Code/Perl/System-Functions/Convertsfromdegreestoradians.htm

 

Basic script to convert degrees to radians in perl.

 

 

Personally not a fan of radians. (Except you get to write pi all the time :& )

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...

[Mandalore 61]

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...

Not sure if this helps, but the rate of change (gradient function) of y=sin(x) is cos(x) and the gradient function of y=cos(x) is -sin(x).

[Fair Strides 509]

Not sure if this helps, but the rate of change (gradient function) of y=sin(x) is cos(x) and the gradient function of y=cos(x) is -sin(x).

 

Well, that'll be worth experimenting with.

 

However, I'll just be releasing a version of GITEdit tomorrow that doesn't bother with fixing the issue.

 

Instead, I'll put boxes for the X and Y Orientation and pretty much nulling the circle graph and the degree input...

[Vriff 21]

That's about as far as I've gotten too.

 

If the sin is between 1 and -1, and the cos is between 0 and -1, the angle is between 90 and 180.

Maybe it's a typo, but that is wrong. if cos() returns a value <= 0 && >= -1 and sin() returns a value <= 1 && >= 0 then angle >= 90 && <= 180.

 

Likewise, if..

 

cos() returns a value >= -1 && <= 0 and sin() returns a value <= 0 && >= -1 then angle >= 180 && <= 270.

 

and

 

cos() returns a value >= 0 && <= 1 and sin() returns a value <= -1 && >= 0 then angle >= 270 && <= 360/0.

 

 

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...

 

If your facing is 180 degrees. cos should return -1, and likewise sin should return 0. (-1,0) = 180 degrees or pi radians. It seems your understanding of radians may be a little skewed. 1 radian does not equal pi. pi of what? You can't convert a unit into a unitless number. 3.14159265 radians = 180 degrees or one half turn to the left.

 

Note: If you're setting that integer to 180, then you are setting it to 180 radians, not 180 degrees. That is 28 full turns, then a partial turn of .6478898.

 

If your user is wanting to set an orientation of 180 degrees then you should do something along the lines of:

 

int facing = GetFacing(oPC);

 

float radianV = (oPC * (pi/180));

[Fair Strides 509]

Maybe it's a typo, but that is wrong. if cos() returns a value = -1 and sin() returns a value = 0 then angle >= 90 &&

 

Likewise, if..

 

cos() returns a value >= -1 && = -1 then angle >= 180 &&

 

and

 

cos() returns a value >= 0 && = 0 then angle >= 270 &&

 

 

 

If your facing is 180 degrees. cos should return -1, and likewise sin should return 0. (-1,0) = 180 degrees or pi radians. It seems your understanding of radians may be a little skewed. 1 radian does not equal pi. pi of what? You can't convert a unit into a unitless number. 3.14159265 radians = 180 degrees or one half turn to the left.

 

Note: If you're setting that integer to 180, then you are setting it to 180 radians, not 180 degrees. That is 28 full turns, then a partial turn of .6478898.

 

If your user is wanting to set an orientation of 180 degrees then you should do something along the lines of:

 

int facing = GetFacing(oPC);

 

float radianV = (oPC * (pi/180));

 

I'm using the understanding of radians that the community has been using for the past decade...

[Vriff 21]

I'm using the understanding of radians that the community has been using for the past decade...

Then 1 radian equals pi of what? 1 radian = 57.29 degrees, 1 π radian = 180 degrees.

 

If your user wants to set a rotation of 180 degrees, then to calculate the sin/cos the radian value perl needs is 3.14.

[Fair Strides 509]

Then 1 radian equals pi of what? 1 radian = 57.29 degrees, 1 π radian = 180 degrees.

Sorry. Originally, when I wrote the statement, I had been thinking of 180 degrees, not 1 radian.

 

I'd been frying on the issue for about a week with no interruption, so I was kinda burnt out on the train of thought...

[Vriff 21]

So what exactly does the game read in to figure the rotation of creatures?

[Fair Strides 509]

So what exactly does the game read in to figure the rotation of creatures?

That would be the Example I gave above. That was how one would get the right numbers from inside the game.

[Vriff 21]

That would be the Example I gave above. That was how one would get the right numbers from inside the game.

Gotcha, so this is where I am confused. So are you replicating this behavior inside of your program or is your program supposed to set the creature's rotation to a radian to then be read by the game with this behavior?

[Fair Strides 509]

Gotcha, so this is where I am confused. So are you replicating this behavior inside of your program or is your program supposed to set the creature's rotation to a radian to then be read by the game with this behavior?

 

Basically, I want to allow the user to put in the degrees and have the program mess with the radians, sin, cos, asin, and acos behind the scenes.

[Vriff 21]

Basically, I want to allow the user to put in the degrees and have the program mess with the radians, sin, cos, asin, and acos behind the scenes.

Okay, got that. How exactly is creature orientation stored in the GIT file? Say, a creature is at a 90 degree angle, how is that represented is what I'm maybe missing or not understanding clearly?

[Fair Strides 509]

Okay, got that. How exactly is creature orientation stored in the GIT file? Say, a creature is at a 90 degree angle, how is that represented is what I'm maybe missing or not understanding clearly?

The angle is stored as an X Orientation and a Y Orientation, the X being the cosine of the angle and the Y being the sin of the same angle.

 

The issue I have is that Perl's sin and cos functions are incapable of traversing the 180-degree boundary, with any number over 180 being halved before conversion to a radian.

[Vriff 21]

The angle is stored as an X Orientation and a Y Orientation, the X being the cosine of the angle and the Y being the sin of the same angle.

 

The issue I have is that Perl's sin and cos functions are incapable of traversing the 180-degree boundary, with any number over 180 being halved before conversion to a radian.

How are you storing this number? you should convert say 270 degrees (by means of 270 * pi/180) to a float(or whatever the equivalent is in perl) representing 4.71238898 radians, then execute sin and cos on that float value.

 

pseudocode:

 

user_input_degrees = 205; (example value)

 

float radians = user_input_degrees * (pi/180);

 

x = cos(radians);

y = sin (radians);

[Fair Strides 509]

How are you storing this number? you should convert say 270 degrees (by means of 270 * pi/180) to a float(or whatever the equivalent is in perl) representing 4.71238898 radians, then execute sin and cos on that float value.

 

pseudocode:

 

user_input_degrees = 205; (example value)

 

float radians = user_input_degrees * (pi/180);

 

x = cos(radians);

y = sin (radians);

 

Okay, I just tried it and it works flawlessly.

 

...Now how would you recommend I do the inverse?

[Vriff 21]

Okay, I just tried it and it works flawlessly.

 

...Now how would you recommend I do the inverse?

What do you need those for?  Reading in from a GIT file to see the orientation in degrees?  (This will be my last post of the night, I'll pick up from here tomorrow).

[Fair Strides 509]

What do you need those for?  Reading in from a GIT file to see the orientation in degrees?  (This will be my last post of the night, I'll pick up from here tomorrow).

 

Exactly. And I imagine you're tired, so get a good night's rest.

[Vriff 21]

There's a way to do this, It's hard to differentiate between quads sometime.

 

For example..

30 degrees and 150 degees can't be told apart by their sin values. 

 

sin(30) = .5

sin(150) = .5

 

so we have to examine their cosine values.

cos(30) = 0.866

cos(150) = -0.866

 

Therefore we can tell them apart by their cosine inverse values.

arccos(0.866) = 30

arccos( -0.866) = 150

 

What we can use the sin value for is to differentiate quadrants using a comparison operator.

 

if YOrientation < 0 then the degree is more than 180, if the XOrientation is also less than 0 then the degree is less than 270.

 

Some psuedo code would be like..

 

float XOrientation;

float YOrientation;

float degrees;

 

degrees = (arccos(XOrientation) * Pi/180);

 

If (YOrientation < 0)

degrees = degrees + 90;

 

If (XOrientation > 0)

degrees = degrees + 90;

 

For reference, the unit circle:

 

[Fair Strides 509]

Dude, I could hug you right now!!!:D:D

 

Using the code below, I am able to get angles up to 270 degrees, but no over. I'm currently working on solving the issue...

Note: I'm adding comments using the # symbol.

 

sub calc_quatcre                      # Name of the function
{                                              
    my $camx = shift;                  # This and the next 6 lines (counting the empty line) are declaring variables
    my $camy = shift;                

    my $quat1;
    my $quat2;
    my $quat1_deg;
    my $quat2_deg;

 

    if($camx >= 0)                      # If the X Orientation is greater than 0.0
    {
        $quat1 = acos($camx);    # Standard inverse of cosine
        $quat2 = asin($camy);     # Standard inverse of sine

        $quat1_deg = $quat1 / ($pi/180); # Convert from radian to degree
        $quat2_deg = $quat2 / ($pi/180); # Convert from radian to degree
    }
    else                                      # If X Orientation is below 0.0
    {
        $quat1 = acos($camx);    # Standard inverse of cosine
        $quat2 = asin($camy);     # Standard inverse of sine

        $quat1_deg = $quat1 / ($pi/180); # Convert from radian to degree
        $quat2_deg = $quat2 / ($pi/180); # Convert from radian to degree

        $quat1_deg += 270; # Add 270, to equal the real measure
        $quat2_deg += 270; # Add 270, to equal the real measure
    }        

    my @calc_cam = ($quat1_deg, $quat2_deg); # Make a list using the two variables
    return @calc_cam; # Return the list
}