DarthParametric

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.

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.

No. All polygons have a normal. It's a fundamental part of 3D graphics. https://en.wikipedia.org/wiki/Normal_(geometry)

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.

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

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.

Make sure you unusubscribe from all mods and then delete whatever files are left over in \steamapps\workshop\content\208580\

A good starting point would be listing those out.

Do you have TSLRCM installed via the Workshop? Or any other Workshop mods with an appearance.2da and/or heads.2da?

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.

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.

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.

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.

Do you want to delete it outright, or restore a vanilla version? Either way you'll want to use the ERF/RIM Editor. Open the MOD with it and you can delete the offending UTC and save the MOD. If you want to restore a vanilla version of the file, extract it from its parent RIM and drag and drop it into MOD while it is open in ERFEdit. Note however that there is no harm in simply adding an unused UTC to a MOD. Nothing will happen if it is not specified in the GIT or spawned from a script, unless it is overriding an existing one used in that module.

If you just need them for machinima and not regular gameplay, that frees you up a little. If you want to be able to freely script anims for the player and party, then you either have to hijack the main supermodels (a very bad idea for actually playing the game) or create custom models that either have the anims on them directly, or use an intermediate supermodel, as I suggested above. The first step regardless is to make a list of the anims you want, then find out what TSL supermodels they are on. There may be separate male and female versions, depending on the animation. Then you need to look at K1's nwscript.nss and determine which of the available scriptable anims you want to replace (stuff like Dance, Victory, etc.). Note that you'll want to differentiate between looping and fire and forget anims. All the ones you listed would be fire and forget (i.e. they play once and then resume and idle). However something like the crouching one might have a second looping anim, remaining in the crouched position, followed by a third standing back up. This sort of thing is common with Force powers, for example. Once you've worked out the anims you want and what supermodels they are on, probably the most reliable way to deal with them is via editing ASCIIs in an advanced text editor like Notepad++ and deleting all the anims you don't want. How you move forward from there depends on whether you want to inject the anims into the existing K1 supermodels, or create intermediate supermodels.

It's not about being simpler, it's about there being no other choice. The game won't recognise new animations, and in K1 there is a very limited number of existing animations that can be fired by a script (hence why a replacement for Dance is so often used). What exactly is the end goal? That will determine how best to go about achieving it.

The "tricking" part is more about scripting, renaming animations in order to play ones for which there is no existing provision. In the first place you'd have to transfer the animation directly onto your target model, or create an intermediate supermodel. The latter is a better idea, as it gives you more flexibility, especially when dealing with scale differences.

Yes, I have fixed it in v1.2, along with some other minor tweaks. I am in the process of testing it now. Will probably release it tomorrow, all things being well.

Yeah you don't want to include the example syntax (edited my previous post to break them up). This compiles: void main() { object oCarth = GetObjectByTag("Carth"); object oCand = GetObjectByTag("Cand"); object oMission = GetObjectByTag("Mission"); object oZaalbar = GetObjectByTag("Zaalbar"); location lCandRun = Location(Vector(215.25, 333.43, 25.23), 0.0); location lMissionRun = Location(Vector(217.01, 331.91, 24.92), 0.0); location lZaalbarRun = Location(Vector(215.63, 330.38, 24.62), 0.0); location lCarthRun = Location(Vector(214.22, 332.15, 24.97), 0.0); DelayCommand(3.0, AssignCommand(oCand, ActionForceMoveToLocation(lCandRun, TRUE))); DelayCommand(3.8, AssignCommand(oZaalbar, ActionForceMoveToLocation(lZaalbarRun, TRUE))); DelayCommand(3.5, AssignCommand(oMission, ActionForceMoveToLocation(lMissionRun, TRUE))); DelayCommand(3.4, AssignCommand(oCarth, ActionForceMoveToLocation(lCarthRun, TRUE))); }

