bead-v

Exciting! That's a LOT of really awesome improvements! Looking forward to it! This could be considered a request, but considering how much is being done, I will rather formulate it as a question and be content with an answer to it: is the PM system getting any updates? (the feature I'm interested in is to be able to search through posts in a conversation – right now, I can only see conversations where the search string appears, not posts).

I finally managed to test this, and I do not get the same results with the latest version. Specifically, no flying into space. I do get the VFX doing small loops on both hands though, that's because of quaternion compression. We'll have to look at the compression and decompression algorithms again to fix this. mdledit-v1.0.4b.zip

Turns out it would be complicated to have a single .exe function both as a GUI and a CLI app. So for now, the answer is the same: use MDLOps. I've been working on mdledit a little, and I've added a hierarchical view of the geometry. You can toggle between the 'linear' and 'hierarchical' views from the View menu while the model is loaded. The hierarchical view shows less information, but it is easier to quickly get an overview of the structure of the model. I've also added options Expand/Collapse All, which make navigating the tree easier. Check out the attached version. Any comments or suggestions are welcome! [Newer test version of mdledit available below]

Really? The 16 bone limit should just be a warning in both kmax and mdledit, if it didn't let you then it's some sort of bug. If you still have that model around, I'd be interested to see what happens if the game gets a model with more than 16 bones. The thing is, the format can encode any number of bones, there's just this one list that only has 16 places for them... and we don't yet know how relevant it is. I'm interested in taking a look into this

Thanks for the suggestion. My default answer to this used to be: use mdlops, it's had that since the beginning. But considering it's not that hard to implement, I've recently been thinking about doing it anyway. We'll see, but your suggestion is noted!

I'll need to check, but mdledit shouldn't require an Xbox supermodel to compile a model for the Xbox. Logically it is not necessary, because it just takes the supernode numbers, which are not different between the formats. So you could simply use the PC supermodel, provided the actual model is the same and mdledit allows it (if it doesn't, I'll change that).

Merci beaucoup !

He added MaskHook and GoggleHook.

