ndix UR

Definitely a good thing to fix. I recently fixed that in kotorblender for the same reason. Although in Blender, it's easier to just import model 1, save it as a blend file, start new document, import model 2, and use the 'append' function to pull in specific nodes directly from the other blend file. That bypasses the text editor part. Before that I was using a text-based approach, similar to you, then a script that did it (but that was for merging specific nodes into a vanilla ascii model file before the compilers had skills).

NPCs won't have a PWK file. The PWK file lets you specifically locate where the 'use' points are. Like, if you have a chest that opens from the 'front', the two 'use' points will be in the front. If you have something without a direction, like a barrel, the use points are usually in 'front' and 'back'. There might be a way to combine an NPC 'placeable' with triggers to get a behavior that tracks closer to a normal placeable. I'm interested in this topic, but I haven't done any experiments yet.

fx_ritual01.tpc is my enemy now. here you go: fx_ritual01.tga

@bead-v I believe your problem with the vanilla model is that you're not applying an orientation transform to the normals. The torso skin mesh has a super cool 180 degree Z orientation (quat(0, 0, 1, 1.27e6)), so, actually all those torso vertex normals you drew pointing away from the cape vertex normals, all "3" of those normals go in the same outward direction (and two of them match). If not complete slop/oversight it was probably done to workaround a bug in the vanilla toolset's smoothing. I suspect when you fix that (apply orientation translation to normal vectors), the patch-based normal construction is going to work out better. I don't fully comprehend why this would be necessary, other than, interestingly, apparently we need to be doing world coordinate vector comparisons in our smoothgroup computations where we've been doing something more like object space comparisons. When I opened the binary model straight into blender, it looked ... well ... like it does in-game. For the record, I wouldn't consider the smoothing on the vanilla pfbim model something worth emulating/holding up as an example. It's reaaaaal sloppy and horrible. The weights along the torso-robeback interface don't even match, such that you can see gapping in-game when you look from the right angle. Here's a screenshot of the vanilla model hilighting the garbage smoothing between torso and robeback (basically it's OK on the 5 rear seams, but kind of sucks on the side seams) @JCarter426 if you're tweaking this model, I'd definitely recommend applying the rotation on the torso skin mesh if that's not one of the for-some-reason-sensitive-for-skin-weights-in-3DS operations. If the model you posted in thread already has this done, sorry and nevermind! (I only looked at vanilla while debugging)

OK, I've got these issues sorted. All kotorblender issues. Will be fixed in 1.0.2. One complete typo was making the particle effect on the sphere wrong (Motion instead of Motion_Blur in two places). The issue w/ the lines & symbols being visible came down to my setting of minimum values for alphaMid and lifeExp that didn't include the full range of possible values. I had them set to 0.0, but apparently -1.0 is the actual minimum value. Because there are 50+ emitter controllers, I think I probably relied on logic, rather than exhaustive cataloging, to establish some of the min/max values. And anyone who tries to apply logic to the functioning of the game engine gets bitten eventually... Here's the code patch:

Cool, if you're interested in getting support, you need to be way, way more specific about what animations are changed and/or what particle effects on what meshes.

Well, that would be after export. Also, in Blender, if you just parent plc_starmap_wg under the plc_starmap_pwk node, you should get the right result without having to make text edits after exporting from Blender. I think. Maybe.

Yeah, that's more of a MDLOps issue than KotorBlender actually. It happens because kotorblender isn't putting the PWK nodes after all the geometry nodes. There's no particular reason that should be required other than the naive way I implemented the code to remove those nodes in mdlops. Technically, in your model, the PWK nodes are after all the geometry nodes, it's just that your plc_starmap_wg node has the wrong parent (which makes it seem like there's one non-PWK node in the middle of the PWK nodes, which triggers the same bug). If you change its 'parent plc_starmap' line to 'parent plc_starmap_pwk' the model works fine. I had to make some fixes to how that stuff was exported to make it more like mdledit after the 1.0.0 release of mdlops, which, I think is why you are having that issue...

Yeah, we put quite a lot of work into that feature, but it's still not perfect. For example, using mdlops, decompiling PFBIM gives you unmatched smoothgroup numbers between torso_Geo and robe_Geo, so recompiling it, you get a result like the screenshots posted. However, compiling the PFBIM that JC posted doesn't show this issue (it has some weird UV stuff happening around the collar and gloves though). I'm a little surprised MDLEdit has an issue with it... I did notice that some of the vertices aren't actually lined up perfectly along the joint between those meshes (in the vanilla model), so possibly bead-v's precision is the issue. I can't quite recall, but I thought we were both using 4 decimal place precision on that... actually, I dug into the code a bit, and fDiff for vector comparison in this context might be 5 decimal places for MDLEdit. That would explain the error nicely because I saw variance in global vert positions at the 5 decimal place level, but not 4. If you need it to work in MDLEdit, you might get more precise matches by putting the robe and torso origins at the same point? Just spitballing... This particular concept of smoothgroups is a 3DSMax-ism. I go back and forth between whether to just bypass them or implement the whole smoothgroup system into Blender, but as of now it's pretty impractical for me to work with them so it's not something I've been able (or motivated enough) to really fix.

I haven't verified that it would work, and I don't know the slot numbers, but it seems to me like you probably want to avoid object comparison, so maybe: ... if (GetTag(item) == "g1_w_lghtsbr01") { ... Also, I think this code would send the value of GetTag(item) to your in-game message log so you could see if you were getting the expected value (i.e. if your slot number is correct): SendMessageToPC(oPC, GetTag(item));

Permission granted to you and anyone to use/redistribute/build-off/etc. that mod.

The problem I see in your model is that you've animated the 'open' animation, so everything is functioning exactly as it should. Usually, like if you look at plc_footlker for example, open is not really animated, because it is representing the 'open' state (not an opening animation, that is close2open). In your case, you just want to have alpha 0 => 1 in open2close, alpha 1 => 0 in close2open, and alpha 0 => 0 in open, and alpha 1 => 1 in close.

So, I don't think I've personally confirmed it in K1, so I can't say. However, from ... other things ... I expect the issue to be the same. I would love to know if anyone does a conclusive test. Just to be clear, the thing is, the engine loads the bumpmap from the TXI ... but only for the texture defined in the model. So, when you are using the appearance to specify a different texture that is not what you have for 'bitmap' in the model file, then it will only do whatever the TXI file for the original texture specifies. So if you are using the same bumpmap on multiple appearances, nothing will really seem wrong. I originally encountered this when I was trying to get different cubemaps on each protocol droid reskin I was doing, and then we actually realized what was happening when DarthParametric was experiencing some crashing issues with his outrageously high quality normal maps. The reason this happens to HK-47 in K2 and not K1 is that the K2 version of the HK-47 model doesn't specify any diffuse textures in the model itself! All NULL. This makes it so that there is no way to get an envmap other than using the appearance.2da column. It's also the issue that makes it so the sith war droid only has a gun texture w/ its 'base' coloration, but with each of the 3+ other colors, the gun model it carries winds up textured with the droid texture and not a gun texture. My personal takeaway has been that it's probably better to remake a model for each custom texture rather than to use appearance.2da, at least until we figure out what the model loader's limitations are... This would actually be a pretty easy/convincing test to run in K1, just NULL out all the bitmap entries for a model, compile it, put it in game (make sure appearance.2da envmap column is set to default) and try to get envmaps via TXI. Or even just recompile the K2 HK-47 model for K1 (for testing purposes) and test using that, since it already has null diffuse textures throughout.

Nah ... Enabling bump-mapping is now a standard feature of MDLOps and MDLEdit, so anyone can enable bumpmaps on any model now by using those tools. This is a solved problem. But while we're putting stuff in this old thread, here are a few extra caveats pertaining to bump/normal maps for KotOR models that have been discovered in the last year or so. To get full-function, full-color normal maps, simply convert to TPC format. The game uses uncompressed image data, but compressed will work. It's been shown that the 8-bit color workaround I mentioned above is being interpreted by the game basically the same as an 8-bit grayscale bumpmap. If you want to use grayscale bumpmaps, that is fine, they work almost as well in some cases with this particular game engine. The only real reason to distribute 8-bit color bumpmaps at this point is probably that people who know what they're doing can convert them into full-function normal maps. The lighting calculations in-game that use normal maps are per model. This means that if you normal map a protocol droid, then you put 10 protocol droids (even with different 'appearance' rows) in one area, the lighting effects would be the same on all of them. Sad but true. There are a few different phenomena that behave like that... (danglymesh, most notably) Sometimes adding bumpmap/tangentspace calculations to a model, then not using a bumpmap (by changing the TXI to not use them), will cause the game to crash. So far this has only been observed in area models. There's no way to use different bumpmaps via TXI when you use appearance.2da rows. For example, say you have modelA, which references textureA in the MDL file nodes, and textureA references bumpmap textureAB in its TXI file. If you add a line to appearance.2da saying model = modelA, racetex = textureB; and you have textureB referencing bumpmap textureBB in its TXI file, textureBB will not be used. The bumpmap will be textureAB. Also, this situation confuses the game when it comes time to release memory (or maybe load models), so if you are using 4K+ resolution bumpmaps, you will crash the game in certain circumstances if you do this (usually during area loading). This problem also applies to envmaps (this is the root cause for why people end up with semi-transparent HK-47 when they try to add an envmap in the TXI), but for envmaps, there is a column in the appearance.2da that lets you override the envmap that is used in each appearance row. There's nothing quite like that for bumpmaps as far as I could tell.

Sure, if this is what's important for you. Or just make this change in nvb/nvb_node.py: @@ -1619,11 +1619,9 @@ class Emitter(GeometryNode): value = value.title() elif attrname == 'render': attrname = 'render_emitter' - if value.title() not in ['Normal', 'Billboard_to_Local_Z', 'Billboard_to_World_Z', - 'Aligned_to_World_Z', 'Aligned_to_Particle_Dir', 'Motion']: + if value not in ['Normal', 'Billboard_to_Local_Z', 'Billboard_to_World_Z', + 'Aligned_to_World_Z', 'Aligned_to_Particle_Dir', 'Motion']: value = 'NONE' - else: - value = value.title() elif attrname == 'blend': if value.lower() == 'punchthrough': value = 'Punch-Through' You might have to look up how to read a unified diff (it shows the before and after in one document) if it's not clear--notice the line number reference in the header line also.

Yeah, it seems to treat pretty much any non-word-character as 'whitespace' for the purpose of word-separation for title(). It's like they used [^\w]\w as a regular expression to match the start of words. It even treats numbers as word breaks! I like a couple things about Python... this is not one of them. >>> 'blah.blah.blah'.title() 'Blah.Blah.Blah' >>> 'blah-blah.blah'.title() 'Blah-Blah.Blah' >>> 'blah$blah.blah'.title() 'Blah$Blah.Blah' >>> 'blah55blah.blah'.title() 'Blah55Blah.Blah'

Hah. Damn python, trying to be clever. Apparently when you call 'title()' on a snake-case string, it capitalizes every part. So 'Billboard_to_Local_Z' becomes 'Billboard_To_Local_Z'. For the non-programmers out there, that's not what most languages do. Normally it capitalizes the first letter, or the first letter of every word separated by whitespace. Thanks for the report, fixed in KB 1.0.1. MDLOps and KotORBlender don't add the empty value 'chunkname ' line. It is especially problematic for how the MDLOps parser was originally written, but KB is fine with it. That is too bad that MDLEdit seems to put it in, but unless I did something special, I'd expect that to cause MDLOps some problems. Maybe I'll take a look at that sometime.

Uncheck 'Export TXI Files' on the Export Odyssey MDL settings and/or don't use relative paths, I believe. Probably one of those places I should look at making paths more OS-neutral, and also probably find /look for the Blender API relative path methods...

The currently released version of KotORBlender lacks a lot of support for emitters. And animation. Definitely animation of emitter properties. It's really hard to tell what you are trying to point out in the low resolution image, but I'm guessing it's the middle portion, which is probably all generated by emitters, and all brought online during maybe an off2on animation or something. If you want to modify this model, or any other with animated emitter properties, you just have to wait for the new KotORBlender version or use 3DSMax/Gmax/KotorMax if you can't wait. Oh, or cut and paste the animations (from the first 'newanim' line to the last ... 'endanim'? line) from plc_starmap-ascii.mdl into plc_starmap_v2.mdl (delete all the animations present in plc_starmap_v2.mdl before pasting in the new ones). They're just text files. That happens after you export from Blender but before you recompile using MDLOps. Also, in MDLOps you should be using weld/minimize vertices when you do 'compute smoothgroup numbers' on the Binary=>ASCII decompile. Otherwise the smoothgroup stuff won't really do anything, as KotORBlender converts that information into 'sharp edge' info, but it won't do it across edges that are 'split' (which is how they come out if you don't use weld/minimize, due to how the MDL/MDX format works).