DarthParametric

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.

You need to edit portraits.2da. That's the one that controls head textures.

It doesn't affect the textures. All it does is edit the model to change the render flag from 1 to 0 for the four meshes that make up the end platform. They are still there, they just aren't being rendered by the engine. It won't have any affect on the rest of the game.

Here, extract this into your Override and see what happens: http://dpmods.wheb.org/files/kotor/k1/[K1]_Manaan_Speeder_Track_MDL_Edit.7z

Nothing practical I would think. For one thing the textures are generic Manaan ones, (middle strip is LMG_Manwall09, side strips are LMG_Manfloor01, railings are LMG_Manwall15) so you'd have to hex edit the level model to use unique texture names to avoid causing issues elsewhere in that and other Manaan levels. For another, presumably any other textures are going to be similarly affected. It could be a GPU/driver issue perhaps. Do you know if it looks like this for everyone? I don't think I've ever bothered with the swoop races beyond the required one on Taris, so I have no personal experience of it. You could maybe try editing the model to raise the platform slightly so the water is no longer above it, but my previous attempts at that sort of thing haven't gone so hot, so maybe someone more familiar with level editing can chime in. One possibility might be just hiding the platform center sections altogether. That is easy enough to do with a simple hex edit, switching the mesh render flag.

I don't think the problem is the platform texture per se, it's the fact that there are multiple water planes that overlay and clip through the surface of the pad. Observe: Presumably the texture semantics that allow for the water effect have an adverse influence on anything they overlay.

For the dead Bioware link, use this - https://web.archive.org/web/20070209092240/http://nwn.bioware.com/developers/

Ah, so it is more of a MDLOps issue then, unsurprisingly. Scale could be useful for placeables, given they are static. I'd suspect it wouldn't be so great for animated meshes like characters (I'd have though Bioware would have just used that instead of having small/medium/large bodies if it worked).