DarthParametric

You can have a look at how they do it TSL for the Academy and Dxun sparring. At a guess, someone's OnHeartbeat is probably listening for the PC using powers. In either the opponent's OUD or maybe another NPC or an invisible placeable. Potentially even in the module's OnHeartbeat, but I'm not sure if that's necessary. Edit: Ah, Obsidian added a dedicated function for it in TSL, SetForfeitConditions. Makes sense, but obviously that doesn't exist in K1. You'll have to try and manually catch the PC casting. You can probably just do a check in the OnHeartbeat for the PC casting at either the opponent or themselves.

Give the opponent a custom UserDefine (you can use the vanilla k_def_userdef01 as a starting template). Event 1010 (on spell cast at) should let you catch the character being affected by a Force power. Their OnSpawn script will need the inclusion of GN_SetSpawnInCondition(SW_FLAG_EVENT_ON_FORCE_AFFECTED). Basically the same way as above, but with other events. There are a multitude of vanilla examples of this happening in both games, and the TSL sparring ring on Dxun and/or sparring with the handmaidens on Telos should give you pretty much exactly what you want, differences in script functions between the games aside. In the opponent's 1006 event (on damaged), have it check its current health status. This will require the addition of GN_SetSpawnInCondition(SW_FLAG_EVENT_ON_DAMAGED) to its OnSpawn. To catch the player, you'll also have to use the opponent's UserDefine, since you can't do anything with the player themselves. That can go in event 1003 (on end of combat round) and basically works identically the opponent's own health check, but checking the PC's health instead. This will require adding GN_SetSpawnInCondition(SW_FLAG_EVENT_ON_COMBAT_ROUND_END) to their OnSpawn. Look at TSL's k_fab_dueluser (vanilla and TSLRCM versions) and k_dojo_ud (vanilla and TSLRCM are the same I believe) for guidance. That's what starting conditionals are for. Add the necessary branches at the top of the DLG and gate them with the required starting conditional check. Typically you'll be doing this via setting local booleans (SW_PLOT_BOOLEAN_01 - 10, etc.). Every major dialogue does this, so you have plenty of potential examples to look through. But if it's easier to use separate DLGs then you just call those when triggering the DLG. Whichever way you prefer. You could also physically block them leaving by spawning in some of the vanilla placeable walkmeshes. In TSL you could just create a custom one, but you don't want to be adding new placeables in K1 due to the 2DA row limit issue, so you'd have to spawn in a bunch of the vanilla ones and arrange them to suit. PLC_Blockage is one, which is a 6m long rectangle (so a bit unwieldy). There are some smaller ones like PLC_CageLgB which are intended for use with force cages and the like. Blocking them would let you switch the trigger to firing a bark bubble message about not running away instead of actively ending the combat.

Because they'd need to be set up as disguises, and disguises are a pain in the ass. Plus both look pretty naff anyway.

I'm not sure how it's possible for people to still be breaking this. Maybe the script needs to be farmed out to an invisible placeable.

A script will terminate when its owner dies. You'll probably need to farm it out to an invisible placeable spawned on top of the actual placeable. That shouldn't be how the loop works. In theory at least.

In that case you don't need any check at all, besides whichever objects are standing inside the blast radius. void main () { int nDamage = 60; int nDCCheck = 15; object oTarget; location lSelf = GetLocation(OBJECT_SELF); ApplyEffectAtLocation(DURATION_TYPE_INSTANT, EffectVisualEffect(1044), lSelf); // VFX_IMP_SCORCH_MARK ApplyEffectAtLocation(DURATION_TYPE_INSTANT, EffectVisualEffect(VFX_FNF_GRENADE_FRAGMENTATION), lSelf); oTarget = GetFirstObjectInShape(SHAPE_SPHERE, 4.0, lSelf); while (GetIsObjectValid(oTarget)) { nDCCheck -= GetReflexSavingThrow(oTarget); if (!ReflexSave(oTarget, nDCCheck, SAVING_THROW_TYPE_NONE)) { ApplyEffectToObject(DURATION_TYPE_INSTANT, EffectDamage(nDamage, DAMAGE_TYPE_PIERCING), oTarget); } else { ApplyEffectToObject(DURATION_TYPE_INSTANT, EffectDamage(nDamage/2, DAMAGE_TYPE_PIERCING), oTarget); } ApplyEffectToObject(DURATION_TYPE_TEMPORARY, EffectForcePushTargeted(GetLocation(oTarget)), oTarget, 0.1); oTarget = GetNextObjectInShape(SHAPE_SPHERE, 4.0, lSelf); } } Who is the script owner, i.e. the one running the script? The placeable?

Well for starters, your script formatting is completely broken. I'm not even sure how it compiles. Second, your current check is pointless because it will always evaluate true for one of the conditions (not a friend OR not neutral OR not an enemy). What exactly are you trying to do?

It has nothing to do with my mod. I don't touch the actual monitor texture.

How so?

