Link actor gear placement to OAR conditions

[GiraPomba]

Hey, we talked about this previously. It seems like OAR will have conditions by behavior variables. Could you add these variables when updating actor weapon placements? I believe each actor will have their own variables, right? Thanks.

[SlavicPotato]

Manipulating graph variables wasn't what I had in mind, it's not safe or realistic to do so for this purpose. Back when we discussed this, I had the idea (of the top of my head) of OAR implementing its own internal actor variables that may be created, destroyed and updated by plugins and used in OAR's conditions - just one possible approach to cross-plugin communication. I haven't reached out to ersh about it so I've no idea what, if anything, they may end up implementing. You'll want to talk to them about it.

[GiraPomba]

Hmm... I misunderstood what you meant earlier. I thought IED would update a variable on the actor so it could be used as a condition in OAR. I'll see if something can be done then.

[SlavicPotato]

I thought IED would update a variable on the actor

You did understand that part right, just not the part about directly writing behavior graph variables. As far as I'm aware, those are defined in the behavior graphs beforehand and can't be trivially created at runtime, but even if that's no the case, the risk of breaking something would be too high IMO.

[GiraPomba]

That makes sense. Will check with Ersh what OAR can do about this.

[GiraPomba]

Hey, OAR will have an API that could have some sort of variables storage system. Maybe something can be done through it.

[GiraPomba]

Hey, I don't know if you have been working on this, but I had this idea on how it could be implemented. It would involve setting graph vars on the actors, something you were against before I know, but I think It wouldn't cause any problems. You wouldn't have to worry about editing behavior files either, as this would be done by the user/modder and papyrus has a function to update graph vars on runtime, so it could be called from IED(the SKSE equivalent of that function). Well, if you are interested I can give more details.

[SlavicPotato]

It would involve setting graph vars on the actors, something you were against before I know, but I think It wouldn't cause any problems.

What I was getting at is that variables are intended to be used with graphs, (ab)using them to exclusively pass data between two skse plugins isn't a good solution. I did some RE since then and as I suspected they're not automatically created just by invoking SetGraphVariable(type) so they'd either have to be predefined (behavior patching) or created at runtime by other means. Both options suck for this use case.

[GiraPomba]

Hmm, I see. I was thinking about editing behavior files to create the variables. With Behavior Data Injector you can easily add those variables. This would on the user end. So, IED could have some sort of config settings were user would create or import. Similar to "Placement" in "Gear nodes", with overrides or multiple configs because of the unrestricted placement. Something like "Sword>Sword back>Variable Name(string), VariableType( int, bool, float), VariableValue" Then IED could call the function SetAnimationVariableInt() (or bool or float) on the actor based on the configs, which then could be used in OAR

But yeah, maybe something better could be implemented.

[SlavicPotato]

I've implemented OAR conditions that can be used to read placement info from IED:

IED_GearNodePlacementHint - gets a placement hint based on where a gear node (first parameter) is attached and compares it to the second parameter

IED_GearNodeParentName - gets the parent node name of the specified gear node (first parameter) and tests if it's equal to the second parameter

SDS_IsShieldOnBackEnabled - checks if SDS has shield on back enabled for the actor

The hint thing is probably most practical, unless you want a different anim for a specific MOV node.. See here which hint is assigned to which MOV. Let me know if you've got some suggestions on these assignments.

Beta built is attached to the comment, the condition plugin is separate from IED/SDS, you can build it easily enough

P.S.: WeaponPlacementID::Default (1) is unused, if a node wasn't moved by IED or something goes wrong during lookup, WeaponPlacementID::None (0) is always returned. In such case just assume it's at the default position.

ImmersiveEquipmentDisplays.zip

[GiraPomba]

That's awesome, thanks a lot. I think those conditions will be enough, but I'll test it later today and let you know.

I never built a plugin before tbh, but I'll give it a go. Shouldn't be too hard.

[SlavicPotato]

It's a few short commands in powershell to install xmake and build the thing, just follow the readme..

New build, had to make some changes for performance reasons

[GiraPomba]

I'm struggling at the Rapidcsv install, but I guess it's the C++ compiler. I'm installing it with Visual Studio now. But it's good to know, maybe I can make a SKSE plugin in the future, who knows lol...

Does this build works with Skyrim 1.6.640 btw?

[SlavicPotato]

Oh sorry I forgot to ask what you use.. That's the pre build, here's the post and I included the current oar plugin build

Plugins.zip

[GiraPomba]

Thanks, I just recently installed 1.6.640, I was hesitating but it isn't that bad. Everything is more stable now haha.

That'll save me some time.

[GiraPomba]

Seems to be working perfectly so far.

But how about nodes created with the Skeleton Extender? I have this mod here that adds new nodes, Maces on back, Swords at back hip and such.. I guess a new parameter in the Json to define the placement hint would be enough.

[SlavicPotato]

I guess a new parameter in the Json to define the placement hint would be enough.

Already there, placement_id

