DarthParametric

No. The path value. Like this: For 64bit: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BioWare\SW\KOTOR] "Path"="C:\\Program Files (x86)\\Steam\\steamapps\\common\\swkotor"For 32bit: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\BioWare\SW\KOTOR] "Path"="C:\\Program Files (x86)\\Steam\\steamapps\\common\\swkotor"You haven't mentioned TSL, so I assume you don't have it, or not the Steam version anyway.

The 2DA shows that males (including Jolee, but not Carth) have the model I variant column set to ROBES/ROBEM/ROBEL (as appropriate) and the texture set to ROBE. It doesn't affect females. You didn't mention Jolee, so I am going to assume you don't have him, but that equipping a robe on him would cause the same crash. If the model were missing I think it should just give you a floating head rather than cause a crash, so I suspect it is a model issue.

Your original posts says you can't equip robes, not that equipping robes causes a crash. Those are two very different things. If it's a crash, it could be a model issue.

This is a bug that Aspyr introduced into the Steam version of TSL. They have been made aware of it. It would appear that they can't or won't fix it. The only solution is either to use the disable vertex buffer option, or use the GOG/CD version of the game instead of the Steam version. It doesn't really belong here. It's a specific game issue that only affects the Steam version, its not a TSLRCM issue (it occurs without TSLRCM installed).

If you can't equip something that's likely a restriction issue rather than a 2DA issue. Possibly a mod has added some Feat requirement to robes. What does the item description say in the game?

Create a new text file anywhere. On your desktop for example. Copy and paste either the 32bit or 64bit version of the text above, depending on what version your OS is. Change the path info to whatever your local K1/TSL install directories are (note that you must use double slashes, not single). Save the text file and close it. Change the file extension of the text file from TXT to REG. Now double click on the REG file. A window will pop up asking if you want to add the information to the registry. Click yes. A confirmation window should say it was added successfully. That's it, you can now delete the REG file. Now older tools that use a registry lookup will be able to find your KOTOR install automatically. For KOTOR Tool you will want to delete the settings.xml file as Fair Strides suggested.

Yes, the skirt in the PxBMM models is a separate mesh, and turning off the render flag as Redrob suggests would be a trivial solution. There seem to be no issues doing so that a cursory examination reveals: As Fair Strides alludes to though, a request to alter a model without altering the model is faintly ludicrous. A texture solution is not practical. A model edit is your only option.

For non-CD versions, set your location via registry keys. Copy and past the relevant version below into a text file, and change the extension from TXT to REG. Double-click it and answer yes when it asks you if you want to add it to the registry. For 64bit: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BioWare\SW\KOTOR] "Path"="X:\\YOUR_DIR\\HERE" [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LucasArts\KotOR2] "Path"="X:\\YOUR_DIR\\HERE" For 32bit: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\BioWare\SW\KOTOR] "Path"="X:\\YOUR_DIR\\HERE" [HKEY_LOCAL_MACHINE\SOFTWARE\LucasArts\KotOR2] "Path"="X:\\YOUR_DIR\\HERE" ================================================================================================================================= Edit 2022: I have created a script that can automate this process. It's available here - https://github.com/DarthParametric/KOTOR_Registry_Install_Path_Editor/releases/latest After downloading the CMD file, simply double-click it to run it. Alternatively, you may need to right-click on it and choose Run As Administrator. The script will scan the registry looking for any install info for CD, GOG, and Steam versions of both games. If it finds them it will display the listed install path. You can choose to edit the CD version's key with the install path of either the GOG or Steam versions (assuming they exist on your system), or create the CD key with that info if it doesn't exist.

