Jump to content

Home

Kotor Tool - v1.0.2210.16738 (2006-1-19 12:38)


Fred Tetra

Recommended Posts

  • Replies 1.6k
  • Created
  • Last Reply
Originally posted by Fred Tetra

It's never a bother to hear what folks would like to have in Kotor Tool.

 

Re:

#1 - I'll put it on the to-do list. Do you want it to highlight the cells as each succesive find is done, like in a text editor, or do you have something else in mind?

 

 

Just like text editor is good.

 

Originally posted by Fred Tetra

It's never a bother to hear what folks would like to have in Kotor Tool.

 

Re:

 

#2 - Since it is a GFF file and I am working on the GFF (re)writer portion of the GFF class in Kotor Tool, I'm not that far away from being able to write editors for various "flavors" of GFF-based files. Area (.ARE) files have the most votes so far, however.

 

Glad to hear that :) I might be able to help with the format of those various "flavors" if you happen to need it.

 

Edit: NVM about helping with the format. I just looked up the bioware site and it has full documentation of it, heh :)

Link to comment
Share on other sites

Hey Fred, I have a suggestion for a future version of Kotor tool.

I find when Im useing Kotor tool sometimes It can take a while to scan through all the different files and file type's. So I often will load NWN Explorer to find out where an elusive file is. I would prefer to use your program than to have them both open ,also some of KotOR's files will crash NWN explorer.

 

Suggestion: Is for there to be subtrees that orginize the Games file types into there respective Catagorys. Useing a similar method as NWN explorer. This feature would greatly enhance the usabilty of your awesome Tool.

 

Thanx. :)

Link to comment
Share on other sites

Originally posted by T7nowhere

Hey Fred, I have a suggestion for a future version of Kotor tool.

I find when Im useing Kotor tool sometimes It can take a while to scan through all the different files and file type's. So I often will load NWN Explorer to find out where an elusive file is. I would prefer to use your program than to have them both open ,also some of KotOR's files will crash NWN explorer.

 

Suggestion: Is for there to be subtrees that orginize the Games file types into there respective Catagorys. Useing a similar method as NWN explorer. This feature would greatly enhance the usabilty of your awesome Tool.

 

Thanx. :)

 

I had considered doing it that way, and still may, but MS's TreeView control isn't the fastest to manage in code. If folks don't mind waiting for the items to be sorted out then have a tree built accordingly, it could probably be add to the list of future features.

Link to comment
Share on other sites

Originally posted by Sunslayer

How about a find option in the main window? Just like you get in a text editor. And if it's not in the 2DA editor, how about there, too?

 

While a 'find' feature for the main tree might seem like an easy task, it requires that all tree nodes be realized to work. What you may not know is that when you "open" a "+" node, many times I am building the leaves underneath just before you see them. In this way, you don't have to wait for the whole tree to be built (and it does take a while, especially for the RIMs section, since you have to open, scan, and build for each one. Perhaps I could have it do the full build only if you choose to find.... hmmm.....

 

As for the 2DA editor, I've got a find feature for that in mind, too.

Link to comment
Share on other sites

Features planned...

 

- Complete GFF Writer function to provide infrastructure for GFF editing.

 

- Area editor (.are)

 

- Save editor (maybe)

 

- 2DA find function

 

- Resource categorization on Tree View

 

- Full tree find function

 

- BIF builder

 

- RIM builder

 

- Auto update notification ("A new version is available...")

 

Fred's request list:

 

- A Teletubby skin and 2DA fileset so I can use it with Master Vandar (sp?) as the main PC

 

- Postcards/stamps/coins from foreign countries

 

- More chocolate :)

Link to comment
Share on other sites

GFF's are dealt with at three levels, the first two of which the user does not see. The first is the reading and writing of the data in the file to and from an internal representation, and the second is dealing with that data in a logical fashion that doesn't care about how it exists on disk. This second level knows how to add a structure to a list, how to find the value of a variable that exists in a list, etc., but doesn't know (or care) how that data was organized on the hard drive)

 

The third level is the one the user sees. Since there are many game data structures that use GFF to hold their information, each would have its own editor. These editors don't have to be concerned with reading and writing of disk files, so coding them is easier. They just have to be written to manage and display the data that is pertinent to the specific content of the file type in question, be it an Area or Creature file.

Link to comment
Share on other sites

Just an update on the GFF effort -

 

I discovered that there are at least two field types that are not found in BioWare's GFF specifications. These two new types are used (for example, but not exclusively) to represent the Position and Orientation of items in the CameraList list.

 

Also, these types are not supported by the GffEditor program. If you try to open and save a file containing these types, they will be ignored and the file will be smaller when you're done. Perhaps quite obvious is the fact that you can't edit attributes of that use those types in their representation. An example of one of these files would be m02ae.git.

