New crisis on horizon: Mod Menu Category Formlist Cap Bug?

[vac333]

I am very new to modding came across this link on the AWKCR page while looking for deep explanation to the KW cap.

I have been working on a compilation of mods (over 320 mods), conforming them to AWKCR and SK. When I was running all these mods with scratched together patches for AWKCR and SK, all craft-able items shows up correctly, but the mods for clothing/armor where messed up. in game I would see 3 lining options for a unique vault suit and when I would add a lining mod, the mod would show up in all three slots no matter which slot I added the mod to. Is this an example of what is discussed here? Hope it is, either way, I will be watching here for the fixed results. I have a big project I would like to complete :smile: Thought I was good just conforming to AWKCR and SK. Also,, I was told that the cap of KW in a category was 255, obviously that is not correct?

[VIitS]

When I was running all these mods with scratched together patches for AWKCR and SK, all craft-able items shows up correctly, but the mods for clothing/armor where messed up. in game I would see 3 lining options for a unique vault suit and when I would add a lining mod, the mod would show up in all three slots no matter which slot I added the mod to. Is this an example of what is discussed here? Hope it is, either way, I will be watching here for the fixed results.

Not sure about the rest of your post (I think the cap is much smaller than that, but not sure), but this issue is a result of duplicate entries in the "APPR - Keywords" field. The easiest way to check a particular armor record is to look at the FormIDs for the keywords in that list, and see if there are any duplicates. Since that list doesn't auto sort, it can be very easy to make duplicates like that if you aren't paying attention to the specific entries.

 

One thing to note: you only mentioned AWKCR, so it probably isn't relevant, but if you are also using Armorsmith Extended, that mod uses a new lining keyword. Just combining all the entries in the APPR field would give you two lining options, but they would be seperate (so it presumably isn't related to the issue you are having).

[vac333]

 

When I was running all these mods with scratched together patches for AWKCR and SK, all craft-able items shows up correctly, but the mods for clothing/armor where messed up. in game I would see 3 lining options for a unique vault suit and when I would add a lining mod, the mod would show up in all three slots no matter which slot I added the mod to. Is this an example of what is discussed here? Hope it is, either way, I will be watching here for the fixed results.

Not sure about the rest of your post (I think the cap is much smaller than that, but not sure), but this issue is a result of duplicate entries in the "APPR - Keywords" field. The easiest way to check a particular armor record is to look at the FormIDs for the keywords in that list, and see if there are any duplicates. Since that list doesn't auto sort, it can be very easy to make duplicates like that if you aren't paying attention to the specific entries.

 

One thing to note: you only mentioned AWKCR, so it probably isn't relevant, but if you are also using Armorsmith Extended, that mod uses a new lining keyword. Just combining all the entries in the APPR field would give you two lining options, but they would be seperate (so it presumably isn't related to the issue you are having).

 

yes it was with AE and only single AE APPR entries, matter of fact, I compared the AE vault suit to a generic vanilla standalone and just copied over, but the vault suit was just example, it was happening to many pieces of clothing/gear, not just what I created, no way for me to check specifics, having 320 + active mods became tedious to maintain the load order with 243 plug-ins, so i trashed it to make room for my current project.

thank you for your input

[VIitS]

It's a viable idea. The only problem would be what if someone used the same combination of keywords. Then the mods for both items would show up for both both items when modding them. It would work best if combined with a condition in the recipe for the OMODs that would limit the mods to only show up for the correct item. Luckily item conditions work with perk conditions for item mod recipes, even though they don't work together for item crafting recipes.

As far as a thread with a detailed discussion of how they work, you're already here. There's some more information that you could learn from if you look at the AE tutorial on how to make an AE patch.

I'm working on a mod for mod weapons atm that puts them all on a shared ma keyword instead of them each having their own. It's in the testing stage atm. Still have a little polishing to do to get all the VIS tagging working properly, and some more game testing to make sure the leveled list integration I set up is working as intended. But it shouldn't be too long before I release it.

