324 replies to this topic

[WilliamImm]

In response to post #15401390. #17105624, #17106969 are all replies on the same post.

Well, I actually was part of the group who made Requiem-compatible plugins for Soul Gems Differ. We updated all the gold and weight values to match Requiem, and we set the proper vendor keyword for the Black Soul Gem (filled/unfilled). That should keep this mod's balance with Requiem.

You can pretty much go and check it with TES5Edit right now. We should have made the relevant changes to make it fit within Requiem.

[WilliamImm]

In response to post #10939089. #10950544, #11015731, #11089542, #17076949 are all replies on the same post.

Investigating the Requiem scripts that block armor switching, I found you did manage an exceptions list for items that shouldn't be blocked (like the Werewolf and Vampire Lord special armors). We could update the Dual Sheath Redux patcher to add it's new armor records to that list. However, it's implemented as a object array property, which is quite convoluted to add to it via the patcher, and it would require modifying the quest itself in order to do so.

What I'd suggest instead is to move the armor switching exceptions to a separate FormID list (say, REQ_Combat_ArmorSwitchExceptions), and have the REQ_PassiveArmorTraining script reference that. That way, we can easily modify the patcher to add our new "armor" records to that list. End result: You don't have to enable armor switching in combat for Requiem in order to have Dual Sheath Redux work properly.

[ogerboss]

In response to post #10939089. #10950544, #11015731, #11089542, #17076949, #17109314 are all replies on the same post.

I think this will become rather awkward in the long run for a few reasons:

1. I don't know if FormLists have a maximum length. If so, this becomes really nasty because membership tests on formlists do not include nested formlists. That means the whole iteration has to be done on the Papyrus level, rather the more efficient native function level.
2. I don't know how many new objects that need to be excepted DSR creates. If I assume one fake-item per real weapon/shield, this might amount to quite a lot of items, potentially degrading performance again.

I think I have a better solution to offer:

Instead of using a hardcoded exception list, Requiem could use a new keyword to identify exceptions. DSR could then probe the existence of Requiem in the load order and if found, fetch the keyword and add it to all its new armors that need it.

Like this, the effort is always one keyword-check, regardless of how many items you add.

[ogerboss]

In response to post #15401390. #17105624, #17106969, #17109119 are all replies on the same post.

As I wrote in the main topic's sticky post, I am on a conference far away from my Skyrim installation.

Please don't take the following paragraph personal, it holds in all generality.
Even if I would be at home I would not do it. The purpose of the compatibility list is to be a community-based project, from the community and for the community. I personally do not need this list, but since it is often requested from the players, I am willing to assemble and distribute such a list (a limited effort) with their input (the real effort).

I don't have the time to investigate every single patch/mod myself. If I would do so, I could write the patches myself as well. But my time is limited and projects like Requiem 1.8 are already incredibly time-consuming. If I now start to grant your patch a special state, the next modder might ask me why his word is of less value than yours and he has to rally his lazy users to confirm that his mod/patch works fine with Requiem, or why I don't do a Tes5Edit comparison myself. (Which does not reveal everything, as you surely know.)

The easiest way is to just poke your users to write a small confirmation about your plugin's state here.

I hope you can appreciate or at least understand my reasoning.

[WilliamImm]

In response to post #10939089. #10950544, #11015731, #11089542, #17076949, #17109314, #17111204 are all replies on the same post.

I like the keyword idea, through one suggestion I'd make is to implement the keyword into Update.esm intentionally. Doing this lets other mods use the keyword (and inject it themselves) without imposing a direct dependency on the mod that does things involving the keyword. That will make things even simpler for Dual Sheath Redux, as we can just inject the same keyword into our patch, use it on our items, and it would only come into play if Requiem is installed as well. This is notably done in kryptopyr's Weapon and Armor Fixes Remade, Complete Crafting Overhaul Remade, and Eckss's Guard Dialog Overhaul - this allows other mods to have their equipment garner additional behavior with those mods, yet no dependency on them is introduced.

The only real problem with that is you should watch for used injected FormIDs - WAF uses 01AF, CCO uses 01CC, and SPIKE mods use 01DA. If you avoid those, you should be quite safe with what FormID you choose for the keyword. Hell, doing this would let other mod bypass the no-switch armor in combat feature. (Moonlight Tales werebear skin, anyone?)

[ogerboss]

In response to post #10939089. #10950544, #11015731, #11089542, #17076949, #17109314, #17111204, #17112869 are all replies on the same post.

I have no clue about "implement the keyword into Update.esm intentionally", might you elaborate on this one?

From the current point of view I think that a normal keyword approach suffices, for DSR it should not make any real difference, since you have to rebuild the SkyProc patch anyway when your mods change. Thus there is no real difference in having a direct Requiem-dependence or not, or do I miss something here?

And with respect to other mods, I assume that the number of mods that need such a keyword but have otherwise no need for a real compatibility patch is rather limited (only Wearable Lanterns comes to mind, which also could use a real patch to merge vendor lists). Given that your suggestion sounds quite adventurous so far, I am not too convinced of this proposal. So please enlighten me about the technical details of your suggestion, so that I can make a better justified assessment.

p.s. It might be a good idea to continue this conversation via private message. I don't think the majority of the readers is interested in these details.

Edited by ogerboss, 02 August 2014 - 05:20 AM.

[toxicnova]

In response to post #15010071. #15153212 is also a reply to the same post.

I'm using it with the requiem patch from Azirok and it seems to work well. I hadn't found anything strange.

[heckur]

In response to post #11226220. #11227655, #11279818, #11282540, #11326648, #17076389, #17106794, #17107139 are all replies on the same post.

Audio Overhaul for Skyrim version 1 also changes the sounds of spells, but does not affect the other spell effects. I presume AOS does this by changing the sound files instead of changing the references in the spell itself. I don't know about AOS 2 though.

[madmortem]

In response to post #15010071. #15153212, #17181589 are all replies on the same post.

Confirming as well. Works pretty well with the patch

[teemul]

Mod Name: Acquisitive Soul Gems
Nexus ID: 5312
Compatibility Status: full
Compatibility Notes: Might need to be loaded after Requiem. Works beautifully. Creates filled soul gem base items which can be used for Requiem crafting (staffs). I've used the mod since an early Requiem version, so I'm not 100% how much has been incorporated to base Requiem by now. Might overwrite gold values of soul gems when installed after Requiem.
Authors: bluedanieru

Edited by teemul, 07 August 2014 - 07:05 AM.