Leaderboard
Popular Content
Showing content with the highest reputation since 09/10/2025 in Posts
-
5 points
-
3 pointsAn, almost, full retexture of the entire game. Made with my AI model. Not an "AI Upscale", which is something different. Vurt's KOTOR Visual Resurgence at Knights of the Old Republic Nexus - Mods and community maybe i can upload here once it reaches a more final version.
-
3 points
-
3 points
-
2 points
-
2 pointsaround 1950 textures are mostly done, gonna go over some of the skyboxes again though, make them 2048x2048 since it just looked quite a lot better.
-
2 points
-
1 pointAbsolutely. I have zero insight into which textures might be entirely unused. It probably would be possible to make a .py script which cross references meshes/textures, but meh.
-
1 pointRemoved the .tpc version since it had many graphical issues. new version is tga!
-
1 pointPresumably alpha channel masks for envmaps, like Sith troopers or Mandos, for example. Or the Hawk, both exterior and interior, amongst many others.
-
1 point
-
1 pointEdit 9/12/2025 This is ready for beta testing! If anyone is interested please let me know. It theoretically should be compatible with both Extended Enclave and Party Swap, plus most other mods in the recommended build. Installs with TSLPatcher. --- I'm still working on learning the scripting side of things to put everything together, but I finally was able to get my test dialogue, lip files, and edited audio working and wanted to share a snippet! This mod will be fully voiced using less-common and cut original dialogue clipped together to form new conversations, and creates a complete romance arc for Atton and the Exile in the style of the K1 romances. (other mods I use that are visible here: Atton with scruff https://deadlystream.com/files/file/528-atton-rand-with-scruff/TOR ports, Kira Carsen https://deadlystream.com/files/file/1301-tor-ports-kira-carsen-female-player-head-for-tsl/ High Quality Skyboxes 2 https://deadlystream.com/files/file/723-high-quality-skyboxes-ii/ - I need to make some new saves without my usual mod build for when I do real testing and making the actual dialogue files, this was just a test. I play on iPad, so that's the reason for the different UI) Content: I have finished writing the dialogue and editing the audio for seven new main conversations that run from Telos to a final scene just before heading to the Ravager, as well as four shorter repeatable flirting options, two conditional conversations (one if you trigger Atton and Mira's jealousy conversation over Disciple meditation with the Exile, plus one short bit if you have Atton in your party during the Handmaiden Battle Circle), plus a few extended options to flirt back/continue with several comments Atton makes to the Exile in the base game. Currently I am planning to use fade-to-blacks for kiss scenes to match K1 (and also because I have no idea how to animate that in the locations the scenes will be in). Compatibility: This mod will only require the TSLRCM, but I will be using TSLPatcher for installation and hope to make it broadly compatible if possible. Any advice on best practices to achieve this is very much appreciated! I will be testing it with PartySwap at minimum but would like to make it compatible with the full mod build if that is possible. I am leaving out gender checks for all of the new dialogue and am hoping to make this compatible with Leilukin's Atton and Male Exile mod so everyone wanting to romance Atton will be able to regardless of PC gender. I usually play on an iPad so this mod will work fully on iOS. Current progress: With the dialog and audio done and the lip making process set, most of what I have left is figuring out scripting and conditionals enough to put it all together. I need to find out: (updated 9/11/25) how exactly fade in and out of black works regarding the pacing and speed options (I got the initial fade out to work here, but I had to cut the scene off there as the fade back in is not the way I want it to be). How to set up TSLPatcher How to manage compatibility with the mod build. If anyone has advice/tutorials for any of those it would be greatly appreciated! As mentioned above under compatibility, I would also welcome advice on how best to set everything up to be less likely to cause issues with other mods. I'm editing Atton's global dialog file which I know may cause problems with anything else that modifies it, but will be making small changes to several other dialog files too throughout the game. I know I will need to figure out TSLPatcher (thank you ZobiZob for making that video guide to get me started!), but anything I should keep in mind regarding file location/names/formatting/anything else would be wonderful! Credit: Huge thank you to JC, as the SithCodec was absolutely essential for me to be able to do any of this, along with creating multiple things to help with making lip files that saved me a ton of time and effort, plus repeatedly answering my questions in the Discord server when I hit problems I couldn't troubleshoot on my own. 2 months ago I was still not understanding how mods even worked as I am not remotely a computer person, and this is my first attempt at any sort of game modding, but the countless tutorials folks have posted and the supportive community here have been amazing and incredibly helpful! If anyone is interested in beta-testing when I get the scripting and installation figured out, or if you have any other thoughts/suggestions/advice, please let me know. Thanks!
-
1 pointHello DeadlyStream folks, It's been a long time since I've attempted to create a mod and I'm trying to create the ultimate performance mod for old hardware for KOTOR. For context, my one and only mod contribution to this site has been the TSL of the OLD PC. This is thanks to a combination of contributions by modders on here like BeadV+MDLedit , DarthParametric for allowing me to take his widescreen menu and remove the particles, and the kotor tool by Fred Tetra). Unfortunately, this didn't really address all of the issues of performance on low end systems for TSL. Thankfully it was pretty effective for a lot of use cases and I had fun working on it. Since then, I've wanted to revisit the original KOTOR in attempt to make it push 60FPS on the most meager hardware possible in a way that I could learn to do the same for TSL. In my current mod output testing, is an old Dell laptop running windows XP with 2GB of DDR2, a less than 2GHZ dual core and the infamous Intel chipset graphics accelerator running at a resolution of 1024x768. Successes: The main menu runs at 60fps, placeable explosions, sparks, and other effects visibly render and don't appear to be a detriment to FPS. Unnecessary map animations, added aurora lights, door animations+particles, particles have been removed. The overall framerate and gameplay pacing is better than the vanilla install (in some cases better than original xbox). Failures: At one point, I considered that the vertices, faces, and overall polygon count for map modules could be the ultimate destroyer of framerate on low end systems. So naturally, I looked up Blender tutorials to lower polygon and vertices count. I ended up using KotorBlender and followed that by using the decimate modifier on the nodes and had very limited gains (with some bad visual outcomes). Even when targeting unnecessary map objects that had a ton of vertices, this method didn't have enough FPS gains for what I was trying to achieve. While some map portions that were modified seemed to give an FPS boost, there seemed to be a deeper problem based on player viewpoint. My current struggles (Endar Spire Command Module): I've modified ALL Endar Spire command module maps, Global fx, characters, creatures, and global placeables using the following tools: MDLedit (BeadV), Holocron Toolset (Cortisol), and the kotorblender plugin for Blender (seedhartha). Even with these modifications, the framerate can't sustain over 30fps on the hardware that I'm testing. So far, the framerate appears to be utterly destroyed by the draw/render distance dependent of the controllable in game camera. In the case of the Endar Spire Command Module, the framerate plummets when the main character's camera viewpoint is pointed towards the bridge of the Endar Spire. Does anyone here have any pointers or advice to give me? I would very much appreciate it! 🙂
-
1 pointApologies for this bump of my own thread, but I wanted to add some additional info/context without an edit. This reply is with the intent to possibly save someone from attempting the same goal as myself without making my own mistakes. Additional steps attempted since my original post: 1. Editing MDL Files: I started with the notion that MDL polygon/vertices/face count was probably destroying the framerate. I had assumed this might be the case, since the modified particles didn't seem to hit the framerate at all after I lowered the birthrate and FPS values of ALL GLOBAL placeable, FX, and V_ MDL files. In my original post, I mentioned facing the bridge with the player camera causing the framerate to plummet, but I needed to test this assumption. After stripping out all of the polygons/faces/vert and walking on basically a black screen, the FPS didn't improve in any noticeable way . I went as far as to remove door animations and particles on the broken door, astro droid (c_drdastro) that is instanced multiple times in the module. I lowered the sith soldier, republic soldier, bandon, and jedi mdl files for polygon count reduction, but even then, there was truly no change to framerate compared to the particle changes I had made. Lightsaber appearance and disappearance had zero impact on FPS when the player sees "one of the jedi accompanying Bastila" cutscene. In short... I WAS WRONG! The removal of vertices/faces/triangles in meshes don't seem to have nearly the same impact on old hardware as I had originally imagined. 2. Editing the appearance.2da: I considered that the sith armor and other reflection calculations could be the culprit of slowdowns on old pcs. I ended up changing the sith soldier, and anything else existing in the appearance.2a envmap from CM_BareMetal to the DEFAULT value. While I did not see any difference on my modern PC of their reflective properties, the older test system reflected, pun intended, no changes in framerate. This is particularly odd, since the GMA renders these characters without any shiny quality at all on the vanilla install. Probably because old hardware just can't output the request. 3. Removing UV Maps of the Module: I wasn't sure what to do next. My next attempt was to strip out all light maps/UV maps from for all of the M01aa_XX files. I took ALL the edited Endar Spire Command Module MDL, which had their particles, animations, and aurora lights removed, into Blender using the KotorBlender add-on. Removing the Lightmap value followed by using changing the Self illumination hex value of 505050, and exported them for the override. I started with M01aa_01a and changed the rest of them in an attempt to see if this would actually give any performance increase. This didn't seem to increase the framerate at all. On the plus side, the game actually looked slightly darker and lights from blasters seemed more influential on the game world (due to the difference in light). 4. Blundering With Scripts: I considered the scripts of spawned characters were animating character models too soon out of view of the camera. In this case, I removed k_pend_bridge01 from the "OnSpawn" value for all the sith + republic soldiers, bandon, and jedi in the module. While this had some funny affects, like the soldiers not fighting on the bridge until you actually engage combat, the end result gave no framerate gains. 5. LYT changes: I was speed reading google searches of the LYT file and its function. All my attempts to change this file ended up with loading a save crashing or failing to start. My limited understanding of this, is that it's probably best to leave this unchanged, since I'm not attempting to make a custom module/map file for the game. Changing these values is no arbitrary task. After all this experimentation, I'm starting to believe there's a bug in the game's code that is causing unnecessary slow downs in all modules in regards to opengl calls. At the moment, I've been attempting to get a program like apitrace to work with KOTOR to do further digging, but I have zero experience in this field. I'm not a programmer, 3d modeler, or developer, just a guy who's playing around with modding for fun. Hopefully my explanation of this attempt might inspire someone with more knowledge to solve this puzzle or point me in the right direction. Help me deadlystream modders, you're my only hope.
-
1 pointHello! It seems almost impossible but only today did I realize that there is a black hole narrative plot in the game. To access the hangar at Davik's where the Ebon Hawk is parked, the Player needs to disable the hangar door's lock mechanism and that needs to be done via computer terminal. So far, so good. But in order to fly away with the Ebon Hawk, the Player should also need the security codes to disable what Davik in the intro tour calls "the state of the art security system I've had installed to protect her." I dismissed those words when I played, but they are significant and they are practically hinting at the existence of a very sophisticated alarm system. Other than Davik himself, the only other person able to bypass the alarm system is the Ebon Hawk's pilot Hudrow, currently being tortured at Davik's and kept in a cage. If you free him, he will reward the Player with sharing the security codes that SHOULD BE NECESSARY to fly the Ebon Hawk. But that is not the case. The Player can just disable the hangar door's security at the terminal just using spikes, enter the hangar, fight David Kang and happily leave with the Ebon Hawk. I'm very surprised that nobody else noticed it or spoke about it before me. Or perhaps I never found a topic about it. If there is an ongoing discussion I have overlooked, I'd be grateful to be pointed at it to learn what others would say. I'm locally going to do something about this to rectify the situation. Thanks!
-
1 point
-
1 point
-
1 point@Sith Holocron requested that I go into some general detail for the community about why the Steam Workshop is generally bad for modding, both to have all the issues laid out and easily referenced, and to clarify some common misconceptions. I can't count the number of issues I've had to troubleshoot as a result of the Workshop and I know its systems and limitations in detail, so I feel fairly qualified to explain what makes the system inadequate compared to the standard methods the community uses for mod installation. I'll first briefly explain how mods installed from the Workshop work, then detail situations where using the Workshop is sensible before explaining why using the Workshop is generally not a good idea. If you'd only like to see an explanation of why you should be downloading mods manually, skip on down to section #3. If you don't use the Steam version of the game with the most recent (Aspyr) patch, needless to say this doesn't really matter for you, as you don't have Workshop support for your title anyway. How the Workshop Works First, it's important to reiterate that the Workshop is only available on the Aspyr patch of the game (not the 'legacypc' beta install option) on Steam. This update causes not a few issues, which means that even if you own the game on Steam you might want to revert it to that legacypc version even before considering modding; an inability to apply new textures to lightsaber hilts, the loss of fog effects, and sometimes extreme game stuttering are but a few of the issues the Aspyr patch causes (though, in fairness, it of course also introduces many useful conveniences, including native widescreen support and controller support, and it is now possible to restore many of the things the Aspyr patch breaks thanks to @J's 3C-FD patcher). To the topic at hand, however: on a basic level, the Workshop is just a download system for mods. It doesn't truly "install" them as such, as the TSLPatcher would do, it just takes stored data from archives and puts them in a repository which the Aspyr-patched version of the game can read. For example, if you install TSLRCM and two texture mods, the Workshop will take the file data from TSLRCM and those texture mods and separately store them in three different containing folders, which the game will then read on startup. A few of you might already see the problems with this, but we'll get into that in a moment. What the Workshop is Good For Jokes of "nothing" aside, the Workshop is actually very good for single-mod installs. If you want to use TSLRCM and only TSLRCM, go for it--the Workshop will download it and you can run it with no trouble at all. It will even keep the mod dynamically updated for you; the TSLRCM team even realized that this is a much easier and more foolproof method of installation for many users. And, so long as TSLRCM (or TSLRCM + M4-78) is the only mod you're using, it truly works fine. The issue comes in with multi-mod setups, which is how we get to.... Why You Should Avoid the Workshop Put simply, the Workshop was not well-designed when it comes to multi-mod installs, especially in the face of the array of tools the community has developed to encourage mod compatibility over the years, the TSLPatcher being foremost among them. For those that don't know, the TSLPatcher can append strings or modify individual lines within existing files (among a myriad of other things), which allows mods which would otherwise directly overwrite the same files to work together fine, so long as they're not editing the exact same data within the same files. Not only does the Workshop not have this, it also lacks a stunning array of other common-sense multi-mod features: Load orders are based on the order mods are subscribed to, and are overwritten in certain circumstances. This is a big one. Even the most archaic games have always allowed users to control file overwrites, deal with compatibility issues, and selectively prioritize one mod over another by controlling the order in which mods are installed, and oftentimes the specific files installed from mod to mod. Because the Workshop does not truly install mods as such and instead merely sits them in a folder to be read by the game, it's up to the Workshop which mods get read in which order, and which get prioritized. Mods subscribed to first are read first by the system, but because they're downloaded as complete packages ready-to-launch, it's not possible to remove files selectively unless you know exactly where to look--even then, the Workshop may try to repair your install of the mod, replacing files that you may have removed intentionally. Furthermore, no file manifest is given by the Workshop, which makes it that much more difficult to see which mods edit the same content, and incompatibility is a major systemic issue with the workshop as we'll see. Worst of all, mod updates or game reinstalls can entirely disrupt this subscription order and randomize the load order, making it difficult to achieve a stable load order even if you're doing all due diligence. One mod's changes can push out another's. Unlike the installation system typical with major mods where the TSLPatcher can minimize incompatibilities, there's no such protection here. Indeed the opposite, as having two mods with the same .2da file means that one's will inevitably win out, and the other's will lose, and the loser's data will be completely and totally ignored by the game. Not only does this guarantee that some mods are incompatible in function simply due to the Workshop's architecture, it means that you could encounter serious bugs if important files from one mod are overwritten by another. This is part of the reason why TSLRCM and M4-78 had to be combined on the Workshop eventually--despite being completely compatible with one another, the Workshop was ramming them together in incompatible ways. Mods installed manually don't play well with Workshop mods. Jumping off of the above, because mods aren't truly installed with the Workshop, a user can mod their game by installing files onto their game directory in steamapps/common as one would normally do, but also subscribe to mods on the Workshop. Yet the same issues as two mods editing the same file on the Workshop will now occur in this scenario: a loose .2da file in the override will conflict with a .2da file from a Workshop mod and one will completely cancel out the other, rather than taking each other into account whatsoever. This is a big reason why it's a good idea to do all one thing or all another, since combinations like this are invariably more work than simply modding with the right tools from the start. The Workshop has limited selection, and few exclusives. This is an indirect rather than direct issue with the Workshop, but it's worth pointing out all the same. Because of many of the above issues, the Workshop has a rather limited base of modifications, and most modifications released on the Workshop have also seen standard releases, either here on Deadlystream or on the KOTOR 2 Nexus. Because those mod versions would be more compatibility-friendly anyway, there's little reason to use the Workshop just for the sake of the mods on it; there's more variety and less headache installing mods elsewhere. Many Workshop mods are out-of-date and not supported by their authors. This is again (at least partly) an indirect issue, but I feel the need to mention it here because it does have consequences for users. It is very easy to upload mod content to the Workshop even if you aren't the original author, and difficult for original authors to get these reuploads taken down. Regardless of your stances on mod ownership or reuploading, the users who perform these uploads often drop them on the Workshop for quick downloads and kudos-padding and then abandon them, not providing any future updates or support that the original authors would at their typical download locations. This leads already-anemic Workshop content to also frequently suffer from being outdated, and lack proper support, as the uploaders are frequently not the original software authors and may not even understand how the content they've hosted works. While the above is by no means an exhaustive list, it does represent the bulk of the problems with the Workshop. I want to reiterate a final time that the Workshop is an easier install method, as it's a simple one-click solution, but, much like the dark side, it's an easy path that often brings its own problems down the line. It's never worth it to use the Workshop for a couple of mods only to find out that you have a serious incompatibility late into the game, and no clue how to resolve it. Manually downloading mods isn't much more difficult, and neither is their installation, while the compatibility benefits from doing so are significant. I hope this post has helped explain exactly why that is, and encouraged you to look into a traditional install instead. If concerns about compatibility now seem significant to you, or if you're new to modding and worried you'll simply be overwhelmed by the install process for mods, I (though biased) strongly recommend the mod builds. As fully-compatible mod lists, you won't need to worry about crashes from their use, and all the mods listed come with detailed instructions where necessary; spoiler-free builds are even available if you're a first-time player. With the builds as an option, there's really no reason not to skip the Workshop in favor of a much more content-rich and stable experience.
-
0 pointsoh, wow, 996 files from KOTOR1 is also used in KOTOR2. Half my work is already done for TSL
-
0 pointsThis may not come as a surprise but work on this has been halted. Changing the TLK file too much resulted in a bugged game. I'm saddened by it myself because I thought I really had some good edits on large conversations, many more personal reactions instead of the standard "I'll kill you!" Ah well, what can you do. It was fun figuring it all out...
-
0 pointsyeah i know i have made remasters before this one, my morrowind remaster likely had 20 updates and it still has a few issues, its a lot of work indeed.
-
0 pointsi'll have the first version up on Nexus Mods tomorrow evening i suspect. Wasn't expecting converting to tpc to be so slow, i'm on a recent CPU and it has taken me the whole day to convert, so far, 800 tga files to tpc, so it'll likely take me 2 days to convert all 2000. I've converted mods to other formats like .tex and whatnot before, usually this is done in 3 minutes for 2000-2500 'ish textures.
-
0 pointsGlad you can find this mod useful then thank you. I don't see why it couldn't be used with that. Just make sure the community patch is installed first then this mod. If it replaces any 2das in the Override, let me know. But I think you should be fine even if it did.