bead-v

KOTORmax bug reporting thread

18 posts in this topic

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.

Share this post


Link to post
Share on other sites

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

 

A9yfnJU.png

 

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

You'll occasionally see something like this:

 

KOTORMax_Rotation.gif

 

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.

Share this post


Link to post
Share on other sites

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. :)

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now