• Content Count

  • Joined

  • Days Won


Everything posted by DarthParametric

  1. Read the manual, padawan: E.g. to install a file in the _HuttHap folder inside the AVO folder inside the StreamVoice folder, type in StreamVoice\AVO\_HuttHap in the Folder name box. If the specified folder(s) do not already exist in the user's game folder, they will be created.
  2. Sounds like it is referring to the specific hook on the model to attach the VFX to.
  3. I would guess that the sonic emitter is actually a Force power/spell, which is why a casting animation is used.
  4. For levels you'll probably want to load the entire area in via a LYT. Extract them from layouts.bif. In KMax, expand the Area Tools section, tick With Models and in the Suffix field add -mdledit (assuming you decompiled with MDLEdit). Note that if you plan on doing any mesh editing and re-exporting that you will need to decompile the models alongside their matching walkmeshes (WOKs) to ensure the ASCIIs contain the appropriate information.
  5. By the name? For weapons, the UTIs will tell you what model variation a particular item uses. But there's little actual geometry variation aside from between the major sub-types. Single bladed vibroswords, for example, all use the same meshes with different textures (which amounts to a small square of glowy bit, each a different colour). The way the engine is set up requires that they be distinct models, even though they probably could have just used a texture override the same as for body models (and I think there's at least some indication of such a system in the UTIs, although it could just be a NWN remnant). Note that you can do batch conversions. In KTool simply dump the entire model archive. Go to BIFs -> models.bif, select Aurora Model, hit the Extract Entire BIFF Subtype button to extract all of the MDLs to a folder of your choice. Do the same for Aurora Model Extension to get all the MDXs. No go into that folder in Explorer and do a search for the particular models you are after, for example w_vbrdblswd, select and copy all the MDLs/MDXs, paste them somewhere convenient, run MDLEdit and go to File -> Batch -> Convert to ASCII and select all the MDLs. It will convert all of them into ASCIIs. Store those in a folder somewhere that you can access easily in KMax. Since there is typically only a single "archetype" model for a given weapon type, you only need to do an unwrap once for each. Then you can just export the model multiple times, renaming the base and assigning a different texture each time as appropriate to account for the required number of variations.
  6. Low res textures on a standard definition TV. It all kind of blurred together into mush. But yes, by modern standards you'd throw everything Bioware did in the trash and start from scratch, given infinite resources.
  7. There are a couple of ways to go about it. The easiest is probably to merge them into a single mesh first, do the unwrap, then split them back into individual meshes afterwards. However, you can instance a single modifier across multiple objects. Select all the meshes, then choose Unwrap UVW from the modifier drop down. That will let you edit the UVs all at once. Afterwards you will need to collapse the stacks individually.
  8. Whatever program you want. Whatever you are comfortable with and does the job. Like I said, the specific program doesn't really matter as long as the game gets what it needs. Photoshop (or Gimp) would be the traditional route, but these days there are any number of commercial and free programs that are either dedicated texture painters, or incorporate texture painting as a sideline. If you can do 3D painting in Max, or Blender, or whatever, then that's fine as long as it spits out a texture at the end.
  9. I wouldn't consider Max a painting app, but all the game cares about is having a diffuse texture at a bare minimum. How you produce it doesn't really matter.
  10. Unless you plan to remap all the animations to your new rig, or make entirely new custom replacement animations for said rig, you'll need to stick to the vanilla rig. But yes, it is certainly possible to create arbitrary rigs. The only limitation is what animations the game will recognise.
  11. All game models use tris. In fact everything that uses polygons uses tris. Any n-gon you see is just a bunch of tris with the edges hidden. All meshes will automatically be triangulated when they are compiled, but due to the way some modelling programs handle mapping UV verts to geometry verts, you typically should triangulate yourself before export to avoid potential texture anomalies. It's probably not overly likely when going from Max to KOTOR, since the engine was built around that workflow, but it's definitely a problem that happens when going from Max to other programs, so it's a good habit to get into. You can easily triangulate by changing the mesh to an Editable Poly (or adding an Edit Poly modifier), going into vertex mode, selecting all (Ctrl-A) and hitting the Connect button.
  12. The problem with the animations in the attached ASCII is that the tracks are empty. MDLEdit is a primadonna. It throws a tantrum if everything isn't just right.
  13. Aside from the global game sound settings, the only thing you can do is edit the file directly to boost its volume.
  14. Have you tried it in the Override? Typically PlaySound is used for files from sounds.bif, not Streamsounds. You also want to make sure it is a mono WAV.
  15. Using KSE is basically equivalent to using them as a disguise. Since they are full body models, a disguise is probably the most expedient route for a mod, albeit one saddled with a few potential issues. If you really want to make a version that turns up in the character creation menu then you'll need to split out the heads to their own model, make provision for them in heads.2da and portraits.2da, etc. Look at an existing head mod for an idea of how the setup works. The main difference would be that you'd need to set every body model to their matching custom body, not the regular underwear/clothes/armour/robes models. Note that since character creation ignores the head's appearance.2da row, the head will be slapped on the appropriate class outfit in K1 and commoner clothes in TSL for that bit.
  16. The two heads are both shading issues. It's a common problem with a number of head models, usually down to the fact that there are UV seams in those areas and thus the mesh is split along those seams, causing hard shaded edges. Attempts to fix the issue are often mixed. A lot depends on the specifics of the particular head model. I'm not really clear on what you are referring to with Zaalbar. His texture is garbage, but aside from that it looks about on par. Edit: Here's a smoothed out Trask: Although he has a bigger problem, namely that his eyelid meshes clip pretty badly. That's probably more effort to fix. Edit 2: I tried a kind of simplistic fix. Turned off the render flags for the original eyelash trimeshes and weighted the upper edges of the eyesockets to the lash bones without creating any actual new eyelash geometry. It doesn't look as bad as I was expecting, but try it out and see what you think. Extract the attached into your Override folder. Trask_Head_Smoothing_and_Eyelids_Fix.zip
  17. That just means they are the high polys for baking out the low poly textures. Of course the real problem with level models is never the geometry. That's the easy part. It's the generating new lightmaps that is the real killer.
  18. Nice. The vista walkways look better than the actual ones. Those are billboards? You should use the source models to make some replacements for the existing level meshes.
  19. The numbered ones are set dynamically via script, so technically they are all available in a given DLG (aside from whatever ones you are already using).
  20. https://deadlystream.com/topic/7436-gender-check-with-k1s-tlk/
  21. No, because those wouldn't be pulled into the compiled script if it didn't call them.
  22. Interestingly though, most scripts that DeNCS chokes on do not appear to be due to recursion, at least judging by running said scripts through ncsdis, which reports the presence of recursion. In my experience, it's the use of per-planet includes that trips it up the most. The module OnEnter and OnHeartbeat scripts for Tatooine in K1 are a particularly good example of this.
  23. Presumably you want to ask @DrMcCoy. Xoreos has done the most recent and thorough (publicly available) work on it. I gather you have perused their repo? I'd advise against any incorporation of "DeNCS" in the name. Xoreos has already taken "ncsdis" and "ncsdecomp". You could perhaps go with something like "NCS2NSS". That's fine. The Xoreos tools are all commandline, and real men compile directly with nwnnsscomp which is commandline as well. Batch scripts are easy enough to write. And as with nwnnsscomp, if someone was keen enough they could always write a GUI front-end for it (ask @JCarter426 - he'll need a GUI project for his course later in the year presumably). Yes. It's presumably due to the way that DeNCS interprets the bytecode, since there's obviously not a 1:1 match between it and the source NSS. I would suggest you try decompiling some of the global scripts that have Bioware source available and compare DeNCS's output with the original NSS. There are certain quirks in the way DeNCS likes to format things, which, while functionally the same, may introduce the subtle differences it complains about with partial matches.
  24. Reset XForm only applies to Max. I don't know if Blender has/needs something equivalent. It is short for "reset transforms". In Max, when you move, scale, or rotate an object, it is only applied as a transform to the original values. Thus if you export the model you get the objects in their original positions/rotations/scale. Doing a Reset XForm bakes the changes into the object. I'm reasonably certain this is a behaviour unique to Max though. Other programs typically just apply such changes permanently as you make them. Beyond that it is difficult to diagnose remotely. If you post the ASCII model I can take a look at it.