Sithspecter

File Name: Canderous' Mandalorian Items File Submitter: Sithspecter File Submitted: 01 Oct 2015 File Category: Mods K1R Compatible: Yes ========================================== A KNIGHTS OF THE OLD REPUBLIC MODIFICATION ========================================== TITLE: Canderous' Mandalorian Items AUTHOR: Sithspecter CREDITS:Stoffe for TSL Patcher INSTALLATION INSTRUCTIONS: Run Canderous' Mandalorian Items, and follow the on-screen instructions. DESCRIPTION: This mod gives Canderous some personal Mandalorian items. I thought that he should have something of his own besides a heavy repeater, so I added them. I created a Mandalorian helmet, which bears some resemblance to Mandalore's helmet from TSL, but is not intended to be an exact replica. Also, I modeled a chain gun for him. It is very large, and has three barrels which do rotate in-game. It has decent stats, but a dexterity penalty because of the weight of it. The chain gun is upgradeable, except for a scope which wouldn't do much good on such a weapon. In addition, I reskinned an armor variant in similar colors to the helmet. It is upgradeable as well. Lastly, I gave him all three implant feats (since he is supposed to have special implants) and gave him his very own Mandalorian implant. You will see Canderous on Taris all dressed in his new stuff, with the exception of the undercity (he doesn't have his helmet on there). He is equipped with the items when you gain him into your party at Davik's Estate. Cheats: giveitem g_w_hvrptbltr27 giveitem g_i_mask64 giveitem g_a_class9064 giveitem g_i_implant364 BUGS: None known. THIS MODIFICATION IS PROVIDED AS-IS AND IS NOT SUPPORTED BY BIOWARE/OBSIDIAN ENTERTAINMENT OR LUCASARTS OR ANY LICENSERS/SPONSORS OF THE MENTIONED COMPANIES. USE OF THIS FILE IS AT YOUR OWN RISK AND THE ABOVE MENTIONED COMPANIES OR THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGE CAUSED TO YOUR COMPUTER FOR THE USAGE OF THIS FILE. Click here to download this file

I see my sarcasm attempt has failed miserably...

Quick Sleheyron History Lesson. 1. Sleheyron was intended to be in Knights of the Old Republic. 2. Sleheyron was cut early in development. 3. There were 5 screenshots of Sleheyron released before it was cut. 4. There are Sleheyron textures still in the game's files. 5. There are Sleheyron gladiator arenas still in the game's files. 6. As far as we know, no VO or dialog exists in the game from Sleheyron. This planet will include 87 side quests. I don't see what the fascination with Darth Bandon/Calo/Leviathan/Star Map order is. We have a list of 10,473 things to do before we worry about that. Big picture right now is getting areas done.

We're trying to deliver a polished, finished product and as such there will be no demo released.

My plan is to worry about that when the time comes.

Yes, the feature that allows you to travel to the Ebon Hawk and back in the map menu.

So, the lightmaps are the biggest part of the lighting picture as far as the area models go. However, this doesn't have any effect on dynamic objects like NPCs, doors, placeables, etc. Using the Aurora lights has just the extra effect of lighting the characters especially, as well as shadows.