OK, I did some further hex edits to stop the animation. The starboard section with Carth and the escape pods is pretty straightforward. The skybox is part of M01AB_10A and is just the starfield, no fighters, planets, nebulae, etc. I simply set the value for all the rotation keys to the one for time 0 (0°) for the starfield mesh. For the Command Module I did the same thing for M01AA_07B, except I tried to get the nebula visible from the bridge windows. I can't figure out the animation data values though, as it is different to the way MDLOps compiles animation rotations, so the best I could do was set it to the value for the middle key, which is 180°. At that value the nebula is just visible at the top of the starboard windows. Endar Spire Command Module M01AA_07B - Invisible fighters, laser bolts, & planet; rotating skybox: https://www.darthparametric.com/files/kotor/k1/[K1]_M01AA_07B_Skybox_Edit.7z Endar Spire Command Module M01AA_07B - Invisible fighters, laser bolts, & planet; static skybox: https://www.darthparametric.com/files/kotor/k1/[K1]_M01AA_07B_Skybox_Edit_No_Animation.7z Endar Spire Starboard Section M01AB_10A - Static skybox: https://www.darthparametric.com/files/kotor/k1/[K1]_M01AB_10A_Skybox_No_Animation.7z

For the Taris version, it would appear that the skybox is a separate model, m01aa_07b. The starfield is a single mesh with its own simple stars texture (LSP_stars02), the planet is its own mesh with its own texture (LHR_planet), there's a separate nebula mesh with its own texture (LSP_nebula01) and then there are a bunch of fighter meshes, some 2D planes (LHR_sithfighter1) and others 3D meshes (LHR_sithfighter). The 3D fighters also have a number of laser bolt meshes. I'd suggest that the best approach would be hex editing the model and turning off the render flags for the fighter, laser bolt, and planet meshes if you want to get rid of those. There seems to be no reason to alter the textures. Edit: Here's a pic of the hierarchy. Edit 2: I went ahead and hex edited the skybox model to turn off the render flags for the planet and fighters as I suggested above. Extract it into your Override folder and let me know if it works as intended. (Edit 4: See below) Edit 3: (Damn, a lot of edits) I just realised the skybox for the Taris ES level is animated to rotate to simulate the ship being out of control. If you are planning on using it for some other purpose like a mod where it is meant to be travelling normally, that's probably not going to be desirable. I assume whatever they use for the Vandar/Dodonna cutscene during the Star Forge sequence is just the bridge, not the whole ship.

The corpses should all be placeables I would think, not part of the level models. The way to do it would be to create a MOD file and delete all the corpse placeables in the GIT file. The MOD would go in the Modules folder. For the skybox you'd likely need to hex edit any appropriate models (presumably every room with a window) and change the skybox texture filename to something custom (with the same number of characters). The edited models and your custom texture would need to go in the Override folder. There should be tutorials/posts detailing how to do both, either here and/or at LucasForums (the latter of which you'll need to use Google's cache or the Wayback Machine for while it is down).

