Are there any tutorials or list of changes for the MDLEdit or MDLOPS updates?

[Malkior 476]

A lot of us are familiar with how MDLOPS functioned and of its limitations and workarounds. However, with the new update that just arrived this year, along with the inclusion of MDLEdit, all of the old tutorials and methods are likely outdated.

 

So, I was wondering if the team behind these new tools had a guide (Like the one that comes packaged with TSPatcher) or was planning to create some tutorials on what the model modding process should look like.

[JCarter426 1,214]

The basic functionality is the same - load ASCII, save as binary or load binary, save as ASCII. There are some things MDLEdit can do on its own without conversion that might warrant tutorials. Anything you could do by hex editing before, and a ton of stuff you couldn't.

 

But the biggest difference between MDLEdit and the old MDLOps rituals would be the files you need when you compile a binary model. For any character models, MDLOps required a binary model in order to copy data from it. There were some parts of the model we knew what they did, but didn't understand how they worked, so MDLOps couldn't write it correctly because nobody knew how to tell it. (I say "we" but hell if I know what any of it is). So instead it looked for a model that was already compiled so it could copy the hex values from it directly. This is also essentially how HeadFixer works - it inserts missing data onto the model that MDLOps failed to. So when MDLOps loaded an ASCII model, it needed a binary model of the same name. If it couldn't find one it would say it failed to load the "original model" (i.e. the one it wanted to copy data from) and then freeze. Often the case was if you werere editing a model, you'd keep the original binary model in the same place and put the new ASCII there and recompile, but this was not always the case. You could have any model serve as the "original" so long as it served that purpose, and you could get different results from using different models in this manner. It was a bit dodgy. The important thing was it needed a binary model named exactly the same as your ASCII or else it would freeze up in such cases.
 

MDLEdit doesn't want that, however. Instead, MDLEdit wants your model's supermodel (aka parent). I'm guessing it's for more or less the same reason, just a different process.

 

In short :

MDLOps - a binary model to serve as the "original model", one similar to whatever you're compiling

MDLEdit - the binary supermodel that your model is using

[DarthParametric 3,782]

The need for the supermodel is still unchanged. The only difference is that under the old MDLOps you had to change the filename of the supermodel to the name of the model you were compiling. The rest of the stuff you talk about regarding binary models sounds more like Tania's Replacer rather than MDLOps, aside from the internal MDLOps replacer function that was primarily used for lightsabers.

[JCarter426 1,214]

Nah, that's what I mean - renaming files for compiling. It wasn't always necessarily the supermodel with MDLOps, though. A head, for example, would require another head as the original, or else the lips wouldn't move.

 

MDLEdit on the other hand specifically wants the supermodel, not renamed.

[ndix UR 218]

We're not really planning to write manuals. We leave that for more experienced modelers who actually use the tools. We know how the tools work, which is a whole different thing from how to use them to achieve specific results.

 

I would think revising old tutorials wouldn't be that hard. It should mostly be simplifying the existing instructions, reducing a bunch of workaround steps. I'm not really that great at writing simple instructions, better at convoluted technical details. Also I don't have/use some of the key tools that people consider standard (3DS/Gmax), so it definitely won't be me writing the stuff up. Probably a bigger issue is that the people with access to rewrite tutorials are gone, or the sites they were published on are gone. I know I used a lot of tutorials from LF via archive.org when I was learning.

 

I've written some docs on our extensions to the ASCII format, but that's not really related to user experience. That would be aimed at model tool authors.

 

Regarding supermodels, the supermodel is required to calculate the node numbers. It is a feature of how the game structures models in a hierarchy in the first place. The node numbers are what tell the game engine that MaskHook in your model is the same MaskHook in s_male01, for example, and the supermodels contain most of the animations.

 

The old MDLOps copied node numbers from 'the original model,' because it didn't know how to construct them properly from a supermodel. Those same node numbers exist in the supermodel usually, which is why the 'rename supermodel as original model' hack worked. It wasn't a known or intended use case by the original authors. Old mdlops also copied over some useless run-time data for skin nodes. That part would fail when you used the 'rename supermodel to original' hack, but it didn't matter at all. MDLEdit & mdlops v1+ calculate node numbers properly from the supermodel, but it is simply not possible to do without reading the supermodel.

 

