Jump to content

Mod Compatibility List for EET


Recommended Posts

As always, I don't like the idea of giving anything "priority." Just give users the relevant information and let them make a choice.

Problem is that the BWS is built that way. If you identify a problem or conflict, the order in which you present the problem is taken as a *preferred* sequence. Unless you change the code, which nobody can anymore, this is what we have to deal with.

 

Whenever you highlight/notify/present something especially to the user, the tool presents a default solution. The only other method is to just add notes into the descriptive texts which you only read if you select a mod and want to see further information. But this method is as effective as putting the stuff into a readme...

 

PS - my personal assessment of IR since the EE game went to v2.3 is that is no longer compatible as a whole. But I was overruled in this.

Link to comment

I just checked again and apparently IR main component does *not* affact mod added items. (I must have looked at a mod item that was also out of date regarding the shaman flag.)

 

That means it would be fairly simple to just fix all the overwritten items and have BWS install them as a fix, I think?

Edited by Ulb
Link to comment

my personal assessment of IR since the EE game went to v2.3 is that is no longer compatible as a whole. But I was overruled in this.

Lots of people play IR on v2.3 and seems perfectly satisfied with it. I always install it. So to say it is "not compatible" seems like an... extreme overstatement. It is a very well-regarded and popular mod... I think if BWS started telling people "this is not compatible with your game" a lot of prople would be unhappy. Plus it's not true, so...

 

I am not aware of how BWS conflict-handling works. I just suggest that it be handled in the most objective way possible, without personal opinion or favoritism. That's just a general pronciple of course. But more specifically: I haven't seen any specific mod conglicts mentioned here - only a basic bug in IR. Bugs /= mod conflicts.

 

IMHO the best thing here is to make a simple hotfix to fix shamans with IR items. People can use the hotfix for now, and eventually IR can just incorporate the code.

 

I can't do it now, have no access to a computer. But it's not a hard fix.

 

We're only talking about Shaman usability, correct?

Edited by subtledoctor
Link to comment

I am not aware of how BWS conflict-handling works. I just suggest that it be handled in the most objective way possible, without personal opinion or favoritism. That's just a general pronciple of course.

BWS conflict-handling can be affected by personal opinion and/or favoritism because it was much easier to design/code it in such way and it gives much more control over mods/components. Also it allows for automatic conflict solving. Lucky for use, there wasn't any bad conflicts or disasters for all those years.

 

Since we talking about this matter, I've designed and coded a new, unbiased and opinion free conflict system. Simple example:

 

BWS Conflict Handle:

C:A(-)>B(-)
C:A(-)>C(-)
C:B(-)>C(-)

Will produce conflicts: A is preferred to B, A is preferred to C, B is preferred to C

Outcome: mod A is always preferred if we solve conflict automatically.

 

Such conflict definition/handling is also a guarantee that every BWS installation will have the same mods/components if the player decide to solve conflict automatically - that's great value for BWS maintainers.

 

New Conflict Handle:

A>B>C

will produce conflict: You have to choose A or B or C because all those mods have conflict with each other.

Outcome: Player is forced to choose one of those 3 mods. (Automatic conflict solving is possible but it depends by other factors)

 

My general feedback about this matter is:

 

From the players perspective, all what they way is to click single button and have all conflicts/dependencies solved. In such case, you can't have automated and unbiased Conflict Handle System unless you introduce randomization for one of the steps. So you are given a choice: sacrifice always the same mod/components list when player choose to solve all conflicts automatically or have biased conflict definitions which can be influenced by personal opinion and/or favoritism. So far the later works pretty good and we will never know how many mega-mod installations was saved from game-breaking bugs because conflict solving produced always the same results for the same mods.

Edited by ALIENQuake
Link to comment