Link to comment
Share on other sites

I noticed Field Type 17 during my investigations into savegame editing. It seemed like it always pointed to 12 bytes of NULL in the Field Data table. In the savegame editor I'm working on, I made the assumption this would always be the case whenever the editor writes a savegame. I haven't found a case yet where the edited/unedited savegame miscompares due to Field type 17 data.

 

What other field type have you seen?

Link to comment
Share on other sites

Well, after spending a few hours analyzing the results of a test that I did.

 

In the test, KT reads in almost 7400 GFF files from the RIMs, turns them into internal data structures, then re-writes them for size comparison (usually a good indicator that your code isn't working if the sizes differ).

 

About 0.3% (27 of 7391 files) differed in size. 15 of those are .utm (store) files. They appear to have been written by a different version of the internal toolset, as the field indice array has duplicate entries! The duplicates are ignored, as nothing references them, and my code doesn't read them because of this, so my output files are more compact, holding only meaningful data.

 

The other files are a couple of .dlg's and the rest are .git's. I'm going to check these out next and see if they're OK. The hard part is that I can't just do a binary compare between the files since I use a different algorithm for writing the data out than BioWare did. This means that all of the data is there, just in a diferent order.

Link to comment
Share on other sites

Fred, those are exactly the issues I was facing too including the size checking, the duplicity of entries, and the order of rebuild. For example, in the partytable.res file, the CExoLocStrings are stored first in the field table, before the primary structure's first field.

 

And hex editing would've driven me bonkers if not for the latest version of Hex Workshop ythat allows the overlaying of structures onto the hex data. It sounds like you've just about conquered all the issues since you're able to describe them... that was the hardest part for me.

Link to comment
Share on other sites

I just looked into Hex Workshop; it would have been nice to have had something like that instead of Hex Editor 2.0 from HHD software (although it is freeware).

 

Since my last post, I discovered more of the same type of issue that I found in the UTMs in the GITs. I'll spare you the details here, but email if you want them for you own edification.

 

What this means to everyone else who couldn't care less about the nitty gritty code details is that I can now start on the GUI for some editors. I had considered a savegame editor (and I may still do one) but you've got that covered well enough for now. I was going to add ability to adjust the global variables in the saves in addition to the features you already have done.

Link to comment
Share on other sites

I've decided to work on the Creature (.utc) editor first. After determining that doing the Area editor would require some really good design decisions, I figured that I'd rather make my mistakes on something simpler. :) Not that dealing with GFFs of any sort is easy (just ask tk102!), but there is less to deal with (from what I can tell) in Creature files. Area definitions would benefit from a graphically-based object positioner and lots of other non-text-entry type GUI elements that I don't feel like dealing with until I feel comfortable with the GFF class implementation and interface methods.

 

People interested in testing possibly buggy versions of KT can email me saying so. You'll get to see where it is going before the next real release, which might be some time off, given the increased difficulty in building the next level of functionality into KT.

Link to comment
Share on other sites

Here's some screenshots from the new UTC (Creature) editor. Right now it can open any .utc from the tree view, allow you to adjust many of the parameters (not all, yet) and save the adjusted content to the override folder. You can very easily change the settings over and over, saving from the same editor instance and seeing what the results are in the game without quitting either.

 

Basic

 

Statistics

 

Class

 

Advanced

 

Skills

 

Scripts

 

Feats

Link to comment
Share on other sites

I'll add my vote for a dialog editor. Just as long as it's not too much trouble. Actually you probly already have it on your list of things to, so i'll just say Im looking forward to the next update you keep makeing this tool better.

 

Oh ya, And I would love to see the file trees enhanced to orginize the file types into categories. :) I wouldn't mind waiting for the tree to build, but I do have a fast PC.

Link to comment
Share on other sites

Well, the various tabs in the UTC editor are now functional, but I have now moved on to the inventory editor portion of it. This is a bit challenging, but I'm making pretty good progress on it. I actually have a treeview from which you can select an item and drag it to the slot where you want it to go. I'm hoping to have the item properties set such that you can't put an item in the wrong slot (no implants in the hand slot, for example).

Link to comment
Share on other sites

Some of you may find this amusing....

 

If you don't already know, each .UTI (inventory item) in templates.bif has a baseitem # field that refers to a row in baseitems.2da. This allows similar items to be grouped together.

 

What I found is that the four Bith (the musicians in the Cantina) instruments (Guitar, Accordian, Trombone and Clarinet) are all considered Blaster Pistols!

 

Better tip them well!

 

Maybe this mystery can become a spin-off game....

 

"The Mystery of the Bith" <groan!>

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...