Jump to content


Member Since 10 Aug 2010
Offline Last Active Yesterday, 10:08 PM

Posts I've Made

In Topic: MDLedit bug reporting thread

02 November 2017 - 08:21 PM

Both problems are fixed, the new version will be available soon. Sorry it took a while!


OK so upon further testing, it appears that I am suffering from a random crash on loading character creation that is unrelated to this issue, as I can induce it independently. So scratch that off the list.

Additionally, I have also established that the problem is unrelated to UV changes/vert count. Basically the changes you introduced to fix the skin weight/node assignment issues in certain vanilla models now appears to cause that very same problem to occur in other models.


This one caused a lot of  :wallbash: because its source was some code that I could have sworn I removed. Things weren't making any sense and I really had to do step-by-step debugging to find the issue. Bleh.



There appears to be a case sensitive issue where MDLEdit will not recognise the name of a node with differing case from the first instance, as per this example.

I glanced at that thread but missed your post somehow, thanks for reporting it here. The checks are now case-insensitive and the model loads properly.

In Topic: MDLedit bug reporting thread

29 October 2017 - 06:50 PM

PMHC04 from TSL, but the vanilla model is fine. The problem is with a modified version of it, as described.


I need to reproduce the problem to be able to do anything about it.


It seems like edited models with differing numbers of verts and texture verts may be causing the game to randomly crash (not 100% certain as yet).


There is an algorithm when an ascii model is loaded that combines the vert, color and all the tvert arrays into a single MDL vert array. If for example the algorithm finds two tverts sharing the same vert, then the MDL vert array will contain two verts as well as two tverts, ie. the shared vert gets split into two. This holds for all the arrays. In addition to that, smoothing also affects the algorithm. If there is supposed to be no smoothing between two faces sharing a vert, the algorithm will split that vert as well. Any stray vertices are deleted, and the option 'Minimize verts' will further reduce the number of MDL verts to the minimum necessary while still preserving all the data.

Mismatches in vert and tverts counts are therefore expected, and tell me very little about what might be wrong.

In Topic: MDLedit bug reporting thread

29 October 2017 - 06:06 PM

It seems like edited models with differing numbers of verts and texture verts may be causing the game to randomly crash (not 100% certain as yet). On trying the old decompile/recompile trick, skin weights are being assigned random non-bone objects much like the issue with vanilla models above, like so:



What model is that?

In Topic: MDLedit bug reporting thread

29 October 2017 - 08:02 AM

Thanks for reporting this. The issue has been resolved and I will upload the new version of MDLedit when I find the time.


And can you please explain how do you make conversion from bezier to linear(mathematic expression, or at least point me where in source code you do the conversion)?


You just keep the point data and throw away the control point data. In the case of position, that means you just keep the first three values.

In Topic: KOTORmax

22 October 2017 - 09:28 PM

I made my own tool for that one a while ago. Would love to compare the code.

If you haven't found your way to it already, here's MDLedit's, in BuildAabb().


The function is a complete mess, because I left in all my attempts to come close to a vanilla result, in case one of them was on the right-ish track. A lot of it is still not commented out when it should be. At this point I'm not even using the negative axis settings in the Significant Plane / Second Child Property. Logically they aren't required, and even though I think there must have been some reason why they included them, we still don't know what the principle is for when they're used.


If anyone tinkers with this and gets better (ie. vanilla-matching) results, let us know. But as ndix UR mentioned, both our solutions work well, so this is low priority. Something I could do though is clean up that messy code...