View File KAurora Created by MagnusII, and uploaded with permission. Welcome to the KAuroraEditor. This tool will allow you to perform some operations on the resource files used by the Kotor games. Please do not disassemble, reverse engineer, copy, distribute etc. the program. The source code will be released with a later version along with the necessary license. --------------------------------------------------------------------- Disclaimer WARNING: this program comes with no warranty whatsoever. Use it at your own risk. This is an Alpha. It will have several bugs and problems. It has been preliminary tested on a few walkmeshes and models from Kotor I. I've used Gmax 1.2 and NWMax 0.7 to work with the exported ascii walkmeshes. Notice that the NWMax 0.7 AABB tree building algorithm is bugged and can enter into an infinite loop; I had to comment out the code to be able to work on some of the more complex walkmeshes. The program does not need the AABB data from NWMax anyway; it rebuilds its own AABB tree. --------------------------------------------------------------------- Installation You must have Microsoft .NET Framework 2.0 installed. You must have DirectX 9.0 SDK Update April 2005 or later installed. The redist will be enough. Note that if you have installed the latest DirectX update without having already installed the .NET Framework, some of the necessary libraries may be missing. If that is the case, install the Framework and then install a newer update. If you're already at the latest level, install the whole SDK. Once you have the prerequisites, just run the executable. Nothing else is required. --------------------------------------------------------------------- Using the program At present, the program has three main functions: it will allow you to extract most of the resources packed in the game files, to export and import the walkmesh (.WOK) files, and to load,render, and import the model (.MDL) files with the option of rendering the textures and the lightmaps. When you run the program, a window with a tree structure will appear, having the two main nodes "Kotor I" and "Kotor II". You can add the games' resources to the main nodes by simply selecting one of them, and then clicking on one of the menu items under "File". A window will appear; just select the appropriate file or directory and the relative tree will be built under the chosen node. To export a resource, simply double-click on its node and another window will appear. Click on the "Save As..." button to export the resource. --------------------------------------------------------------------- Walkmeshes The Walkmesh menu lets you load and save a Kotor walkmesh file, and it also gives the possibility of visually editing the room adjacency values. To load a walkmesh from a node, you must first select a node with the appropriate resource (i.e. a .WOK file). Once it is selected, simply click on the "Load From Selected Node" menu item and the walkmesh will be loaded in memory. You can also load a walkmesh from an ascii or binary file, without the need to build the tree first. Also, if you load a model file with a walkmesh in it, the walkmesh will be autoloaded. Once a walkmesh is loaded in memory, you can export it either in ascii or binary format by selecting the appropriate menu items. You can also clear the memory; the export items will be disabled. The "Render" option will open a DirectX window with a top-view rendering of the walkmesh, along with a drawing of the first perimetric line in the walkmesh. Edges hilighted in red are those with a room adjacency value different from "-1"; this means they are those edges which, once crossed, will bring you into another room. The room to which they lead is expressed as a zero-based index of the room list which you can find into the .ARE file of the area to which the walkmesh belongs. Some walkmesh files have several perimeters in them. If that is the case, hitting the up and down arrow keys will let you cycle through all the perimetric lines belonging to the walkmesh. Once you can see the perimeter you want, you can double-click on the edges [best results by trying to hit the edge center]; a window will appear, detailing the edge number along with its current adjacency value. You can change the value by choosing "Apply"; if the value is anything else than "-1", the edge will be hilighted in red. The "Refactor" option is mostly needed when you need to export a binary .WOK of a room having a displacement in the .lyt file, and you didn't load the walkmesh directly from the .WOK. Simply enter the coordinates you find in the .lyt file and hit refactor; the walkmesh will be translated to its new position. The initial coordinates you find when you open the refactor window represent the position of the walkmesh node. You don't need to refactor if: A) you loaded the walkmesh directly from the .WOK file, or from a file exported using the .WOK as the original source (the walkmesh is already expressed in absolute coordinates in the .WOK) you loaded a .mdl file, it had a walkmesh in it, and the position of the model in its .lyt file is (0, 0, 0). The walkmesh gets auto-translated to its absolute position based on the rest of the model nodes You *DO* need to refactor if: A) you loaded a .mdl file which had a walkmesh in it, and the model is translated according to the .lyt file. --------------------------------------------------------------------- Models At the moment, many of the model export and import functions are incomplete. The ascii export is disabled. They will be added in a future release. The binary export and ascii import are currently limited to models containing nodes of type: dummy, trimesh, walkmesh, and light. Lights will be imported in binaries without crashing the game, but I'm not sure they work properly. Only the first walkmesh in a model will be used for .WOK generation; second and subsequent ones will be ignored (and you shouldn't have them in the first place, anyway, as the game only uses 1 walkmesh/room). Select either Kotor I or II model format before loading the node. To load a model from a node, simply select the node in the tree. To load it from a binary file, you must have the respective .mdx in the same directory. Export is pretty obvious. Just one thing: if you reuse an existing file, the game overwrites the existing one WITHOUT DELETING IT first. So if the new file is shorter than the old one, your new file will have spurious extra bytes at the end. Bottom line: either change the name, or delete the old one before re-exporting. Select wether you want to visualize textures, lightmaps, or both before rendering the model. REMEMBER TO LOAD THE ERF FILES IN THE TEXTUREPACK DIRECTORY if you want to render textures, and the chitin.key if you want lightmaps; otherwise the program won't be able to find them. You can somewhat navigate the model with the arrow keys and the "u" and "d" keys. This will move the camera in fixed increments. It is not possible to rotate the camera at the moment. If nothing is shown on the screen, try to hit "u" a few times to rise the camera higher and get an increased field of view. The program tries to center the initial camera placement, but sometimes this works suboptimally and the model is off center. Right now only trimesh type nodes are rendered. This means no animations, no skinmeshes, no danglymeshes, no sabers, no lights, no emitters and no references. Sorry. On the plus side, area models do look cool in the rendering window. --------------------------------------------------------------------- Layouts Load a .lyt file from a node. You can now render all the rooms in the lyt at once. Selecting which one to render will be added in a future release (will be useful f.e. to keep the skybox from being included, since skyboxes are huge compared to everything else and they mess up the image proportions). --------------------------------------------------------------------- So, how do I export, modify, and import a walkmesh anyway? A simple procedure: - load the chitin.key file. All the walkmesh resources are in "models.bif" - select the one you want to change and load it. Take a note of which edges are red, and which values they have - export to ascii - load the ascii model using GMax with NWMax - modify it as needed, then export it back into ascii format - load the modified ascii with the editor. You'll see that no edge is hilighted anymore, as the adjacency info has been lost - use the render window to select the edges you took note of in the second step, and give them their old values back - export to binary, *using the same name as the original resource*, and put it into the override directory --------------------------------------------------------------------- What if I'm creating an area from scratch and I need a walkmesh? - create the area in GMax, including the walkmesh. Try to keep the walkmesh object as child of the root node (this is the default, so you shouldn't have problems on this) - export everything to an ascii file using NWMax scripts - import the ascii in the editor - choose refactor, insert the .lyt displacement coordinates, hit the button - manually insert edges adjacency if you need them (I trust you know which edges lead to which rooms in the area you just made....) - export to a binary .WOK file as above --------------------------------------------------------------------- I want to create an area! Do everything as above, and also binary export the model to produce the mdl and mdx files. Note that if your area is new (i.e. you're not "overwriting" an existing area and recycling its other files) you will also need at a minimum: - the .lyt file (just look at another one, figuring it out is pretty easy) - the .vis file (as above) - you'll need to build a .MOD file containing the .ARE, .GIT and .IFO and put it INTO THE MODULES directory (NOT the override one....). Of course the values in these files should be changed to reflect your new area (e.g. the room struct should contain a list of your new models...) - put the value "16777215" in the sun diffuse and sun ambient fields in the .ARE file. This will give you a nice white sun. Otherwise, without lights and lightmaps, you'll find yourself in the "absolute pitch black night which doesn't render textures" - when you apply a texture to the mesh, use only UV mapping types which do not change the number of verts (i.e. planar). If the number of tverts is different from the number of verts (you can check it pretty easily by looking at the ascii file exported from NWMax), your texture will be messed up. This is because having tverts verts needs additional processing which will be added in a future release Submitter Sithspecter Submitted 09/20/2015 Category Modding Tools  

Sleheyron Update Work on Sleheyron continues, not at the fastest pace, but at a steady sustainable pace, which is as good as we can hope for at this point. The area models continue to progress well and are constantly being refined. I've won a major battle against the Walkmesh-Destroying-Federation-of-Sleheyron. I went in to make a minor edit to one of the walkmeshes. "Ah, this will take 10 minutes tops," said I. WRONG. Four hours later I was reduced to snarling like a dog at my computer screen, hoping that the Walkmesh Gods of NWMax would be moved by my plight. Finally, I discovered some rogue vertexes and edges hiding out in the dark corners of the walkmesh. I destroyed them and left none standing. Okay, that was a little harsh. I left all the good ones there, and voila, a good walkmesh is born. Lesson learned: sometimes you can't just weld all the vertexes, you've got to look over the walkmesh, and find extra edges and use some precision. 2 vertexes or 2 edges occupying the same space does not equal a happy walkmesh. Then it was time to add minimaps, which was the main objective of the day. I was dreading working on the minimaps. I did one for the main street a while back, and it was a 4-6 hour trial and error process that was annoying as all get out. So, I pulled up another module, rendered the top down view, and took it to Photoshop. Opened up the .are, and got ready to begin the process again. I knew that the fields in the .are were based on knowing the precise pixel coordinates on the 512 by 256 TGA of the map, and referencing actual meter coordinates of the area. However, last time I tried this, something didn't add up. So I have 8 different values I have to figure out in the .are to get the map and the scaling right, based on 2 (x,y) points on the TGA and the coordinates of the area. MapPt1X (TGA reference of X coordinate #1) MapPt1Y (TGA reference of Y coordinate #1) MapPt2X (TGA reference of X coordinate #2) MapPt2Y (TGA reference of Y coordinate #2) And WorldPt1X (Meter value of X coordinate #1) WorldPt1Y (Meter value of Y coordinate #1) WorldPt2X (Meter value of X coordinate #2) WorldPt2Y (Meter value of Y coordinate #2) I picked out two references I could see visually on the TGA of the map, and got their meter coordinates in MAX. Filled in the WorldPt values, which was the easy part. So I had figured out that the MapPt values were decimals based on how far from the top left corner the pixel representing the coordinates I just found was. For example, if the pixel was halfway to the bottom, the MapPtY for that pixel would be .5. That seemed to work fine for the Y-axis. I would figure out how many pixels from the top the pixel was, divide by 256, then I'd have the right MapPtY. The weird thing was the X-axis. This was off for the X-axis for some inexplicable reason. However, I finally discovered that while the textures are all 512 by 256, the game only uses ~435 by 256 of the texture. By diving the X pixel values by 435 instead of 512, the map worked perfectly!! I did several maps right in a row, making up for the sustained time loss fighting the Great Walkmesh War of 2016. At one time, this was sort of a trial-and-error process, but I've brought it down to an exact science. It has been heartening to see the areas with all of the little features that the default ones have, including minimaps, aurora lights, and the Rapid Transit System. That's right folks, the Republic Rapid Transit System has been implemented in Sleheyron. It may not seem like much, but since it's never happened before on Sleheyron, I think it's about the coolest thing ever. Fair Strides takes the credit for that of course, I just play with area models while he works the magic. And lastly, all of the modules have been connected together, which is a big step in making the planet feel, well, like a planet. You can now roam the streets and other modules, and travel to and from Sleheyron. Once again, it's been a big morale booster to see that happen. Thanks for the continued support. I will try to post updates occasionally, but like I've said before, we're here to deliver a mod, not get the most replies to a WIP thread.

I think the version 1 looks better. I'm looking forward to playing with all of these. I'm especially looking forward to a Taris mod.

Try disabling movies in your .ini file.

Aside from the clothing and underwear models, only the large models for females and small models for males exist in player.bif, I've searched there before. I'm unable to find the small and medium models for females and medium and large files for males. They don't exist in the models.bif either. Just found them under the items.bif. Don't know why they put them there.

Does anyone know exactly where all the sizes of the different body models are stored in KotOR 1? The appearance.2da points to them but I've been unable to locate them.

Based on a quick look through the modules, there are around anywhere between 0-12 instances of these different placeables per module. Assuming an average of 6 (could be high, could be low), multiplied by the ~120 modules, you're looking at roughly 720 or so individual placeable edits. That's a huge number of files to edit, especially files dealing with necessary content to the game. I understand that the immersion would undoubtedly increase by use of different looking computer panels and chairs across the different planets, and that's tough to weigh against editing all those files. Not to mention the modding implications it would have. An alternative that you might consider is making all the reskins as you suggested, and putting them in different folders when you release the mod, along with a generic one-size-fits-all folder. This way if the player is traveling to say Manaan, they put the Manaan textures in their override and so on. If they're not into that much immersion, they install the generic one. Another hypothetical option that would have a number of modding related repercussions would be to hex edit the placeable models to refer to a different texture name, and then include texture files of that name in all the different .rims for the module. I'm not even sure that would work though, but it might.

That's a pretty tall order, you'd have to add additional lines in placeables.2da, then change every single placeable .utp in those modules to use the new placeables.2da lines. It's doable if you're up for the work.

You are free to use my helmet in your mod.

They're more of a guessing game than a puzzle. They don't make any sense.

Favorite part was the expanded Vulkar Base. Least favorite part was the pillars outside the Rakatan Temple. They don't make any sense whatsoever.

Wow, those look fantastic!! And that texture name is LMA_lite01.