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!