Fair Strides

GITEdit: What do you guys want?:)

Recommended Posts

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:

 

 

GIT1_zps6d26af69.png

GIT2_zps56f221e6.png

GIT3_zps842b9408.png

GIT4_zps7ec9f5ed.png

GIT5_zps47b72ac9.png

GIT5a_zps0e235658.png

GIT6_zps73ae75e1.png

GIT7_zps8fc43114.png

GIT8_zpsdc4bcb2f.png

GIT9_zpsb2e4ddfe.png

GIT10_zps9bebbfad.png

 

 

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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));

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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);

Share this post


Link to post
Share on other sites

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?:P

Share this post


Link to post
Share on other sites

Okay, I just tried it and it works flawlessly.

 

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

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

 

unit-circle7_43215_md.gif

  • Like 1

Share this post


Link to post
Share on other sites

Dude, I could hug you right now!!!:D: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
}

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.