darthbdaman

The way Suvams dialogue is setup makes him more difficult to work with. His dialogue conditionals are also different than any of the other players, which is likely why you are having issues. First of all, you are setting YAV_SUVAM_NUM to 10, and due to how the dialogue is structured, the game assumes that the last match must have been a practice game, as if that value is already 10, it is not normally possible to start a for money pazaak game against Suvam after 10 games. And Suvams scripts also check the last pazaak result directly (which shouldn't work according to scripts comments, but apparently does), which make this much more difficult, as the pazaak menu is being skipped. So it will require a little more engineering to make it work. First of all, in your simulator script, I would just change the variable to 9 instead of 10. Suvams pazaak count is not increased in an endscript like all the other players, it is instead increased in the first dialogue script after a win. This will allow the dialogue to naturally increase the value at the right time, and will skip the first dialogue branch, which is the current block. The next obstacle is yav47_suvam18, which is checking the last PazaakResult, which is not going to be a consistent value, as we have not actually played Pazaak, so this script will need to be edited. The easiest way to do this would be for you to set a local bool when you fire the simulator script. There are some unused ones as referenced here https://deadlystream.com/topic/3201-kotor1-local-booleans/. Then in yav47_suvam18, change this line int int1 = ((GetGlobalBoolean("G_Paz_JustPlayed") == 1) && (GetLastPazaakResult() == 1)); to int int1 = ((GetGlobalBoolean("G_Paz_JustPlayed") == 1) && ((GetLastPazaakResult() == 1) || (GetLocalBoolean(OBJECT_SELF, 57)))); and you can set your local back to 0 in this script as well. I've attached scripts with these changes. Quick test verified his dialogue plays normally. As an expansion to all of these scripts, you could forcibly restart the conversation with a delaycommand after closing the dialogue in the simulate script. This would improve the user experience, as they would not have to always re-converse with the npc, after doing the simulation As an aside, you should include all of your uncompiled source scripts with your mod, not just some of them. yav47_suvam18.ncs yav47_suvam18.nss simpaz_suv.nss simpaz_suv.ncs

I personally don't think there is any need for files to be deleted. I would instead use separators to divide the build mods from the non-build mods, and just deactivate and move the old mods to the bottom of the list (which is the default behaviour if they are not actually in the folder list and appear). This is a screenshot of how I setup the separators for myself, with different spots for placing non-build mods in between the build mods, as well as a separator at the bottom for mods which are new/not in the builds/haven't been categorized yet. Having played around with this more, I also think that having a single [Patcher Files] is going to become a problem eventually. I'm sure you've thought about this more than I have, and I doubt that this would be practical, but I will list out how I think the patching process should probably be handled, to better reflect how mods were installed manually: When the patching process is started, all active mods are disabled in the mod list. Then, starting from the top of the list, the patcher should check if the mod was previously activated, in which case it should be reactivated, or has an active TSLPatch in the Patcher tab, in which case the those patches should be run on the currently active files. Then, any modified files by the patcher should be copied to a new mod, which should be named something like [Patcher Files]*Mod Name* and placed directly below the mod with the tslpatchdata. That mod should be activated, and the patcher should then move on to the next mod in the list and repeat the same process. Whenever the patching process is restarted, in the preparation phase, all of the mod with the [Patcher Files] prefix should have their contents erased, similar to how the current [Patcher Files] are handled. This should perfectly reflect the process of installing the mods manually, as the order between patcher and override mods can now be mixed. This also has the added benefit of better utilizing the features of MO, to be able to detect conflicts. As an author, I'd find it very useful to be able to quickly see what mods in the builds my mods would be potentially conflicting with for instance. This does have the downside of increasing file size, as files that are edited by multiple mods would have multiple copies (I'd expect to see dozens of dialog.tlk files for instance), but this seems like a small price to pay.

This is really impressive, far superior to any other mod management solution we had before, and will substantially improve my development workflow. There are couple things I would like to suggest. For the mod build installation, it would be helpful to be able to mark mods as not to be downloaded if you don't want them. This would be helpful for shortening the installation if you don't want larger texture packs for instance. Syncing also deletes any mods which are not part of the build, which really needs to be clearly noted somewhere, as I had already downloaded the high-res movies, and put them in MO, and had to redownload them. The Root Builder plugin for MO, designed for Bethesda games, allows directly copying exe's and other files outside of the virtual file system. I would like to see functionality of this kind to allow having replacements for the exe for instance, done directly in MO, so no games files need to be touched at all. Currently TSLPatcher mods are all disabled in the file list. It might make more sense to have them be active, but just ignore the TSLPatchdata folder in the virtual file system. Then the patch list could only look for patches in the activated mods. That would probably be more consistent with the MO behaviour for other games, although this isn't a big deal. It would allow having a mixed mod with override and TSLPatcher files, which would be useful This has worked great so far in my testing though, and will probably save me hundreds of hours of re-installing

