ndix UR

Members
  • Content count

    145
  • Joined

  • Last visited

  • Days Won

    8

ndix UR last won the day on May 6

ndix UR had the most liked content!

Community Reputation

87 Jedi Grand Master

2 Followers

About ndix UR

  • Rank
    Jedi Knight

Profile Information

  • Gender
    Not Telling
  • Location
    ca, usa
  • Interests
    I like to code. Also animation, manga, puppetry, digital visual arts.

Recent Profile Visitors

4,150 profile views
  1. ndix UR

    Fair Strides' Script Shack

    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));
  2. ndix UR

    K2 Community Patch

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

    MDLedit bug reporting thread

    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.
  4. ndix UR

    Bump Mapping Research

    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.
  5. ndix UR

    Bump Mapping Research

    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.
  6. ndix UR

    TOOL:KotORBlender

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

    TOOL:KotORBlender

    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'
  8. ndix UR

    TOOL:KotORBlender

    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.
  9. ndix UR

    TOOL:KotORBlender

    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...
  10. 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).
  11. ndix UR

    K1 Main Menu Widescreen Fix

  12. ndix UR

    Czerka Sign and Desk Enhancement

  13. ndix UR

    K1 Music Fix

  14. ndix UR

    TSL Main Menu Model Fix for Widescreen