DarthParametric

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.

Easiest way is probably just to attach it to a dialogue.

That literally makes no sense. A single PC can do both. Why would you waste money on a whole second PC when you could just put all that money into a single PC?

That's not a patch, it's a cracked exe. Presumably the Aspyr version.

You're thinking of Flawless Widescreen, which patches the game in memory. You should never use it, precisely because it causes crashes. UniWS permanently edits the exe, the same as manually hex editing it.

All of it is possible, none of it is probable. Take it from someone that knows: never go full total conversion.

That's all pure lightmap.

I thought we addressed flaky animation resumption in K1CP at some point, at least for specific instances anyway.

KBlender will automatically load all referenced textures as long as you have defined the texture locations in its settings under Edit -> Preferences -> Add-Ons: You can specify multiple folders separated by a semi-colon ( ; ).

Milliseconds. A script that took seconds to execute would make the game freeze and unplayable. If you mean how often do they re-execute, then yes, every creature will have multiple scripts firing every round, so every 3-6 seconds. Also anything else with a heartbeat, like placeables and so forth.