From the players perspective, all what they way is to click single button and have all conflicts/dependencies solved. In such case, you can't have automated and unbiased Conflict Handle System unless you introduce randomization for one of the step. So you are given a choice: sacrifice always the same mod/components list when player choose to solve all conflicts automatically or have biased conflict definitions which can be influenced by personal opinion and/or favoritism. So far the later works pretty good and we will never know how many mega-mod installations was saved from game-breaking bugs because conflict solving produced always the same results for the same mods.

True, but you could make an option that allows complete automization of conflick resolution, and then no automation where the player is allowed to resolve the possible conflicks with help of the BWS, and even option that says "I can handle conflicts on my own", which will then just note which conflicks there are and has multiple ways to handle them. One being that "so what, install all of them that I don't remove". And then default it to the first, this ways the setup person needs to select the other ways to handle conflicts. Yes, essentially it's there already ... and you might want to allow selectable pauses into the component install list, especially before the EET_END, if it's not there already.
Link to comment

From the players perspective, all what they way is to click single button and have all conflicts/dependencies solved.

And you always have trued to give that to them... I think that's noble but possibly not for the best. I follow the age-old rule: "you can't always get what you want, but if you try sometimes, you get what you need."

 

Rather than clicking a sinhle button and hace everything done for them, let players be presented with information rekevant to their dedired sekection of mods. If they get 12 conflict notifications and have to click A or B 12 times... thise 12 infinitesimal movements of their ibdex finger are hardly a serious burden.

 

And of course you can give the option for sonething like "just solve all the conflicts for me" in a single click. And for peopke who like a certain combination of mods you can do curated settings, like there used to be - there, it is good to have favoritism, just be open about things and call it "Subtledoctor's Selection" instead of wannabe-semi-official-sounding "Recommended" and stuff like that.

 

But, we're talking entirely in the abstract here. BWS is what it is and it ain't gonna change. The main thing now, IMHO, is to maintain it as neutrally as possie and not do things like deprecate popular mods just because someone with admin access to the bitbucket repo doesn't like them...

 

my post in IR-R v1.12 thread has a starting point for you to check out and improve the code from.

I have the code sitting around somewhere. It's not complicated. Only need the time to throw it together.

Link to comment
and then no automation where the player is allowed to resolve the possible conflicks with help of the BWS, and even option that says "I can handle conflicts on my own", which will then just note which conflicks there are and has multiple ways to handle them

 

 

But you can do that already?

 

BWS shows you two conflicting components and you can either just click on slove conflict or decide which of the two you don't want and then have that one removed.

Link to comment

 

and then no automation where the player is allowed to resolve the possible conflicks with help of the BWS, and even option that says "I can handle conflicts on my own", which will then just note which conflicks there are and has multiple ways to handle them

 

 

But you can do that already?

 

BWS shows you two conflicting components and you can either just click on slove conflict or decide which of the two you don't want and then have that one removed.

 

You need to understand that someone who does not use the tool (due to not using windows) cannot know how BWS treats conflicts or expert mods or other such detail.

Not knowing does not mean you cannot post about it, it is the year 2018 on the internet, *alternative facts* are new (U.S.) standard these days.

Link to comment

Install it immediately after IR; it must be installed before any mods that change item types or the proficiency system.

Why ? It's it the same or even better if it's installed after all mods that add items are installed that contain items that Shamans should but can't use ?

Link to comment

 

Install it immediately after IR; it must be installed before any mods that change item types or the proficiency system.

Why ? It's it the same or even better if it's installed after all mods that add items are installed that contain items that Shamans should but can't use ?

Well, it uses the shortbow proficiency (105) to identify shortbows, and item type (5) to identify arrows. If some mod sets shortbows to use a different proficiency (there us a "3.5E" mod out there that puts all launchers under a single proficiency, and uses the freed-up proficiencies for feats), or sets arrows to a different item type, then running this hotfix afterward would fail to patch the correct items. Or if a mod allows druids to use bows, installing this afterward would undo that change.

 

It was designed specifically for IR, and it is going to be included in the IR main component; if other mods have problems, they or we can address those problems.

