Leaderboard

Making good progress on the updates. I have ironed out most, if not all the glitches, and am now putting on the finishing touches in the TSL version of the Overhaul. Still unsure whether to make this latest version require both TSLRCM and M4-78EP, or create two modular bits for the patcher.

I'd be remiss in not pointing out my loading screens for Crouscant which are a partial alternative for HK-42 Jedi Temple Extension. I say "partial" as you would still want his rotating Coruscant planet for Galaxy Map. If you want my loading screens and his loading screen, first install HK-42's mod using the loading order above, then delete the following files from the Override: load_952cor.tga, load_953cor.tga, and load_954cor.tga. Only then should you install my mod.

Thanks! It's good to be back! Things have started to become more routine now, and I'm hoping to have more time for KOTOR now

Hello! All that you have fixed I have done as well on my side (hopefully). I remember finding many oddities and testing quite extensively. These are my notes about the Sand People: - Fixed bug with Sand People Enclave turning hostile when it shouldn't (modified m18ab.are) - The death trap outside of the Sand People Enclave entrance is disabled once the Party gain access to the Enclave (modified k_ptat_sanddeath.ncs) - Fixed bug with Party being able to wander about among the Sand People without a necessary disguise (modified k_cri18aa_heart.ncs and k_ptat18ab_heart.ncs) - The Sand Enclave turrets will no longer be invulnerable to attacks after the Party has accessed the Enclave (created k_cri18ab_enter.ncs) - Small camera/orientation fix for dialogue with Tusken guarding the Enclave entrance (created k_cri_senclave.ncs, k_cri_spgdlook.ncs, k_cri_spgddlg.ncs; modified tat18_14sandg_01.dlg, tat18_senclave.utt) - Fixed bug with random walk script triggering while in dialogue mode after custom changed made to tat18_tusken.dlg (modified k_pkas_randwalk.ncs) - Fixed bug with spawning before the Sand People Chieftain to deliver the moisture vaporators even if the truce has been broken and the whole Enclave is hostile (modified k_ptat_tuskenhost.ncs) - Enclave turrets now activate when they should (created k_cri_perctur.ncs; modified tat18_turret.utc and tat18_turret2.utc) If I remember correctly, I did remove the duplicate heartbeat script from the .are file OnExit because it seemed it was an oversight but I don't recall any crashing of the game when leaving areas after removing the disguise (which I am sure I have tested doing to test hostile reaction/ambushes). I introduced a few tweaks of my own and that's why there is mention of custom scripts in the above notes. Cheers!

This is definetely a model problem. In fact, female padawan robe model was always known to have issuises if it were compiled with old MDLOps versions (I have no idea how it works with new ones or MDLEdit). Like @ebmar said, try to remove PFBIM.MDL and PFBIM.MDX from your override and see what happens.

I found H-42's Jedi Temple Expansion. Game Front restored their website apparently.

I need to keep myself awake tonight so I slapped this together. Or if it's a more upscale joint. I guess the Tarisian Ale isn't in stock anymore for some reason...

View File Restored equipment for HK-47 / GO-TO - TSL A new version! Instruction: Move all the files from the archive to the override folder. Description: This updated version of the modification: Restored equipment for HK-47 - TSL has been converted to Restored equipment for HK-47 / GO-TO - TSL. Old content: This modification returns the HK-47 stuff to the game. Can be found in the first droid assassin on Peragus. I put the armor on the droid assassin in the polar zone of Telos. The Narodi can be found on the Naro of the Vogga Hatt when meeting with the droid assassin. What's new: 1. Deleted unnecessary files; 2. Added the ability to get the rest of the droid GO-TO; 3. You can buy three pieces from Tienn and Kodin, as they are merchants of parts of droids (Tienn trades indirectly); 4. The cost of one of the parts was reduced from 6,000 to 4,000 credits, since it is foolish to buy two parts for the same price, the second of which is much more powerful; 5. I increased the price of individual parts for T3-M4 and 1000 credits. Characteristics of the parts of the droids are presented in the screenshots. The screenshots are not visible, but the HK rifle will fall from each of the three droids. This way, you can fully pay back one of the parts from Tienn. It depends on you only how rich you are or from personal desire. The modification does not include parts for T3-M4, since even in the game we can find all three of them: the first part is built into our droid; the second falls from the HK-50, the third part (shield) is given to us for the successful completion of the mission to buy (or if you are a dark Jedi, the threat of punishment) the droid from Kodin. Thus, on Nar Shaddaa you will become the owner of all the parts for your droids, unless of course you have missed some of them. Credits: Do not use this modification in any form without my permission. Submitter todevuch Submitted 09/22/2018 Category Mods TSLRCM Compatible Yes

