Leaderboard

Heeeeeeeeeeey, that sounds... ...familiar. My guess is it's thanks to the good old -a node. It seems like that's a catch-all method to have objects on an area model but behave not like an area model. Obsidian definitely did something under the hood that changes how things are rendered. I think we discussed this away from the ears of the common soldiers already, but might as well put it on record. In K1, dynamic objects (creatures, placeables, doors) only render depending on the visibility file, just like areas. If the room they're in isn't visible from the room you're in, you won't be able to see them. You can confirm this by messing about with the camera using GLIntercept. In K2, it's different, however. All dynamic objects render all the time. This includes any area objects linked to the -a node. Here's a good visual example of it: I took the screenshot when my party was in their apartment. You can see an example of a room that's visible from our apartment - the exit to the shuttle bay. You can also see that the apartment complex across from us is not visible from our apartment and therefore most of the area geometry doesn't render. However, all the dynamic objects in those rooms do render - the doors, the placeables, Harra - as well as the windows and window blockers on the room models, because they are linked to the dynamic -a node. Why they did this, we can only guess. But as I said in my previous bug reports, I suspect the presence or absence of a walkmesh is interfering with things because Obsidian used the aabb node to differentiate between static area models and dynamic objects as some sort of prerequisite for what should be rendered. Perhaps if they hadn't done that, then all rooms would render all the time, making the visibility file pointless. The trick, it seems, is sorting out what exactly the other prerequisites are....

New entry. enjoy. Credit to @Sith Holocron for the beautiful intro and thumbnail for the video.

I checked our conversation about that issue, there's indeed a lot of bizzare stuff happening, but I'm pretty sure it all has to do with the setup of the models and not the tools themselves. Unfortunately, all the .zips with the model files are inaccessible and it seems that since the site update we can't download previous versions of mods anymore, so I barely have anything to look at. I guess I'll just try to describe what was going on... Kexikus added the model 851nih53 to 851nih for his Backdrop Improvement mod. At first that had ignorefog off, so telos appeared completely fogged out. He originally disabled fog for the entire module to fix it. Then for v1, he hex-edited (I assume) his 851nih53 to ignore fog. Now the issue was gone so fog could be turned on for the entire module again. BUT, now the flames in 851nih02 dissappeared. Apparently this was caused by enabling fog for the module and disabling it for 851nih53. It was then discovered that if the walkmesh in 851nih53 was deleted, the flames would show, but now 851nih53 wouldn't show. We now know that this is because the game doesn't render area models without a walkmesh if the .vis file is available. So it seems that if it has to render 851nih53, in some way that breaks the flames in 851nih02. This the structure of the model: It was discovered that if the plane* nodes were deleted or moved under 851nih53a, the flames would show as well as the model. But apparently, moving those planes under the 851nih53a dummy caused (or at least, didn't fix) the smoke VFX in Visas' room to disappear. DP then deleted the walkmesh and moved everything under the 'a' dummy like so: This then fixed all the issues. Apparently, under some circumstances, an area model is STILL rendered even though it doesn't have a walkmesh. @JCarter426 😮 Then there were some more problems in the other ravager module. This time something was up with the lighting. There were two area models added, 852nih13 with some ravager geometry and the reused 851nih53. The issue was fixed by applying the dummy solution to 852nih13. On the first try we forgot to move the skydome itself under the dummy, which though it caused the skydome to show, made it fogged up, and that's even though ignorefog was enabled! This is all even more bizzare than I remember. I guess the first step in solving this would be to figure out why 851nih53 renders without a walkmesh.

Fantastic! Thanks for providing the analysis! It could act as a preview; to decide whether yes or not to install the particular mod in the next playthrough.

All animated objects must be children of what is termed the "A" node. This is the dummy that is named "LEVELNAMEa". For example, "M01ABa" for level "M01AB". It seems in some cases that vanilla models don't always conform to this rule, but it is a requirement for any level models compiled by MDLEdit/MDLOps. Additionally, my own recent experiments indicate enabling the tangent space flag (possibly only in conjunction with an enabled lightmapping flag) counts as animation as far as MDLEdit/MDLOps compiled level models go, so they also need to be children of the A node. This appears to be a requirement regardless of whether the model is actually truly static or not. This particular issue is currently being investigated by @ndix UR. so clarification will hopefully follow in due 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

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.

Here's a two-for-one special episode of Mod Analysis (fixed)