bead-v

How this whole Speaker/Listener business works isn't simple, I once did extensive testing and wrote a guide about it. A lot depends on the exact syntax of how the conversation was started in the script. This was for TSL only though, K1 may be and probably is a little different. If you give me a specific example I may be able to tell you why it's not working.

The question then is why the fogged out skybox in 852nih13 rendered when it wasn't under the a-dummy (everything else was though). There was no walkmesh and ignorefog was enabled... Well, what else did you change when it started working?

I checked our conversation about that issue, there's indeed a lot of bizzare stuff happening, but I'm pretty sure it all has to do with the setup of the models and not the tools themselves. Unfortunately, all the .zips with the model files are inaccessible and it seems that since the site update we can't download previous versions of mods anymore, so I barely have anything to look at. I guess I'll just try to describe what was going on... Kexikus added the model 851nih53 to 851nih for his Backdrop Improvement mod. At first that had ignorefog off, so telos appeared completely fogged out. He originally disabled fog for the entire module to fix it. Then for v1, he hex-edited (I assume) his 851nih53 to ignore fog. Now the issue was gone so fog could be turned on for the entire module again. BUT, now the flames in 851nih02 dissappeared. Apparently this was caused by enabling fog for the module and disabling it for 851nih53. It was then discovered that if the walkmesh in 851nih53 was deleted, the flames would show, but now 851nih53 wouldn't show. We now know that this is because the game doesn't render area models without a walkmesh if the .vis file is available. So it seems that if it has to render 851nih53, in some way that breaks the flames in 851nih02. This the structure of the model: It was discovered that if the plane* nodes were deleted or moved under 851nih53a, the flames would show as well as the model. But apparently, moving those planes under the 851nih53a dummy caused (or at least, didn't fix) the smoke VFX in Visas' room to disappear. DP then deleted the walkmesh and moved everything under the 'a' dummy like so: This then fixed all the issues. Apparently, under some circumstances, an area model is STILL rendered even though it doesn't have a walkmesh. @JCarter426 😮 Then there were some more problems in the other ravager module. This time something was up with the lighting. There were two area models added, 852nih13 with some ravager geometry and the reused 851nih53. The issue was fixed by applying the dummy solution to 852nih13. On the first try we forgot to move the skydome itself under the dummy, which though it caused the skydome to show, made it fogged up, and that's even though ignorefog was enabled! This is all even more bizzare than I remember. I guess the first step in solving this would be to figure out why 851nih53 renders without a walkmesh.

From your wording it sounds like recompiling such a vanilla model would break it. Have you encountered anything like that?

All extra_data does is add in a few bytes that the game doesn't use, just for the sake of byte-for-byte comparison in mdledit. So really all that you're doing is deleting the keys. Now the question is whether the keys are there in max, or whether kotormax somehow puts them there during export.

Okay, so there is space in the MDL for two more bones beyond 16. However, because we never found more than 16 bones (didn't look hard enough, as it seems), we assumed that was just padding (an otherwise common situation in the MDL). Anyway, I checked Vandar's model, and the first part of the padding corresonds to the index it's supposed to have, so at least that one is still a bone index and not padding. If that is the case, I'm thinking the last one must also be a bone index. It's possible that it didn't work before because mdledit was configured to only put 16 indices in there and ignore the rest. Maybe with the attached version of mdledit, 18 bones will work. I'll look into this some other time. What I meant was that mdledit would automatically add an empty aabb node. If you want to fix the issue, you just need to add a mesh in kotormax, make it a descendant of the OdysseyBase and apply the OdysseyWalkmesh modifier with the Type set to Aabb. Mdledit crashes when compiling aabb nodes without geometry, so the mesh should have at least one face. This is already fixed and when it's released, you'll be able to add an empty aabb node via the ascii simply as: node aabb NEW_AABB parent BASE_NAME endnode mdledit_v1.0.102b.zip

Yes, normally I'd agree with you, but controllers are stored in the model by number, and some controllers share numbers: nr 88 = birthrate (emitter) = radius (light) nr 96 = combinetime (emitter) = shadowradius (light) nr 100 = drag (emitter) = verticaldisplacement (light) = selfillumcolor (mesh) nr 132 = p2p_bezier3 (emitter) = alpha (mesh) nr 140 = randvel (emitter) = multiplier (light) The tools can only know which controller it is if the type of the node is also present in the model. We could agree to only turn meshes into dummies, and make mdledit default to mesh (and light?) controllers, but there's no guarantee... The tools can't know if what they're outputting is correct. I find that problematic.

Well, that explains it then! EDIT: Actually, @DarthParametric, I have another question. TOR_Hat for example is a dummy in this model. But it has animation nodes with alphakeys. Mdledit will ignore those, because it gets the type of the geometry node, which returns 'dummy', not 'trimesh/skin', so it refuses because dummies don't have alpha controllers. I've never seen this situation in vanilla files. If this is valid, then I may need to change the logic for mdledit.

How did you even manage to compile it?

So I found the reason why I (and probably no one) can decompile Dodonna's holo supermodel – one of the node offsets is 0 Could I get the ascii for further investigation?

The reason I created this thread was precisely because I wanted everybody who wanted to to contribute their ideas and find the best solution together. I wrote that whole format in a minute right before posting, just to show approximately what the format could look like, to get the discussion started. No need to keep picking holes in it like that ☹️ I've discussed this some more with VP on discord and it does seem like going with JSON is the better way. A typed version is fine by me, maybe something like ndix UR proposed. But I can also see VP's point – we could potentially be forcing the user to remember types, which could easily go wrong, especially if that causes problems with the game once it's compiled. Also an option, but since the correspondence between the type and the label (+path) doesn't ever change, it makes little sense to put it in a separate file where the user could potentially change it and in so doing ruin it. That information may be best kept inside the program. And there's only so many types of GFF files. Does that mean a (de)compiler already exists? It's been a running joke, but I don't think we actually do need another mdledit/mdlops situation. The answer to this is no. There may be a script somewhere on the Internet that does it though. A quick search did reveal some attempts, but not the full thing. The problem is also that later versions implemented python support, which is what some used to solve the problem. Kotormax should remain compatible with gmax however, so that doesn't help. Two points about that. FIrst, do we even have an occurrence of the void type in the Kotors' GFF files? Second, if we do, do we really need to be able to import that anywhere in this form? Another way to export the void format on decompilation would be to put the binary code into a separate file and specify the name of the file for the value in the JSON export file. That filename could then also get imported into max (and other editors).

I confirm, you only get a wok if you feed it a model with an aabb node. Well, at least this much mdledit does. It won't read a .wok.ascii though, even if it's present. In the K1 version of the wok for this particular file, that uint32 is 0. It's also unset for other woks (same module) where mesh data ( and therefore wok data) is present. So that's probably just some uninitialized memory getting in there for some reason. So maybe K1 simply takes the presence of a wok file as an indicator? Or maybe it doesn't even need that and always renders. EDIT: So me and @JCarter426 solved the puzzle (for now). There's gonna be an update about it in the area research thread (where most of the above really belongs), but I wanted to continue talking in this thread about the part that requires the tools to be modified. Through testing, we discovered the following: 1. If there is no .vis file, K2 will render all area models, no exceptions 2. If there is a .vis file, K2 will render only the area models with aabb nodes, whether or not .wok files also exist. K1 appears to not have the aabb requirement on rendering area models, so the aabb node is missing from a number of area models (though the .wok is present). So directly porting such models to K2 won't work, because it won't render since there's no aabb node. In order to automate this, I could fairly easily do the following in mdledit: on decompilation, if there is a .wok file and no aabb node, generate a dummy aabb node. This could be an option that you turn on or off in preferences. This would make the area model render in K2, and wouldn't affect K1 as far as I can see. If my understanding is correct, MDLOps will also need an update to allow for this. @ndix UR do you see any other solution?

Watcha doin?

What happens if they're not? 😮

Your textures are set up wrong in max, I'm not sure how, but they're exporting as NULL to the .mdl.ascii. Open the .mdl.ascii file, find the nodes that are missing textures (the skins in your case). And you'll see that the texture names (keyword "bitmap") are set to "NULL". You need to enter your texture name here, without an extension or quotation marks (e.g. bitmap tunic). Then recompile that. Also, ambient and diffuse colors seem to be set to black on your skins. DP can probably tell you more about what effect that has, but judging from another body model (Atton's), those should be set to white (1.0 1.0 1.0). You find these in the .mdl.ascii as well, where you found the bitmap, look for ambient and diffuse. Hope this is the last of your problems

@Stormie97 you got your alternative! Fingers crossed! Edit: If this works I'll script it and make it a button, promise!

I can't open the archive you posted for some reason. But if it's a .max file, then there's no point, since I have gmax and can't open that. You need to send me a .mdl.ascii file. Anyway, you definitely need to fix the orientation controller problem. Here's what I would do in gmax: The weld error you are getting is nothing, it's just saying that the distance between those verts is small enough that you should consider merging them. You can turn off specific sanity checks, I suggest you turn this one off. But leave the others, not getting warnings doesn't mean everything is fine. Also, I suggest you load a working model decompiled with mdledit/mdlops and import that and use the hierarchy in that model as a guide to fix your hierarchy.

From what you've said, I gather that the patcher is missing the functionality to find a struct not only by number but also by the value of one or several of the fields that it contains. The new format itself can't solve that. It's a TSLPatcher problem not a format problem. The benefits of the format are: 1. It's easier to write a program that handles a text file than a binary file (at least in the specific case of GFF files). Any new tool could benefit from it. 2. No need to use the GFF editor, you can edit the file in a text editor, which can speed some operations up a little bit, but will at the same time make errors more likely. 3. Kotormax could read and write GFF files with the help of the compiler, since it can only deal with text files (except maybe when used with 3ds, but even that wouldn't be optimal). Exactly! You need a way to specify for every case specifically how to compare the structs. And since you can't generalize this, there's no way you could put this into a format, it needs to be part of the program that handles the GFF. That's what's missing from the Patcher.

Well, it's his dream I take it that by "trees" you mean "structs". If so, then you'd basically need to specify for every struct operation what fields in the struct have to match for it to be considered identical. There are struct IDs in the GFF, but they aren't even used a lot of the time and even if they were, there's a big chance that still wouldn't help you find the right struct to run the operation on.

Well, it's either a) configure kotormax (or other relevant tool) to export coordinates AND create a new tool to convert specifically that type of coordinate list file to a specific gff format using some logic, or b) configure kotormax (or other relevant tool) and force it to export in .gff.ascii AND create a general compiler from .gff.ascii to the GFF format. In b), the compiler can handle any type of gff, so unlike in a), you don't need a new conversion tool for every type of gff file and also, a compiler takes no effort to make because many of us have a GFF library by now. Since it would be merely a compiler, all that would be done in the ascii file. The compiler's only job would be to convert the ascii into a binary gff. If the structure in the ascii is valid/correct/as intended, then the one in the compiled gff will also be valid/correct/as intended.

Yeah, there's also a problem with the ascii format for the VOID data type, because that one stores binary code. I was thinking we could convert to Base64 or the like. Though I don't know if it's even used in any gff file in Odyssey. But for the other data types, I think an ascii format would work fine.

Yep. If it comes to that, I'd also make the compiler part of mdledit as well, so it would simply compile everything. Although getting things ready for this on the kotormax side will take its time... for now, all that I'm really considering is the compiler.

@JCarter426 and me were talking on Discord and we came up with this idea. We were talking about editing .pth files directly in kotormax, but since kotormax can't export binary files, we'd need a compiler to produce the actual .pth file. So the idea is that the compiler could turn any gff file (dlg, pth, git, utc, ifo, ...) into a .gff.ascii file. The ascii file would contain the information about the file type, but otherwise the files wouldn't be distinguished. The ascii file might look something like this: # GFF ASCII # Created .... type dlg version 3.2 newstruct dword DelayEntry 0 dword DelayReply 0 dword NumWords 0 resref EndConverAbort script1 resref EndConversation script2 byte Skippable 0 resref AmbientTrack mus_amb_1 byte AnimatedCut 0 resref CameraModel 003ebocam byte ComputerType 0 int ConversationType 0 list EntryList newstruct 0 cexostring Speaker "Atris" cexostring Listener "Kreia" list AnimList endlist cexolocstring Text -1 0 "This is a cexolocstring English male variant." 1 "This is a cexolocstring English female variant." 2 "This is a cexolocstring French male variant." endcexolocstring resred VO_ResRef someresref resref Script script3 dword Delay -1 ... int RecordNoVOOverri 0 endstruct newstruct 1 ... endstruct newstruct 2 ... endstruct endlist byte OldHitCheck 0 list ReplyList endlist ... cexostring EditorInfo "v2.3.2 Apr 30, 2008 LastEdit: 13-Dec-16 16:31:52" endstruct Does anyone have any objections, ideas, concerns, opinions etc... about this?

Looking great VP! I love the filter/search. However, I got an exception when I wanted to search for **** (it's in French, sorry): Also when you copy and paste a row, **** pastes as an empty string. Another remark is that when you make a new row, its index is -1 until you move to another row. As long as it has -1 it also appears in the filtered result even if it doesn't contain the searched string. Is this just a quirk because it would take a lot of code to fix it or does it have a purpose? There's also a grayed out Add Template option when I right click on a row, what's that about? Anyway, it's fast, functional and looks great! Kudos VP!

Not sure what you mean with the eyeballs, but I'm glad it appears to work! As for the million credit question, that's gonna have to be someone else.