Just want to confirm something: if a vanilla keyword isn't referenced by anything, it won't count towards the cap, right? I'm currently in the process of trying to make the Kerrigan Color Changer useable (currently uses 15 new ma keywords and an ap keyword), and I was planning on using combos of vanilla keywords. After building reference info for Fallout4.esm, I found there were about half a dozen unused vanilla ma_ keywords. If I understand things right, using those keywords would be no different from making a new one.

 

Edit: Also, does using a Keyword for the "ModdedItemHasKeyword" conditional add to any known keyword caps? My first instinct is to say no, but I have learned not to trust my understanding of the keyword bugs.

 

If it wouldn't contribute to the mod menu category cap, using new Armor/WeaponType__ keywords on the new armor/weapon records, and then using the "ModdedItemHasKeyword" conditional might be a good workaround. It definitely works for limiting the OMOD to a specific item, but I don't know if it contributes to the keyword cap (or hell, maybe excessive use of this method will result in a brand new keyword cap bug).

[Gambit77]

@VlitS

"Just want to confirm something: if a vanilla keyword isn't referenced by anything, it won't count towards the cap, right?"

I don't think that's the case. I think they always count whether they are used or not. So I think that using one of those would not add to the count.

 

"Also, does using a Keyword for the "ModdedItemHasKeyword" conditional add to any known keyword caps?"

This is used mainly (only?) for dn keywords for dynamic naming. So there a small number of these that define what naming rule is used. And then there is more of these in the omods as triggers for the dynamic naming rules. Excessive use of these could probably lead to a brand new keyword cap bug.

 

It's probably safer to use a different conditional, like GetItemCount or GetEquipped for further filtering.

 

You should probably talk to the SynthCAST guys. They pulled off a color changing mod with no ma keyword footprint. I took a look at it but didn't fully understand why or how it worked, but it did.

 

@Vac333

It sounds like you have this bug. Usually when people get it, when I've made myself have it, the mod slots usually just disappear, but I think that the weird doubled/tripled up appearance of the mod slots is probably just another manifestation of the same issue.

Edited March 7, 2016 by Gambit77

[VIitS]

@VlitS

"Just want to confirm something: if a vanilla keyword isn't referenced by anything, it won't count towards the cap, right?"

I don't think that's the case. I think they always count whether they are used or not. So I think that using one of those would not add to the count.

 

"Also, does using a Keyword for the "ModdedItemHasKeyword" conditional add to any known keyword caps?"

This is used mainly (only?) for dn keywords for dynamic naming. So there a small number of these that define what naming rule is used. And then there is more of these in the omods as triggers for the dynamic naming rules. Excessive use of these could probably lead to a brand new keyword cap bug.

 

It's probably safer to use a different conditional, like GetItemCount or GetEquipped for further filtering.

 

You should probably talk to the SynthCAST guys. They pulled off a color changing mod with no ma keyword footprint. I took a look at it but didn't fully understand why or how it worked, but it did.

 

 

The reason I thought it would only count if used is because the game seems to be perfectly fine with you using keywords as any type regardless of the naming scheme. Back when the only keyword cap known was the category menu cap, I used an ma_ keyword as a build category keyword, IIRC (might have been something else, but it definitely was using keywords for different categories than intended). That made me think that, for whatever array is filling up with keywords and causing this bug, what matters is what keywords are used in a particular manner and not the name of the keyword.

 

A quick glance in FO4edit shows all the ma_ keywords have TNAM - Type "Unknown 5", the ap_ keywords have 2, and the category keywords have 9. I guess that is probably related to how the game loads keywords, and maybe after that it looks at what keywords are used in what fields (i.e. it would then see if you used a ma_ keyword as if it was a category keyword). If that is the case, then the unused vanilla ma_ keywords would be good to use, I guess.

 