Couldn't disagree more. Its absolutely possible to get to level 34 with TSLRCM, which would give assassin full Sneak Attack in vanilla. More to the point, even if they only got to 8 or 9, that still means taking the first 15 levels as a sentinel is substantially less beneficial in the long run if you are going Watchman or Assassin, then it would be if you are going for the other Prestige Classes. You can certainly argue the long run doesn't matter, but I personally think most people who design character builds do build around the final point, even if that isn't actually optimal. There's satisfaction from maximizing the utility of all you choices at the final moment, which is very core to rpg progression. I also think nerfing the Watchman/Assassin is good thing. Even weaker is an odd thing to say about by far the best prestige classes. They get the most skills, which are actually important in K2, and due to the sneak attack feats, are far and away the best at combat. Sneak attack is immensely powerful as an ability. Without BaB differentiation, there is no reason to pick the other options. With this mod, some mix and match can make sense still, as you can get 4 sneak attack levels from sentinel to add to the other prestige classes, while you no longer are choosing between some damage and extra feats access, some more force powers, and 7 or 10 SNEAK ATTACK RANKS. You are now choosing between up to 6 Sneak Attack ranks at max level and the other options, which still isn't a good trade. Watchmen and Assassin are still the best prestige classes imo. I strongly dislike the idea of Assassin's capping out there Sneak Attack at level 26, especially as Watchmen will start to catch-up and pass them at level 31, as you pointed out. This can already happen with this mod if you some get into the high 30s, but I've left it alone as that doesn't happen by default. If I did not make the change to Watchmen/Assassin progression, the problem with vanilla would persist, where Watchmen/Assassin is by far the best prestige class choice, but now you would be losing out on some of the perceived value of taking Sentinel in the long term (even if objectively there isn't any real difference from vanilla, save getting the feats earlier). I think it is very positive that you can't max out Sneak Attack without being a Sentinel to start off with. That was the whole point of making the progression changes to Watchman/Assassin in the first place. The real problem with this mod is that it makes sentinel the only real choice of base class, without any other changes like restoring BaB, but that was basically true in vanilla already.

I don't think anyone's asked yet, but a level cap increase should be doable, and is something that gets requested all the time. I much more difficult task, would be expanding the reading of the appearance.2da file, to get extra columns, so that more armor model types could be added to the game. This is probably the oldest and most well known modding limitation in kotor. I imagine this would be incredibly complicated though

Regarding the Sith Armors don't restrict force powers request, I have a personal mod I've used for a long time that changes Exar Kun's Armor, Ulic Qel Dromas Armor(in K2 and K1 if restored), and Darth Bandon's Armor (in K1), to not restrict force powers (and edits the descriptions to match the K2 Jedi Armors verbiage). I personally haven't had a strong desire to nerf the armor as well (though I'm not opposed). The thing I really dislike about the K2 Jedi Armors is how absolutely horrific they are. Some of this is just Battle Precognition breaking the game, but the armors themselves just have extremely low defenses, compared to the attainable Dex values with Robes. K1 doesn't have quite the same problem (your Dex isn't likely to get over 40, while 50+ is not out the question in K2, nevermind adding Wisdom on top of that with battle precog) The Qel-Droma robes are already +5 defense and +2 Wisdom, which is very strong, and have no Dex restriction (and Darth Revans and Star Forge robes are both better, but so late I won't consider them). Fully upgraded, Bandon's armor is 7 defense, +5 max dex, and some fire and mind affecting bonuses, Ulic Qel Dromas is +8 defense, +4 max dex, fire and cold bonuses, and Exar Kuns is +9 defense, +3 max dex. They also all require armor feats (Exar Kuns will require medium and won't be available to scoundrel players, while the others won't be available to jedi companions without a feat, so this is mostly affecting the player) Assuming you are under the affects of valor at all times, you would have a constant +5 to Dex, and Dex adrenal can add another +6, you are probably not pumping those constantly in K1, but for important fights you can use them. If you were invested heavily into Dex and had 20 base, with another +10 from items, at the end of the game, that gives you a +15 modifier, or +12 without adrenal. That would give you +20 defense in Qel-droma robes (+17 no adrenal). Exar Kuns armor obviously caps out at +12 no matter what, and you can conveniently set your Dex at 11, and go into strength. This is overall proabably still better (though your maximum defense will be lower and you do not get the +2 Wisdom) because you can focus Strength for damage. (I know that there are other issues with the effects mod cap which will reduce the value of defense bonuses, but increase the value of raw armor defense and dex mod, but that's too complicated and probably washes out anyway) I do think there is a place for some nerfing of defense values, but I don't think Wisdom penalties and the like are right direction imo. Wearing Armor as a Jedi should be a valid choice, and it absolutely isn't in either game now.