Aha, dancing Selkath returns!. Looks good. The only real issue I can see is the elbows, which I also noticed in your previous post. Seems like that may need some adjustment. As to Theron, how'd you set him up in appearance.2da? By default it will want to apply a single texture to the whole model if you specify one in the 2DA.

Unfortunately ndix UR hasn't been active for a long while now, so you're not going to get a response. Fortunately it's not too difficult to edit the GUIs yourself with a GFF editor, although it can be a little daunting at first.

I assume you're using one of the 21:9 GUI sets? Should be the closest for your resolution's aspect ratio (24:10). You could try picking a smaller resolution (like 2560x1080 or 1280x1080) and see if that helps. As to the health bars, I'm not sure where they are defined. I'd have to go digging. I know I edited the barkbubbles before (the pop-up speech bubbles you get from ambient NPCs, etc.).

Nah, it's not really an issue. It's easy enough to generate meshes of the TOR bones via FBX. You should also be able to use dummies/null objects as well, which is also possible via FBX. I'll whip up a set of the character rigs for you to play around with when I get a chance. As to importing, it seems a scale factor in the ballpark of 8.8 aligns a "normal" male (BMN) TOR character with a medium KOTOR character, albeit they are rotated 180 from each other: Not sure if you just live with the rotation and then rotate the NPCs in-game. There's kind of a bit of that already with Rakata, since all their anims are weirdly angled off to one side. One thing to note is that the TOR plugins can't currently handle additive anims (anything prefixed "ad_"), so stuff like facial animations and so forth, due to the way they are stored. That instantly takes a lot of anims off the table, but there are still plenty of canned anims that would work for background NPCs. Not sure if it would be feasible to have an actual interactive NPC you could talk to, much less fight, fully using TOR anims. Another thing to note that due to the use of a cloth system, capes, cloaks and the like have a separate set of unique-per-model bones that are not imported by the plugin with the standard rig and don't receive animation. It's all dynamically driven by the cloth sim in TOR. This also applies to things like Twi'lek lekku. Also, currently the plugins don't support the new 64bit animations in the live game (the game switched from 32bit to 64bit about a year ago). You have to download an archive of the original 32bit anims, which obviously means you aren't getting anything added to the game recently. Although the plugin devs are apparently working on 64bit anim support. You can download the 32bit anims here - https://drive.google.com/drive/folders/1hItkqGGX2ut9FMslTrxQV5GahbHYqT7F Make sure you get both GR2 plugins: https://github.com/SWTOR-Slicers/Granny2-Plug-In-Blender-2.8x https://github.com/SWTOR-Slicers/ZG-SWTOR-Tools I'd advise sticking to Blender 3.6.x with these. They are flaky with 4.x, and it breaks KOTORBlender anyway. Edit: Hrm, I can't remember how I managed to convert the bones to meshes previously. I can see two ways to convert all the bones into a single skinned mesh, one of which can be done in Blender (see here, first export the TOR model to a glTF file and reimport to transform the bones into a usable size). But that's not particularly helpful. I thought I had just done something like exporting the rig to OBJ, but that doesn't work. Blergh.

Nice work. How does it handle stuff like the fingers? It's interesting that you are using Auto-Rig Pro. Is it the version they were giving away for free a month or two ago? I had been thinking about possibly importing TOR anims directly via an NPC-only TOR rig for stuff like the dancers and so forth. But retargeting would obviously be much more useful. The TOR Blender plugin(s) have evolved a lot in the last couple of years, so getting TOR anims in a usable state is much more viable. For example, in-built rig scaling, removing added orientations, etc.

I don't think they have the medal hook. I'd have to check. Assuming the hook was added though (either previously or in the future) then it would work in conjunction with JC's script since it's just a replacement for the regular Revan/SF robes.

You don't need to extract the files anywhere in particular. You can put them wherever you want, you just need to point KBlender to the folder locations. Go to Blender's Preferences window (top menu bar Edit -> Preferences), select Add-ons in the lefthand list, optionally tick the "Enabled Add-ons Only" checkbox up the top of the righthand pane to filter the list, scroll down to "Import/Export: KotorBlender" and expand it. You'll see two fields you can enter values into, "Texture Search Paths" and "Lightmap Search Paths": The "Texture" path is the contents of swpc_tex_tpa and the "Lightmap" path is the contents of the multiple lightmaps.bifs (or singular in the case of TSL). Male sure you extract each game's textures into their own separate folders, assuming you want/need content from both. You can add multiple folder paths into each field, separated by semi-colons (;). For example, in my case for the Texture field I have the K1 texture folder, then the TSL texture folder, then the K1 Override folder.

It doesn't work due to changes Blender made to how normals/smoothing works in 4.0, so you'll have to stick with 3.x.

It has been brought up, JC just never got around to addressing it in the mod. An alternative solution can be found here - https://deadlystream.com/files/file/1378-jcs-fashion-line-i-cloaked-jedi-robes-for-k1/?do=findComment&comment=9320