AAF and slot stripping?

[Trykz]

Okay, maybe not....

 

Is there a way to block AAF from stripping a *specific* slot, and not any others? My custom race uses two specific slots for custom parts that get locked onto the player. One works fine. AAF doesn't touch it. The other causes AAF to CTD the game during the gathering stage. I suspect it's because the part is locked onto the slot by a script, and AAF is trying to strip it. I need this to NOT happen.

 

TIA for any tips, suggestions, etc....,

 

Trykz

[EgoBallistic]

This is possible, but because users can modify the config files that control which slots AAF equips or unequips, a mod author can't guarantee that a particular slot will never be touched.

 

The better solution is to add a keyword to the items you don't want AAF to strip, and to make a protectedEquipmentData file that tells AAF not to remove items with that keyword.    This is the mechanism used to prevent AAF from messing with Devious Devices, Real Handcuffs, and similar.

 

Create the keyword, add it to the ARMO record of all the item(s) you don't want AAF to mess with, then create a protectedEquipmentData file in Data\AAF like so:

<meta title="MyModName_protectedEquipmentData.xml" version="1.0" dataSet="protectedEquipment"/>
<defaults />

<condition>
    <protectKeyword form="000F99" source="MyModName.esp"/>
</condition>

Now AAF will never strip any item with that keyword, regardless of what slot it is in.

[Trykz]

2 minutes ago, EgoBallistic said:

This is possible, but because users can modify the config files that control which slots AAF equips or unequips, a mod author can't guarantee that a particular slot will never be touched.

 

The better solution is to add a keyword to the items you don't want AAF to strip, and to make a protectedEquipmentData file that tells AAF not to remove items with that keyword.    This is the mechanism used to prevent AAF from messing with Devious Devices, Real Handcuffs, and similar.

 

Create the keyword, add it to the ARMO record of all the item(s) you don't want AAF to mess with, then create a protectedEquipmentData file in Data\AAF like so:

<meta title="MyModName_protectedEquipmentData.xml" version="1.0" dataSet="protectedEquipment"/>
<defaults />

<condition>
    <protectKeyword form="000F99" source="MyModName.esp"/>
</condition>

Now AAF will never strip any item with that keyword, regardless of what slot it is in.

I have NO idea what you just explained ?

 

The keyword part I get. The xml stuff is lost on me. Is it just a simple text file that I give the .xml extension? Or do I need something else to do it?

 

TIA,

 

Trykz

[EgoBallistic]

58 minutes ago, Trykz said:

The keyword part I get. The xml stuff is lost on me. Is it just a simple text file that I give the .xml extension? Or do I need something else to do it?

It's as simple as that.  Create a new text file in the Data\AAF folder, name it mymodname_protectedEquipmentData.xml, and structure the contents like I showed above.  Obviously you should change mymodname to something more meaningful, and the form ID and plugin name in the protectKeyword line need to match your mod.

 

Everything AAF does is configured using XML files.  It's a great system because each mod can include its own files with their own names, and AAF loads them all at startup and processes all of them.  You can have 10 different mods each with its own protected keywords, and AAF will handle all of them.  No muss no fuss no conflicts.  Animations, tag files, overlays, etc, all work the same way.

[Trykz]

18 minutes ago, EgoBallistic said:

It's as simple as that.  Create a new text file in the Data\AAF folder, name it mymodname_protectedEquipmentData.xml, and structure the contents like I showed above.  Obviously you should change mymodname to something more meaningful, and the form ID and plugin name in the protectKeyword line need to match your mod.

 

Everything AAF does is configured using XML files.  It's a great system because each mod can include its own files with their own names, and AAF loads them all at startup and processes all of them.  You can have 10 different mods each with its own protected keywords, and AAF will handle all of them.  No muss no fuss no conflicts.  Animations, tag files, overlays, etc, all work the same way.

