DarthParametric

Do not upload assets from mods without the author's permission. The problem is likely the source models were compiled with MDLOps v0.7, which exported non-compliant files. Thus MDLEdit chokes when trying to read them. Try MDLOps v1.02 or, if that fails, a ye olde version of MDLOps.

Or you could just use KSE.

The AV flagging is a false-positive. HoloPatcher (the mod's installer) runs on Python, so some AV sees the way it is packed as some sort of malware. What's the exact error? And what is giving the error? HP itself or something else? If it's from HP, post the log file.

It's a global setting in the options menu, not save-specific. It will apply to a new game unless you disable it.

You enabled auto-levelling.

It does, but it's the one used for the placeable sitters. So it's in the super models, but not accessible via the regular human animset.

I assume you're referring to the "disabled" animation. No, that was only added in TSL. Fortunately though HK uses standard human animation names, so that means you could go with the old standby hack of adding the anim to his model renamed to "dance" or "dance1" (or one of the other anims he doesn't use).

Unfortunately no. The wiki on the PyKotor repo is pretty barebones and only has a few bits and pieces regarding HoloPatcher. K1CP is probably the only mod currently that uses the feature. You can see some discussion about it in the "HoloPatcher migration" issue on the repo as the feature was initially being developed/implemented. There's more on the DS Discord as it was being refined/implemented/tested, between October and December 2023 (I'd have to go digging to find specific links). Probably more useful (and less confusing) would be to just look at the K1CP changes.ini's [TLKList] section. The gist is that you can now specify a TLK in the tslpatchdata folder to be used for overwriting vanilla strings. In this case, K1CP uses the regular append.tlk for double duty, both overwrites and the typical appends. Any appended strings follow the same format they always did. Overwrite strings get listed in a sub-section under the heading of their filename specified at the start of the block. The vanilla StrRef ID is then linked to source TLK ID (i.e. basically the same way the append list works). So in this example, vanilla StrRef 25859 (one of Mission's lines after breaking Zaalbar out of his Gamorrean cell) is being overwritten by string 27 in append.tlk, etc.

Just use HoloPatcher and edit the TLK string directly. Far less effort and it's less intrusive.

The only way that sounds feasible is if you're buffing a skill via script. For example: ApplyEffectToObject(DURATION_TYPE_TEMPORARY, EffectSkillIncrease(SKILL_xxxxx, nBuffAmt), oTarget, fDuration);

You sure you're not thinking of redrob's Player and Party Underwear mod for TSL? https://deadlystream.com/files/file/344-player-party-underwear/

I believe there's some discussion of it in this thread. Physically adding additional room models is pretty trivial. It's mostly a question of what you do to flesh them out with actual content.

Check your Override folder for the presence of PMHA05 textures - PMHA05/PMHA05d/PMHA05d1/PMHA05d2/PMHA05d3 - either TGA or TPC. If the former, see if there are any TXIs of the same name. Also, make sure when using KTool that you have enabled the option to read 2DAs from the Override folder. You could just be looking at the vanilla 2DA.

Gimp's fine. What I recommend is that you learn how to use it.

As ebmar said, you need to edit appearance.2da and change the values in the envmap column for that player's rows: 148 P_MAL_A_SML_05 149 P_MAL_A_MED_05 150 P_MAL_A_LRG_05 from CM_Baremetal (or whatever it is) to DEFAULT, like the other player rows. Search for a tutorial on how to edit 2DAs. Note that this is likely going to introduce transparency issues with armours that will need to have TXIs added to fix.

I don't use Gimp. You'll have to Google how to edit/delete an alpha channel with it.

Just add some new dedicated upgrade vendor NPCs? Doesn't seem like it should be a big deal.

Yes, those are still in my "cannot decompile" folder, comprising 3 of the last 11 remaining scripts. Not sure if @JCarter426's recent TSL successes would allow for any headway on these or not. Although I do have some that @th3w1zard1 produced for me a while back. Probably need to take a look at those. You'd have to compile the NSS in question, then disassemble it and compare the bytecode to the vanilla script's to see what the disparity is. Nothing obvious in the source stands out, although I wouldn't be surprised if it was the format of the tunnel struct. Edit: Looks like SWMG_SetPlayerTunnelPos([0.0,0.0,20.0]); should instead be SWMG_SetPlayerTunnelPos([20.0,0.0,0.0]); A brief perusal of a couple of the onfire scripts looks like it is defining performance values for each individual gear, given that it is referencing the global for gear selection. Seems like it would be pretty easy to add in some checks for upgrades being installed to adjust those. Just add in some multiplier variables that default to 1.0, then do a check for upgrades and adjust the multipliers based on that.