There are a couple interesting ramifications of this change. The node number calculation requires matching hierarchy, so, using 'calculate from supermodel', you can't change the parent of MaskHook and have it still connect to supermodel animations. Using 'copy from original model', you would get away with that. Using 'calculate from supermodel', you are free to add any nodes from your supermodel, even ones that did not exist previously in the model. Using 'copy from original model', you can only do that by doing what DP describes, having the supermodel impersonate the original. All of these technical issues have subtleties I am abusing with this general view, but I'm just trying to clear things up a little bit. Also "MaskHook" is probably not a great node to use as an example but it just popped into my head.

 

It's worth noting that mdlops v1+, like MDLEdit, will use a supermodel (without rename-as-original hack) if you have it in the folder with the model you are compiling. If you don't, unlike MDLEdit, it will fall back to using the old, crappier 'copy from original' method. That is what this is about in the readme:

 

"

 5: For importing models that have supermodels, the super model or

    the original model must be in the same directory as

    model being imported. Super model is better.

"

The philosophy of the newer mdlops is to not break the practices people used before, precisely because I didn't expect tutorials to be updated over night (if ever). It's probably not 100% successful in that, but that was a goal.

[JCarter426 1,214]

So it was compiling a valid model (which it definitely would if you used the wrong source as the "original") but the issue was its failure to realize hey, this object is the same as that one over there, and it should animate as that one does... that totally makes sense.

 

I haven't done much compiling since before the latest MDLOps release, so I wasn't sure how it handled things differently, but that sounds like a good solution to me - try the cleaner method of loading the supermodel, and resort to the arcane rituals if that fails.

[bead-v 251]

A lot of us are familiar with how MDLOPS functioned and of its limitations and workarounds. However, with the new update that just arrived this year, along with the inclusion of MDLEdit, all of the old tutorials and methods are likely outdated.

 

So, I was wondering if the team behind these new tools had a guide (Like the one that comes packaged with TSPatcher) or was planning to create some tutorials on what the model modding process should look like.

 

I'm a bit late with this but whatever. My suggestion would be, whenever you want to do something and you don't know how, create a thread asking about the process. We'll answer questions until you make it through, then we can make a tutorial from that.

 

If there's already tutorial for what you want to do but you're not sure it applies to the new tools, you can send it to me, I'll look at it and tell you what's different with the new approach. We can then release an updated version of that tutorial (provided the author agrees) or write up a new one.

 

That's the only way I see new tutorials being created.

[Malkior 476]

I'm a bit late with this but whatever. My suggestion would be, whenever you want to do something and you don't know how, create a thread asking about the process. We'll answer questions until you make it through, then we can make a tutorial from that.

 

If there's already tutorial for what you want to do but you're not sure it applies to the new tools, you can send it to me, I'll look at it and tell you what's different with the new approach. We can then release an updated version of that tutorial (provided the author agrees) or write up a new one.

 

That's the only way I see new tutorials being created.

Certainly. However, how would I proceed if I want to change something in the game that hasn't been successfully done with the previous tools, (like, for example, editing Emitters) and I am unsure of whether the new tools are even capable of it?

 

As per my original question, is there a Master List of their new capabilities such as adding bumpmaps to textures which until now was impossible? Is there a new interface or button for these new features?

[bead-v 251]

Certainly. However, how would I proceed if I want to change something in the game that hasn't been successfully done with the previous tools, (like, for example, editing Emitters) and I am unsure of whether the new tools are even capable of it?

 

In exactly the same way. Make a thread where you specify what you want to do. If you're unsure about something, ask. Publicly, so everyone can see and benefit from it.

The new tools have great control of the MDL binary, so they will not be a limiting factor anymore. You can achieve anything by feeding the tools the right data.

 

As per my original question, is there a Master List of their new capabilities such as adding bumpmaps to textures which until now was impossible? Is there a new interface or button for these new features?

 

I don't think there is. You're welcome to create one!

As for the interfaces and buttons... well, sometimes yes, sometimes no (e.g., we changed an algorithm so it enables something that didn't work before because of the algorithm).

 

Let me just say that part of being a modder is also getting your hands dirty, and if you wanna really get somewhere then there's no way around it. So open a few models in MDLedit, look through the nodes and try to piece it together. Make a thread and I'll gladly answer any question about the meaning of the things MDLedit displays that don't make sense to someone who's new to this.

 

And a general (and a little harsh) note to anyone who thinks the creators need to provide the manuals (without having anyone specific in mind, maybe only for future reference):

We put a lot of time into making these tools, keep that in mind when asking us to spend even more time writing tutorials for you so you don't have to take the time to figure it out yourself.

In my book, making ourselves available for any and all questions should be good enough.