Leaderboard

OK, here's an overview of how you go about a fix like this. The first step is to locate the specific room model that needs fixing. This is pretty much down to loading the entire module's layout into Max/GMax and trying to match up what you saw in-game vs the location in the layout, Then you can select a piece of the offending geometry and find out which model it is part of. Typically at this point I then reset the scene and load that specific model only. Some people prefer to work inside the full layout. That's a matter of personal preference and doesn't really affect the way you go about the fix. Just make sure you enable the Export Layout Co-Ords option. On to the fix. Here we see the length of corridor in M01aa_03a: I will assume you know how to manage hiding extraneous elements like walkmeshes and so forth. The light sockets we are interested in are comprised of two separate meshes. The white outer/surrounds: And the red inner: If you zoom out, you'll see that each mesh is comprised of much more than just the light sockets. Level models are typically divided based on materials. Primarily shared diffuse texture, but in larger levels there can also be further division based on shared lightmaps. In this case the problem is that three light sockets lack the red inner mesh. The solution is to duplicate some of the existing red mesh and slot it into the empty light sockets. We start by selecting the red textured mesh and creating a copy of it by going to Edit -> Clone. It is very important that in the options window that pops up that Copy is chosen. The default is Instance, which we don't want. That option transfers any changes made between the duplicate and the original, which would be bad. With the new copy selected, hide everything else. The next step is get rid of all the geometry we don't need. In this case there are two light socket inners at this end of the hallway, but we only want the left-most one. The reason is that the righthand one has different lighting info, making the texture very dark (as you can see in-game - it's in the dark, collapsed section). Expand the Editable Mesh modifier in the stack, select the Polygon sub-level, then select all the polys of the light socket inner that we want. Now go to Edit -> Select Invert (shortcut CTRL I) and press DEL. That should leave just the socket inner mesh. Now to make out life easier, switch to the Hierarchy tab, enable the Affect Pivot Only button, then choose Center to Object: After that disable the Affect Pivot Only button. This can be a little flaky, so you may want to deselect the object and reselect it to be certain. With the rest of the scene unhidden, the socket inner piece can easily be dragged to approximately where it needs to be: Don't worry about precise positioning at this stage, as we'll handle that at the vertex level. To make it easier to see what you are doing, enable the Edged Faces option in the viewport. With this done, we are going to utilise the Snap feature to line up our mesh with the existing light socket surrounds. You may first want to go to Tools -> Grids and Snaps -> Grid and Snaps Settings and make sure Vertex is ticked in the Snap tab. With that done, select the Vertex sub-level of the Editable Mesh modifier (I circled the wrong thing in the image below, whoops). Select the verts in one corner of the object, and enable the Snaps Toggle button in the toolbar Hover the Move tool over the front-most vertex until you see a little blue cross. Then select and drag to the position you want to snap it to. You may need to alter your view position to make sure you are snapping to the correct vertex. Remember to only snap using the front-most verts. The back verts will retain their proper relative position as long as they are selected together. If you make a mistake, use Undo (shortcut CTRL Z) rather than trying to drag it elsewhere, as that often makes things worse. It can take some practice to get the hang of it, as the system is a little finicky. You should get something like this: Once you have done one, you can duplicate that mesh and repeat the process two more times for the remaining sockets: For the sake of reducing the object count, you should merge your three socket inners into a single mesh. Select one of them, then select the Editable Mesh modifier and hit the Attach List button (you can also use Attach to select objects directly in the scene, but I find the List approach less subject to mistakes). Select both of your other meshes in the list that pops up and hit the Attach button. Now your three socket inners are a single object. The final step to make sure there are no problems is to run a Reset XForm command from the Utilities tab. Then switch back to the Modify tab, grab the XForm modifier and drag it underneath the OdysseyTrimesh modifier. Right click on it and select Collapse To. This bakes all your transforms with destroying the OdysseyTrimesh data. Not a big deal in this case as it would be trivial to recreate, but something you want to get into practice for when dealing with skinned meshes. And that is pretty much it. All you need to do now is make your new mesh a child of the OdysseyBase, export it, and compile it. As we didn't make any walkmesh changes you can discard the binary walkmesh that MDLEdit produces.

I am making a request for a Jukebox to be added to cantinas that would allow the player to insert their own music - multiple tracks - so they can hear their own music choices play in those areas. I know you can just replace the music for those cantinas but not necessarily multiple tracks which would allow for some choice for the player. In addition - for the cantinas that feature bands - I'd like those bands to function in mostly the same way. This key difference would be that instead of using a jukebox dialogue, you'd essentially make your request for your song in a dialogue with a clickable band player. Finally: to have instructions in the read-me that make it simple to figure out how to both add the player's tracks of choice and also how to remove them. Songs would be provided by the player, of course.

The music side of things sounds easy enough. I've attached sound objects and the scripts to play them. These are the game sound objects - UTS files - and not the actual music. You can put in whatever music you want to play, so long as the file name matches what's on the sound object. I've included support for up to ten tracks, named sh_juke00 through sh_juke09. Or you can change them to whatever you want if you edit the files. The scripts will stop all ten sound objects, then play the specified new track. That's assuming they're all spawned, however. I don't know if you can spawn a sound object through a script - the notes in NWScript don't say - so they might have to be added to the module. Anyone who wants to continue this will need to figure out how to spawn the sound objects, create a jukebox placeable, and make that placeable able to fire the scripts for each track through a dialogue or whatever. SH Jukebox.zip

Can confirm. It's perplexing. And I don't know if discovering the underlying cause is even worth it, when fixing it is so much easier. For those interested, though, we were able to confirm the following things: It only occurs with certain appearances. All the affected models lack hand hooks. (e.g. HK-47 is unaffected) Not all models that lack hand hooks are affected. (e.g. Gizka are unaffected) It only happened with one UTC file that we tested. The weapon is spawned at world origin, making the problem unlikely to occur in other areas because the origin is usually outside the visible game world.

And you wouldn't even need to model the jukebox. The modder could export their favorite from the SWTOR files. Like this one? or this one? or this one? Or even this Rhythm Augmentation Droid!

They were likely added by KOTORMax as part of the baking process. The keys are there in 3ds Max and I can confirm that removing them does get rid of the problem, even without the "extra_data". I can take a guess at the problem now. I suspect it's some order of priority issue which may be limited to the talk animation specifically. I had thought the game the game loads animations in the following order: stunt model > body model > supermodel and that it shouldn't matter what animations are on the supermodel because it's loading from the stunt model first. Plus, in most cases it's only playing animations directly from the stunt model (CUT001W etc). But of course the game is playing the talk animation from the supermodel for the lip flap. It seems at the very least the order of priority loads the talk animation first, so keyframes for cutscenedummy on the talk animation will override the keys on on the stunt model, causing the problem. The question now is whether this problem is limited to the talk animation. I haven't encountered any other examples of it so far, but if the order of priority really is: body model > supermodel > stunt model and it just usually isn't an issue because the game usually only plays animations from the stunt model, then there very well could be other problems. But we can't fix what we don't know. I guess we'll have to wait and see.

I can't take any credit for it. You were the one that identified the war droids being the issue. It was simple deduction from that point. I doubt I would have ever leapt to that conclusion myself.