This is the newest test version of mdledit. In this version, the order of the nodes in the ascii will no longer cause problems with skins if it results in an order that is different from the name order in the binary. [Attachment removed – there's a newer test version of mdledit available below]

It was. I had only fixed the part during bin→ascii, I hadn't solved it for ascii→bin. So if the hooks had been placed in a different place in the ascii, it would have worked, but the way it was it created a mismatch between the tree order (actual node order) and the name order. Anyway, this has now been fixed. I will post the latest version in the MDLedit bug thread. Sorry about that! Apparently I messed up my settings in the IDE when I was changing them for work. The build worked when run from the IDE, but I never checked if it does by double-clicking the .exe. Sorry! Obviously that second message was confusing, so I decided to do something about it. My first though was to make the target game be the same as the supermodel's game, but then I decided against that because the user could have left a supermodel from the wrong game but with the same name in the folder from a previous compilation and forgotten about it. There would then be no error message indicating that the whole thing is for the wrong game. So instead, I just tried to expand on the error message. Does it make more sense now?

You need to find the model files (.mdl and .mdx) for the effects, as well as the textures they use. You can get the texture names by opening the model file in MDLedit. Then you can either edit the values directly in MDLedit or decompile the model, then edit the parameters with a text file or with Kotormax if you want. Kotormax has some logic in place that prevents you from choosing nonsensical parameters, but then again, we know very little about how exactly the parameters work, so it would be great if we try out all possibilites. Read the visual effects section of this pdf to get an introduction into emitters: https://neverwintervault.org/project/nwn1/other/custom-content-guide-v30 Also, here are some tests I did with emitter flags:

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

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.

That's what I needed to hear! Thanks, DP! Okay, so I can rewrite the walkmesh modifier to take the data from the previous material before replacing it with a walk material and store the data somewhere in it. I think that covers all the possiblities. Or is there any other reason why max would need the information about the lightmap texture after the walkmesh modifier is applied?

There is: the material. With a regular mesh you do mesh.material and you get a material that you can add a diffuse or ambient texture to. You can't do mesh.material and then add diffuse or ambient info on a walkmesh, because it's a multimaterial, which does not accept diffuse or ambient info. It's just a collection of regular materials. So what I can do in kmax, is add the diffuse or ambient info onto the first regular material in the bundle. What I don't know is if the lightmapping workflow can do the same, or if it causes any problems. Somebody needs to try it before we can move on. The problem is just with the texture name. The tvert coordinates as well as the trimesh properties are handled perfectly. As for getting 3dsmax, I know I can. I use gmax because it's more light-weight, and because it's easier to keep kmax compatible with gmax if I use gmax myself. I'm in a serious lack of time, so even if I decided to install it now it would take forever for me to test this.

Here is an updated mdledit and some fixes to kotormax. 1. The VFX issue Not tested, but maybe resolved? I will test it when I have time, or somebody else can do it. 2. The grass and roomlink issue Apparently, walkmeshes can also be lightmapped. Since I only have Gmax (which can't render), I can't test what the workflow would be for adding a lightmap to a walkmesh. It is non-trivial because the walkmesh has a multimaterial, while the other meshes have the basic material type. Anyway, for now, when importing a model with a walkmesh, the texture map will be saved on the walkmesh's editable_mesh, a trimesh modifier will be created which saves the 'lightmapped' property (as well as all the others), and the lightmap name is saved on the first material of the multimaterial ('Dirt'). Since the mutlimaterial is only created once per scene, in case you load several walkmeshes into a scene, they will also end up having the same lightmap texture on export. I'm leaving this as is for now, until we figure out what the workflow for adding lightmaps to a walkmesh would be. I can't do this alone, so if anyone is ready to help out, try using Quanon's tutorial to add a lightmap to a walkmesh and then report your findings in this thread. 3. Detonate I have disabled the exporting of 'detonate' from kotormax as a static controller, but I left it in for when it is animated. We have no examples of this in the game, but it should be tested at some point. 4. Emitter, Light and Mesh animation controllers missing Apparently I changed the way animated controllers are handled at some point and forgot to change some other code accordingly, so while reading an ascii, mdledit would ignore any controller except for position, orientation and scale. Fixed now. + also fixed a crash issue with mdledit I encountered that hadn't been reported. DISCLAIMER: These files have not been tested and may be unstable. After they have been tested, they will be uploaded to the download pages. Unless you want to help with testing, you should wait for the new versions to be released there. [there is a newer test version of mdledit further down] kotormax_scripts.zip

http://deadlystream.com/forum/topic/32-malachor-vi-an-ending-mod/

Reading that brings back memories! Good old times

I'm slowly trying to make time to look at these things now that my exams are over. I've fixed the issue with model suffix during lyt import, but I haven't had time to look at the selfillumcolor animation problems. 1. The VFX issue. [MDLedit issue] Have you figured out anything about what causes it, beyond that it's caused by mdledit? 2. The grass and roomlink issue. [KOTORmax issue] Okay, so the way I see it, the problem was that kotormax wasn't importing the trimesh modifier with the aabb node, I must have deemed it unnecessary. So I fixed that now, but I'm not getting the lightmap texture name, because of the way the walkmesh material is set up. I think I may be able to exceptionally save the name with the walkmesh modifier and retrieve it from there when necessary, though this might be problematic for export. Anyway, the fix for this is on the horizon. 3. Detonate. [KOTORmax issue] Since there is not a single detonate controller in either game, I'm considering simply removing it. While I'm at it, I've analyzed all the possible (non-animated) emitter controller combinations in the game. It seems that at all times, all the available controllers were exported to ascii. However, it seems there are different sets, which I assume are the result of the different stages in the development of the tools, because the differences are always in the newer controllers, sometimes even by a single controller. There are two larger orderings, but the following, the newer one, is the commonest in both games (and should therefore probably be followed by our tools):

Handmaiden's global VOs, the numbers I mentioned. Yes. Listen through his VOs and you'll find them. Then search the dialog.tlk for the strings.

Actually, Handmaiden, as well as every other trainable NPC, does have VOs for the training. They are part of the range 411–418. So this would just be straight up restoring stuff.

Kotor Tool uses MDLOps for that conversion, right? So maybe if you just plug in ndix UR's MDLOps instead, it could work. "could" because I've never tried it.

I made this once (6 years ago apparently ): All of it, including the sound, is in-game. It basically plays a track that is a mixture of the music and parts of the audio track of the original .bik video.