Mod Compatibility List for EET

[K4thos]

Faiths and Powers has been added to the list. Not sure why it wasn't there in the first place (maybe I forgot to paste it back when I rearranged alphabetical order recently - sorry, if that's the case). Coming forward I think the more viable way to keep the list updated is converting it to HTML file hosted on Github with free permission for everyone to edit it (pull requests no needed). I'm planning to do it in the near future.

 

Also moved ToDG from section 3 to 2 (it has native compatibility for some time now)

 

edit: the list from first post has been moved to Github repository with free access to everyone (simply click "edit this file" button directly in the browser. The change should show up immediately unless I messed up permissions settings). It can be viewed via this link.

Edited August 17, 2017 by K4thos

[lynx]

subtledoctor: do you see the difference with the first post? There you said you tried *everything*, but now it's clearer that you just don't want to contribute. And you seem to rather keep projecting that Roxanne is incapable of a sensible discussion. :s

 

"anything but civil"

[Roxanne]

edit: the list from first post has been moved to Github repository with free access to everyone (simply click "edit this file" button directly in the browser. The change should show up immediately unless I messed up permissions settings). It can be viewed via this link.

Making it easier for modders/mod maintainers to contribute to EET is certainly a good move.

 

Just a remark

- in order for BWS to support EET, it becomes even more crucial now to provide such updates to BWS as well.

Ideally this is done via a pull request containing the details of the mod/update, its components, conflicts, dependencies, and sequence requirements.

Otherwise there are still people around willing to help with such an update, but the data needs to be provided in order to create correct BWS configuration. There is no hidden magic mechanisms that gets the data from the list into BWS

[Jarno Mikkola]

subtledoctor: do you see the difference with the first post? There you said you tried *everything*, but now it's clearer that you just don't want to contribute.

There's a difference between wanting to and being able to... the fact that there's no information on how to properly contribute is likely a big factor in this. It's just that you don't listen what you are told about.

For example, I could go and just wreck havoc in the Github repository linked above, by for example editing the whole thing, after all, it's just a bot a way from being ruined... but I don't want to be a dick about it, so I don't.

Edited August 17, 2017 by Jarno Mikkola

[lynx]

That's why it's great that it is under version control — any malice is easy to detect and revert.

 

There's plenty of information on how to contribute to BWS; how do you think Roxanne, jastey or me started?

[Jarno Mikkola]

You... Maybe you read a project that included buhtig's details and then moved to use it in GemRB project. Then moved to throw your knowledge to other projects in the said setting. It's not hard to use the Notepad and weidu to do things if you know what they can do and have known examples...

 

But try to get a person to digest this file without knowing what the coding it's based upon... and how it's used. That and then go over all the other files that need to be changed/not-changed to include just this. I myself think that that's deep enough swamp to call people upon when the tool begins to excommunicate mods that are known to be compatible. Without any notice.

 

And by the by, how about these:

"+EET mods not approved by K4thos F=D:Fade(-)|Faren(-)|FR_ROV(-)|fullplate(-):BG2EE" the fullplate and steel won't modify the new items, and FR_ROV is not BGT nor likely EET compatible, but what about the rest ?

[lynx]

That's what docs are for, of course banging your head against the code directly is harder.

[Roxanne]

That's what docs are for, of course banging your head against the code directly is harder.

This whole discussion is really pointless because it changes nothing until possible BWS successor appears..

Facts are that BWS stands as it is, with no further development done.

 

It is anybody's choice to maintain it or part of it or ignore it.

Some modders still maintain their contributions to those games they deal with.(mainly EE games for the last 3 months)

There is still documentation and help here or on Spellhold if anybody wants to put their contribution to it.

Nothing else to be said about the case.

[Roxanne]

edit: the list from first post has been moved to Github repository with free access to everyone (simply click "edit this file" button directly in the browser. The change should show up immediately unless I messed up permissions settings). It can be viewed via this link.

 

The edit works as a pull request. I can directly modify the list (I tried to update Sandrah version number). However, for the change to become active it needs to be accepted and merged by K4thos. I can either work directly or branching it to my own repositories, there is no difference.

 

So modders/maintainers can do all the editorial work on the list, but it will not show for others until approved.

 

What is "edit this file" for the owner, appears for others as "edit this file in your fork of the repository".

Edited August 19, 2017 by Roxanne

[SCO]

