DarthParametric

Modders
  • Content Count

    4,568
  • Joined

  • Last visited

  • Days Won

    514

Everything posted by DarthParametric

  1. Not a mod, just a function of GLIntercept.
  2. You just need to encode them as MP3s and add a fake WAV header like the vanilla files.
  3. Typically it's easier to use the vanilla model as the supermodel for your new model. Then just edit appearance.2da to point to your model. Screwing around with anims if you don't know what you are doing is going to cause problems.
  4. DLGEditor presumably resets it because it doesn't use dynamic values like I said earlier, only hardcoded ones, so as far as it is concerned row 18 doesn't exist/is invalid.
  5. So row 18 works if you specify an anim in the DLG, but doesn't work if you specify an anim via script?
  6. So it doesn't actually "reset", the game just reads it as row 0, i.e. VIDEO_EFFECT_SECURITY_CAMERA? What happens if you add additional copies of the row and choose higher numbers like 19, 20, etc?
  7. Yeah all DLGEditor's references appear to be hard coded, not pulled from 2DAs dynamically. Resets when? After saving via DLGEditor? Are you editing it in KGFF afterwards to change it back?
  8. You might want to provide more specific details/examples. I'm not following what you are saying.
  9. A little tweaking of the end bit and you could have the Skroob Salute!
  10. I have never messed around with dynamic lights, so I can't really offer any insights. The closest equivalent I can think of would be something like the War Droid, which uses a light during its death animation (but is otherwise off). It has the values: radius 5.0 multiplier 2.0 color 0.0 0.0 0.0 lightpriority 1 ndynamictype 1 ambientonly 0 affectdynamic 0 shadow 0 flare 0 fadinglight 0 flareradius 0.0 texturenames 0 flaresizes 0 flarepositions 0 flarecolorshifts 0
  11. Aurora (and Eclipse, as I recall) both had limits on the maximum number of dynamic lights a given map/level would support. If you are getting differences within a single level, it could either be due to the limit only applying to some specific radius of the camera, or a room-based limit. There's a reason Bioware didn't stick lights in their glow batons.
  12. Btw, to dispel another misconception, KOTOR doesn't use blur for its saber trails either. The reason you need the blade planes is because they are what creates the trails - i.e. the trails are a geometry effect. Here's a wireframe to demonstrate: This is why sabers have their own unique model type. I would guess this is some sort of vertex buffer trick or the like.
  13. Nothing of direct importance to modders. I gather it has something to do with data structures in the model format, but @bead-v would be the one to elaborate on its mysteries. You can't. It's an engine issue, due to the way it handles the render order of objects. It was likely a deliberate choice as the lesser of evils vs other render problems.
  14. TOR doesn't use blur for saber trails. It's all VFX textures.
  15. Looking at that, the UVs are uneven, but they are roughly in the right place for the texture. Looks to me like your eye texture is rotated 90 degrees. K1_PFHB04_Eyes_UV_Fix.7z PFHC04 on the other hand is something I can't really fix. If someone else wants to take a crack at fixing the smoothing, be my guest: pfhc04-kotormax.mdl.ascii Otherwise, you'll have to live with the vanilla model for now. Come back in 6 months after bead-v has done his MDLEdit update THAT HE HAS NOW TOTALLY PUBLICLY COMMITTED TO DO WITH NO CHANCE TO BACK OUT OF IT. *cough*
  16. Yeah, but it's still crap. Just a different kind of crap. Make me a 2020 replacement for Taina's Replacer so I can just sidestep dealing with smoothing/normals altogether and simply inject my UV/vert position changes into the vanilla model.
  17. The PFHB03 one is an easy fix. For some reason the head link flag wasn't enabled. K1_PFHB03_UV_Fix_v1.1.7z The problems with PFHC04 are shading errors. Since the original vertex normals get destroyed when decompiled into an ASCII, you have to do a lot of screwing around trying to recreate them. Damn your eyes @bead-v. I'll have to play around with that tomorrow when I get a chance.
  18. It's a UV problem. If you want to change it you'll have to adjust them so they are properly symmetrical. As to PFHC04, I was only looking at the teeth meshes earlier, but I see now that the tongue mesh does protrude through the lower teeth mesh. That would need a mesh adjustment to pull it back a bit. Edit: Here, try these out.
  19. The teeth use mirrored UVs. The are fine in the vanilla model, so the problem is your texture presumably. As to the eyes, eh, looks fine to me.
  20. The first step is stop using sabers on Peragus you goddamn cheater.
  21. Looking at some of the anims, there is maybe a bit more lip repositioning in the SS/Single Saber animations compared to the 2HS/Two Handed Saber anims. You could delete all the relevant keys on those SS anims, or maybe copy the positions/rotations from the equivalent 2HS anims. That would kind of be a pain to do manually though. Maybe you can hassle @JCarter426 about writing a program to automate it.
  22. Looks like she has some duck lips going on in the single wield pose though. Are you using a supermodel mod? Not that I'd expect one to affect those particular anims in TSL anyway. Still, if you are it couldn't hurt to try removing them and see what happens.
  23. Doesn't seem like there is anything particularly out of order with the skin weights for the lips/mouth/chin. Have you tried swapping to a different head to see if the issue occurs with them? If it does, then presumably the problem lies in some mod, since I don't recall seeing this issue reported before.
  24. What's the problem? I can't see anything wrong with the mesh or UVs in the vanilla model.