bead-v

It appears it's not about the animated values but about the base value. On the vanilla c_holododonna.mdl, all the skins have an alpha value of 1.0, same as all the other meshes, and that appears to be fine, even when they're at the bottom. Now I wonder if the same also applies for meshes, i.e. that the base alpha value needs to always be equal to or larger than the previous one throughout the model. Hopefully this wasn't just a case where it randomly doesn't crash, though.

No, your edited model, the one you released.

Well, there's one obvious difference between the dodonna holo model and the rakata holo model – all the skin nodes (= all the meshes with alpha 0.5) come before all the trimesh nodes (= all the meshes with alpha 1.0) in the dodonna model, but not the rakata model. That's one thing you could try. Also, mdledit fails to load dodonna's supermodel binary will this ever end....

Phew! So, do we know of any vanilla models with a non-1.0 alpha on skinmeshes?

Okay, so it appears at least that the changes a mdledit recompilation introduces aren't the culprit. So I guess we're back to suspecting the added alpha controller. If you're using mdledit's comparison function, it doesn't take offsets into account because that'd be way too much work to implement. So it's basically only useful for comparing models that should be for the most part 100% identical. If you add one byte in the beginning of a binary and compare with the original for example, it will mark the entire file as different. Anyway, if you add the alpha on the last mesh (Head), only the very last part of the MDL suffers from this, while before that the only changes are to the total MDL size (the first four yellow bytes in the header), the offset to the camerahook (at offset 73073) and the offsets and counts of controllers and controller data for the Head node (block 218471–218494, this is the part I forgot when I sent you the first file above). So it really is minimally different.

Me and VP had a cutscene in 903MAL for MVI which crashed often, but at very specific times during the cutscene. It didn't crash always though... at the time we didn't have the necessary knowledge to figure it out. This seems like it's more or less the same. So first we'd need to establish the following: 1. The vanilla model doesn't ever crash. 2. Does a straight mdledit v1.0.100 recompile sometimes crash or not? Do you feel like you've repeated the scenarios enough times you could confirm/answer those? Happens to me too... That's one thing I can't do without putting in A HUGE AMOUNT of energy, so much it's definitely not worth it. Besides, you'd still hit them by accident like that. I could move them between the two panels, but I bet people would hit them by accident there as well.

Nope, what we found so far is inconclusive. You say the vanilla model crashes when recompiled with the latest mdledit, I sent you an .mdx which is identical (we should check that actually, but it should be identical) to the .mdx that caused a crash, and apparently this one didn't cause a crash. If the crashes don't happen regularly, which is possible, it may be that the issue is not even the .mdx and we were just lucky to not get a crash while testing the .mdx's. If you load a binary model, the current game in mdledit changes to match the one of the loaded binary model. If you load an ascii model however, it compiles the model to whatever game was selected. And yes, mdledit always has compiled model data in memory (which is what it displays in the hex view. Also, when you save the model as binary, all it does is print those bytes to a file. All the processing happens when the model is loaded). Some actions in mdledit (changing the game/platform, adding bumpmapping) will cause a recompilation of the model, so the hex view will also show these changes. Apparently you changed the game to K2 (because it says so in your screenshot), so you caused the model to recompile in memory. At this point, you could change the game again, then load the original model with 'Compare to ...' to see what changes mdledit introduces to the model during recompilation.

Yes, all that the MDX contains is data for every vertex of every mesh, which includes: vertex coords vertex normal vertex color uv1 coords uv2 coords uv3 coords uv4 coords tangent space 1 coords tangent space 2 coords tangent space 3 coords tangent space 4 coords weight values weight indices + an extra empty vertex structure + sometimes some padding. So if there is no mesh on the model, then there's no MDX data. In such cases there is still an .mdx in the game files, but it's just an empty file. So visual effects, animated cameras, etc... all don't need .mdx's at all.

Ha! Well, something's fishy, because the last one is a straight recompile after adding an alpha to Head (which doesn't affect the MDX at all and is therefore the same as a straight vanilla recompile).

Another one... Also, what version of mdledit did you use to recompile the model? c_holorakata_alphaed.mdx

How about this one? c_holorakata_vanilla_v1.mdx

I just checked all the weights on the model, they all seem to be exactly the same. I looked very quickly, but there's also no reason why the should be different and they seem to work on the model, so I'm excluding that. I'm attaching an .mdx, if you can try that and it crashes, it'll exclude the padding bytes. That leaves the vert coords, UV coords and normals, the normals being the most likely cause. The algorithm fails to find some cross-mesh normals in that model, I will add those to another .mdx and send it for testing. c_holorakata_alphaed_v2.mdx

Yes, I missed some values in the new binary... here's a fixed version. This one definitely has alpha added to the Head node. Awesome! So, the MDX contains the vert coords, vert normals, UV coords, tangent space vectors, weights and the padding which may be different after recompiling with mdledit. It can't be tangent space vectors, because there aren't any on the model and it'd be weird if it crashed because of vert or UV coords. The MDX padding is also unlikely. So that leaves the vert normals and the weights. c_holorakata_vanilla_alpha_v2.zip

Not sure what you're talking about here. You said: My question is, does it still crash if you use the vanilla .mdx instead. Have you also simply tried recompiling the vanilla model without any changes?

