bead-v

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.

You know, my guess is as good as yours. People forget sometimes, but I don't actually have a lot of experience with modeling or working with gmax (and 0 exp with 3ds for that matter). Anyway to figure this out, you need to isolate the thing you did that caused this. From just a static gmax file it won't be possible to figure out what action caused the state, you need to try a bunch of things you did to the original, check after every single action and see at what point the problem appears.

They may have different geometry – we had one example from Manaan where one vertex had different coords in the WOK, but this was lost on recompilation because MDLedit took the MDL AABB data by default (operating from the same assumption that they're always the same). As a result, the PC would get stuck trying to walk over that part of the walkmesh. It's possible that this was a manual fix only to the WOK, while the AABB node retained the original value. But yes, generally, they're the same. According to ndix UR, this is probably a remnant of a client–server setup. Nope, the "root node" is not a node in the same sense as its children, it doesn't have the same structure in the file format. The structure it has does not support controllers.

We called it the "inverted counter", it seems to be a number that is different for each mesh, but it usually starts from something like 99, 98, 97, etc... however, it doesn't seem to affect anything, even if we leave it zeroed out. The tools use an algorithm that creates this kind of sequence, but really the pattern isn't uniform across models, so the algorithm is just there for the numbers to kind of look like the vanilla ones. In case you decompile a model, the numbers will be stored as inv_count in the ascii, so that the same ones may be used if that model is recompiled.

I wanna do DAO-style vertex normal exporting/importing, like you suggested once... I also want to completely rewrite mdledit anyway... hopefully I'll have enough time during the summer. But yeah, until then you're stuck with what we have ...

🙈 MDLOps might produce different results, but I'm sure you're aware of that.

I think that's why we brushed it off to some limitation in the engine, IIRC

The format can store 65535 verts and 4294967295 faces per mesh. Weights are per vert, so they're also tied to the 65535 limit. It's also possible there's some limitation in the engine, but I wouldn't know about that.

That did the trick, thank you very much DP

As for the first one, I've also been getting it, but it only started recently and I haven't noticed it cause any problems. As for duplicating, you can drag holding Shift and then there's also Edit → Clone.

A breakdown of Palpatine's plan

It may be that those weren't intended to print anything in the game itself but a console window, which would be present in a working/debug version of the game. If that's the case, it's not so much that they don't function as that they have no effect. In any case, anything that can be preserved, should be!

So does this mean the entire mesh's weights are destroyed if you just add or remove one vert? Or is it just that in the relevant portion the weights don't correspond to the ones around them?

You could use the onEnter script to temporarily disable the script while the module is loading. Something like void main(){ if(GetLoadFromSaveGame()){ SetLocalBoolean(GetArea(OBJECT_SELF), 50, FALSE); /// Disables the behavior DelayCommand(2.0, SetLocalBoolean(GetArea(OBJECT_SELF), 50, TRUE)); /// Continue behavior after two seconds } } If GetLoadFromSaveGame() works as described, it might even work if you put this directly into your UD script.

Thanks for reporting this! This is a situation the code doesn't consider, so it crashes (unfortunately). I can reproduce the problem, but I'll have to hunt down to place where it happens when I have more time. In the mean time just make sure your animations have nodes in them if your experience another crash (or alternatively delete the animations). Sorry for the inconvenience!

I can't check now, but you can do it yourself, open the ascii with a text editor and see which skin has "weights 0".

There are 0 weights on one of the skins in the ascii, which is why mdledit fails to load it. I've handled this case for the next version of mdledit, it will convert such skins to trimeshes and issue a warning in the report. Thank you for reporting this! In the case at hand, you either need to make sure there are weights on the skin and that they're being exported (could also be a kotormax error), or just convert the skin to a trimesh (if there weren't supposed to be any weights in this particular version of the model) to get it to compile.

No no, just the one ... that is a list of textures that appear in the model. Every mesh has it's own texture (you can see that in the screenshot; btw in area models, the meshes can have a second texture which is the lightmap; texture 3 and 4 that you see in the screenshot are not in use by any vanilla model). So when you rename one of the entries in the list, the textures will be renamed on all the meshes that use it in the model. The game will apply the DS texture dynamically based on what you've entered in the .2da files. But you do need to specify a base LS texture in the model apparently.

The result of just renaming a random texture to the right name: Check that your texture is named the same as in the model and is present in the override folder (not a subfolder of it because those don't work in K1). Also make sure the name is <=16 chars, because that's the maximum length of any resource name.

You're gonna have to be a more specific than that ... 😐 You can use mdledit to change the names of the textures safely without hex editing (Edit → Textures).

Here's what worked for me: changes.ini.txt I needed to make three new rows in appearance.2da, one for each body size. This information then had to be inserted into portraits.2da (check the changes.ini). I think this is the reason why your character appeared headless. As for the portrait not showing up, I'm not sure what exactly was wrong, but mimicking the vanilla setup solved it. Make sure you have all the PO_*.tga's in your override folder.

Read this: https://www.moddb.com/games/star-wars-knights-of-the-old-republic/tutorials/new-playable-character-tutorial Apparently your portrait textures are not named correctly. Also, you are copying the first row in the appearance.2da, which doesn't seem to be the most suitable choice. EDIT: Also, you shouldn't be setting the .2da files to be replaced. If you want to be able to run the installer multiple times, TSLpatcher can be configured to check whether a .2da row/file already exists and not install it in such a case.

Well, the model is fine: So you must have done something wrong with the TSLpatcher... I can't help you further without knowing the details... maybe you can upload the changes.ini file ..

Can you describe what you did to put the head into the game? Did you try to replace one of the existing heads or add it as an additional one?