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.

5 hours ago, Malkior said:

I plan to send a copy of my GMax file to bead-v in the hope that he can figure out what went wrong with my file.

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.

4 hours ago, Crazy34 said:

In the model ascii for trimesh there is the property inv_count. What is it and what is it tell me? 

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.

1 minute ago, DarthParametric said:

Yeah, but it's still crap. Just a different kind of crap. Make me a 2020 replacement for Taina's Replacer so I can just sidestep dealing with smoothing/normals altogether and simply inject my UV/vert position changes into the vanilla model.

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

13 hours ago, DarthParametric said:

Damn your eyes @bead-v.

🙈

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

2 minutes ago, DarthParametric said:

Hrm. I'm not sure that I have the specific mesh I encountered the problem with any more. I know it was a Nautolan head that I ran through Turbosmooth. But the version I dug out of my crap pile is only around 8K tris/4K verts (if it were a single mesh - it's actually split out to about half a dozen). It does seem that was only a single iteration though. I think the mush version must have been 2 iterations as kind of a "let's see what happens" experiment. But running the source low poly through that still only comes out to ~32K tris/16K verts. Maybe it was actually ye olde MDLOps choking on it.

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

19 hours ago, DarthParametric said:

Single skinned meshes up around 10K polys tend to turn to mush, presumably due to some upper limit for weights in the model format or something (@bead-v would know more). Shadow casting meshes above around 2Kish polys cause crashes. It's mostly the hair that's the problem, and that should be able to be completely separate static mesh, so you shouldn't have too many hard limits.

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

3 hours ago, DarthParametric said:

I'm assuming these are all the debug functions? PrintString, AurPostString and the like? I was playing with those only yesterday and noticed that despite removing if (!ShipBuild()) checks, they still didn't appear to function. I assume they gutted them from the retail release altogether? While they are unnecessary for the code to run, I would argue they should remain in any decompiled scripts since, in the absence of commented source for the module scripts, the debug functions are the only thing remaining that can indicate developer intent. Additionally, the user can manually change them to SendMessageToPC for their own debugging purposes if needed.

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!

15 hours ago, DarthParametric said:

Adding geometry or welding verts will destroy the skin weights, since weights are assigned per vertex and thus rely on unique vert ID numbers, so this is not something to be done haphazardly.

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?

On 3/1/2020 at 5:30 PM, Salk said:

The problem comes if the Player saves during the countdown. The script will be running while the game is being loaded and that is not good but I fear there is no way to disable saving the game?

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.

1 hour ago, Kexikus said:

in both cases MDLedit just crashes when loading the model.

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!

3 hours ago, defreili said:

Do you know which skins lack weights bead-v?

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.

3 minutes ago, defreili said:

In the textures it needs all 4 to be there right? Or just the one? Because it only allows me to put 2 there for some reason.

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.

10 minutes ago, defreili said:

I need to change the texture name in the mdl then. I'm trying to use mdledit but I'm unsure of where I make that change in mdledit. I've renamed the textures to what you had in the changes.ini file

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.

23 minutes ago, defreili said:

However I have issues with the textures.

You're gonna have to be a more specific than that ... 😐

24 minutes ago, defreili said:

Do I have to hexedit the head?

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

1 hour ago, defreili said:

However, I run into issues regarding the installing and using of the head mod.

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?

If you open the binary file in mdledit, you can edit the textures by using the Edit → Textures... feature. It will take care of problems like the new texture name being longer or shorter than the previous one...