Anatomy of the .git file

[Seamhainn]

Introduction

 

EDIT01: A BIG NOTE: Something I forgot to mention during my first write down is (my bad!), that I found out most or all the stuff mentioned here with the friendly help of many members of this community, to many admittedly to mention!!!

 

The .git file is used in every module to spawn and arrange certain things in said module when the pc enters it for the very first time.

 

To work with and manipulate the .git file of a module you need two programs which were created by members of the community, and we can’t thank enough both of them for doing so!.

 

First it is KotOR Tool, second it is K-GFF, and both (beside many other useful tools) you can download from here: http://www.starwarsknights.com/tools.php

 

One thing of note: If you want to familiarize yourself with the .git file you must keep in mind that if you make changes to that file, it is NOT enough to save the .git file into your override folder like you do with many other mods. If you want to change a .git file to use it with a mod you must create a .mod file for the appropiate module. Don’t sweat though that task can easily be done with KotOR Tool (which you have already downloaded by now, right?).

 

The .git file has a certain notation in every module. As I worked on the Taris Black Vulkar Base lately for some time I will take it as a guiding example. Open KotOR Tool. Goto -> RIMs -> Modules -> tar_m10aa.rim -> Dynamic Area Info -> m10aa.git. This is the .git file for that particular module of the Black Vulkar Base on Taris.

 

Every .git file has the notation m+a two digit number+two letters (in this case: m+10+aa = m10aa.git). This usually corresponds with the name of the module itself which has three to four letters+_ infront of the before mentioned designation. In our case “tar” (which stands for Taris) plus “_” plus “m10aa” ( = tar_m10aa).

 

To know that is quite useful because with the warp cheat you can test your manipulations later. Note that if you test your changes it is crucial that you warp to the module from a state BEFORE you ever have entered that module! To do that open the cheat console and type in “warp tar_m10aa” and return. This should bring you to that module.

 

Okay, if you don’t want to mess with your game, I advice that you do something similar that I did. If I work on a certain module I create a new subfolder in my SWKOTOR -> override folder and name it exactly like the module I am working on. So I advice that you create a folder in your override folder and name it “tar_m10aa”.

 

If you open KotOR Tool and go to tar_m10aa.rim and click on it, you’ll see a button in the upper right hand corner which says “Extract entire RIM file”. If you click on that button you are prompted to designate a save. Chose the above mentioned folder tar_m10aa. (Maybe it is adviceable that you check if you extracted the files properly. If you open up Explorer and look into the folder you should see three files, one of which is m10aa.git.)

 

In KotOR Tool click now on the next entry in the list which should be named tar_m10aa_s.rim. Here all the other files are stored like Creatures, Dialogues, Waypoints, Doors and so on. As we need to make a new module after manipulating the .git file we need that stuff. Click again on the button “Extract entire RIM file” and save the files in the same folder. Your folder tar_m10aa should now be shockful with all kinds of files (more on some of those later).

 

One of those files is – I mentioned it already – m10aa.git. (There is actually more then one file with that name. Be sure that you chose the .git file!) If you open that file from Explorer designate that it is always opened with K-GFF! Now you are ready to take a closer look into the anatomy of this secret tome.

[Seamhainn]

To be honest, I never messed with these entries. Also there are some remains of NWN. But as KotOR does not have a day-night cycle, the entries for MusicDay and MusicNight are the same. You can manipulate which music is played in this module while walking around and during a battle.

 

As Jeremy’s scores are some of the best ones every written, I can see no reason why one would want to change anything here.

[Seamhainn]

I am not familiar with the camera entries. Maybe one of the module makers can enlighten us.

 

From what I recall, the Camera List was entries for invisible placeables that was the 'camera' for game cutscenes that happened in that module, etc. I hope this helps. FYI, I'm editing this here because the way this was done to keep the info on this is this post, feel free to eliminate my ramblings if I am incorrect. -RH

[Seamhainn]

Now we reach where most of you were aiming for, be honest! In this entry list the game spawns all the npcs which are listed here. I’ll explain all those entries step by step to the best of my knowledge.

 

TemplateResRef: It may seem a bit harsh, but I must tell you that, to spawn a npc (or any other “thing” in the game for that matter) you need a certain other file (more on that later). To make the connection between the .git file you are working on now and that said file which holds all the information of – in this case – the npc you need a reference. This reference in our case is called TemplateResRef. So you must enter a name here. Where the connection is I’ll explain later. For test puposes type in “tar10_testy” (without the quotes).

 