File Name: Party Time Sith - DS Player Main Menu Replacement for TSL File Submitter: DarthParametric File Submitted: 10 Jul 2016 File Category: Mods TSLRCM Compatible: Yes This mod changes the main menu variant featuring the Dark Side player (CurSithLord=4). The original version of the mod used the dancing Twi'lek Assassins from the Easter Egg menu. The revised version now adds two additional options featuring Dark Side versions of certain party members. Mira, Visas, and Brianna: Mira and Visas: Twi'lek Assassins: As per my TSL Main Menu Model Fix for Widescreen mod, fixes/adjustments for widescreen aspect ratios have now been incorporated into this mod. I would advise installing that mod first to gain access to the improvements in the other menus. Additionally, I have adjusted one of the dancing animations used in the menu (by Mira and the light coloured Twi'lek) to fix an issue at the end of the animation loop where there was a pause for a few frames which caused some noticeable jankiness. I've also properly fixed the texture issue on one of the Twi'leks, so if you were using the older version of this mod you can safely delete N_TwiAssasin01H.tga from your Override folder. Instructions: To install, simply choose your desired version and copy mainmenu05.mdl and mainmenu05.mdx to your Override folder. To uninstall, simply delete those two files from your Override folder. If you are using my widescreen menu fix mod, overwrite when prompted. Known Issues Obviously it won't be compatible with any other mods that replace the mainmenu05 model files. Note that any texture mods that alter the Twin Suns Assassins will also affect this mod. I'm unsure whether the Brianna version will be suitable for 4:3 resolutions (or a non-widescreen patched version). Acknowledgements Thanks to TeamTwi'lek* for their secret tool project that made editing and compiling the menu models possible *Not their real name, but it should be Click here to download this file

Well there was a period where they were still using their own colocated server hardware which would regularly fall over, but supposedly they transitioned to proper virtual server hosting some time back. I don't know what the current issue is, or how long it will last, but the site was up only a few days ago.

Here you go, in the back room between Sakarie and Kiph where Panar and Bakkel lurk:

They already have some in the Onderon cantina as I recall. Shouldn't be too big a deal to replicate those in the Nar Shaddaa cantina, maybe in the entrance way. Although that's also a prime spot for a wall sign indicating strippers dancers and booze to the right, illicit gambling den to the left.

Spawning via script was for ease of testing purposes. Placing them via a GIT edit/MOD file is the "proper" way to do it for a public release version. You do one or the other, not both. If you wanted a SWTOR-style sign, it would probably be best as a simple 2D plane, like these: Model-wise, that's fairly straight forward, and if you want animation that's just in the texture. You'd set them up as new placeables and spawn them via the GIT, just like the billboards that Jorak Uln posted earlier.

There were script edits over at LucasForums which would allow you to skip both the Taris and Leviathan turret sections, but the site appears to be down again. Here it is in the event it comes back up: http://www.lucasforums.com/showthread.php?t=179868 Fortunately you can still see it via a Google cache (Wayback Machine doesn't seem to have it). While tygaran provided source for the Taris script k_ren_taris03: #include "k_inc_debug" #include "k_inc_stunt" void main() { StartNewModule("ebo_m12aa", "K_TARIS_DESTROYED", "11b", "", "", "", "", ""); }allowing a new copy of that to be compiled, unfortunately TK102 only attached a ZIP file of the Leviathan script to his post, without posting the source as text or even mentioning the script filename. I had a brief poke through the Leviathan scripts, but didn't see anything obvious. Perhaps someone else can chime in with an independently created script for that.

I wonder if you could use elements from the textures for C_ConDrdBoss, C_ConDrdL, and C_ConDrdM as a basis? They are all basically the same series with obvious shared similarities, yet those three have 1024x1024 diffuse textures and normal maps, yet C_ForDrd just has a 512x512 diffuse. It may require a remap to accommodate that though, which is likely more trouble than it is worth.

That's pretty much the way it has always been, end-users being in favour of the open season model, anything on the internet being fair game. Of course modders are not all of one mind. There are certainly those that advocate basically the open source model for mods. I recall running into a faction of them with Dragon Age Origins modding, back 5 or 6 years ago, where they were almost militant in their open source zeal. There was a period there with some pretty nasty inter-modder factional hostility.

All the mods that Nexus archived were already archived by the Wayback Machine. That was only GameFront though. Whatever wasn't already there from KOTOR Files was lost years ago.

This belongs in the request forum. Apparently ninja moderators are amongst us, lurking in the shadows. All the Gamefront-hosted mods are still available. Can't find what the mirrored KF link to Gamefront was, so that leaves the Nexus harvested version - http://www.nexusmods.com/kotor/mods/144

The problem is the easiest way to discover offsets for various information is via compiling slightly different versions of a single ASCII model with MDLOps and comparing them, but MDLOps adds some confusion into the mix because of the way it works. For example, look at this test model compiled with MDLOps: The self-illum values are no longer the final bytes of the Controller Data chunk like there were in the above example, instead they are before a (presumed) blank/buffer block and the alpha value. Now for the game this doesn't pose a problem, as the model itself specifies what values can be found at what offsets within the file. But for people blindly hex editing, lack of consistency becomes a serious pain in the ass. It's difficult to make a tutorial saying "do XYZ", because in many situations that may not apply. In other words, the above example is less "here's how you do this" as much as "here's what I did for this specific model". What would be really useful (albeit almost certainly never going to happen) would be some sort of built-in hex editing functionality for the MDLOps Data Viewer. If it identified/labelled select values for a given mesh like self-illum, ambient/diffuse, etc. and 0-1 flags like render, shadow, etc. and let you change their values and save out a new file, that would be great. But like I said, I doubt that is likely to ever happen.

The texture itself is irrelevant, inasmuch as self-illumination is controlled by the mesh. KOTOR only supports one texture per mesh, so level models comprise a whole bunch of separate meshes. In order to change the self-illum for those lights, you need to find the MDL for that particular room/chunk of the level, decompile it, open it up in Max/GMax, and find the mesh/meshes that you need to edit. In this case, the model in question would appear to be 151HAR08. For that room there are two meshes that comprise all the light sections. The ones that consists of the strips between the seats and one doorway offscreen in that pic (the second doorway is part of the adjoining MDL) and already has self-illum enabled is named HAR08_LITE_01. Interestingly, the second mesh that comprises the strips on the ceiling, under the windows, and at either end of the seats is also named HAR08_LITE_01, which is pretty atypical. It does actually have some self-illum, but the colour (which determines intensity) is set at a grey of 80,80,80, instead of the white 255,255,255 like the other mesh. If we compare the two meshes in the ASCII MDL, we can see the first mesh has: selfillumcolor 1 1 1 and the second mesh has something like: selfillumcolor 0.313726007938385 0.313726007938385 0.313726007938385 Now that we know what we are looking for, we need to extract a copy of the original MDL/MDX and open it up in MDLOps. Hit the Read button, then the View Data button. Expand the Nodes tree to expose the meshes. Normally your mesh (or meshes) would have a unique name, but in this instance we know from the hierarchy that the mesh we are interested in the second one of that name in the list. So scroll down until you get to the second instance of HAR08_LITE_01 (node #18 in this case) and expand it, like so: The last 12 bytes of the Controller Data chunk represents the self-illum (0.313726007938385 0.313726007938385 0.313726007938385) values: In this case, it equates to a hex value of B2A0A03E B2A0A03E B2A0A03E. If we check the other light mesh (node #15), we can see its self-illum value, 1 1 1, which is what we want to replicate: Which equates to a hex value of 0000803F 0000803F 0000803F. Now we can open up 151har08.mdl in a hex editor, and search for the hex string B2A0A03EB2A0A03EB2A0A03E. In this example it's easy, as there is only a single instance: It's a simple matter of replacing those bytes with the string 0000803F0000803F0000803F: In other cases it may not be so simple. For example if you search for 0000803F0000803F0000803F, you'll find 32 instances in that MDL. So for cases like that, you may need to include surrounding bytes in your search until you find a unique example. In this case, you might use the entire Controller Data chunk, seeing as it is pretty short. For the first light mesh, that would be 00000000 AA102FBE 2558E83F AE47A13F 00000000 00000000 00000000 00000000 0000803F 00000000 0000803F 00000000 0000803F 00000000 0000803F 0000803F 0000803F In this case there are two instances of that chunk, but it is fairly easy to spot the one we want by the surrounding bytes. For instance the preceding 64000000 FFFF0100 0D000E00 036EC501, which is the last 16 bytes of the Controllers chunk: So there you go, a crash course in hex editing for fun and profit. Here's the hex edited model from the example - http://dpmods.wheb.org/files/kotor/tsl/[TSL]_151HAR08_Self-Illum_Edit.7z

Those specific meshes in the level model would need their self-illum values hex edited.