This question goes pretty deep. I know module modelling is a pretty new concept, and there are still a lot of bugs, but maybe somebody out there knows something... Well, here goes. Using KAurora, we have the ability to create walkmeshes. The problem is, they do not block the camera, blaster shots, or the line of awareness. If anyone can help, or wants to do research, this would be a major lift for module modelling. I will post my knowledge of this subject as I discover more about it.

I doubt the problem is in the walkmesh. I decoded pretty much every field of the .WOK files except one; but this unknown field can only take a finite number of values (-1, 1, 2, 4, 8, 16, 32). The -1 is assigned to every leaf node in the AABB tree, while the other six values are differently assigned to non-leaf nodes. On a hunch, they have something to do with the axes used for the splitting algorithm used while building the tree; they ought to represent a bitmap field coded to positive and negative X, Y and Z axis.

KAurora correctly assigns -1 to every leaf, while the other values are assigned using an algorithm which is certainly wrong but doesn't look like it has an impact on the game; maybe this field was used while compiling the tree.

My guess is that the problem you have in the new models is due to unknown fields in the .MDL and/or .MDX files which are generated by KAurora; I decoded the .MDL and .MDX structures too, but there are still a few fields which I don't get.

I'm not sure. I mean, I'm not saying you're wrong, but I've taken a look at quite a few walkmeshes, and they all use a floor material, and then walls of non-walk. But, when I try to use non-walk, a lot of times I get an error, but some of those times I've tried to make a walkmesh out of multiple meshes.

I'm not sure. I mean, I'm not saying you're wrong, but I've taken a look at quite a few walkmeshes, and they all use a floor material, and then walls of non-walk. But, when I try to use non-walk, a lot of times I get an error, but some of those times I've tried to make a walkmesh out of multiple meshes.

Now this is more interesting. What kind of error do you get? If you can, send me the model which is giving you problems. I can use it for a debug run to find and correct any bug KAurora might have.

Remember, though, that you can only have one walkmesh in a room. If you need to create one from multiple meshes, just clone all of them, combine the clones in one single big mesh and then "walkmeshize" it.

I think the Exporting script of NWmax might be to blame to.

It isn't perfect and it even doesn't generate every possible option for meshes.

I just recently dug into the .mdl files of Kotor areas and noticed this
"SelfIlumColor". I added it manually in the ASCII file before compiling with Kaurora.

It gives you the change to Illuminate your applied textures.
This comes in handy for things like Lights to be bright and actually look "ON".

Now SelfIlumColor is one of those standard things in Max Materials like Diffuse and Ambient.

The last 2 get exported out, I once had a purple floor and had no idea what affected my texture which was a dark grey steel. Untill I noticed my Diffuse color was set to purple instead to the standard neutral grey.

Anyway I just want to point out the exporting done by NWmax isn't perfect.
So perhaps it might have an effect on the Walkmeshes/ meshes.

I think the Exporting script of NWmax might be to blame to.

It isn't perfect and it even doesn't generate every possible option for meshes.


While you are absolutely right on this, most of the data contained in the WOK file (like the AABB nodes) is recreated by Kaurora anyway because NWMax does it the wrong way for Kotor. So I doubt the problem stems from some missing field. Then again, I didn't decode everything, so....

About the crashing, it was because I tried to use multiple meshes to do the walkmesh. Too bad we dont have a KMax.

While you are absolutely right on this, most of the data contained in the WOK file (like the AABB nodes) is recreated by Kaurora anyway because NWMax does it the wrong way for Kotor. So I doubt the problem stems from some missing field. Then again, I didn't decode everything, so....

Yeah I notice, did some tests this week, but no result what so ever...

I wonder, what do we know about the Camera of Kotor ?

It must be some kind of "object", with a bounding box I suppose... how else could/ would the game do the collision testing.Plus there's this 2DA with differant Cameras...

This makes me wonder where the hell they keep the info about the box surrounding the player/NPCs/Beasts ?

Or would the WalkMesh have nothing to do with ?

It's definitely the model. I made a door model and used door .dwk's from the game, but the camera just flies through the door. About the characters/NPC's, it must be something in the model. OR, it could be the cameras.

I've done a little experimenting in this field, though hardly enough to have the whole picture, and I may have an idea what the problem is.

Basically, as I understand it, each of the new walkmeshes created has been 2-D - that is, effectively a clone of the floor, with holes in for the walls/etc. Now, if I'm right, wall-walkmeshes need to be made, which should stop this.

The alternative theory I have is that you should cheat much like I think the devs do several times in-game, by making it so that you can never get close enough to the wall that the clipping issue becomes a problem - so build the walkways slightly away from the wall, like in the sith tombs on Korriban, or something.

I hope something there is useful.

Even if we make the walkmeshes far away from the wall, we still have problems with the line of awareness and blaster bolts. The blasters will still fire right through the walls, and this is a BIG problem, and I don't think we could cover it up, with a whole planet and all. I have discovered that Walkmeshes are not the problem. It's the models. My door uses an origonal walkmesh from KotOR, but it does not block the cameras. We need a new modelling tool for GMax and 3Ds Max.

I have discovered that Walkmeshes are not the problem. It's the models.

That's what I have been suspecting, too.

There's an unknown array made up of a set of 9 [IIRC] coordinates per vertex within the .MDX file. It looks like some kind of normalized vector field, though I still don't have a clear picture on what it is.

KAurora currently never creates it while importing the model from Max. This is for 2 reasons: A) I can't know how to create it until I figure out what it is; B) this structure is not present on all trimesh nodes anyway, so I figured it was not strictly necessary for the model to work.

Ever since Quanon first reported the camera problem, I've had a nagging doubt that this structure could be a sort of "collision field" used by the engine to handle cameras, lines of fire etc. It certainly is the only as yet unknown piece of the model puzzle that seems able to hold the necessary amount of data to handle something of this complexity. Everything else in the trimesh structure which I haven't decoded yet is made up of simple fields, one per node, which would hardly be enough to handle this (the exception would be a simple on/off binary flag which tells the game to use the whole node for blocking sight, but all the unknown fields use a range of values which goes beyond a simple 0/1 choice).

I'll have another, more in-depth look at this structure. Maybe I can find something interesting.

(the exception would be a simple on/off binary flag which tells the game to use the whole node for blocking sight, but all the unknown fields use a range of values which goes beyond a simple 0/1 choice).


Blast, I often thought it might have been something along those lines and that it might even have been contained in the AuroraTrimesh modifier.

No luck, the modifier just gives things like "Render" , Beaming, Shadow and the selfIllum thing :bump1:

Which like a dumb*ss I'm overlooked or forgot that it was there...

Plus I had no idea Kotors engine would have it so difficult to detect these kind of collisions ? => Mainly wiht the camera object.

I suppose the choices might effect how the game should react with the meshes .

Offering that it blocks the camera, but not LineofSight of AI and blaster fire.
That blocks all.. or nothing at all like we have now.

Perhaps they did this for meshes that are curved or who form a corner.

I've found out that it's not the walkmesh, definitely. Well, at least not the placeable. Placeables just have a flat walkmesh, so I know it's the model. I wish we could get those d*** fields figured out...