DarthParametric

Modders
  • Content Count

    4,626
  • Joined

  • Last visited

  • Days Won

    523

Everything posted by DarthParametric

  1. Is that the first time you visit the council? I think I remember someone else mentioning it before, but I'm not sure if I have ever seen it myself. Edit: I can't test it myself, as I don't get the issue, but try dropping this script in your Override and see if it changes anything. Edit 2: Actually, try these two scripts: k_pdan_zhar_scripts.7z
  2. I don't see any problems with the ASCII. UVs are the same as vanilla and the texture issue doesn't show up in Max. Must be something going on in the binary.
  3. Is that the source model? I need the binary model decompiled. There's no issue with that ASCII in Max at any rate. You'd have to ask @bead-v to have a look at the binary model perhaps. No, otherwise the diffuse texture would be mangled.
  4. Yes, I changed it when the placeables limit bug came to light after the initial release. Looks to be an issue with the UVs being mangled. You'll need to decompile the affected model and then load it up in Max/GMax and look at the UVs. Or just attach the model and I'll have a look at it.
  5. If you want to add stuff to K1, I would suggest considering adding them directly to the room model where possible. That will require lightmapping the placeable meshes (or at least faking it) and possibly room animation, but it will cause less grief for end-users.
  6. I assumed you were using an existing placeable, hence why I didn't cover that part. I would advise against adding new placeables to K1 unless absolutely necessary, at least for public releases. As far as collision goes, most placeables already include it. Is that a TSL placeable? Did you recompile the model for K1? You should have got a PWK, which, as the letters suggest, is the Placeable Walkmesh. That needs to go in the Override folder along with the MDL/MDX.
  7. You only specify the exact placeables you want to spawn. If you just have that one, then your script would be: void main() { if ((GetEnteringObject() == GetFirstPC())) { if( GetObjectByTag( "PLC_TSLCpnl" ) == OBJECT_INVALID ) { CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_TSLCpnl", Location(Vector(179.16,65.40,0.00), 180.0)); } ExecuteScript("k_ptar_02aa_ORIG", OBJECT_SELF); } } Note that the "180.0" is the rotation, so you will need to set that appropriately. I would start with 0.0 (it's a float, so it must always have a decimal) and adjust as needed. Your new script must be the exact name of the original OnEnter script. If you are editing M02AA then it would be k_ptar_02aa_en and the original would need to be renamed something else, remembering that you do not want to exceed 16 characters in a filename. I have provided a suitable example in the script above. Once your new script is compiled, put it, the renamed original OnEnter script, and your UTP in the Override folder and test it in-game.
  8. The module's ARE will specify the OnEnter script (although I think there may be a couple where this isn't the case, stunt modules and the like). You can find the script itself in the XYZ_s.rim under Scripts, Compiled. As the category name suggests, these are compiled scripts - NCS. You don't actually need to alter the OnEnter script itself, so you don't need to decompile it. You just need to extract it and rename it. As far the GIT goes. you'll want to save editing that until last. If you are modifying an existing module, changes will typically be inject into a MOD during installation.
  9. In KOTOR Tool, the GIT (dynamic area info) is in the XYZ.rim along with the ARE (static area info) and IFO (module info). A UTP is the GFF template for a placeable, equivalent to a UTC for a creature or UTI for an item. You'll find them in the XYZ_s.rim under Blueprint, Placeables. Regarding the script, yes, PLC_301RefEnt etc are the individual placeable tags (as opposed to the resref - i.e. filename - an important distinction) . Basically what the script is doing is firing when the PC enters the module, checking for the existence of the placeable with the tag PLC_301SignPad. If that placeable exists, it then jumps straight to the ExecuteScript command, which fires the original OnEnter, renamed with the "_ORIG" epithet (this new script is given the original OnEnter name so the module loads it). If the placeable is not found (i.e. the engine returns OBJECT_INVALID) then it will proceed to spawn each of the listed placeables at the specified locations (assuming UTPs exist for them).
  10. Like most things in a module, it will need a GIT entry to actually spawn in the level, along with the UTP that defines it. For testing purposes you are probably better to start with spawning it via script so that you can quickly adjust the position as needs be. For this you will typically want to hijack the module's OnEnter script with a new script that spawns the placeable before loading the original OnEnter. Here is an example of one I used for the Nar Shaddaa landing zone module: void main() { if ((GetEnteringObject() == GetFirstPC())) { if( GetObjectByTag( "PLC_301SignPad" ) == OBJECT_INVALID ) { CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301SignPad", Location(Vector(-85.25,19.45,9.66545), 131.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301SignShp", Location(Vector(-55.5,-6.15,9.722), 90.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301DckEnt", Location(Vector(5.7,41.65,9.66551), 180.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301CanEnt", Location(Vector(38.25,0.00,9.66545), 180.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301RefEnt", Location(Vector(0.0,-44.25,10.0), 90.0)); } ExecuteScript("k_301_enter_ORIG", OBJECT_SELF); } } The important difference to note is that scripts specify rotation in degree, but the GIT specifies the bearing of placeables in radians. From memory they also use differing origins, so it can take some trial and error getting it right. As far as actually determining the position values goes, you can either run around in the level in-game and use one of the armband mods that will spit out your current position, or you can load the level up in Max/GMax and derive it that way.
  11. Yes. Simply recompile the ASCII against the equivalent K1 supermodel. If you made use of TSL's added bones however, such as for the cloak of a robe, then that won't work in K1, as it lacks those. Fortunately however, @JCarter426 has ported the TSL supermodels to K1 as part of his robes mod, so you can either install his robes mod or just take the supermodels from it (or the modder's resource pack) and compile against those.
  12. Typically heads will need to be re-rigged with the target game's rig rather than just recompiling the vanilla model.
  13. It is looking up the registry key for the CD versions, while you presumably have the GOG or Steam version. This has already been asked before many times, including by you.
  14. That is a texture semantic. Only the tangentspace flag is enabled in the model. I would suggest for any normal mapped models with danglymeshes/OdysseyFlex that you try MDLOps until bead-v gets around to updating MDLEdit.
  15. No. All polygons have a normal. It's a fundamental part of 3D graphics. https://en.wikipedia.org/wiki/Normal_(geometry)
  16. Cube maps are very hit or miss. Their effect seem to be tied to the mesh in some fashion beyond what you'd typically expect. I would think the normals, but possibly the UV orientation as well. I could not get a nice result on the Upper City cantina arena glass for example. The reflections always came out mangled, unlike with vanilla models. Further information/explanation would be required from the @bead-v / @ndix UR brains trust.
  17. No, it's not intended. Just one of the many minor issues that escaped the notice of QA (or exceeded the post-release patching budget). Fun fact: all the ivy in the landing bay is one single mesh. I did a quick test and everything seems ok. https://www.darthparametric.com/files/kotor/k1/[K1]_Dantooine_Enclave_Landing_Pad_Ivy_Fix.7z
  18. I provided the source NSS for all the scripts, so there should be no problems. The adjustment was to the waypoint the player jumps to (tar02_wppcarena2), as initially I thought that might be the source of the orientation issues. You can see the change in the Y orientation if you compare it to the vanilla GIT (1.22514845490862e-016 vs 3.29414865518629e-006). As it turned out it made no difference to the player's orientation, but I just forgot to revert the change.
  19. Make sure you unusubscribe from all mods and then delete whatever files are left over in \steamapps\workshop\content\208580\
  20. A good starting point would be listing those out.
  21. Do you have TSLRCM installed via the Workshop? Or any other Workshop mods with an appearance.2da and/or heads.2da?
  22. Here, try this: https://www.darthparametric.com/files/kotor/k1/[K1]_Lite_Commoner_Placeables_Replacement.7z Before After You can change the body textures to one of the other variants by editing the ASCIIs and recompiling, or you can import them into Max/GMax and swap out the heads for different ones. Of course the real issue is that, being placeables, they can't equip the Pazaak card item. I think the proper solution for that is swapping them for real NPCs with stunt animations. That would also free you up to use whatever appearance.2da row you wanted. So you could diversify them a bit with aliens and so forth.
  23. Ah yeah, I forgot about the placeables. Yeah they will require a full body model. Not too difficult, it's a simple bit of surgery in Max. But adding additional entries is not practical given the placeables.2da row limit bug.
  24. Does the Lite Upgrader mod not already do this? By the way your lack of head would be because you didn't alter the appearance.2da entry from F to B and assign a heads.2da row ID.
  25. If that UTC is in the vanilla module, you can't just delete it. If you want to revert changes, you may have to edit the vanilla copy manually and add it back.