Edited by subtledoctor
Link to comment

Well, it uses the shortbow proficiency (105) to identify shortbows, and item type (5) to identify arrows. If some mod sets shortbows to use a different proficiency (there us a "3.5E" mod out there that puts all launchers under a single proficiency, and uses the freed-up proficiencies for feats), or sets arrows to a different item type, then running this hotfix afterward would fail to patch the correct items. Or if a mod allows druids to use bows, installing this afterward would unfo thst change.

 

It was designed specifically for IR, and it is going to be included in the IR main component; if other mods have problems, they or we can address those problems.

Yes, but there are other mods that are installed at a similar time as Item Revisions, now I am not telling to not put this tweak to a IR, I am telling that other mods need it too that are installed before the proficiency tweaks. This is just one of those, that IR can install as it's own component or as a part of the other patch components.

And by the by, I specifically used file names as the patch starters to limit the patch to past vanilla items that the IR has patched.

Edited by Jarno Mikkola
Link to comment

It was designed specifically for IR, and it is going to be included in the IR main component; if other mods have problems, they or we can address those problems.

Yes, but there are other mods that are installed at a similar time as Item Revisions, now I am not telling to not put this tweak to a IR, I am telling that other mods need it too that are installed before the proficiency tweaks. This is just one of those, that IR can install as it's own component or as a part of the other patch components.

 

I mean, it doesn't have to be installed right after IR. I specifically said before any other mods that change item types or proficiencies. All mods that add items should be installed before that point. So the best time to install it would be, say, immediately before CDTweaks. Or immediately after Might & Guile. Something like that.

 

But again, IF there are problems with other mods, best to identify them - no sense prescribing fixes for stuff that isn't broken. And if some mods install items that are broken, best that the broken things be discovered so that they can be fixed, rather than hiding them behind a patch for a different mod altogether...

Edited by subtledoctor
Link to comment
And you always have trued to give that to them... I think that's noble but possibly not for the best. I follow the age-old rule: "you can't always get what you want, but if you try sometimes, you get what you need."

Rather than clicking a sinhle button and hace everything done for them, let players be presented with information rekevant to their dedired sekection of mods. If they get 12 conflict notifications and have to click A or B 12 times... thise 12 infinitesimal movements of their ibdex finger are hardly a serious burden.

And of course you can give the option for sonething like "just solve all the conflicts for me" in a single click.

 

 

We are not at the point zero: there is already a tool which give players certain features so even if you create new, wonderful tool, if you don't include it's main features then people won't be using it. So automatic conflict resolution is a must-have from the players view. BWS already presenting conflicts for the players in order to give them a chance to choose what mod/component they prefer. And such button as you describe. But in order to make that button working, you must have biased conflicts to some extend.

 

And for peopke who like a certain combination of mods you can do curated settings, like there used to be - there, it is good to have favoritism, just be open about things and call it "Subtledoctor's Selection" instead of wannabe-semi-official-sounding "Recommended" and stuff like that.

 

That's more like player defined mod selections. They are also in BWS. But those selections was useless in the long term because DESIGNATED problem. The design of next BWS already include "player defined mod selections" as a replacement for build-in "Recommended". You know what next BWS needs in order to make this feature happen.

 

The main thing now, IMHO, is to maintain it as neutrally as possie and not do things like deprecate popular mods just because someone with admin access to the bitbucket repo doesn't like them...

This is not a problem because all bWS-related things are open source and open to modify. If you or someone else thinks that the conflict resolutions are biased or doesn't like them, he can fork whole project, call it BWS by X and do what he wants.

 

I appreciate you feedback because even if you request things which already inside BWS, you also point at design,solution,implementation which is far from ideal. My advice would be to focus on the fundamentals for next BWS rather than finding holes in it. As I said, i've spend lot of time to design and code new conflict system but I cannot make use of it without UUID/GUID. Or generally, a support from modders and weidu.

Edited by ALIENQuake
Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...