DarthParametric

Modders
  • Content Count

    4,666
  • Joined

  • Last visited

  • Days Won

    531

Everything posted by DarthParametric

  1. You'll likely want a new appearance.2da row pointing to a custom version of the model with the alpha adjusted, then add the blue glow VFX via script. Refer to this post for an example: http://deadlystream.com/forum/topic/5574-how-to-make-a-character-see-through-k1/?p=58371
  2. You have a degenerate UV face on the outer side of the knee area, so you need to pull the offending vert out a bit, something like this: You'll presumably have to adjust your texture to match. As to the backface culling, while it might not be noticeable in motion, remember half the game she is probably standing around. It's very noticeable when she is idle. So as to not destroy your existing skins and UVs, I'd just create some copies of the glove and boot meshes, then extrude out from the edge loop and delete the original polys. You should be able to form an inverted cone shape with a bit of lip where it meets the original mesh that will do the job.
  3. Sounds kind of like an issue in Dragon Age Origins, where even though the toolset could address a theoretical 65,535 rows in a 2DA, a GFF bug/error meant that the ID field in UTIs was only 1 byte instead of 4 bytes, so the game could only address up to 255 rows. http://www.datoolset.net/wiki/Bug:_High_M2DA_ID_ranges_might_work_in_the_toolset,_but_not_in_game
  4. You should set Max's two unit settings to cm for working with KOTOR models. Customize -> Units Setup -> Display Units Size Customize -> Units Setup -> System Unit Setup -> System Unit Scale Moving bones is inadvisable, you should always modify your mesh to suit the rig, not the other way around. In broader terms, any moving, scaling, rotating you do on any object in Max needs to be followed up by a Reset XForm (reset transforms) operation in order to "bake in" the new transform. This will apply a modifier to the object stack which once again needs to be collapsed. Not doing so will lead to headaches down the line. Also, one thing I forgot to do was to adjust the diffuse/ambient values of your material. Max sets them around 50% by default, so your textures will appear dull in the game unless you change that. You can easily edit the ASCII in a text editor. Under your individual mesh nodes you'll see something like: node skin Visas18 parent VisasAssassin position 0 0 0 orientation 0 0 0 0 scale 1 alpha 1 selfillumcolor 0 0 0 diffuse 0.587999999523163 0.587999999523163 0.587999999523163 ambient 0.587999999523163 0.587999999523163 0.587999999523163 render 1 shadow 0 specular 0.000000 0.000000 0.000000 shininess 0.000000 wirecolor 1 1 1 bitmap MiscDiffuse3 Change the diffuse and ambient to diffuse 1.0 1.0 1.0 ambient 1.0 1.0 1.0 You can do a find and replace, but the values for the 3 textures are different so possibly it may be easier to import it back into Max and re-export. Speaking of textures, I said early on that ideally you want a single texture, especially if you want texture variants. The game can handle a model with multiple textures, but not for anything that requires variants (or an appearance.2da texture override). I imagine in this instance, the same as the vanilla Visas outfit, it doesn't matter, but it's something to keep in mind for future projects. Edit: I realised that the version I posted earlier had completely screwed UVs. MDLOps up to its old tricks again. I fixed that up, and adjusted the diffuse/ambient values while I was at it. I also compiled it and tested it in-game. I noticed that your legs still have a few UV issues, although I don't think this is the fault of MDLOps, rather just an edge texture vert or two that needs adjustment. Also, you will need some additional geometry to cap the ends of your boot and gloves because of backface culling, and the neck/shoulders area may need some adjustment if you want it to mate with the vanilla head (probably not relevant if you are making a new head). Fixed binary and ASCII model - https://www.darthparametric.com/files/kotor/misc/Goose_VisasAssassin_Fixed_UVs.7z
  5. Half the names were at 37 characters, so it seemed advisable to rein it in a bit.
  6. So I can export the meshes fine on my end. You don't have the "compile on export" checkbox enabled do you? I noticed a few unrelated issues: Your mesh names are possibly too long. I'm unsure what the maximum the MDL format can cope with is, but I would suggest capping them to 15 characters. You have uncollapsed Unwrap UVW modifiers in virtually all your mesh stacks. I'm unsure if NWMax will handle that, so I would advise moving all those modifiers underneath their respective skin modifier and then right clicking and choosing "Collapse To" in order to bake in your changes. Your scale seems to be an order of magnitude or more off. I suspect in-game you will have a titan on your hands. Did you do some sort of scaling of the rig to match your mesh? A rescale units of around 0.039 seems to get it back into the ballpark. Here's a revised ASCII - https://www.darthparametric.com/files/kotor/misc/Goose_VisasAssassin_Rescaled_ASCII.7z
  7. I can take a look at the Max file if you want. Might save some guesswork.
  8. You can do it with KTool, but I prefer Convert2DA myself. As the name suggests, it will convert 2DAs to a tab-delimited text file, which you can open in a spreadsheet like Excel. Once saved, you can convert the text file back into a 2DA. The original GUI-based version is a little hard to get hold of these days though. If you are well stocked with ad and script blockers, you can brave this link - http://deadlystream.com/forum/topic/3649-im-getting-into-modding-and-doing-fairly-well-but-i-have-one-issue-i-really-could-use-help-with/?p=37788 Alternatively, there is a commandline tool available as part of the Xoreos Tools package that will do the same thing - https://github.com/xoreos/xoreos-tools/releases Edit: Actually, Convert2DA isn't in that package. Fortunately the Wayback Machine comes to the rescue - https://web.archive.org/web/20161229181814/http://www.starwarsknights.com/tools.php Also I'm still not seeing your meshes in the ASCII.
  9. Excluding the eyes and eyelids (which Visas doesn't need), it's more like 14 bones including the jaw. Very simplistic indeed by modern standards. Make your custom meshes children of the AuroraBase. You shouldn't need to touch anything else, assuming you haven't modified the rig. As an aside, this is a useful trick when using an existing model as a template. You don't need to delete the vanilla meshes, just make sure they are outside the AuroraBase and they won't get exported.
  10. It's mostly hyperbole, yeah. KOTOR heads don't have a lot of bones to start with, and assuming you keep the bag (or equivalent) over most of her head, all you really need to worry about for Visas is the mouth. Aside from that, there is one trick with heads which is probably what gets people's pants in a twist. By default the model won't correctly link to the neck of the body, meaning it will be offset and floating in the air. You can fix that by patching the binary model that MDLOps compiles with VP's HeadFixer. Regarding the model you posted, you presumably missed my last post after it was buried by all the off topic spam. Your ASCII doesn't contain your meshes because they (presumably) weren't children of the AuroraBase. The script ignores anything in the scene that isn't a child of the base. You'll need to fix that and re-export, then recompile.
  11. I just realised your ASCII has none of your actual meshes. You must not have made them children of the AuroraBase before exporting. You'll need to do that and re-export. This is unrelated to your compiling issue, but in effect the compiled model I have now is just a skeleton.
  12. I compiled it on Windows 10, so that shouldn't be the issue (in theory). I can just give you the one I compiled, but of course that doesn't solve your root issue.
  13. It would also be wise to utilise a folder outside the OS drive. It's unlikely to be related in this instance, but Windows is extremely pissy about permissions, especially in Windows 10 with the nerfing of admin privileges.
  14. My guess is that is a call to the OpenGL command GL_CLAMP that stops the texture shifting more than the specified amount of pixels. This is logical given that some of these textures are only 256x256, so there is basically zero tolerance for the texture wrapping around past the edges. That command is deprecated in newer versions of OpenGL though, so I am wondering if that is part of the problem. As I posted above, the modern alternative is GL_CLAMP_TO_EDGE, which should stop texture wrapping altogether (in theory).
  15. Presumably you derived the base model you rigged to by decompiling the vanilla model, so I can't see that being the problem. And as such you can obviously decompile, which should notionally rule out a problem running MDLOps. You didn't change the ASCII? You have hide extensions turned off in Windows Explorer so you can be sure the filenames are right?
  16. I used the ASCII you posted earlier in the example above. You are using the original binary copy of P_VisasBB on your end, right?
  17. The AuroraBase was already named correctly, VisasAssassin. You just failed to properly rename the original P_VisasBB binary model (and also had a wrong filename on the ASCII, but MDLOps doesn't care about that).
  18. It is. Your model is named VisasAssassin. You need to change the filename of the supermodel (i.e. P_VisasBB) to VisasAssassin.mdl/mdx
  19. Typically when MDLOps hangs trying to compile it's because of an incorrect filename. If you want to post your models I'll take a look.
  20. You'll need to rename your AuroraBase to a unique name and then change the supermodel to P_VisasBB. Export without animations. After exporting the ASCII, change the filename to something like XYZ_ASCII.mdl. Extract a copy of the binary P_VisasBB MDL and MDX, then rename them to your custom model's name (whatever XYZ is). Put them in the same directory with the ASCII then load up the ASCII with MDLOps, hit Read and Write Model. Fingers crossed it doesn't screw up and collapse your PC into a singularity. Your compiled model should be something like XYZ_ASCII-k2-bin. You can delete the renamed supermodel, then change your compiled model's filename to XYZ. After that you'll want to edit appearance.2da and replace the references to P_VisasBB in her row. If you plan on making texture variants, you will need your texture names to conform to the format ABC01, ABC02, etc. In the texture columns of appearance.2da you just put the base ABC texture name. The item UTIs will specify the texture variant number.
  21. The highest res textures are stored in an ERF archive located at TexturePacks\swpc_tex_tpa.erf but they aren't TGA, they are TPC, Bioware's own format. You'll need to install KOTOR Tool anyway as a prerequisite for just about any KOTOR modding, and that will let you browse and extract the textures. Regarding bones, for the most part what you are looking for is anything with a "_g" suffix, for example rthigh_g, lforearm_g, etc. Although that's not a universal rule, for example breastbone. Anything with "_geo" is actually a rendered mesh, not a bone. Anything that is a dummy object you can ignore, like the AuroraBase that everything is a child of, anything with "hook", like DeflectHook or HeadHook, etc.
  22. You have weights assigned to non-bone objects, like the AuroraBase (P_VisasBB), the ignore ngon, and all the various dummies/hooks. You need to clear all those out. That's causing most of your distortion. But you also have incorrect bone weights, like fingers weighted to the pelvis.
  23. A simple diffuse is pretty much your lot in most cases. The game doesn't support specularity in the typical sense. It uses environment maps (i.e. cube maps) to fake a combined specularity/reflection. In practice it is mostly used for shiny metals because of how over the top it is (getting a nice flat specular highlight is pretty much impossible). You use the alpha channel as a mask for this, then specify the envmap via a text file sharing the texture name with the TXI extension (vanilla textures include this info internally). As you may suspect, this is an either/or proposition if you want to use alpha transparency. As for your skinning woes, it's hard to say from looking at pictures beyond a generic "weight issue". If you want to post or PM me your model I can take a look.