By form ID you mean the ID of the keyword as displayed in the CK? Because I did that and it still CTDs. The form ID in the CK is "070B90B3". So I used "0B90B3* and it still CTDs. I'm starting to suspect it's going to come down to an issue with the mesh. Which is odd, because the script fragment equips and un-equips it just fine. Though it does it while in a menu ?

 

Thank you though. I appreciate all the help. And I got to learn something new ?

 

Trykz

[EgoBallistic]

1 hour ago, Trykz said:

By form ID you mean the ID of the keyword as displayed in the CK? Because I did that and it still CTDs.

Yes, the form ID of the keyword, and you are correct to strip off the first two digits.  I assume the * was a typo when you were typing the post?  It should be "0B90B3"

 

You might want to check the AAF Admin console to see if there are any errors involving that XML file.

[Trykz]

11 minutes ago, EgoBallistic said:

Yes, the form ID of the keyword, and you are correct to strip off the first two digits.  I assume the * was a typo when you were typing the post?  It should be "0B90B3"

 

You might want to check the AAF Admin console to see if there are any errors involving that XML file.

Yep. Typo. I'm notorious for them. And thanks again for the help. I stripped my character of the item in question using the console, and re-equipped a new one just in case. Before I equipped a new part, I tested AAF with a TH Pose and it worked fine. So the part is *definitely* the issue. I just can't put a finger on why. The script fragment has no issue equipping or un-equipping it at all. I'm thinking it might be the fact that it's a two part mesh. It's built from two individual meshes, so maybe that's why AAF is throwing a fit with it.

 

Anyway, I've taken up enough of your time with this. So again, thank you for all the help. I'd have never gotten this far on my own ?

 

Trykz

[Trykz]

@EgoBallistic,

 

I have one last question. Mostly because I figured out the issue with the part I'm trying to get working with AAF.

 

Is there any particular reason why AAF doesn't work with slot 59 (shield)? I found this when on a hunch, I tried switching the slot assignment on the armor addon and the armo forms. I mean, my script fragment doesn't CTD the game when it equips OR removes the part, yet AAF does. So why should AAF be having this issue? Or maybe I missed something about this being a known issue?

 

TIA,

 

Trykz

[EgoBallistic]

1 hour ago, Trykz said:

Is there any particular reason why AAF doesn't work with slot 59 (shield)? I found this when on a hunch, I tried switching the slot assignment on the armor addon and the armo forms. I mean, my script fragment doesn't CTD the game when it equips OR removes the part, yet AAF does. So why should AAF be having this issue? Or maybe I missed something about this being a known issue?

I'm not aware of any issues related to specific equipment slots. AAF loops through all the slot indexes from 0 to 44 (biped slots 30-61 + the weapon slots) and unequips the item if the conditions allow it.  None of the slots are treated special.

 

Are you saying that moving the item to a different slot allowed AAF to unequip it without issue?  That is really strange.  I would have to look at the item, its script, etc, to try and understand why this happens, as I can't think of a reason for it.  I contributed a fair bit of code to the equipment handling in AAF, so if you don't mind sharing this with me I would be interested in debugging it.

 

Edit: I just tested this, and AAF unequips/re-equips/copies items that are slot 59 no problem.  So there is something more going on here.

[Trykz]

4 hours ago, EgoBallistic said:

I'm not aware of any issues related to specific equipment slots. AAF loops through all the slot indexes from 0 to 44 (biped slots 30-61 + the weapon slots) and unequips the item if the conditions allow it.  None of the slots are treated special.

 

Are you saying that moving the item to a different slot allowed AAF to unequip it without issue?  That is really strange.  I would have to look at the item, its script, etc, to try and understand why this happens, as I can't think of a reason for it.  I contributed a fair bit of code to the equipment handling in AAF, so if you don't mind sharing this with me I would be interested in debugging it.

 

Edit: I just tested this, and AAF unequips/re-equips/copies items that are slot 59 no problem.  So there is something more going on here.