Strangely enough, I hadn't actually notice its use for dynamic naming (looking at the INNR records, it would make sense for it to be using the function, so I guess the it just isn't readable by FO4Edit). I first noticed it as a possible conditional when looking at the vanilla COBJs for OMODs, and saw it used in COBJs for both Laser Musket receivers and every synth armor material OMOD. Looking a bit more shows it also being used for all the non-helmet material OMOD recipes, It seems to be using it to limit a recipe to the particular size (Light/Medium/Heavy) the armor is. Some quick math shows about 200 COBJ records using the ModdedItemHasKeyword conditional, with 4 different keywords (3 sizes and laser musket). A quick estimate of how many combined dn_ / Has_ keywords used in the vanilla INNR records looks to be well over 200 separate keywords.

 

The reason I want to use ModdedItemHasKeyword is because it is just so much better than either of those (for the purpose of properly limiting OMODs). GetItemCount means things will show up for two armors/weapons using the same ma_ keywords if you are carrying both in your inventory, and GetEquipped means you have to exit the workbench, change what you have equipped, and use the workbench again if you want to mod something else. It would be fine if the weapon/armor workbenches let you change what you have equipped like the Power Armor workbench does (that functionality would be nice even without the benefit of being able to use GetEquipped, but I assume it would require scripting, so it isn't something I can do right now).

 

I'll definitely take a look at the Synth CAST mod, thanks for the suggestion. Hopefully it'll let me fix things without having to resort to mesh/texture edits.

 

I found that the DX Courser Power Suit mod actually does it the way I would prefer (it has the glow separated from the base texture, letting a bgsm replace just the glow map, whereas the Kerrigan armor doesn't). It would let me reduce the number of OMODs (and related COBJs) to 26 (15 base textures and 11 glow options) down from 165, and completely eliminate the need for ma_ keywords or the ModdedItem conditional. Unfortunately, looking at the relevant textures from each mod makes me think I'll have to either do some precision editing of the UV map (and even then I'm not sure my idea for that would work) or require me to edit the dds files, which is something I haven't got into yet.

[JonathanOstrus]

 

You should probably talk to the SynthCAST guys. They pulled off a color changing mod with no ma keyword footprint. I took a look at it but didn't fully understand why or how it worked, but it did.

 

 

Is this this mod you're talking about? It doesn't look like it handles color changing. Only the ability to have unique colored items. Kinda like how the vanilla game has different colored miner helmets but you can't change or choose them.

[Gambit77]

@SlapMeSilly

That's not the one. It's Synth Armors and Uniforms - Standalone Mega Pack - C.A.S.T by Echoes56560 and MaaroTakai And it does do color changing. It's the CCCA of synth armor. The colors are fully customizable at the armor workbench. But like I said, I don't fully understand why it works. Looking at it, it looks like it wouldn't work properly, but it works as intended, so it's some genius that I just can't make out.

 

@VlitS

I just uploaded Weaponsmith Extended. Could you take a look at what I've done for filtering the OMODs and let me know if you think something else would be more effective.

Edited March 8, 2016 by Gambit77

[JonathanOstrus]

@SlapMeSilly

That's not the one. It's Synth Armors and Uniforms - Standalone Mega Pack - C.A.S.T by Echoes56560 and MaaroTakai And it does do color changing. It's the CCCA of synth armor. The colors are fully customizable at the armor workbench. But like I said, I don't fully understand why it works. Looking at it, it looks like it wouldn't work properly, but it works as intended, so it's some genius that I just can't make out.

 

@VlitS

I just uploaded Weaponsmith Extended. Could you take a look at what I've done for filtering the OMODs and let me know if you think something else would be more effective.

 

Took a quick look at the AWKCR esp they have. Unless I'm mistaken it adds 9 ap style keywords (without the ap_ prefix), 2 of which are not used.

 

I think I understand your confusion about why it works, since they don't add any of them to the APPR section of the ARMO records. They do have the ma_ keywords on them and those are in the MNAM field of the OMOD.

 

So unless I'm so sleep deprived that my brain ain't working, it seems they do what we all do, except not putting in APPR references.

[VIitS]

 

@VlitS

I just uploaded Weaponsmith Extended. Could you take a look at what I've done for filtering the OMODs and let me know if you think something else would be more effective.

From what I am seeing, you used the ma_ keyword to make the new OMODs only show up on modded guns, and then used the "GetEquipped" conditional on all the COBJs to limit them to only showing when you have the relevant weapon equipped. Barring the use of the ModdedItemHasKeyword conditional I already suggested (which, as you said, could potentially result in another keyword cap bug if used frequently)*, the only thing I can think of is maybe using FLSTs for the GetEquipped reference.

 

Whether or not that would work depends on the way it gets treated (I'm assuming it would just check if you had one item on the list equipped, but it's possible it would require you to have them all equipped). On it's own it wouldn't be useful, but if you added more (vanilla/AWKCR added) ma_ keywords to the OMODs, used together it could allow a little more flexibility in crafting mods without running into the problem of two mods inadvertently using the same keywords. Of course, then you run into the problem of making the FLSTs. Since most mods only add a single weapon, the FLSTs would have to either be made by each person (which the majority of mod users wouldn't have a clue how to do) or would require a s#*!-ton of compatability patches. I guess that would work if you had a list of compiled patches on the Weaponsmith Extended page like you do on Armorsmith Extended, you would just need to add the FLST to the patch. And using the Equal to/OR for the conditional type would make it so it would still work if the person didn't have the patch with the FLST without requiring you to edit the COBJ in the patch (assuming it was made using your infrastructure/guidelines). If nothing else, the FLST idea would probably work well for armor mods, since those often have a bunch of armors, so you could have a single FLST for all of the armors made by each author. Combine that with properly vague-yet-descriptive-enough categories, and you could use the same ap_ keywords for a hundred different mods without having to craft (for instance) texture changes under the "utility" category. While your current armor system works pretty well, a "GetEquipped" conditional pointing to an FLST would allow any armor to use OMODs for different texture versions instead of having each one a separate armor, all using just a single ap_keyword. You could even re-purpose vanilla lining keyword AE replaced for that purpose, so it wouldn't add to the ap_ keyword count.

 

Alternatively, instead of FLSTs you could use the crafting grenade idea DDproductions used for his buildable castle and flag mods (instead of checking if you have the relevant weapon, it checks if you have a certain grenade equipped, and only enables the recipies if you do). You could use either vanilla grenades or new ones (to reduce the chance of someone seeing the wrong thing because they happen to have a grenade equipped), and a set of guidelines/list of mods using the infrastructure could help reduce the chance of two mods using the exact same ma_ keywords and grenades. The advantage of this method over FLSTs is that making two mods work together "in the same list" (i.e. using the same grenade) wouldn't require any compatability patches, and if a compatability patch was needed it would just need to change the referenced grenade, so the compatibility patch wouldn't actually need to have multiple masters. The disadvantage is, of course, the need to carry different grenades for crafting (although you could, again, use "Equal to/OR" condition types so you can also mod something if you have that weapon equipped but don't have the grenade).

 

One question: if all the mods for a weapon have the "GetEquipped" conditional, does it not show up in the workbench unless you have it equipped? If it shows up anyway, the only thing needed to make your current method perfect is a script that allows you to equip the selected weapon/armor within the workbench (like the Power Armor station does). Honesty, I don't understand why they didn't include that functionality from the beginning. I guess it would probably need to include a bit in the script that transfers an item from the workbench inventory to the player's inventory, since most of the time most of the weapons/armors that you can see are stored in the workbench (unless you cranked up the carryweight to ridiculous levels like me because you have a compulsive need to loot every single thing you can possibly loot).

 

*I honestly don't think there would be much of an issue using that conditional. Yes, those keyword types are used for dynamic naming, but with the shear number of dn_ keywords people who include dynamic naming add to their mods I think we would have seen that keyword cap several months ago.