DarthParametric

A gap in the floor? Whereabouts specifically is that?

Stunt modules are just cutscene-specific versions of a given module, although often they will use a custom layout to remove any excess rooms that won't be seen (for example, STUNT_07 is the Ebon Hawk stunt module used during the Taris escape cutscene). TSL does the same thing, they just use the standard level naming convention rather than using the "stunt" label (for example, 352NAR is the Goto's yacht stunt module used for the bounty hunter briefing cutscene).

That's because that scene uses a stunt module, not the regular Hawk module. That would definitely point to there being some sort of mod issue with the Hawk module. See if you have a ebo_m12aa.mod file in your Modules folder and, if so, attach it.

I believe that AMD has a framerate lock option incorporated into their driver control panel. See if you can find that and set it to 59fps.

It's either covered over with a different set of panels, or they use a completely different model instead. From what I can tell, the turret module the game uses is M12AB, which uses models M12ab_MGT01 through to M12ab_MGT07. All of these models only contain a "modelhook", no geometry of their own. They also have animations, so I gather that is how they handle the enemy fighters. Hook them on to the dummies and then remove them when the game registers a hit with the turret. I guess the turret geometry itself must also be loaded this way, but there are no references in the layout or models themselves.

The only models in either game that reference it are MGF_carthturret and MGF_turlights (the former comprising the majority of the turret window and surrounds, the latter being some additional computer panels), both in K1. Both would appear to be part of the turrent minigame, but I see no reference to them in any layout. Looking at mgf_ebonhawk.lyt, it only references MGF_turretcam. I would guess MGF stands for something like "Mini-Game Fighters".

I can barely remember what happened yesterday, much less whenever that must have occurred.

Eh? What in the what now?

It's certainly possible, but I have no plans to port it. This is not a request thread.

View File TOR Ports: Handon's Enhanced Waistline This mod adds a new fat commoner male model, ported from The Old Republic MMO. It replaces the generic appearance used by Handon Guld on Dantooine, who, judging by the dialogue he is involved with, was originally intended to be an overweight character. Additionally, there are several other changes that have been made to the Calder Nettic murder investigation sequence: Handon now sports an injured idle animation to conform to dialogue mentioning he is holding his injured side Two erroneous fades to black in penultimate dialogue lines have been removed When the player solely accuses either Handon or Rickard, the other will now run off after being given permission to leave rather than standing around Master Bolook has had his appearance changed to a green Twi’lek to match one of Rickard’s lines of dialogue referring to him as a “green-skinned nerfherder” (apparently he was green in the original Xbox version, but was changed to orange for the PC version) N.B. - You will need to load a save prior to entering the Dantooine Grove for the first time in order for this mod to take full effect. Acknowledgements: This mod was inspired by Merkuri22's episode of her "KOTOR 1 Experience" series dealing with this quest Very special thanks to @JCarter426 for writing the custom scripts and doing lots of troubleshooting to get them working correctly Thanks to @bead-v for KOTORMax and MDLEdit Thanks to @ndix UR for TGA2TPC and normal map normalizer tool Original models and textures ported from The Old Republic MMO Thanks to zaramot on the Xentax forums for the TOR GR2 Max import script Submitter DarthParametric Submitted 09/20/2018 Category Mods K1R Compatible Yes  

Got something you might want to add @A Future Pilot The vanilla green female Twi'lek has a couple of problems. TSLRCM fixes an issue with the model, but there is still a colour mismatch between the head and body. It seems like Obsidian made a texture fix for it, but forgot to use it and kept appearance.2da pointed at the original K1 version instead. Changing the filename of the fixed texture and popping it in the Override is a simple fix. TSL_Twilek_F_Body_Texture_Fix.7z

Naturally I couldn't work on upgrading Wookiees without also devoting time to their mortal enemy: The textures are mostly still the base untinted brown colour at the moment.

http://starwars.wikia.com/wiki/Max_Rebo/Legends

Seems like the perfect place for one of Max Reebo's greatest hits.

That would purely be a shadow issue. The engine has trouble generating/rendering shadows from certain kinds of self-intersecting/non-watertight meshes, which classification the eyelids would definitely fall under. You can see a very clear example of this in action in M4-78:

The issue I had in TSL was that a static mesh with tangent space and lightmap flags enabled would not properly render the lightmap (i.e. the mesh was pitch black) unless the mesh was made a child of the A node. Then the lightmap would appear correctly.

Wasn't that basically the issue with @Kexikus's starfields mod breaking the fire VFX on one level of the Ravager and lighting on another? Vanilla worked fine, editing it borked it.

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 nulls are just model variation numbers with no vanilla models. It would be almost a certainty that some mod uses one of those variation numbers.

I couldn't see it on my tests, and as I recall both the turret inventories have null weapons equipped (which is the fix).

It's not done yet. Provided above is one way to circumvent this particular occurrence, but further experimentation by @JCarter426 only lead to more head scratching about the exact nature of the underlying cause And there's also the question of where else it might occur in either game.

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.