It's clamped to 0-8 range when read from json, I'll remove that

[SlavicPotato]

ImmersiveEquipmentDisplays.zip

You can assign a unique ID for your nodes now

[GiraPomba]

Perfect..

Another question, does IED or SDS know if CGO is installed? I want to add dual wield animations for 2h weapons, but if it's not installed, the game considers 2h weapons equipped on both hands, so that wouldn't work very well. I don't want to create an .esp just to have a toggle to enable CGO support...

[SlavicPotato]

I could add an IsPluginLoaded condition, wouldn't be foolproof but close enough I guess

[SlavicPotato]

Or maybe not, iirc it has a toggle for that it's not just on by default.. Maybe it has a global variable that shows whether it's enabled?

[GiraPomba]

Yeah, it adds a plugin, I think I can use a existing condition within OAR for that.

[SlavicPotato]

CompareValues can be used to match a global var

[GiraPomba]

Yeah, that can work. Does IED assign the same GearNodeID for two handed weapons on the left hand? I guess it's SDS that creates the display for the equipped weapon and IED only creates the display for the unequipped weapon on the display manager if enabled there.

Maybe the node assigned in SDS also changes the ID/placement hint?

[SlavicPotato]

There's no left 2h gear node to speak of in the vanilla game and neither plugin really needs it.. SDS redirects the geometry onto an arbitrary node (if it detects a lh equip) after the game creates it, IED just treats lh/rh hand forms as separate pieces of gear and also attaches to an arbitrary node..

I could add it to the so called 'weapon nodes' (gear nodes is more accurate, the labeling is horrible in the code lol) list and assign a name/id to it, it would be picked up automatically if defined in extra nodes (there should already be WeaponBackLeft and WeaponBackAxeMaceLeft in the public package)

[GiraPomba]

Only if you are willing to haha. I guess most users would assign the same node as the right hand weapon, so it should work fine for the animations.

[SlavicPotato]

That should probably do it. 00205_2HLeft.json (included in 1.7) needs to be loaded for it to work. You can tweak anything on those nodes except name, cme_name and mov_name.

ImmersiveEquipmentDisplays.zip

[SlavicPotato]

Fair warning: I didn't test it at all lol

[GiraPomba]

Lol.. nice, I'll test it and let you know. So far it's working great. Thanks again.

You went out of the way to add the conditions, it's amazing. IED it's revolutoniary, so is OAR. I hope you can port IED to Fallout 4 in the future. I guess the games are similar in structure, there's F4SE and CommonLib I think, maybe the skeletons are an obstacle.

[SlavicPotato]

Making some nice replacer configs is thanks enough so we can finally move away from xp32 and I can stop telling people to sync up the placement configs just so their anims work on nemesis heh

[GiraPomba]

Fair enough haha

[GiraPomba]

I can't get them to work, probably doing something wrong. I only managed to enable the node with SDS, but it doesn't change in IED. And I think it needs a new ID to use in the OAR plugin? But it's fine if you revert the changes tho, no problem. Pic: https://imgur.com/mlTUEUp

How to enable Two-Handed Axe/Mace btw? And how to use Two-Handed IED? I guess it was Two-Handed Extra before, but I never managed to get it working.

[GiraPomba]

Oh, changing the placement in the UI works for Two-Handed (Greatswords) but not for Two-Handed Axes/Maces.

[SlavicPotato]

WeaponBackAxeMaceLeftshould be fixed. Check out their assigned ids here.

Don't worry about the 'IED' nodes, they're not of any use here.. plus they were broken somewhere along 1.7 development, i've only noticed and fixed it yesterday

[SlavicPotato]

ImmersiveEquipmentDisplays.zip

[GiraPomba]

Alright, got them working now. One thing I noticed is: Two handed on right hand is sharing the same node, Greatswords and Battleaxes/Warhammers use the GearNodeID 5. Which is fine, since it's vanilla behavior and that could be changed in the UI.

But on the left hand however, they're using separate GearNodeIDs, Greatswords use 17, while Battleaxes/Warhammers use 18.

And the new gear node for Two-Handed Axe/Mace is "deactivated" for me here, maybe if I can enable it, then the weapons on the right hand will use separated IDs? Pic: https://imgur.com/AsnP0hi

But the conditions and displays are working fine now :D.

[SlavicPotato]

Yeah that's fine, it doesn't matter whether a display is activated or lh item enabled in sds... I think you're looking to much into the visual side, what you should look for is a way to tell what equip slot (2h,1h,..) the weapon in question has.. What CGO does is change the equip slot on all 2h weapons between 1h and 2h as you toggle..

P.S.: from what I can tell OAR doesn't have a condition to check this, I could add it in the plugin though..

[GiraPomba]

Oh, I also noticed that the left 2h weapons nodes are not loading correctly for my custom nodes (in this mod) but are loading fine for the slots in 00205_2HLeft.json

The "IEDTwoHandedBackHipLeft" is designed for 2h handed left weapons at back hip, it was working fine in previous versions. But now, assigning that node for the left weapons, makes them rotate (as if using a wrong node).