Try // 382: Force the action subject to move to lDestination. void ActionForceMoveToLocation(location lDestination, int bRun=FALSE, float fTimeout=30.0f); DelayCommand(3.0, AssignCommand(oCand, ActionForceMoveToLocation(lCandRun, TRUE))); Or you can use a waypoint instead with // 383: Force the action subject to move to oMoveTo. void ActionForceMoveToObject(object oMoveTo, int bRun=FALSE, float fRange=1.0f, float fTimeout=30.0f); object oObject = GetObjectByTag("CREATURE_TAG", 0); object oWP = GetWaypointByTag("WAYPOINT_TAG"); AssignCommand(oObject, ActionForceMoveToObject(oWP, TRUE));

It looks like there's a facing command in the script that jumps the player to the arena. There's also a separate facing script. I'll look at inserting that (or my own script) into the dialogue once I have a fixed version to upload.

Ah, crap, that's a TSLPatcher bug. I thought it was only that it couldn't edit filenames with + and other symbols, but it seems it also completely nukes them when repacking an ERF. That's a problem. @Fair Strides help? Edit: Thanks to @A Future Pilot pointing me to a fixed version of TSLPatcher, this bug should now be resolved in v1.1. For anyone that downloaded the original v1.0 release, I have provided a separate patch that will inject the missing files back into the MOD.

It is set to only copy the MOD file if one doesn't already exist. It will inject the changes into a pre-existing MOD file. As such, the included MOD is not pre-patched.

View File Taris Dueling Arena Adjustment This mod makes some alterations to the arena in the Taris Upper City cantina. The primary change is the removal of the original low quality crowd sprites. In the vanilla game these are VFX nodes. It appears that Bioware's original intention was for these to be animated, but that was likely disabled due to performance issues on the Xbox. Subsequently, most of the sprites are lacking arms. Another issue is the scaling. The sprites are completely out of scale with the rest of the game world, appearing to be about half the height of an average human. This was possibly an attempt to skew the perspective, an attempt to make the arena look bigger than it actually is. The original sprites have been completely removed in favour of better quality crowd sprites ported from The Old Republic. Additionally, the bays housing the crowd have been resized in order to fit proper human-sized figures. To comply with recent local ordinance changes, transparisteel safety screens have been fitted for the crowd’s protection. Other minor changes include some texture swaps on the roof section and a dummy door model to hide some unsightly fog on the original. Additionally, players participating in duels should now correctly face their opponent, and give an alignment-specific emote when they are announced. Opponents will now politely wait until their name is announced before giving their little fist pump. After some complaints by their union about a lack of proper medical services, defeated opponents are now healed back to full health post-match rather than being left to limp around. The view screens in the cantina have been upgraded to have a dynamic display of the current arena rankings. These will change as the player progresses up the ranks. The placeable computer screens have all had their positions adjusted so that they properly contact the walls they are supposed to be mounted to, and to align them with one another. Ajuur the Hutt’s dialogue has also had some minor surgery performed on it, to better deal with player and party positioning. Carth should now properly face Ajuur and the player during his relevant interjections, and won't be replying from across the room. N.B. - Because alterations are made to the module's GIT file, the mod requires a save before entering the Upper City cantina for the first time. It is thus best suited for a new game. If you load a save after having entered, none of the screens will line up properly with the computer placeables. Known Issues: If you initiate a conversation with Ajuur while the party is standing in the corner with the medpac bin, you will likely see them jump out of frame as they are moved to their now scripted fixed positions directly in front of the Hutt. That's an unfortunate consequence of the way it was handled, but the camera angle should mask the transition from pretty much anywhere else. Acknowledgements Thanks to @bead-v for MDLEdit Thanks to @ndix UR for TGA2TPC Special thanks to @JCarter426 for helping with some scripting, particularly extended troubleshooting of the Ajuur party positioning script Thanks to @Salk for alerting me to the TSLPatcher problem with v1.0 Thanks to @A Future Pilot for pointing me to the fixed version of TSLPatcher Thanks to @Publicola for informing me about the ability to click through announcement animations Some screenshots feature @Sithspecter's High Quality Blasters The video features @ndix UR's KOTOR High Resolution Menus Crowd and glass textures ported from The Old Republic MMO Submitter DarthParametric Submitted 11/18/2018 Category Mods K1R Compatible No