DarthParametric

Yeah I was aware of that, although not that it could resize them. Interesting. Something on my end presumably, but I have no idea what. Haven't encountered it with 3.2 yet. I wasn't using that previously because I wasn't aware that KB was compatible with it.

OK 2.93 didn't seem to be doing anything, just stuck there Not Responding with 0 CPU use. I tried 3.2 and that seems to have successfully completed. Not sure if that is anything to do with KB, or just another manifestation of the lockup issues I described with 2.93 in previous posts. Are you able to specify the output resolution of the bakes anywhere? Seems like it is fixed at 512x512?

Ah ok. I tried it with a freshly imported LYT and got this error: Python: Traceback (most recent call last): File "D:\Blender\2.93.9\2.93\scripts\addons\kotorblender\ops\bakelightmaps.py", line 53, in execute bpy.ops.object.bake( File "D:\Blender\2.93.9\2.93\scripts\modules\bpy\ops.py", line 132, in __call__ ret = _op_call(self.idname_py(), None, kw) TypeError: Converting py args to operator properties: : keyword "margin_type" unrecognized location: <unknown location>:-1 Error: Python: Traceback (most recent call last): File "D:\Blender\2.93.9\2.93\scripts\addons\kotorblender\ops\bakelightmaps.py", line 53, in execute bpy.ops.object.bake( File "D:\Blender\2.93.9\2.93\scripts\modules\bpy\ops.py", line 132, in __call__ ret = _op_call(self.idname_py(), None, kw) TypeError: Converting py args to operator properties: : keyword "margin_type" unrecognized location: <unknown location>:-1

So is the "Object '{}' material does not contain diffuse by lightmap node" error complaining about lacking a link to a physical file?

Well it's a good example for why you should always use unique tags, at least for anything plot-critical. There are a few vanilla examples where they have to tie themselves in knots to nail down a specific object like a door because there are half a dozen other objects in the level with the same tag. It's no doubt why functions like GetNearestObjectByTag exist. But then again they do rely on duplicate tags quite a bit to handle things like animating placeables, dealing with trash mobs, etc.

I would imagine the first time in a module should be the spawn order, subsequent visits should be based on the stored GIT order. Edit: That was kind of poorly worded. It's still spawn order in both cases, it's just that the starting module GIT ordering is not retained in the game save GIT. So the real question is "how does the engine decide the struct order when creating a GIT?".

Nah, as I said a few posts back, new UVs aren't practical. The original script does actually auto-UV if the mesh lacks a second UV set, but I stripped that out. I could create new atlas'd UVs far more easily in Max if it came to that. So batch baking was all I was interested in. After playing around with the script a bit, one thing I discovered is that the baked maps are very washed out. Seems like it applies a pure white material to the mesh first, which is screwing with things.

The problem with KMax is that OdysseyLight radii are all ginormous, so if you try using those you typically just end up with overblown whiteout. My understanding was that KBlender had addressed this, so I was hoping that it would allow for less work. Of course in a lot of cases - like pretty much every single interior module - there's really no option but to create all new lights from scratch, since the in-game lights don't match the baked lighting. If I am forced to go that route then yeah I'll just do it in Max. See for example some of my Ebon Hawk lightmapping experiments. But I thought maybe exterior modules might be doable in KBlender. But not if you can't easily batch bake the maps. Edit: Interesting. I found a batch baking script that sort of works, after a bit of editing on my part. The only problem is that it seems to regularly cause Blender to eventually lock up and become unresponsive at some random point in the process, although I did manage to get it to successfully complete a full run through a level of around 60 meshes twice. Original script here. Modified script: blender-bake-lightmaps.py Not sure if that is of any interest to you @seedhartha. Edit 2: Seems the lockup problems aren't the script, it's Blender not liking something about my system.

It's a gazillion times easier than Blender's approach to things certainly, but the results aren't exactly stellar. I've discussed the issues with KMax's OdysseyLight implementation with seedhartha previously and I was lead to believe that KBlender deals with them differently. I figured there was no harm (except loss of sanity points) in seeing what sort of lightmaps Blender could spit out.

Is that a limitation of Blender or just because of dealing with Odyssey models? I stumbled across this - https://github.com/Naxela/The_Lightmapper - although it seems heavily focused on creating lightmap UVs, which isn't my primary concern. As terrible as the vanilla lightmap UVs are, I'd prefer not to have to replace hundreds of room models.

Is there a way to batch lightmap an entire level in one go? The described process of doing each individual mesh one at a time is not particularly practical given the sheer volume of meshes in an average level.

It's not accounted for in the current version, but I have plans for an update that will add a starting cutscene for Canderous when he is the chosen jail breaker (since he's the only one that lacks one), and in that he will automatically re-equip his gear, just like now happens for the PC (and Bastila/Carth) at the end of the escape. I'm still working on the stunt animation at the moment. I may have to add an additional sequence to the end because the collision around the beds is too excessive to allow regular scripted anims to work as intended (a character can't get close enough to the bed). Either that or I need to adjust the walkmesh. I'm taking a break from it for a while to work on some K1CP additions, but here's a couple of snapshots of the WIP:

The vanilla game setup is as follows. The exit node of the pre-Leviathan cutscene on the Hawk starts the Prison Block module with a waypoint in the torture room as the custom destination. When loading that module, the player is inside a trigger, which has the escape setup script as its OnEnter. This script spawns a force cage on top of the player, then gives the player a safety jump back to the waypoint in case they got displaced by the cage it seems. The end of that script starts the cutscene of the three troopers discussing the chosen jail breaker. Later on, when the jail breaker opens the doors and control is switched back to the player character, the PC is spawned at the destination waypoint near the door, where they were supposed to run to from their cage (like Bastila and Carth do). During the development of the mod, I moved the PC's starting point back inside their force cage and quickly discovered a collision problem. It seems that placeables that are spawned via script do not rotate the PWK to match the rotation of the parent placeable. Which is a pretty big problem if the PWK is non-symmetrical. It appears that Bioware, rather than fixing the underlying issue, just didn't bother putting the player back in their cage. After a lot of messing about, I ended up adding the player's cage to the GIT, so the initial setup script was changed to remove the (now unnecessary) spawning of the cage. I didn't encounter any errors with the player not starting the module correctly, so I'm not exactly sure what the vanilla setup was in aid of. Maybe it was some issue on the Xbox that forced that approach, or maybe it was a legacy of the original boarding sequence scene that was cut. Although either way I still see no reason to have spawned the cage via script. The vanilla script cannot be decompiled by DeNCS, but you can have a look at k_plev_escsetup_ATTEMPTED_RECONSTRUCTION.nss in the SOURCE folder for my interpretation of it based on the bytecode. What I probably should have done is just nixed the trigger setup altogether and moved everything into the module OnEnter. But by the time I actually figured out what the hell was going on under the hood with the spawned placeable I had been working on the mod for 3 or 4 weeks and was kind of sick of the whole thing and just wanted to get it out the door. Plus more radical changes would potentially raise additional potential compatibility issues. At some nebulous point in the future I may add my own boarding sequence, at which point I would definitely rework the entire initial setup. And yes, if you are using anything from K1R then it's likely got a whole bunch of incompatibilities.

The animation should actually be pretty straight forward. I'd put all the rings as child of a null/dummy. You can use that to control the height, as per the original animation. Then each ring just needs a rotation on one axis. Each ring should be rotating on a different axis. The real trick is getting a smooth continuous loop. I know Max tends to get a bit derpy trying to do that with linear keys. As to the video, you'd set up a DLG that has an animated camera that rotates around the map and a script that starts the map animation so that everything is synced. Then in a video editor you'd just crossfade between each clip. Honestly that should be the easiest part of the whole operation. Edit - As an example: Although I noticed that compiling the model and then importing it into Blender the animation didn't quite loop smoothly like it does in Max. You'd need to test it out in-game to see what it looks like there I guess. Also this is not the gimbal style of animation where each successive ring is a child of the former. You can do that if you prefer, although the current starting positions would need to be altered in order to get all three rings in gimbal lock. rings_temp-kotormax.mdl.ascii Edit 2 - And if you want a gimbal style version: rings_temp-GIMBAL_VERSION-kotormax.mdl.ascii

If you want to try your hand at animation, I was thinking the other day you could maybe swap out the ball for a set of rings, kind of like a gimbal:

I think the addition of the extra "feet" is good enough. You don't want it getting too noisy. It's not exactly the focus of attention anyway.

I think the central base piece could use more subdivisions. It's not running on a circa-2000 pocket calculator any more, you can budget more than a handful of tris for it.

Yes, you need to change the Race column.

Extract the attached into your Override (it's a renamed copy of the vanilla 47 model), edit the 50 and 51 rows to point to that model instead (P_HK50) and restore the original racetex values. TSL_HK-50.7z

That's an appearance.2da edit. Presumably it's the clothing (B) body, but I've never used the mod myself so I couldn't say for certain. But you'd need to copy the model and texture references for those into the equivalent cells for your target's appearance row.

Same appearance.2da texture override problem presumably.

Nah I checked the original TSL HK model and there aren't any Mesh01self-illum keys for the Disabled anim. But sure, if the mesh name doesn't match the original then it won't work regardless. But that would also break the talk animation as well. If his eyes don't flash while talking then you'll know that's the case.