KOTORmax bug reporting thread

[bead-v 251]

This thread is for reporting bugs you encounter while using KOTORmax.

 

If you encounter a bug, then before you do anything else, try to reproduce it. If you manage to reproduce it, describe what you did that caused the bug, in steps. If there was an error message please post a screenshot, especially if some code is also displayed, that will greatly speed up the bug fixing process. If the error occurred while processing a file, please include that file in your post.

A note: Sometimes the error message will contain the line of the file at which an error occurred, but that number is not necessarily correct and the error might be elsewhere in the file. That's why it's important you include the entire file (and all the files) with your message, not just the snippet that allegedly caused the error.

To-do:
 - add a warning when there is a BASENAMEa child of the base, but there are animated nodes that are not descendants of the BASENAMEa node.

[Sithspecter 909]

Lightsabers that go through KotORMax/MDLEdit seem to end up like this:

 

 

Fortunately this seems to resolve the issue I had with my crossguard lightsabers being extended all the time, just looks like a little UV mixup.

 

This is the unchanged default blue lightsaber, simply brought into ASCII by MDLEdit, into KotORMax, exported back out of KotORMax, and then back into binary by MDLEdit.

[DarthParametric 3,794]

I just tried a decompile of a vanilla saber, import/export into KOTORmax, recompile and get the same thing. Trying to decompile the new binary gives an error:

 

 

Here are the files: https://www.darthparametric.com/files/kotor/misc/Recompiled_TSL_Saber.7z

[bead-v 251]

It's a probem with MDLedit, the same thing happens even if you don't pass it through KOTORmax. I've got a few ideas, gonna try them ASAP. Thank you both for the screens and the files.

[DarthParametric 3,794]

The screwiness between animations still persists. You may want to add that to a "known issues" section in the download description so people are aware of it.

[Guest Qui-Gon Glenn]

Well, this is interesting

 

Beyond my feeble skills to take of advantage of, but still quite interesting!

[bead-v 251]

The screwiness between animations still persists. You may want to add that to a "known issues" section in the download description so people are aware of it.

Heh I've since long accepted that there's nothing I can do about that. Since it's just padding anyway, I even stopped considering it to be an issue. But I can totally see how it might confuse people, so I'll definitely do what you suggested.

[Sithspecter 909]

Heh I've since long accepted that there's nothing I can do about that. Since it's just padding anyway, I even stopped considering it to be an issue. But I can totally see how it might confuse people, so I'll definitely do what you suggested.

 

What's the screwiness between animations?

[bead-v 251]

What's the screwiness between animations?

I was looking for a video to demonstrate it but I couldn't find one. Basically when you import a model with animations 10 frames are inserted as padding between every animation. Sometimes, the model will do some (unwanted) rotation of body parts during those frames. Because those frames aren't actually included in your animations this won't have any consequences for the model in the game, you just have to learn to ignore it in max because there's nothing I can do to get rid of it.

[DarthParametric 3,794]

You'll occasionally see something like this:

 

 

in the padding before the start of an animation sequence. Although it has been drastically reduced in the release version, to the point where I had to hunt around a bit to find an example.

[JCarter426 1,220]

I got some reports on the area tools. As I said when we talked on Discord, these are more ease of use issues than critical bugs. But I think I've nailed down which problems were in KOTORMax and which were in the user, so here we go:

• If I've imported rooms from different modules or duplicated rooms, then some rooms will have the same assignment number in the room order. This breaks the Order Rooms function - it won't allow reordering of rooms until the conflicts are dealt with. The issue will happen if there are Odyssey base objects with the same room number (obviously) but it can still occur after the duplicate rooms have been deleted. I suspect this happens if there are still walkmeshes pointing to the deleted ghost rooms. At first I was deleting all Odyssey bases and OddysseyWalkmesh modifiers and redoing everything, but fortunately that is not necessary. I've found that setting every Oddyssey base layout type from "room" to "none" will clear the room order and then they can be set back to "room" without having to relink everything. Though these must be done one by one, so it's a little inconvenient. Edit: Scratch that, I was just dealing with this again and this didn't work. It gave everything the same assignments they had before. And the walkmeshes assignments seemed to be cleared already. I did have to delete one of the "duplicates" and create and link everything to it.
  Maybe when that error occurs, have an option to clear the room order and all assignments?