That's just it. I don't know for sure. My mod equips and un-equips the part silently, and while in a menu for both actions. I only know that with the part in slot 59, any attempt to run any kind of animation in AAF causes the the game to CTD during the actor gathering phase. I can't definitively say whether AAF is crashing the game because it's attempting to strip the slot or if it's some other reason. But I *can* definitively say that it only happens with AAF, and only when the part is in slot 59. I moved the part to slot 58, and then to slot 48 and the CTD no longer occurs, the gathering phase continues normally, and animations can be chosen and used normally.

 

The mod is my new Droids of the Commonwealth race mod. And the part in question is the custom fusion core part that the players gets access to at level 25. The part is in the file with each of the individual body type downloads. I can send you the patch (V1.0.1f) which uses the part via PM if you want to take a look. I don't want to post it on the open forum and have a bunch of people potentially causing damage to their setups since I don't really know what is causing the issue.

 

Let me know,

 

Trykz

[dagobaking]

With a CTD there might be a clue in the logs.

[Trykz]

5 minutes ago, dagobaking said:

With a CTD there might be a clue in the logs.

@EgoBallistic discovered it was a game engine issue, exacerbated by a setting in my mod. My concern was that it might be a critical issue with my mod, or even worse, an issue with AAF. Such a critical fault in my mod affects nothing other than my mod. Such an issue in AAF affects a LOT of mods, which was my bigger concern. Anyway, it's neither so we're all good. @EgoBallistic detailed it in more depth here.

 

Trykz

[SpicyNuggies24]

On 5/26/2020 at 7:44 PM, EgoBallistic said:

The better solution is to add a keyword to the items you don't want AAF to strip, and to make a protectedEquipmentData file that tells AAF not to remove items with that keyword.    This is the mechanism used to prevent AAF from messing with Devious Devices, Real Handcuffs, and similar.

 

So I made a custom protectedEquipmentData file for an outfit from another mod (TheKite's Vault Slavesuit mod if you're curious). It works fine for animations involving the player (when either my character or the character im banging is wearing the slavesuit), but anims involving just NPCs still unequips it. Any idea why?

 

Edited July 30, 2022 by SpicyNuggies24

[EgoBallistic]

13 hours ago, SpicyNuggies24 said:

So I made a custom protectedEquipmentData file for an outfit from another mod (TheKite's Vault Slavesuit mod if you're curious). It works fine for animations involving the player (when either my character or the character im banging is wearing the slavesuit), but anims involving just NPCs still unequips it. Any idea why?

 

Not sure, I can't reproduce that myself.  I tried it with that same outfit, with the line

 

<protectKeyword form="00115D" source="TheKite_VTS.esp"/>

 

and it worked as expected for NPCs in solo animations.

[Heinz01]

On 5/27/2020 at 1:16 AM, EgoBallistic said:

It's as simple as that.  Create a new text file in the Data\AAF folder, name it mymodname_protectedEquipmentData.xml, and structure the contents like I showed above.  Obviously you should change mymodname to something more meaningful, and the form ID and plugin name in the protectKeyword line need to match your mod.

 

Everything AAF does is configured using XML files.  It's a great system because each mod can include its own files with their own names, and AAF loads them all at startup and processes all of them.  You can have 10 different mods each with its own protected keywords, and AAF will handle all of them.  No muss no fuss no conflicts.  Animations, tag files, overlays, etc, all work the same way.

This is awesome

 

I used it now for the disguises from flashy Crime and Punishment. If someone wants to see how this has to look like, here is for raiders disguise. It simply uses the already existing disguise keyword from C&P for the nonstrip function (gunners would be 028887)

<meta title="cap_protectedEquipmentData.xml" version="1.0" dataSet="protectedEquipment"/>
<defaults />

<condition>
    <protectKeyword form="028886" source="Flashy_CrimeAndPunishment.esp"/>
</condition>

Now the disguises can be used to do some dirty stuff too (without that function everyone would turn hostile)