Now that you decided WHAT to spawn, you must decide WHERE to spawn it. Usually you should have an idea where your npc should appeare in the module. If you have decided on that most crucial information go with your pc to that point in the game. Open up the cheat console and type whereami. You’ll get three numbers. Note them down as they will disappeare after a few seconds.

 

The first number denotes the XPosition, the second number the YPosition and the third number the ZPosition in the module. Don’t be shocked if the in-game npcs all have position entries with many numbers after the digit. The developers had a program to position the npcs with such accuracy. We don’t need that accuracy and entries with whole numbers or X.5 at the most are accurate enough.

 

Write in the numbers you gained via your whereami cheat.

 

There are two more entry possibilities: XOrientation and YOrientation. Those entries determine in which derection the npc “looks” when spawned.

 

I am not sure which entry is the more significant one, and if there is a certain rule of thumb. Maybe the community can help here. Regarding my experimentation I usually begin with the value 0 for XOrientation and 1 for YOrientation. If your newly spawned npc looks in a direction you don’t like try to increase the YOrientation in whole number (2 or 3). If you discover a rule here, please tell me.

 

EDIT01:

This thread has further information about rotating creatures:

http://lucasforums.com/showthread.php?t=185200

 

Now we must take a look at the corresponding file I talked about above. These files all have a name and an extension called .utc. Go to your tar_m10aa folder and COPY one of those .utc files into your tar_m10aa folder, but rename it before. For test purposes it might be adviceable to name it tar10_testy.utc. Open that file with KotOR Tool. KT will start the Creature Editor for you, and at the top of the window you see a menue. Click on the one called “Advanced”. In the part which is titled “Info” you can find a field that is called “Template ResRef”. (Does that ring a bell?) To spawn that particular npc you must write in here the exact name you entered in the .git file above (tar10_testy for example, see above and below).

 

Now you made the connection between those two entries, and now the game engine “knows” what to spawn at the point you designated in your .git file. Save the file, but make sure it ends in your tar_m10aa folder!

 

If you now create a .mod file as I discribe further down you now have spawned your first own npc.

 

Some things of note though.

 

I assume that you have a particular npc in mind if you want to spawn it. I found it very practical to follow the following rules for naming rules. Lets assume the name of your npc is Testy. I always set the name of the module infront of a (shortend) name of the npc. In this case it would be something like tar10+_+(shortend) name of npc ( = tar10_testy.utc). To bring the confusion to a minimum I always use that name (tar10_testy in this case) for the value in the field TemplateResRef of the .git file and the field Template ResRef of the .utc file (which MUST be the same!) as well as the field Tag (unter the manue “Basic” in the “Profile” area) which is also in the .utc file (and which must NOT be necessarily be the same). But that is just me, though I found these rules helpful and there might be circumstances which break these rules.

 

To be honest I don’t know what every single entry in the .utc file is good for. My intention is nevertheless to collect all these information in another thread.

[Seamhainn]

Doors in KotOR to the best of my knowledge have three purpuses in the game. The first one is purely estatic. That means you can see a door while the pc is walking around in an area, but you can’t interact with that door, meaning you can’t open it and you don’t get a reaction when you click on the door. It might be possibile that the developers intended that something is behind that door but during the creation of the game that part was cut off and for simplicities sake they placed a door at that point which can’t be opened. This might or might not be the case for every door which can’t be opened in the game. It might be also be the case that a long wall looked to boring, and so the designers decided to place a door there which can’t be opened. We just don’t know what is the backstory for each door which can’t be opened in the game. For some of those doors the community found hints what might have been intended to be behind them. But that is a matter for another thread.

 

Second there are doors which just open other rooms in the SAME area. Usually these doors open when you click on them in the game. Sometimes you have to break them open by pure force because they are locked. Then again you need a keycard or you must pay a fee at some spaceports. Those things are all declared in a correcponding file which hase a .utd extension. What all the properties of such a .utd file are and what they do must wait for another thread. Ultimately I can’t see no reason why you would want to manipulate any of these doors which are in-game. But it is your game, and you can mess them up as much as you want. To make the proper connection with the .utd file you must enter the corresponding values of the Tag field and the TemplateResRef field of the .utd.file.

 

The third, last and maybe most interesting effect of doors is that they can transit you to another module! Placing a door is very similar to placing a creature/npc so I will not cover it again here. The other entries which make your transit to another module are as follows:

 

LinkedTo: This is a waypoint where you will appeare in the desired module. More on waypoints later.

 

LinkedToFlags: This entry must be set to 2. Don’t ask me why.

 

