DarthParametric

Hrmm... I wonder how it would go if the skybox had scrolling UVs for a bit of cloud movement? That might require converting it into a single mesh though.

Yes, it works on 10. All versions of 10 should be 64bit.

Sitters need to be a full body model, since for placeables there is no provision to specify a separate head like with parts models in appearance.2da as happens for characters. As there is no regular "high poly" Twi'lek full body model, you'll need to create your own in Max/GMax by merging the appropriate separate head and body models. Edit: Also, be aware that K1 has a very small row limit for placeables.2da, so it is highly advisable not to add new placeable entries.

You'll probably want to do some in-game testing and see what the feedback log says to make sure they didn''t just skip scripting and hardcode it all.

Probably.

// 533: Get the creator of oTrapObject, the creature that set the trap. // - oTrapObject: a placeable, door or trigger // * Returns OBJECT_INVALID if oTrapObject was created in the toolset. object GetTrapCreator(object oTrapObject); You may also find the following useful in order to grab the trap in the first place: // 488: Get the trap nearest to oTarget. // Note : "trap objects" are actually any trigger, placeable or door that is // trapped in oTarget's area. // - oTarget // - nTrapDetected: if this is TRUE, the trap returned has to have been detected // by oTarget. object GetNearestTrapToObject(object oTarget=OBJECT_SELF, int nTrapDetected=TRUE); Since GetTrapCreator returns an Object, just do a GetTag on that and then you can do some simple if checks against the party member tags.

Should be PLC_RepTab, although there's also a second variant, PLC_RepTab2.

You should definitely use the Unofficial Tweak Pack to remove the most questionable elements of TSLRCM. Some other suggestions from my usual suspects list: Backdrop Improvements HD Cockpit Skyboxes (despite violating my "HD" rule) Head Model Fixes High Quality Blasters Luxa Hair Fix (make sure to use the hotpants option!) Realistic Nar Shaddaa Skybox Realistic Visual Effects Telos Citadel Station Skybox Since I seem to recall you not always playing in widescreen, these are optional I guess: Improved Widescreen Experience (stretched UI fix) Main Menu Fix for Widescreen Probably a good idea. Not least because, unlike K1, TSL is fundamentally broken in ways that are not easily fixed beyond the remedial work TSLRCM has already performed.

It's ok, if completely overhyped. It is the best thing to come out of the Disney Star Wars era by a large margin though, so I guess that shouldn't be too surprising. If you've ever seen Eddie Murphy's skit about a starving man in a desert being given a cracker, you know what to expect.

Note that since Bioware's compiler (and nwnnsscomp too) pull in all globals listed in listed includes, the script doesn't actually need to make any use of RACE_DEFAULT. Simply being in the global list is enough to bork it. Which is why half the Tatooine and Manaan scripts don't decompile, despite none of them appearing to actually make use of it (not that I have seen anyway). Doing this: #include "k_inc_tat" void main() { } is enough to choke DeNCS.

Nope, still fails. I'd already hex edited it to replace that, as with all other Tatooine/Manaan module scripts. There are a number that still fail to decompile for unknown (to me anyway) reasons.

You can start a new game if you want, although that's a bit extreme for a simple Bowcaster. If you have a burning need to add it to a store inventory rather than simply directly to your own via KSE, like I said you can either edit the save file or use a script to add it.

You don't need to do this. The G vs G1 was merely Bioware's internal reference for differentiating items added in the Yavin DLC. Whatever you call it, the UTI filename (ResRef) should match the TemplateResRef field. Ideally for items you should also keep the Tag the same, although that is primarily for scripting purposes. This is the real problem. It doesn't matter. All three inventories are added to your save on the very first visit to Yavin. The only way to add it in a later save is either via script, or editing the save.

No, that one still doesn't decompile.

Indeed, but better late than never. Hopefully most/all of the remaining ones will be able to be decompiled eventually as well.

Thanks to AmanoJyaku's input, there's now a hacky workaround for decompiling most of the problematic Tatooine and Manaan scripts. Some still won't decompile, but these should be all of the relevant ones that fail specifically due to one of the globals in the Tatooine/Manaan includes. Tatooine_Swoop_Registration_(tat_m17ae)_Scripts_Using_Include.7z Manaan_Ahto_East_(manm26ab)_Scripts_Using_Include.7z

Depends on how exactly the BarkString function works. Since, results-wise, it performs exactly the same as calling a DLG with a single node, it's probably just passing the StrRef to the engine's conversation system in the same manner as when it parses a DLG.

What happens if you call it as a BarkString? I assume the same thing, which would presumably mean it only works in a DLG.

GetScriptParameter is a TSL function. Salk is talking about K1.

Add new lines to the TLK that are just the <CUSTOMxx> identifiers. Then use GetStringByStrRef(nStrRef) to pull the value as a string. You can use GetStringLeft/GetStringRight and StringToInt if you need to break it up into its mins/secs/milliseconds components.

Your UTI appears to lack a file extension. Add .uti to the end.

Per some discussion we were having about this in the Mod Development channel of the /r/kotor Discord, is it actually nwnnsscomp that is choking? I'm kind of hazy on how exactly it works, but my assumption is that DeNCS calls nwnnsscomp to decompile the NCS into bytecode, it then converts that into a script, then it calls nwnnsscomp to compile and decompile that and compares that bytecode back to the original's. I would be interested to know what DeNCS would do if you could feed it the bytecode from ncsdis, since that apparently is able to generate it from that script. But the recompiling step would be a roadblock. Edit: Hrm, trying nwnnsscomp directly it seems not to be the case. It can apparently produce bytecode for those scripts just fine: 00000C67 02 05 RSADDS 00000C69 04 03 00007E21 CONSTI 00007E21 00000C6F 05 00 00EF 01 ACTION GetStringByStrRef(00EF), 01 00000C74 01 01 FFFFFFF8 0004 CPDOWNSP FFFFFFF8, 0004 00000C7C 1B 00 FFFFFFFC MOVSP FFFFFFFC So I guess it really is all down to DeNCS. Did you get a chance to have a look at that third set of non-decompiling scripts btw? Going through some of the Tatooine modules I also found some new ones that still fail after hex editing them to remove the GetStringByStrRef from the include (although I gather a couple of them could just be recursion): Additional_04.7z

Both games are chock full of bad lightmapping. K1CP & K2CP have addressed some of the worst of it, but not all.

They tried to use a (blank) string instead of an int? Or a string and an int.