DarthParametric

Modders
  • Content Count

    4,747
  • Joined

  • Last visited

  • Days Won

    539

Everything posted by DarthParametric

  1. So, this bloody horrible thing: I have always hated the "Mark One" design with a passion. So it's on the scrapheap - I am looking to replace it altogether. I am thinking of something along the lines of one of SWTOR's various incarnations of battle droid: Animations would have to be completely custom though, which I'm not looking forward to. I might have to cap some video in TOR of how their versions walk so I can study it frame-by-frame. Trying to imagine how to animate the mechanics of a three-legged gait is hard to wrap my head around. Edit: A quick trip to Dromund Kaas later, it looks like the two front legs more or less use a typical biped walk cycle, with the third back leg skipping to keep up at twice the rate. Edit 2: I whipped up a very basic version to act as the base skeleton/rig (Mando for scale): I figured there's no point getting carried away with fancy models until I can actually be sure I can make functional animations. Seeing as it needs to have both melee and ranged attacks, I went with a version that has hands, like the one on the right in the TOR reference picture above. For ranged attacks I was planning on a wrist-mounted arrangement, like the Prequel Super Battle Droids have.
  2. This would be a good starting point - http://deadlystream.com/forum/topic/5501-the-missing-heads-in-tsl/ As to how you make them show up, the same as any other player head: entries in heads.2da, appearance.2da, and portraits.2da.
  3. Looking at this, the primary update would appear to be "added stutter fix based on fk.'s code", which is presumably derived from this, for anyone not using the GOG version that wants the same fix. I can't say I recall ever experiencing stuttering myself, but I haven't yet played it on Windows 10.
  4. I've been poking through the modules of both games, looking for specific NPCs to replace. Here's what I've come up with so far: Some of these will require unique entries in appearance.2da, presumably with some sort of custom texture/model configuration, but others will just be a case of simply assigning a specific model/texture based on what order they get assigned as replacements for the vanilla models. Everything else should just draw from appearance.2da as per usual, and get whatever their replacement is. Although if anyone has suggestions for further additions that warrant specific customisation, let me know. Seeing as I added the protocol droid on Dantooine in TSL at the end, I should probably also edit that door guarding droid in K1 to imply they are the same droid.
  5. A good starting point would be Xoreos: https://github.com/xoreos/xoreos/blob/master/src/aurora/rimfile.cpp https://github.com/xoreos/xoreos/blob/master/src/aurora/rimfile.h
  6. Here you go, an Anakin AOTC saber for TSL: https://www.darthparametric.com/files/kotor/tsl/[TSL]_Anakin_AOTC_Saber.7z
  7. It seems more likely to me that would be an issue with the module itself. Both of those would be edited as part of TSLRCM. It could also be an issue with placeables.2da. Changes by a different mod could have screwed things up in either case. Are you using the Steam version and Workshop mods?
  8. If you are running it from a folder under Program Files then you will likely need to always run it as an admin. Right click on the exe, Properties, click Run as Administrator. That will enable it permanently.
  9. https://www.darthparametric.com/files/kotor/k1/[K1]_Bearded_Mullet_Man_Vanilla_Style_Portraits.7z
  10. It has never been taken down, just never formally released. https://www.darthparametric.com/files/kotor/k1/[K1]_Bearded_Mullet_Man_PMHC04.7z
  11. Those keys are what the CD version already uses, hence why you need it for the other versions (seeing as they didn't exist when KTool was coded). There should be no need to use it for the CD version unless you have manually moved the install folder.
  12. Made some adjustments to the lighting and the horizontal bars/surrounds. Also switched the exported texture from DXT5 compression to uncompressed, as there were some nasty compression artefacts (probably not really noticeable in a compressed video). I think it needs to be shifted a squidge to the right. And it could possibly stand to be narrowed up a touch as well to tighten in around the buttons, although it probably needs to be tested on other aspect ratios/resolutions first to see how it mates with ndix UR's GUI files for non-1080/16:9 resolutions.
  13. I tried out the pre-rendered approach. After looking at the vanilla model (I replaced the original background plane with my own), I realised they used self-illum to brighten it up. I did that as well but I still need to fiddle with the balance of it, as I had compensated for the previous darkness by changing the lighting of the render, so now everything is probably a bit too uniformly bright. I can play with that later though. For the moment I am still messing around with different materials. I'm not really keen on the look of the horizontal blue stripes/surrounds, might need to fiddle with those a bit.
  14. I did do an Anakin AOTC high poly hilt, but that is around 32K polys, not a practical game model. Here are a few KOTOR bits and pieces I could find. An untextured Vader ANH hilt. It could probably also be converted to an Anakin AOTC hilt without too much drama. The TOR concept/Ven Zallow hilt (very low quality): The Starkiller/Force Unleashed hilt that I could never get to work properly with MDLOps (should be fine now with MDLEdit though, a mere 9 years later): The Ki-Adi-Mundi hilt: An untextured Revan's hilt (apparently?):
  15. Played around with a physical mesh replacement background. I tried adding it to the menu model with some dynamic lighting, but that was kind of crap: I was thinking about trying baked lighting, but it's probably just better to do it completely pre-rendered and keep it as an image. Needs various adjustments, but more in the vein of this kind of thing:
  16. I was poking through my scrap heap earlier and noticed I have an ESB version that never made it past the WIP render stage, circa 2008. I can throw that one together as well if you want.
  17. There appears to be a case sensitive issue where MDLEdit will not recognise the name of a node with differing case from the first instance, as per this example.
  18. I dug out my ye olde Luke ANH saber and slapped together an installer for it. Also provided a straight override for the vanilla turquoise hilt. Not Kol's perhaps, but why settle for anything less than a genuine Graflex™? https://www.darthparametric.com/files/kotor/tsl/%5BTSL%5D_Luke_ANH_Lightsaber.7z
  19. You chose a good time to return. The first step is to remove NWMax and grab KOTORMax. Then ditch MDLOps in favour of MDLEdit.
  20. MDLEdit will handle sabers just fine. All it takes is a simple decompile and recompile to the other game version. There's no need for any of the complexities with the old MDLOps replacer routine any more.
  21. The MDX is generated when compiled. You don't have to do anything to it. Loading the ASCII model, it looks fine. It's the same as the vanilla I_Mask_012 model - http://starwars.wikia.com/wiki/Stabilizer_mask Make sure your MDL/MDX is named correctly (I_Mask_050) and your UTI is pointing to the right model variation.
  22. Your source model was I_Mask_012 and you didn't change all the references. However the cause of your error appears to be a case-sensitive problem - you have "parent i_mask_050" and it was expecting "parent I_Mask_050". That is a bug and should be reported to bead-v in MDLEdit's bug thread. i_mask_050_FIXED.mdl.7z
  23. Seems like user error to me. There are no nodes like that in the vanilla I_Mask_011 model (for either K1 or TSL).
  24. With the release of ndix UR's KotOR High Resolution Menus, I figured a K1 main menu model edit was in order. Nothing fancy so far, just a replication of the widescreen adjustment I released for TSL, stretching the background and adding in an extra VFX node (although I did replace the logo image with a less washed out one). The image quality of the background is terrible, even at its native res. It's full of artefacts and colour banding. I'm wondering whether a better approach might be to replace it with an actual physical model.