[wip] DP's Droid Foundry

[newbiemodder]

In your destroyed T3, are the parts moving at all or do they remain fixed? Try converting your new .mdl model back to ASCII. Then import back to gmax/ 3dsmax. If the skin is in its distorted position try moving them back to where they should be and export again.

[DarthParametric]

There's no skin. They are trimeshes.

 

And trying to load back a decompiled model always causes a script error, even with HK which actually works fine in-game.

 

Edit: Here's something interesting though. Comparing the decompiled replacer model with the source exported out of NWMax, there's definitely some screwiness. The vert positions match, but the object position and orientation values are different. Not just different, the replacer version actually only has two co-ords for position (which is probably why NWMax crashes):

 

DECOPMPILED REPLACER MODEL
node trimesh body
 parent rootdummy
 position 0.00191847002133727 -0.358599990606308 
 orientation 0 0 0 3.14159265358979

SOURCE CUSTOM MODEL
node trimesh body
 parent rootdummy
 position 0.00191847 -0.3586 -0.345338
 orientation 0 0 0 0

 

As I said though, decompiling the HK model also gives the same error, so I assume it is the same cause (will need to confirm). If that's the case, then I'm not sure that is directly related to the initial conversion problem, as HK works fine in the game, as I said before.

 

Edit 2: Importing the original and re-exporting it untouched results in the same thing. A straight compile causes a crash on load, replacing results in displaced parts. Strangely it also turns the model red. I thought with my mesh it might be an artefact of not having a texture in the initial tests, but obviously not.

 

 

Also, when decompiling the replaced mesh, the last value in the orientation quaternion for every replaced object is always 3.14159265358979 - i.e. Pi.

[Kainzorus Prime]

Any news on this, or the HK?

[DarthParametric]

The protocol droid and T3 are a wash, unless someone wants to code a replacement for MdlOps.

 

HK needs the textures finished, but I'm waiting for the next version of the Quixel Suite beta to come out to do that. The current version is too buggy to persist with.

[GeorgNihilus]

The protocol droid and T3 are a wash, unless someone wants to code a replacement for MdlOps.

 

HK needs the textures finished, but I'm waiting for the next version of the Quixel Suite beta to come out to do that. The current version is too buggy to persist with.

dam%$#$#t! after ALL that effort!!

 

so unpleasing to hear that:argh:... can't HK be textured without Quixel Suite then??

[DarthParametric]

Of course it can, I just choose not to. The original textures were done with the legacy version of dDo which they made available for free, but the new Suite is a lot better (assuming they iron out the bugs), so I'm waiting for that. The new version is due out any day now, so they keep saying.

[Quanon]

Have you tried to just edit the ASCII. I've had the same sort of problem with meshes in some of my area models. Reset x-form and all the other stuff didn't help.

 

But I just used notepad or a text editor with search/ replace function. Because somehow some meshes got rotated the same way.

 

I fixed the faulty rotating with the coords below.

orientation 1.0 0.0 0.0 0.0

 

Not sure if this would work with character models...

[DarthParametric]

Yes, I have tried multiple edits of the ASCII with no success. If people want to try themselves, just take the vanilla T3, decompile, then recompile (or use Replacer). You get exactly the same problem. Has nothing to do with NWMax, it's a MDLOps problem.

[GeorgNihilus]

Of course it can, I just choose not to. The original textures were done with the legacy version of dDo which they made available for free, but the new Suite is a lot better (assuming they iron out the bugs), so I'm waiting for that. The new version is due out any day now, so they keep saying.

I see ... so ... at least HK "should" be cleanly replaced once textured DP?

without major issues or buggy animations that is??

 

keep up the awesome work

[DarthParametric]

Yes, HK works appears to work fine, at least as far as I can tell, as covered in the request thread. It will need people to properly test it by actually playing the game though, so only time will tell for sure.

[Hunters Run]

I may have a solution to your problem. Apologies if you tried this method and it didn't work.

 

I believe that the replacer function is screwing you over. To test my theory I made a quick model and stuck it game using the replacer function:

 

Show spoiler

(hidden content - requires Javascript to show)

 

Look familiar?

 

I am no expert but I believe the replacer function works only with weapons. Or at least works best with weapons (and then only lightsabers).

 

Next I used a different method to get the model in game:

 

Show spoiler

(hidden content - requires Javascript to show)

 

I am unsure of what you know so apologies if some things a redundant.

 

Simply rename your exported model with an extra letter at the end (p_t3m4 becomes p_t3m4a) and place it in the exact same location as your extracted model(the p_t3m4 from kotor tool). Then load up mdlops v6.1a and select p_t3m4a and click read and write. A k1/k2-bin.mdl/mdx will be created in the same folder. Drop them into override. Delete the k1/k2-bin part and the a leaving you with p_t3m4. To test it load a save. Unlike .mod's models automatically update even on save files.

 

I noticed that a straight compile crashed your game.That happened to me to. I believe it is an issue with k2 models.

[DarthParametric]

A straight compile gives the same result as using the replacer function. The reason replacing is necessary is because of the inability of MDLOps to compile particle emitters, as mentioned by Sithspecter on the previous page. It's a moot point anyway as neither method works on a proper multi-part model that is set up in the correct hierarchy to work with the animations.

[Kainzorus Prime]

Despite these replacement being a dead end right now, I'd suggest keeping them somewhere on your hard drive, in case someone comes up with a solution later.

 

Better than starting from scratch.

[DarthParametric]