• After changing the room order, the new order is not reflected in the visibility GUI or the walkmesh room link GUI.
• KOTORMax's visibility preview is super handy in theory, but the problem is you can't control the viewport while editing the visibility because it's in a prompt window. If it could be changed to an undocked window, like the animation editor, that would make it a lot more convenient.
• Visibility is always output in the order that it's selected rather than being based on the room order or alphabetically or something. This doesn't make a difference, but it kind of irks me that there's no way to change it once it's done apart from setting everything to no and starting over. A way to reorder the visibility in the same manner as the rooms would be nice.
• With the above two matters in mind, I've found it quicker in some cases to edit the visibility in Notepad, but there is no way to then import that back into the KOTORMax project. Same goes for the layout file. I tried importing them without models but KOTORMax treated it as adding new copies rather than updating them. I can update the info if I import everything from scratch with the new files, but this means losing stuff outside KOTORMax's scope like selection groups or anything not linked to an Odyssey base (like objects kept for reference, or templates for things like doorways). So I can get around the issue, but it would be more convenient if KOTORMax had an update function for layout and visibility files.

For your consideration.

[JCarter426 1,220]

I got another bug to report. You can probably file this under "problems only JC will ever have" but I've confirmed it's KOTORMax's doing and not mine. I've attached two sets of ASCIIs and binaries; v19 is broken, while v28 works. If you warp to stunt_51a or stunt_07 (among others) in K1 you'll see it. I've compiled both with MDLEdit, so the issue was specifically with the data KOTORMax exported. The fix was to copy data from the original ASCII file (also decompiled with MDLEdit) to overwrite the data that KOTORMax exported.

The problem here was with my cloaked robe/dancer outfit rig, putting the K2 robe bones on the K1 skeleton. It works as intended, but it had unintended consequences with the cutscene dummy on certain animations. It would cause the model to get stuck in the wrong position, either at its last known location or the origin. I solved most of the problems by baking the cutscene dummy and adding some missing keyframes in certain places. However, this process seems to have broken the talk animation - the one literally called "talk" that handles the lip movement, not the character talk animations such as tlknorm or tlksad. The problem was specifically with cutscene animations for female characters when they talked. Male characters (talking or not) and silent characters (like the player) would not have this problem. It took me a while to figure this out, though. When I did, I was able to manually edit the ASCII file to fix the problem with the data KOTORMax gave me.

Here is KOTORMax's output:

    node dummy cutscenedummy
      parent S_Female03
      positionkey
        0.0 -0.00019955 0.0 0.0
        0.5 -0.00019955 0.0 0.0
      endlist
      orientationkey
        0.0 0.0 0.0 0.0 0.0
        0.5 0.0 0.0 0.0 0.0
      endlist
    endnode

And here's the corresponding part on the original ASCII model / what I had to do to fix it:

    node dummy cutscenedummy
      parent S_Female03
      extra_data 18
    endnode

Changing that and that alone was enough to fix it.

Talk Woes.zip

[bead-v 251]

On 9/7/2018 at 3:09 PM, JCarter426 said:

I was able to manually edit the ASCII file to fix the problem with the data KOTORMax gave me.

All extra_data does is add in a few bytes that the game doesn't use, just for the sake of byte-for-byte comparison in mdledit. So really all that you're doing is deleting the keys. Now the question is whether the keys are there in max, or whether kotormax somehow puts them there during export.

[JCarter426 1,220]

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.

[Kexikus 995]

It seems like KOTORMax's area import function does not properly import (all?) animations.

I noticed that when working on the Telos skybox models that contain animations for the birds flying around. When I imported the entire area using the "Layout File Import", those animations just wouldn't be there. "With Anims" was checked of course. But when I use "MDL Loading" instead with the exact same model, the animation will load just fine.

I've attached all the corresponding files. The issue was with 233TELSB. The other models don't have animations (I think).

233tel.zip

[JCarter426 1,220]

They animate for me. The only difference I see is that when loading the area instead of the individual model, it does not zoom out on the timeline to fit the animation length.

[Kexikus 995]

I wasn't able to see the animation in Max and when I exported the model the animation was missing as well.

The first might be due to the timeline not zooming out but it should still export the animation, right?

[JCarter426 1,220]

It shouldn't matter, yeah. That's just a preview in 3ds Max and shouldn't affect the animation actually being there.

[DarthParametric 3,794]