LinkedToModule: This is the name of the module where you want to make the transition to. If you open KotOR Tool and go to RIMS -> Modules you can find a list of all the modules which are in the game.

 

TransitionDestin: If you transit to a new module in the game a box appearse which denotes where the transition will take you to. You must know that (most) every written word in the game has a connection to a file in which all those text is stored. That file is called dialog.tlk and can be found in your SWKotOR folder. (Essentially this file determines which language version you are using.) Every written line has an entry in dialog.tlk. You can make an entry into the TransitionDestin with a number. That number corresponds with the entry number of dialog.tlk. If you want to view what is written in dialog.tlk I advice to download the very handy program TalkED from the link in my very first post.

 

Admittedly if you don’t find a proper entry in the dialog.tlk file not everyting is lost. (Be warned messing with dialog.tlk is usually not a good idea unless you know 100 percent what you are doing.) If you type “-1” (without the quotes) into the TransitionDestin field and after right click on TransitionDestin a window pops up. If you click on “Add String” you get the opportunity to write in something after your own liking. By typing in “-1” you also break the connection to the file dialog.tlk.

 

This thread has more information about transitioning (though with the help of triggers, but the fundamental stuff is essentially the same): http://www.lucasforums.com/showthread.php?t=180447&highlight=Transition

 

This thread has more information about rotations of doors:

http://lucasforums.com/showthread.php?t=185200

[Seamhainn]

.....

[Seamhainn]

.......

[Seamhainn]

Placeables – to the best of my knowledge – have two purposes in KotOR. One is purely estatic. You can encounter many “things” in the game which are placeables. This can be crates, footlockers and so on, as well as corpses, rubble etc., but also a computer terminal. Those can be brought into the game only to make an area look interesting, and the pc can’t interact with these placeables.

 

The second category are placeables with which the pc can interact. These placeables are the ones I mentioned above, but all have something “inside” and/or you can converse with these placeables. “Inside” means it might be in a footlocker or “in” a Wookiee corpse. You can see what is “inside” these paceables in-game by clicking on them. Then a window appearse and you can grab all those goodies. (You played the game, so you know what I speak about.) In case of a terminal you might even be able to start a “conversation” with said terminal.

 

All those interactions with the pc are declared (similar to a creature/npc) in files which have a .utp extension. The properties of such a .utp file must – again – be explained in another thread.

 

To make a long story short, everything I said about spawning a creature/npc goes for placeables also. Be warned though that finding the proper position for a placeable can be a real pain if it has to be alligned against a wall or something similar. Try and error is your friend here.

[Seamhainn]

The SoundList offers the opportunity to implement sounds in the game which gives it an air of autenticy and realism.

 

Again the entry in the .git file corresponds with a .uts file where all the specifics are determined. In the .git file you type in the location where the sound is located (with XPosition, YPosition and ZPosition). Generated Type, to the best of my knowledge is always set to 0. The entry in TemplateResRef corresponds with the appropiate entry in the .uts file as mentioned above.

 

Also as mentioned earlier without the .uts file the entry in the .git file does nothing. In the .uts file you can adjust the volume, in which area the sound is heard, and so on. And again those specific must be explained in a separate thread.

[Seamhainn]

........................

[Seamhainn]

Triggers in KotOR to the best of my knowledge are used to accomplish several things in the game. They can be used to trigger (!) a conversation, a transition to another module in the game, start a fight and more things.

 

Which these “things” are is declared - you expected it by now – in a corresponding .utt file. And again – you expected that by now already too – that .utt file must be explained in another thread.

 

So how do I place a Trigger? Placing Triggers are different to other things which can be spawned with the .git file in so far, that Triggers define an area. That particular area can be a triangle or a rectangle.

 

Okay, by now you know how to get coordinates in the game with the whereami cheat (I hope). Declare the center of your trigger area and get the coordinates. In this case don’t look at the center as the real centerpoint of the trigger area. Center in this case means it is the point from which you make your calculations (see below).

 

Now that you declared your center point you need three or four more coordinates. These coordinates form the cornerpoints of your trigger area (three if you want to make a triangle, four if you want to make a rectangle).

 

Note those coordinates down. Lets assume that your “center” coordinate is 109, 80, 0. Then you have to enter these values in the XPosition, YPosition and ZPosition fields.

 

Now take the first coordinate which you took for the first cornerpoint. Lets assume that this coordinate is 111, 85, 0. Then go to the first set of PointX, PointY, PointZ. Now you must do some calculations: suptract 109 from 111, 80 from 85 and 0 from 0. You should get the results: 2, 5, 0. Enter those results into PointX, PointY, PointZ.

 