So with the idea of astromechs and protocol droids currently on ice, I tried my hand at the War Droid. No luck with those either, giving the same problems as T3 (wild distortions or freezes/crashes). So then I decided to try the Assassin Droid. I actually managed to get a custom version of that to work in TSL, but there was some sort of issue - presumably with the model (bullet hook maybe?) - that was causing its weapon not to do any damage. In K1 the model would load, but was stuck in the T-Pose.

 

Then I hit on the idea to use HK's rig, seeing as I already knew that worked fine with custom meshes. And success:

 

 

 

In TSL a simple appearance.2da override was sufficient, but in K1 it looks like they used "null" weapons (i.e. no models), because both the War Droid and Assassin Droid have a blaster as part of the model. Doing an appearance.2da override leads to them shooting blaster bolts out of their fingers, which is humorous but probably not desirable. I had to do a UTC edit and swap out their weapons for ones with physical models (which is why they have different ones). Interestingly I tried the UTC edit approach first, but I could not get the Dxun Assassin Droids to swap that way for love or money, either with UTCs in the Override folder, or in a MOD file. So it seems like the two games will need two different approaches, but this would appear to be a viable route.

 

Here's a render of one intended replacement model, the Imperial Autotrooper used in the shots above:

 

 

I actually would prefer to use the Assassin Droid rig, in TSL anyway, if I could get the blaster issue resolved, as it has some more interesting animations, like exploding on death and just leaving the legs. Not to mention there might be problems if specific animations are ever called. If anyone has some ideas on what may be causing the no damage issue, I'd be interested to hear. I can't use the Replacer method, as it has skinned meshes, and they don't appear in the replace list (only trimeshes and dummies/emitters/etc.).

[milestails]

More intimidating! I like this.

[Sith Holocron]

I always liked that droid.

 

(This BBCode requires its accompanying plugin to work properly.)

[DarthParametric]

So now that someone has kicked the server back into (no doubt brief) life again, I can post some updates.

 

Obviously a glutton for punishment, I've been playing around with T3 again. I made an interesting discovery some time back that seemed promising, namely that KAurora would compile a mostly working model. There were three issues with it. The first was minor, namely that it wasn't respecting any smoothing info, but I could live with that. The other two were more significant. The most apparent was massive distortion/stretching on the gun and probe arm meshes:

 

 

Interestingly, invoking an animation that used those meshes would force them back to their proper size/shape. After slicing a door, the probe arm went back to normal, just leaving the gun arm distorted:

 

 

And after firing in the combat tutorial, the gun arm went back to normal as well:

 

 

However, on level transition, the meshes would revert to massively distorted again:

 

 

I tried a few messing around with the ASCII model, but nothing I did made any difference, so I ended up shelving it again. Then last week while I was troubleshooting the Assassin mesh, I realised that MDLOps had a feature I'd never used before - the data viewer. By reading a binary model with the data viewer open, you get the full breakdown of each node, with the relevant hex sections and their appropriate values. I compared the original T3 binary MDL to my MDL compiled with KAurora, and with the ASCII MDLs for both. What I found was that the rotation data of the probe arm and gun arm meshes in the original binary MDL did not match those in its decompiled ASCII MDL. Interestingly, my compiled MDL did match its ASCII MDL values, but I got the same in-game distortion whether I used the values exported from Max or swapped in those from the ASCII original. So I decided to try hex editing my compiled MDL, swapping out the relevant sections with those from the vanilla binary MDL. And success!

 

 

However, the 3rd problem mentioned above still remained. This only seemed to manifest itself in combat. With vanilla T3, when combat starts, the camera zooms back behind him. With my custom model, the camera seems to zoom almost into the mesh itself, giving something approximating a first person view. I thought this might be a similar issue to the probe arm and gun, with the camera hook having screwed up positional/rotational data. I tried hex editing these to replicate the vanilla MDL, but this time no dice. The issue still occurs. I also just discovered what may be a related symptom. I'm not sure if this also happened with my the original version of my model, I'll have to check later, but with the latest hex-edited-to-death version the party selection and character screens reveal something interesting:

 

 

Scratching my head over this one. Out of combat the camera seems fine. It's positioned normally and doesn't glitch out. It only happens during combat. Oh and I guess there is now also that selection/character screen offset issue that may or may not be related. Anyone got any ideas?

 

EDIT: So I recompiled the model swapping out the rotations for the camerahook dummy (and the probe arm and gun meshes) in the ASCII model with those from the vanilla binary model. That seems to have corrected whatever was causing the selection/character screen offset:

 

 

But the combat camera screwiness continues.

[Kainzorus Prime]

Good to see you're making some progress on that tricycled nightmare. Hopefully it'll let you find a pattern to also have the AutoTrooper use the Assassin Droid's animations, instead of HK's.

[GeorgNihilus]

goodness ... so good u r making progresses indeed ... impressive tweaking

 

so ... do any of these distortions end up in a CTD I wonder??

 

keep it up ...

[DarthParametric]

Some of my more excessive hex edits would eventually result in crashes, when I was replacing entire blocks of data in an attempt to solve the camera issue, but the current one appears fine in the brief tests I have done (aside from the combat camera). It isn't even hex edited, I just recompiled using the rotation data directly from the vanilla MDL.

 

I have one more thing I can think of to try, namely the bounding box co-ords. Comparing the values in the binary MDLs for the main body mesh, it appears my model has some negative values, so I'll try copying the values of the vanilla mesh. Other than that, I can't think of much else to tinker with.

 

Edit: Nope, that made no difference. Also tried editing the camera hook's controller data, seeing as the final 3 bytes for each block, listed as unknown in cchargin's MDL structure table, differed between my model and the original, but again no luck.