Leaderboard

I would suggest DeNCS is the most in need of a replacement, since it chokes on a number of scripts. You should start by looking at what progress Xoreos has made on their decompiler (along with other tools for the various Odyssey formats) - https://github.com/xoreos/xoreos-tools

Hi, all! I'm writing modern versions of the tools for myself and wondered if there is interest in making them publicly available. Some motivations: Performance - K-GFF, DLGEditor, etc... are quite slow Dependencies - DeNCS, KSE, etc... require (sometimes deprecated) Java, Perl, QT, and other 3rd party packages Workflow - The tools are generally great, but you need to use more than one to do simple things like edit a GIT (e.g. ERFEdit on the SAV files, then K-GFF on the GIT) Ease of use - Most of these tools are less than intuitive, with steep learning curves Bugs - Some of these tools have still have bugs (e.g. GITEdit wouldn't open a file, or exit) With these issues in mind, my "holy grail" tool would be: Fast - Every action should complete in milliseconds, including building structures from GFF files Self-contained - No dependencies, just pure C++ code One workspace - Files that contain other files should be modifiable along with the files they contain, with valid options for all file types (e.g. add creature to GIT stored in save game file) Intuitive interface - Noobs shouldn't have to read a manual Error-free - Including required knowledge of file formats, file names, and game mechanics And the tools I'm targeting for replacement/consolidation: KOTOR Tool KOTOR Save Editor ERFEdit K-GFF DLGEditor DeNCS GITEdit Others? Let me know what you think!

This is a little something that I'll be working on over the upcoming months. A cross-platform modding tool designed to create and modify the various file types used by KotOR's engine. A new KotOR Tool if you will. This is in very early stages so don't expect much and anticipate crashes and bugs - so save regularly! The file size is fairly large as well due to it including needed libraries inside the executable. I do intend to make this open source at some point in the future, but not for the time being. I'm testing this in Ubuntu, so I'm unsure of how stable the Mac and Window versions are so testers are appreciated. I welcome any feedback and suggestions. Whats currently implemented in v3: GFF Editor 2DA Editor TLK Editor ERF/RIM Editor TPC Viewer MDL Viewer Audio Player Saving files directly into modules Opening and extracting files from the game's data Search filter on files from the game's data Any number of game directories are loadable at one time Choose between different themes (System/Light/Dark) Download Links: Windows (7 and up, requires VC++ Redist) Mac (10.9 and up) Linux

And the latest version is live! Enjoy everyone!

I'll get it to you when I have a moment That was a hint to the mods Maybe this will help:

What have you done so far? Some time ago I started working on a "dlgedit" (for the same reasons you listed) in C++. ATM it can open/save dialog files, display them in a tree (which I wrote from scratch to maximize speed), it allows for copy/paste/cut/delete/create tree operations and most of the fields work, although not all are fully implemented yet. With it I made a GFF and a TLK library. If you're interested I can show you the code, either to use parts from it in your own work or to continue work on this tool (since I don't have the time right now. It is written using WINAPI, however... I can imagine that's not something you're interested in..). (this topic should probably be moved to the modding tools section?)

Edit: Have made it to Korriban. Followed compatibility instructions and now am about to see just how well this works.

I couldn't file the cause of the error (I think it's an error in the source code, not in the scripts) but I did came out with an workaround, if anyone is curious, here is what I did: on the jump file (onjump.ncs), the script checks if the player is already fying, if he is, it returns 0, what I did was changing that behavior to simply accelerate the player downwards. The issue with that is that a player can cheat that way, as in, interrupting the jump earlier, but, I'd rather not use it that way, and be able to race when it bugs. IF there is interest, I can polish it and publish a mod of that (or even a better solution)

Thanks for both! The head you gave works really well! and thanks for the link to the forum post. took a look through and it makes sense. I'll be trying to do more of this in the future. again, thanks!!!

Bit of an addition to DarthParametric's elaboration earlier - Thankfully, @JCarter426 did write an extensive Analysis of the Combat Animations' tutorial to cover such lacks of description for K1 which should provide necessary information ones could need on this particular attempt.

Sorry, I didn't see your post before... It's true, it's not immediately obvious the way I wrote it, I had to think a bit to remember what I wanted to say. So: VP = BaseHitPoints * (PlayerLevel * vpmult(autobalance.2da) - 1)(only if mult > 0) + HitDie(classes.2da)/Levelup + CON * Level Here you have several references to levels: 1. PlayerLevel: "All values depend on the player level, which is determined from experience. This means that if you have enough experience for level 33, the game will consider that level even if you haven't levelled up yet." 2. Level: "Level = Level(Class I) + Level(Class II) + (PlayerLevel * levelmult(autobalance.2da) - 1) (only if mult > 0)" 3. Levelup: "At levelup, you gain: 6-12 points depending on your class" So, the base is BaseHitPoints (which is multiplied by (PlayerLevel * vpmult(autobalance.2da) - 1) if the vpmult is > 0). To that value, you add some amount for every level up (ie. it's not retroactive, if you get a character at lvl 6, they will not get the bonus for the levels up to 6, they will only get it added once you level them up [I haven't checked this recently, but I think that's what is meant, and if I wrote it down I must have checked it back then]), the exact amount that's added depends on the HitDie column in classes.2da. Then at the end, you add the CON modifier * Level (as it is defined above). Force points work the same way, the only difference is that there is no autobalance scaling of the base value (there is scaling of the attribute modifier however, because of Level). As for the LEVELUP for Skill, that's the points you assign to skills when you level up your characters. As you probably know, the amount of points you can assign depends on your class as well as your INT modifier. Again, only player controlled characters get this part, since non-playable characters don't level up. [I just realized, I haven't checked or at least don't remember having checked what happens if you change the PC to another party member. Is the PC's level still used as PlayerLevel for autobalance (which is more likely I think) or is it the party member's? But if it's the PC's, then the party members that you get at higher levels have quite a disadvantage against the enemies compared to the PC and the party members you get at lower levels.] Hope this helped clear things up!

I've got this pack, which has all the versions of MDLops. I often switch between different versions if some models don't work out OK. http://www.mediafire.com/file/86el1fo6vc87oov/MDLOPS.rar