Thanks for the ping @Qui-Gon Glenn. You want the honest to goodness truth, the answer is just a lot of trial-and-error. Before I reached my first stable build release I had to play the games through, shifting order and switching mods out, 4-5 times before I could even complete one. That was back before I was more familiar with what I was doing, but the moral of the story, if you will, is still the same--depending on what you're trying to get to work together, it might just come down to a lot of tinkering. That said, JC is absolutely correct that incompatibilities are pretty rare. The most common type you'll have are obvious straight file overwrites, which are disproportionately texture or model changes. In those cases it's as simple as installing what you want last. More rarely you have file overwrites that involve more important files, which you can sometimes get away with overwriting if you know that the file from one mod is just minor changes (a rebalance of values in spells.2da, let's say) while another makes additions. Obviously in that case you keep the one that makes the additions, if you're dead-set on both mods, and either manually re-implement the balance changes or just eat the loss. Properly major file overwrites, like two loose appearance.2da files, can still be made to work if you've got the know-how and patience to merge the data from both files. Otherwise it's a matter of deciding which mod you prefer. TSLPatcher mods are more stable, but whether you'll encounter stability issues as a result of them is often less obvious, as they tend to do more (just by the nature of what mods benefit from using the TSLPatcher) and warnings the patcher spits out can sometimes be intentional, or benign even when unintentional. You don't always know which is which, and even if you go through everything with no errors thrown at all, you can still get a conflict at the end of the day. There's nothing you can do for that, though, except try to structure your install order logically and be smart about what mods you want to integrate. The more you add, and the more that anything you add edits, the more risk you inherently run. Determining a provisional load order is where you're going to be doing most of your legwork, and it's the step that will most directly impact the stability of your final build. This is probably the one thing I might be able to give some useful advice on. For the builds, the install order favors installing loose-file mods first, then larger TSLPatcher mods descending down to those with the most minor changes. The order of importance thus goes from the most trivial loose-file mods to the most important loose-files, then shifts to the most important TSLPatcher/.exe content down to the most trivial. In addition, mods of similar styles (texture replacers, model edits, mechanics changes, etc.) and those with similar thematic foci (Dantooine, let's say) are also grouped somewhat closely together. I've found that this is helpful in determining where you're likely to have conflicts, because by starting with the smallest mods first you'll have less stuff to go through in your override when/if you have a direct file conflict so you can easily determine what mods you're going to be forced to select between, and by grouping themes you're more likely to run into those potential conflicts back-to-back. From the TSLPatcher side of things, installing the largest mods first lets you know right away whether or not your most important mods are throwing any errors in their install phase, and also allows for mods with more specific changes (which are generally smaller) to overwrite the changes made by your larger, broad-stroke mods. Your final functional order might not be similar to that, but installing a test run in this way is the best way I've found to quickly diagnose problem areas or potential issues in what you intend to install, which will let you fine-tune what you're using and when you're installing it to get better results. Once you've cleaned up the obvious issues, though, there's nothing for it but to do a run and make sure everything works. Sometimes it won't--most times it doesn't, for me. A little over half the time I have to restart or modify a test partway through due to unforeseen issues that didn't crop up during the install phase. If you're bound and determined to use a bunch of mods, that's just how it goes.

Here's a direct link to the aforementioned builds. If there are any specific mods you're wondering about, now would be a good time to bring it up, as Sniggles is currently in the process of updating them. That's a nice idea, but I don't think it's really possible to get a definitive list. For one thing, the number of mods for which the install order actually matters is probably very small. In most cases, you could pick a bunch of random mods and be fine, so long as you don't pick two mods that obviously do the same thing. When there are conflicts, the majority of the time it makes the mods mutually exclusive - either you use one or the other, you can't use both. So the order doesn't matter. Things get more complicated with TSLPatcher mods, because they can be installed on top of each other, but it isn't always safe. Certainly if you have one mod that does a hard .mod, .2da, or .tlk edit and another mod that patches the same file, you need to install the TSLPatcher one last to ensure the changes don't get overwritten. But if you have multiple TSLPatcher mods editing the same file, sometimes it can cause an issue, but a lot of the time it doesn't. For example, the KOTOR 1 Community Patch and my Korriban: Back in Black both make changes to various NPCs on Korriban. Some of these changes are the same, but a few are different. If you install mine last, you will get all my changes, and if you install the Community Patch's last you will get its changes in favor of mine when there are conflicts. But there's no problem either way. In this case it's a matter of preference. So I figure the more mods you put on the list, the less helpful the list becomes. It would get full of mods for which there is no correct order, and would need a lot of footnotes for various exceptions. The best you can do is verify the order for a list of specific mods you want to use. If you want to get more in depth than that, you could look into some technical stuff so you'll be able to judge roughly when you should install a mod - like if you see it's making a hard install rather than patching, you know you have to install it before your TSLPatcher mods - but obviously the average user isn't going to want to do that. Of course the other issue is that modders can't be expected to know how their mod is going to interact with every other mod in existence, especially relics from a bygone era. There are plenty of popular mods I've never tried or don't care for, so I couldn't be sure whether there would be any problem.