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.

[GiraPomba]

Are they separated? I never notice tbh, I thought all equip/unequip were on the "main" folder and not the "female/male default". I don't think it's possible for OAR to play animation from different projects right now. It's possible to copy-paste the animations. But that would probably mess the sleletons lol.

[SlavicPotato]

I thought all equip/unequip were on the "main" folder

Yeah they are, normally oar assigns a single hkx to both sexes, in this case they only play on male. They can't even be previewed on females. I barely know anything about this but I doubt there's two separate anims packed in the hkx, maybe they just need to be flagged to play for a particular sex..

[GiraPomba]

Hmm, I see, I barely play as a female character. I'll take a look and see what the game does for the vanilla 2hc animations and then try to replicate. When I "made" those animations for my mod, I just copied and renamed the 1hm_equip/unequip animations, since it was a "sword at hip" animation for 2h weapons.

Theoretically, it should've worked. Maybe it's a different name for female chars?

[SlavicPotato]

Copy pasted 2hc* and 2hw* into female subfolder and now it's picking them up heh

[GiraPomba]

Nice catch :D, I'll add this to my mod when I update.

[GiraPomba]

Btw, OAR has some nice conditions that IED could use. Like graph variable vars on the actors and Target function.

Target function could be used in a shader effect display to make weapons glow when near certain kind of enemies.

[SlavicPotato]

I've pondered on implementing similar conditions in IED, the issue is performance.. These types of conditions need to be evaluated continously. IED has several different components with conditions each with potentially dozens (unlimited really) of entries, this wouldn't really scale well if each had to be evaluated on frame-by-frame basis.

The conditions that are implemented currently are actually only evaluated when:

• events are recieved from the game (like equip, location change, etc..) either from the sinks already implemented in the game or though hooks installed by the plugin
• by polling the values that the conditions check like actor flags, sit state, combat state, and so on, triggering an eval only when something changes

This way it can completely avoid having to run each individual condition every frame which scales very well. There's still some cost when adding new conditions, but it's paid only when an eval triggers and even then it's minimal due to some heavy caching being done in the background. Before an eval runs the inventory data is built from the very slow linked list that the game stores it in and dumped into a sorted array for rapid random access. For example, if you make an effect and plaster it with getitemcount conditions, it will walk through that linked list each time which can cause huge slowdowns. In contrast, if you add a count condition somewhere in IED, it only needs to run a quick binary search through an array to find a particular form and read the count from it, everything is already cached.

[SlavicPotato]

Added IED_PluginOption, removed reverse axe hint (seems useless)

IED_PluginOption accepts keys 0 and 1 atm that read if frostfall idle/attack anims are enabled in settings (return values are 0 = disabled, 1 = enabled)

Release MT Post 629 143.zip

[GiraPomba]

I've pondered on implementing similar conditions in IED, the issue is performance..

Understandable. Thanks for the explanation.

Added IED_PluginOption, removed reverse axe hint (seems useless)

I was using that hint lol. I even assigned it to a "reverse mace" node that I created.

[SlavicPotato]

I was using that hint lol. I even assigned it to a "reverse mace" node that I created.

Do you have an animation for it?

[GiraPomba]

Yeah, actually I'm reusing the mace animation for the reverse axe and the axe animation for the reverse mace lol. But I talked about expanding the animations with a friend of mine that's an animator, hopefully we can fill the gap soon.

The animation works almost fine, the axe needs to be flipped.

[SlavicPotato]

Alright, it's back

ImmersiveEquipmentDisplays.zip

[GiraPomba]

Thanks.

IED_GearNodeEquippedPlacementHint this reduced the number of conditions from 4 to 1 and 8 to 2 in some cases. Nice...

[GiraPomba]

I think I finished converting, conditions worked fine so far. Works well with Overrides and all. Pretty cool.

https://cdn.discordapp.com/attachments/1125787883748458558/1140415373473218662/Weapon_Styles_IED.7z

The converted mod in case you're interested. I didn't mess with the "Unarmed/Staff on right hand" folders... Yet. And didn't use the IED_GearNodeParentName. I'll consider it.

[SlavicPotato]

Works great! Technically, the less you use that condition the better. It's for cases where there's no other choice.

[GiraPomba]

Yeah, now I can truly have a "style randomizer". I guess not many users would use the Unrestricted placement nodes, so it's not worth it to change the default ids or even use that condition.

[SlavicPotato]

It wouldn't look right in almost every case.. Like if you move two-handed to sword or sword back, the position is totally off.. I suppose I could add hints to the default nodes too, but that would just mean more work for you since you'd have to rework conditions to accomodate for it (now you can just assume it's at its proper default position and let it fall through to whatever submod handles the weapon).. I don't think it's worth it imo

[SlavicPotato]

Closing this for now, btw we can coninue this on discord so we don't blast repo watchers with notifications on here.. I'm in the nexus mods server atm, same username