Lets assume the next coordinate is 103, 65, 3. Now subtract 109 from 103, 80 from 65 and 3 from 0. You should get –6, -15, -3. Enter those values into the next PointX, PointY, PointZ block.

 

Go on with all your cornerpoints. If you use a triangle the fourth PointX, PointY, PointZ all have the value 0.

 

Please note that you have to determine the cornerpoints in-game. I made the experience that it does not work to just use the values 5, 5, 0 / -5, 5, 0 / -5, -5, 0 / 5, -5, 0 if you want a 10 by 10 rectangle. If one or more of those points is outside where the pc can actually walk in the game the trigger does not work correctly. So you must take the exact coordinates with the whereami cheat for every cornerpoint.

 

In TemplateResRef you must type in the name of the TemplateResRef which is used in the corresponding .utt file.

 

What the entries in XOrientation, YOrientation and ZOrientation do I don’t know admittedly.

 

You can find further information about Triggers here: http://lucasforums.com/showthread.php?t=145870

[Seamhainn]

................................................

[Seamhainn]

The entries in the WaypointList of the .git file correspond with a .utw file. Again, the specifics of said .utw file must be explained in another thread.

 

Nevertheless it can be explained here what waypoints are used for. It is possible to spawn creatures etc. at waypoints. Also you can make npcs/creatures walk to a waypoint, and you can make npcs walk along a predetermined path of waypoints. All those accomplishments can be done with scripts. How those scripts must look like and how they are compiled is the topic of various other tutorials here on the forum.

 

Waypoints are also used to make certain points and notations appeare on the map. In-game you have a mini map in the upper left hand corner of the screen. By double clicking on it you can expand the map, and then you can see certain importend points on the map (if the pc/party already reached that point). Those map notations are also done with waypoints.

 

If you want to know more about making npcs walk certain waypoints and how the naming convention for those waypoints must be read this tutorial: http://lucasforums.com/showthread.php?t=142290

 

Okay, what are the properies of the waypoint entries?

 

Appearance: I encountered values of 1 and 4, but admittedly I don’t know what those entries are good for.

 

Description: This field is usually set to -1. But by right clicking on it and after clicking on Add String you can enter whatever you want. I never tried it but you could also make a connection with the dialog.tlk file, although I don’t know why one wants to do that.

 

HasMapNote: This value usually is 0. If you want the waypoint as a notation on the map the value must be set to 1.

 

LinkedTo: This field, as far as I know, is usually empty.

 

LocalizedName: If you want that a map note appearse on the map, you must type in the value 349 here. You can type in whatever you want here, and also by rightclicking and Add String you can make any entry. But for a map note that looks like all the others in-game the entry must be 349.

 

MapNote: You can make a connection with the dialog.tlk file here. The corresponding entry will appeare on the map with what is entered in LocalizedName as a prefix. You can make your own entries by right clicking and Add String here.

 

Tag: The entry in the Tag field of the corresponding .utw file. But see the turtorial for walking waypoints further above.

 

TemplateResRef: The entry in the TemplateResRef field of the corresponding .utw file.

 

XOrientation: I don’t know what the orientation is used for.

 

XPosition: The first value which you get with the whereami cheat if your pc stands exactly where the waypoint is.

 

YOrientation: I don’t know what the orientation is used for.

 

YPosition: The second value which you get with the whereami cheat if your pc stands exactly where the waypoint is.

 

ZPosition: The third value which you get with the whereami cheat if your pc stands exactly where the waypoint is.

[Seamhainn]

Making a .mod file isn’t actually very difficult.

 

Open KotOR Tool.

 

In the upper left hand corner you can see four small buttons. Click on the one titled “ERF”.

 

A window opens. In the first entry field type in “tar_m10aa.mod” (without the quotes!).

 

Click on the button “Add dir…” go to the folder you named tar_m10aa. Click on “OK”. If you are asked if KT should filter out unused files you should confirm that. In the drop down menue in the upper right corner of the window select “MOD”.

 

Now you can click the button “Build MOD”. After a few seconds a confirmation window should appeare that confirms that the .mod file is created.

 

Depending on where you designated the save for your .mod files a file called tar_m10aa.mod is created there. Paste that file into your SWKOTOR -> modules folder (NOT your override folder).

 

From now on, if you go to that module for the very first time (in-game or by warping to it) the game uses your newly created .mod file instead of the in-game one.

 

Enjoy!