BWS simply needs to be replaced. Various people wrote good suggestions for it. I for one think that the rules on it should be translated to native WEIDU tp2 directives of the mods, put on the fix pack, or another 'verificationpack' - if upstream doesn't accept patches - and optionally verified by weidu itself with a command.

 

Then it would be pretty easy to replace it. The parts that are actual code and verification for EET, BGT etc, can be coded elsewhere better, it's this crucial feature and data that needs to be preserved.

I was thinking of:

weidu --verify [listofselected (mod_tp2, components)] (mod_tp2,component)

 

which outputs all errors for the 2nd argument. Precedence verifications like 'requires' only verified if the 2nd argument is also part of the first list. If the second argument doesn't exist, output all errors.

 

The directives for the tp2 would be 'requires this#component mod2#component' (this mod component requires mod2 component), 'requiresoneof this#component mod4#component mod5#component' (this mod component requires mod4 or mod5 component) and 'conflicts this#component mod3#component mod4#component justificationstring' (this mod component conficts with mod3 and mod4 component for X reason).

 

Component would be optional in conflict but not in requires or requiresoneof (in order to be able to forbid completely mod combination. Not sure if this is needed).

 

There are things this wouldn't sort correctly, like how the biffpack has to go after all mods or the fixpack before all mods - and that these verifications should be done after installing the 'verificationpack', but before installing the rest, but that kind of stuff can cheated (installing 'verificationpack' first) or left to users (the sort order).

 

All the BWP is sustained on a fixed sort of mods anyway.

Edited August 20, 2017 by SCO

[Jarno Mikkola]

BWS simply needs to be replaced. Various people wrote good suggestions for it.

Well, as an expert, you are free to do that of course. So go ahead. As it sounds like you have already considered everything and you just have to make it work, so chop chop.

[SCO]

Who wants to do work on weidu itself? Honestly.

 

For posterity, and because i don't like to only bitch (in spite of not being able to install BWS at all, because i'm on linux) this is my strategy to make a verification script work if weidu gets the ability to verify compatibility constraints on a list of tp2.

 

1. download the mod tp2 file in order not to have to download the whole mod. This only really works for github or similar mods, but i'd gladly be restricted to that over the jungle of terribly packaged mods nowadays. Github has a ways to get the raw file from a repository, and no, it doesn't need a cookie (though the 'obvious' way does).

2. apply the patches. It's possible to use this to filter the right part of the diff (only the tp2 file), so patches for the constraints can go right on the fixpack, even only having downloaded that single file and the normal fixpack diff applying to more files. Another possibility is to create a dedicated 'validationpack'.

3. have some gui for the user to import a sorted mod list and select components and be warned every time something doesn't blend. Primary GUI programming. Every time a checkbox changes run weidu on the temporary tp2 etc.

4. continue on a wizard, actually download mods, install etc. Pretty simple with github mods, since it's just cloning them.

 

The main code complications are the differences between BGT, EET, tutu and the normal games. This would be a opportunity to get rid of code like 'search for savegames to find language' like it's done for EE games even if they don't need this etc. If cloning doesn't work, there is a way to download zips without the .git files at the 'cost' of having a unzip at the end.

 

Possible complication with repository : non standard dirs or extra executables, just don't do that when you upload the mod to git

Possible complication with github zip: revision name gets appended to extraction directory, possible to avoid with simple heuristic.

Edited August 20, 2017 by SCO

[Jarno Mikkola]

Who wants to do work on weidu itself? Honestly.

The whole community... if you go and actually look at the above posters credits here, they have (nearly) all done something towards the weidu's version updates.

[K4thos]

The edit works as a pull request. I can directly modify the list (I tried to update Sandrah version number). However, for the change to become active it needs to be accepted and merged by K4thos. I can either work directly or branching it to my own repositories, there is no difference.

that's a bummer. I don't know if it's possible to make the repository completely open. Maybe someone more experienced with Github will be able to help.

 

I've updated the link for html viewer into: https://rawgit.com/K4thos/EET-Compatibility-List/master/EET-Compatibility-List.html

This one makes changes visible within minutes (previous one was slower)

Edited August 20, 2017 by K4thos

[SCO]

I think you should simply add the 'people you trust' who are collaborators to the list of people who can merge pull requests. In effect, this is Roxanne. If someone else wants to take up maintenance, say a author, they can ask to be added.

 

It's on 'settings->collaborators' and add her github account id or email if you own the project, iirc. I don't know if other people can be made owners, or if normal collaborators can invite others, or if that requires them to fork the project into their own page.

Edited August 20, 2017 by SCO