DarthParametric

It's somewhat random depending on what the player does, but most noticeable on Kashyyyk. You can find the specifics in the issue thread for it - https://github.com/KOTORCommunityPatches/K1_Community_Patch/issues/756 I haven't looked at it for over a year, so my recollections on the implementation specifics are kind of hazy, but I gather locking it to a cutscene was the most expedient and least intrusive (from a game changes standpoint) approach. If you wanted to change it then I'd suggest you'd need to strip all the scripted animation cues out of the DLG and manage them externally so they can't be interrupted.

This was done to prevent the animations breaking.

Upload the TPCs in the enduser mod (one for K1, one for TSL). Create a separate modder's resource with the source assets. Optionally you could have a single modder's resource or split it per game, since the site has per-game modder's resource sections. Its use will likely be pretty minimal, since most downloads will just be the actual mods, so just go with what you think is best. Have a look at how JC split his cloaked robes mods for how it could work.

I assume you're still using NWMax? You may want to consider switching to KOTORMax (with this fix) and MDLEdit / MDLOps v1.02. Although note that these are not compatible with Tainia's Replacer due to changes in the ASCII format.

With the advent of seedhartha's fork of KBlender and his implementation of binary model I/O, breaking normals shouldn't be an issue. At least if you can stomach using Blender.

Wow, long time no see. Welcome back. You definitely want to split them for each game. Definitely not half a gig's worth. You'll have to create an off-site gallery somewhere. Imgur maybe, or you could create a Github repo and use their Sites functionality (have a look at Kex's skyboxes mods for an example of how it is done). Not sure off the top of my head, but I have released stuff under CC BY-NC-SA 4.0 before - https://creativecommons.org/licenses/by-nc-sa/4.0/ You'd need to add it to every release page and readme I guess. You'll want to read the rules regarding it, since I have never looked into it personally - https://deadlystream.com/topic/7454-deadlystream-forum-rules/?do=findComment&comment=73940

That was the plan eventually, although it wouldn't be of any use here since it is designed for taking screenshots/videos of weapons. This particular case would require a custom solution, but would follow the same basic idea.

Because it's the vanilla blaster model. It was for testing/demonstration purposes, nothing more. That's why I mentioned the invisible character approach above, because it obviates the need for any model at all (besides the character itself), so it will work with any arbitrary custom model simply by specifying the appropriate UTI in the script (exactly as you'd equip any other NPC). Albeit possibly/probably requiring custom positioning adjustment, depending on the type and style of weapon.

Not necessarily. Off the top of my head, the only other obvious examples I can recall are for Matrik laying mines and Calo throwing a grenade. I don't think there are any problems with either of those. For the former, that presumably explains why the trapkit models protrude beneath the floor. But as far as weapons go, yeah if you are creating a custom scene then it's probably not great. A better, or at least more flexible, alternative to the current approach would be something like the stunt weapon holding rig I made for taking screenshots of my melee weapons mod. Basically an invisible character that's just a couple of hand hooks. Going that route would allow you to equip any weapon you wanted dynamically, without needing custom models for each one. It would probably require different positioning depending on the weapon though, for which you can use different animations.

Try this: Alt_Model_v2.7z

That's the "measuring stick" I mentioned. Each colour is 10cm high. It allows for a rough estimate of the required offset. Based on the pic, looks like -10cm is required (bottom of the light blue/top of the green is the model's Z axis 0 point).

Yes. As I said before, there could be some hardcoded element to prevent clipping through the floor. Given that changing the height of the spawn location doesn't appear to change anything, I'm assuming it just ignores the Z value altogether and calculates it from the walkmesh height. While item is listed as a valid object type for that function, that could just be a holdover from NWN. They have the specific CreateItemOnFloor and CreateItemOnObject functions in Odyssey to handle their needs. Try this alternate model: Alt_Model.7z It contains a "measuring stick" that should be useful to gauge the offset from the floor. I also moved the blaster mesh below world zero.

Is that with the adjusted waypoint height? Try this script that switches to a location instead. Alt_Script.7z

If you want to test it, try this and see what happens. Duncan_Stunt_Blaster_Test.7z

The only difference is that vanilla blasters don't have shadows enabled. Just makes it harder to notice that it's floating as well. If you edit the vanilla model and enable shadows you'll see the same thing. If it was laying flat on the floor then half of it would be clipping beneath the ground. This could be an issue with the way CreateItemOnFloor works. Perhaps it only takes X and Y co-ords from the input location and calculates the Z (height) value dynamically from the walkmesh to prevent clipping. After all, locations only support a Z rotation value (heading), so it is giving it a Y rotation by itself. There might be some hardcoded element for how to deal with certain object types. In that case you might need to create a custom model of a different type.

Texture sets defined by appearance.2da will only use the TXI data from the 01 texture. So if the 01 texture doesn't have the semantic you want then editing the 02, 03, 04, etc. texture TXIs won't do anything. It's presumably due to the way the engine instances data to handle memory use on the Xbox. TL:DR: Add whatever semantic you want to the 01 texture's TXI as well.

And after all that you didn't go for the threesome?

No, you don't use an extension, just the base script name. Seems like that function was cut, along with a bunch of others. You can check nwscript.nss in the Override folder to see the available functions. It's what your script is compiled against. There are some functions that would display floaty text: void DisplayFloatyFeedback(object oObject, int nStrref); void ShowHint(int nMessageStrRef, float fDurationInSeconds); void ShowDialogBox(int nMessageStrRef, int nShowCancel, string sOkScript, string sCancelScript); But they requires a StrRef (i.e. a string in dialog.tlk) which is kind of a pain in the ass. There are also the various debug Print functions for outputting to a log file, but just like KOTOR they presumably won't work in the release version. Talking about cut functions, it seems GetPlayer() is the replacement for GetFirstPC(). One thing you could do to determine if the script is working is have the player do an animation, or apply some VFX. You could also use this as a sort of half-assed alternative to a log file. Do some checks of the global states after you have changed them and play various animations based on whether they return the value you want or not. But even random StrRefs from the TLK would work as well I guess if you want to use DisplayFloatyFeedback. Choose StrRef 375 for a laugh.

You only need to add it in the Script field. That will automatically execute it when the line plays. You can try adding some debug feedback. I'm not sure if JE still has all the same script functions. Does it even have a combat log? Been a while since I played. Anyway, try adding the following to the script: SendMessageToPC(GetFirstPC(), "SCRIPT FIRING");

Just edit any DLG that you can quickly access in-game. One of the companion DLGs would be the easiest. I haven't looked at JE's file structure for years, so I couldn't tell you where to look. The easiest solution would be to just find a mod that already edits one of those DLGs and steal it as a basis. You only need to keep it long enough to execute your script once.