Got a LYT that causes the script to choke. Seems it absolutely does not like the room count not matching the actual number of room models.

#MAXLAYOUT ASCII
filedependancy m40ad.max
beginlayout
   roomcount 13
      **** 225.0 44.99 0.0
      **** 195.0 65.0 0.0
      **** 215.0 45.0 0.0
      **** 160.0 43.0 0.0
      **** 131.0 80.0 0.0
      **** 106.0 79.0 0.0
      **** 175.0 65.0 0.0
      M40ad_25a 300.0 50.0 0.0
      **** 160.0 110.0 0.0
      M40ad_08d 244.0 44.99 0.0
      **** 145.0 65.0 0.0
      **** 170.0 110.0 0.0
      StuntRoom40d 280.0 50.0 0.0
   trackcount 0
   obstaclecount 0
   doorhookcount 12
      M40ad_08a door_17 0 190.45 55.0 3.0 0.707107 0.0 0.0 -0.707106
      M40ad_24a door_15 0 151.65 55.0 3.0 -0.707107 0.0 0.0 0.707106
      M40ad_20a door_14 0 123.0 75.15 3.0 1.0 0.0 0.0 3.84015e-007
      M40ad_21a door_13 0 115.0 61.15 3.0 1.0 0.0 0.0 3.84015e-007
      M40ad_28a door_16 0 166.85 55.0 3.0 0.707107 0.0 0.0 -0.707106
      M40ad_27a door_21 0 122.5 92.5 3.0 0.0 0.0 0.0 1.0
      M40ad_27a door_20 0 126.5 96.5 3.0 0.707106 0.0 0.0 0.707107
      M40ad_27a door_22 0 184.5 79.5 3.0 -1.0 0.0 0.0 0.0
      M40ad_27a door_23 0 184.5 63.3 3.0 -1.0 0.0 0.0 0.0
      M40ad_27a door_24 0 184.5 70.5 3.0 -1.0 0.0 0.0 0.0
      M40ad_08d door_18 0 249.2 55.0 9.0 0.707107 0.0 0.0 -0.707106
      M40ad_07b door_25 0 141.15 55.0 3.0 0.707107 0.0 0.0 -0.707106
donelayout

This is stunt_levbridge.lyt, which is obviously just M40AD with most of it removed.

[JCarter426 1,220]

Could be it's not happy with the rooms named **** or that there's more than one of them with the same name. Is this for import or export?

If you're importing, it would probably be fine to just delete the unused lines and change the room count. If you're exporting, maybe substituting the real lines from m40ad would get it to behave.

[DarthParametric 3,794]

It's both the **** and the roomcount number. You have to both remove the former and change the latter to get it to successfully import.

[Kexikus 995]

Encountered a small bug today or at least a small issue.

The "uvdirectionx" and "uvidrectiony" parameters for animated UV maps have a smallest possible value of 0.001 but there are actually vanilla models like the Manaan underwater skybox that use smaller values that are rounded when importing them into Max. The same is probably true for other parameters as well but that's where I noticed it.

[DarthParametric 3,794]

That's probably a Max problem. I don't think the UI supports higher than three significant figures for stuff like that. Try typing in some co-ords and see what happens.

[Darth_Misha 0]

Hi, 

 

I am currently trying to tweak Darth Parametrics https://www.darthparametric.com/files/kotor/k1/[K1]_DeadMan_Ep3_Anakin_Skywalker_Revised_02.7z

I use MDLedit to compile the MDL into an ASCII 

I import Geometry and Animations into 3DS Max 2012 Via KotorMax 

I make a slight adjustment to the face 

When I export the OdysseyBase, the photo in the attached happens.

How do I fix this? 

I have been a fan of this game since late 2004 and would love to be able to create my own head mods. Can anyone help me out? Thanks in advance.  -Misha

Also, is there a way to change this? I want to resize different things and am not able to due to this.

[bead-v 251]

Hey Darth_Misha!

You can try opening the file that is displayed in your first screenshot with a text editor and change

if (nMaxVersion == 14000) then bone_name = (skinops.getbonenamebylistid m bone_id 1)
else bone_name = (skinops.getbonename m bone_id 1)

to

bone_name = (skinops.getbonename m bone_id 1)

and try again.

If that doesn't work I'll do some digging, but I may need your help in terms of testing because the issue is related to the version of max you're using.