Okay, in the mdledit-compiled version, the following types of bytes are different: Float bytes (green) – These are the most likely cause for the crash if the crash is caused by the binary. These are the reasons I can see why they might be different: mdledit's calculations result in different numbers a minimal difference on the float is introduced just from converting it from binary to ascii and back to binary the total area of a mesh is 0 in the vanilla binary animated UV floats have random values in the vanilla binary Some adjacent faces (purple) – unlikely Unused bone index bytes (purple) – unlikely Bone indices padding bytes (light grey) – unlikely Bone garbage array bytes (light grey) – unlikely Supermodel reference number bytes (light grey) – unlikely Padding bytes in the header, animation, controllers ... (light grey) – unlikely String padding bytes (dark grey) – unlikely MDX padding bytes (black) – unlikely The recalculated floats are: In the MDL: face normals, tbones, qbones, orientation controller data if compressed. In the MDX: vertex normals, tangent space vectors. My suggestion is to first try using the vanilla .mdx with the mdledit-recompiled .mdl (with alpha added to the Head node). Unfortunately, I can't test this myself because my game crashes as soon as I enable VBOs.

Wait, so you decompiled and recompiled the model I sent you with mdledit and it crashed?

Actually, it's even easier. Load the binary, change the game, save the binary. This'll work as long as there is no supermodel (in which case the newest version of mdledit will give a warning).

First off, what's the model? There are other models where alpha is present even when it's 1.0, so it's a good question why it's gone there. Anyway, if it really is gone, maybe we could convert another controller to alpha for testing. I'm not sure whether you can do that with mdledit or not (without recompiling the model of course). As for the big endgame model, mdledit keeps running out of memory, I'm trying various things to make it more efficient, but testing is really slow because of how long it takes to process that model before it crashes (it's even slower in debug mode). So yeah... don't have high hopes about this being solved soon is basically what I'm trying to say 😕 EDIT: Sorry, just saw you mentioned it's the same as above! EDIT2: I was checking mesh nodes, nevermind, I'm stupid today. EDIT3: Okay, I took the vanilla model and added in only the alpha controller for the Head node. Only the changes necessary to accomodate the new controller were made, everything else is the same as vanilla. Will this be a good model for testing? @DarthParametric c_holorakata_vanilla_alpha_v1.zip

Ah yes, I think I see it now. Anyway, @ebmar, do you know what to do to fix it?

Seems reasonable... I just find it weird that I don't see a sword on either model (looking at ebmar's pics).

The objects that end up in the pwk/dwk (the walkmesh itself, the use hooks and the parent hook) sometimes have their names listed in the .mdl, even though there are no nodes with those names in the model. It's not always though, and especially if you weren't using a walkmesh for them, you definitely successfuly avoided the issue. First we need to figure out what that means. Is it an animation that plays, is the model exchange for another one....? Yep, that model sure takes its time... anyway, I'm on it, I'll report back when I figure it out!

Whoa, crashes during ascii parsing! Wow, where have you been hiding that model? There were three problems with it. Two were my mistakes: 1. mdledit didn't ignore tabs, so when you put tabs instead of spaces it treated them as (parts of) keywords and got all confused. 2. Then there was a case where I was resizing the bone array to the number of names instead of actual nodes. This was never a problem because you practically never get bones in placeables and doors (which is where those numbers mismatch), so hooray for this model! 3. The last one is the ascii format. One of the animations was missing nodes connecting the ones that were animated to the base. You fix this like so: # ANIM ASCII newanim on2off PLC_RakatHol length 0.0333333 transtime 0.0 animroot PLC_RakatHol node dummy PLC_RakatHol parent NULL endnode /************************************************* INSERTED node dummy cutscenedummy parent PLC_RakatHol endnode node dummy rootdummy parent cutscenedummy endnode node dummy torso_g parent rootdummy endnode node dummy torsoUpr_g parent torso_g endnode node dummy necklwr_g parent torsoUpr_g endnode node dummy neck_g parent necklwr_g endnode node dummy Hturn_g parent neck_g endnode node dummy head_g parent Hturn_g endnode node dummy REyeStalk_g parent head_g endnode /************************************************* END INSERT node dummy eyeRA parent REyeStalk_g alphakey 0.0 0.5 0.0333333 0.0 endlist endnode node dummy eyeRlid parent REyeStalk_g alphakey 0.0 0.5 0.0333333 0.0 endlist endnode node dummy eyeRlidLWR parent REyeStalk_g alphakey 0.0 0.5 0.0333333 0.0 endlist endnode I'll check it out, but it's interesting cuz it's the same function handling all the controllers... we'll see mdledit_v1.0.100b.zip mdledit_v1.0.100b_xp.zip

I know I said there'd be no more unoffical versions, but the changes for this version were so big it would be stupid to release it directly. All the binary read/write functions were rewritten to make sure errors that were happening previously can't happen anymore. In terms of new functionalities there's not much, except that the connection between the tree view and the hex view has been improved and if you turn on AutoScroll, the hex view will automatically jump to the corresponding data as you traverse the tree nodes. Nothing new with the tangent space vectors, I took a look at it but I would need more time for that... I think this'll have to wait a bit more until me and ndix UR have more time to figure out the algorithm. Anyway, this is the release candidate, if there are no serious bugs I'm releasing it as v1.1.0. mdledit_v1.0.99b.zip mdledit_v1.0.99b_xp.zip

You do use the .tcl, but that uses the CSLU toolkit, which you have installed apparently.

That's not a .phn file, that's a .tcl file. You can't import that into the LipSyncEditor.