And if I use the "IEDTwoHandedBackHip", which is designed for the right hand weapons, for the left weapons, it makes them be displayed as if they're are a right hand weapon. Don't know if that makes sense.

If it's the intended behavior I can adjust the .json files for this new version.

[GiraPomba]

P.S.: from what I can tell OAR doesn't have a condition to check this, I could add it in the plugin though..

OAR can detect 2h weapons equipped on the left hand with IsEquippedType.

[SlavicPotato]

OAR can detect 2h weapons equipped on the left hand with IsEquippedType.

Not what I was talking about, this determines whether it's a 1h or 2h weap:

[GiraPomba]

Oh, yeah right, it doesn't have that. But I don't think it's necessary.

[SlavicPotato]

Pretty sure it is, else there's no reliable way to tell 2h and 1h weapons apart when dealing with invasive modifications like what CGO does

[SlavicPotato]

The "IEDTwoHandedBackHipLeft" is designed for 2h handed left weapons at back hip, it was working fine in previous versions. But now, assigning that node for the left weapons, makes them rotate (as if using a wrong node).

And if I use the "IEDTwoHandedBackHip", which is designed for the right hand weapons, for the left weapons, it makes them be displayed as if they're are a right hand weapon. Don't know if that makes sense.

If you're hinting at changes in how xfrm data is read, that would be fairly disastrous and would break even the included stuff (i'd have to update it, which I didn't except for reorganizing the files)... I'm reasonably sure you've got something else going on, maybe in your test environment?

[GiraPomba]

If I set the Simple Dual Sheath ini like this:

[2HSword]
Flags=Player
SheathNode=WeaponBackLeft

[2HAxe]
Flags=Player
SheathNode=WeaponBackAxeMaceLeft

It will read from the 00205_2HLeft.json and it allows me to change the gear nodes with the UI. But assigning IEDTwoHandedBackHipLeft with the UI, makes the left hand weapons in the "wrong" position.

If I set the Simple Dual Sheath ini like this:

[2HSword]
Flags=Player
SheathNode=IEDTwoHandedBackHipLeft

[2HAxe]
Flags=Player
SheathNode=IEDTwoHandedBackHipLeft

It loads the weapons in the correct position (for those extra nodes), but I can't change them with the UI... I can also just update the .json files...

[SlavicPotato]

Yeah that's normal since IED's placement moves WeaponBackLeft/WeaponBackAxeMaceLeft to "MOV IEDTwoHandedBackHipLeft", your MOV needs to be positioned in a way that's compatible with the back left nodes. We only added this ability yesterday (on your request lol), idk what you meant with "it was working fine in previous versions".. previously it was impossible to place WeaponBackLeft/WeaponBackAxeMaceLeft and it was never possible to place any custom nodes added via extensions.

I could add it to the so called 'weapon nodes' (gear nodes is more accurate, the labeling is horrible in the code lol) list and assign a name/id to it, it would be picked up automatically if defined in extra nodes (there should already be WeaponBackLeft and WeaponBackAxeMaceLeft in the public package)

Edit: by 'place' I mean move those nodes around, you can only move to the nodes you create, you can't move them around unless they're registered internally in IED.

[SlavicPotato]

Added new condition, IED_GearNodeEquippedPlacementHint

Same as IED_GearNodePlacementHint, except that it determines the gear node ID from an equipped weapon.

Found it pretty useful, can help reduce the complexity of your conditions

Release MT Post 629 143.zip

[SlavicPotato]

Added IED_HasEquipSlot

Returns true if an item equipped in the target ref's hand has the specified equip slot configured.

OpenAnimationReplacer-IEDConditionExtensions.zip

[SlavicPotato]

[GiraPomba]

idk what you meant with "it was working fine in previous versions".

Oh, I meant with Simple Dual Sheath, using the node there in the ini. Okay then, I'll update the json files to be compatible with the new feature now. Thanks.

Added new condition, IED_GearNodeEquippedPlacementHint

Nice, I was using isEquippedType, now I can delete that condition :D

Added IED_HasEquipSlot

Neat, I think I can properly detect CGO now.

Now I need to think of a way to properly detect "Unrestricted placement" nodes. For example, default hint for Two-Handed is 1, default hint for One-Handed is 1. If I set Two-Handed to One-Handed the ID will still be 1, but the One-Handed is at hip and not on back. Maybe it's possible with IED_GearNodeParentName

Anyway, thanks for the new conditions and sorry for the dumb questions lol.

[SlavicPotato]

If I set Two-Handed to One-Handed the ID will still be 1, but the One-Handed is at hip and not on back.

Edit: nvm, I didn't read that right.. IED_GearNodeParentName is the way to go for sure

[SlavicPotato]

Got a Q for you:

2hc_equip/unequip anims from xp32 (same as those included in your anim mod) seem to be missing female anims, I don't suppose there's a simple way to coax OAR into playing the male variants instead?