AL|EN

@subtledoctor If you point me to the file and add a quick info where I should put it, I can preform update via Fixpack.

It's rather not the case but maybe the game itself didn't exit properly and the baldur.exe process is sitll running in the background and locks file modification?

New version is up, no new features, rewrite using WPF. please test new version and report if it crashes/doesn't work. So...I have rewrite this application to use Windows Forms in order to remove Powershell dependency. It was nothing more but event-based programming app. Then I decided to rewrite it to use WPF just to learn new things and for fun. I use Themes, Commands, Threads, XAML and the rest of the modern ways to write applications. And it was a real enjoyment for me to work with "Windows GUI Frameworks". For beginner developer, who just barley start, editors, libraries, tools and design patterns were really good pieces of ecosystem. When you learn and use nice things, you do not want to give up on them because somehow you work doesn't feel so "great" anymore. I hope that I could find a solution which also offers all those great things which I've used but for cross-platform. If I will find a solution, I could put my effort to make this app as cross-platform.

After working closely with the creator of this tool for the past few months, posting ideals, hunting for bugs etc I can finally say that it's great piece of work which, qwerty1234567 has done! Great support for the community, thank you! When I started to showing github hosting benefits (which someone might find annoying) I didn't know about such project. But I feel in my bones that because of the nature of the github, some amazing things could be created. This one of the example if it. This tool takes painful process of translation mods and make it trivial! It is whole new level! I wasn't able to provide too much translations, but I corrected typos, mistakes etc and it was so easy! Also, updating translations for existing mods, when there are new components can be done instantly. I strongly suggest that every modder should use this tool, integrate his mods, even if it has few flaws and annoyances.

Yes, I bevile that it is reason why there wasn't any EET updates. Code changes must take patch changes into consideration and it's a waste of time and effort to do anything with EET/IWD-in-EET before patches will be introduced.

No, unless 2.5 will be released for BG1EE + BG2EE. Then we should expect return of the K4thos. Until then, please don't be depressed

Well, it looks very nice My only concerns is the future: adding Icewind Dale EE (IWD-in-EE) there is no place for the icon. Same for "theoretically possible IWD2-in-EE" and "PS:T". Do you have a concept where 2 additional icons are required? Futher feedback: - SoD icon is missing - "EET" label is not needed - "Enhanced Edition Trilogy" should be in one line

Well, current logo looks better if you ask me

Reagarding: 10300: Prevent Watcher's Keep statues from disappearing (in case randomisation gave them something) Readme doesn't mention about component redundancy by installing SCS/tactics. It would be better for players (and BWS because there was several reports BWS constantly make pause during installation. ) that they would not need to read tp2 weidu code in order to know that you don't need to install this component if corresponding components from SCS/Tactics are installed.

The new logo can be identical of the current one with "Enhanced Edition Trilogy" text. Or you own invention with BG1, SoD, BG2, ToB and IWD icons/logos combined.

Unfortunately not. Not an end of the world but I would welcome any decent and similar theme logo

1.3.0 - responsive "Change GUI to ..." operation Application is no longer frozen/suspended during "Change GUI to ..." operation and the user will receive feedback of the operation status during execution

Vanilla means "game without mods" for many many games out there: - Classic games without mods = vanilla - EE games without mods = also vanilla (for eg vanilla BG2EE ) - the "is modded?" covers both Classic and EE games That's is how I see it.

It will cause EET to fail. The "EET preparation: Fix ARE actor offsets" must not add weidu.log entry. Direct patching EET is to much work.

@Lem Icebear Open Powershell and execute: (Get-CimInstance Win32_OperatingSystem).version if you see 10.0.17110 or 10.0.17643 you can use WSL. But I have to warn you that its very slow. Better way for now is to use Bash for Windows but you have to deal with case-sensitive problems.

@Caserius Tendook Yes, you can move mod archives without problems.

Yet another approach: Use cygwin to install SCS using Linux weidu 64-bit - require linux know-how, case-sensitive problems, installation time is 5x slower, so 1h for AI become 5h Use Windows Subsystem for Linux: - require linux know-how - require Windows 10 RS4 17110 or later / Windows 10 RS5 17643 or later - enable Windows Subsystem for Linux feature, install Ubuntu/Debian from Windows Store - set you BG partition as case-insensitive: fsutil.exe file setCaseSensitiveInfo <pathToBG2EE> disable, this will save you from case-sensitive errors for WSL - open WSL, download weidu Linux 64-bit, extract binary to /mnt/<windowsDriveLetter><pathToBG2EE>, set executable flag - install SCS from WSL by executing ./setup-stratagems But the installation time is 10x slower, installing first component "Initialise mod (all other components require this)" took 11 minutes while on Windows 32-bit took one minute! Im posting this as it might improve for in next version of WSL but now such solution can't be effectively solution for the "Out of memory" problem.

Community took various attempts in order to eliminate this problem: 1. Provide windows wiedu 64-bit: according to wisp, OCaml support for Wnidows 64-bit is very poor ( who's fault is? ) so it's not possible to compile windows wiedu 64-bit binary 2. Enable windows weidu 32-bit Large Address Aware setting - wisp didin't agree to do it because 'some things might broke' 3. People manually sets Large Address Aware setting with CFF Explorer - SCS doesn't display error but Bhaal only know if the macros/tp2 code actually do what they suppose to do 4. Use cygwin to install SCS using Linux weidu 64-bit - require linux know-how, installation time is 5x slower, so 1h for AI become 5h 5. Use Windows Subsystem for Linux - require linux know-how, installation time is 10x slower, installing first component "Initialise mod" took 11 minutes while on Windows 32-bit took one minute! It has been more than a year, since "wait for SCS 31", no indication that it will be released anytime soon. It looks like all big EET installation are doomed, unless somebody take look at the wiedu macros and convert them into LUA

Another reason is that weidu.log doesn't have answers to READLN-based components, it can make lot of difference. Also without it, BWS installation will be paused in order to provide those answers.

I'm glad to hear that minimum support won't be a problem, it's even simpler than you think. Don't worry about other mods. The data for those can be added via Fixpack etc. The system is not 100% opt-in but the main goal of it is to give back the control of mod metadata into modders hands and free community maintainers from modders work. I will send you one small PR and then we can see what it might bring. The Rome wasn't build after one day.

If it's cross-platform, I'll be happy to pitch in. If I can't use it, then I problem won't. Just to be crystal clear: I'm talking about putting single file with 6 lines of text into mod repository. No coding required. The data can be used via old BWS, next BWS and any external tool/system. You decision seems to be dependent only at the fact that the OS which you have choose, doesn't have tools which can make use of this data. Don't you think that decision should depend only on the usefulness of the solution for the players/community maintainers? So the majority of the players will benefit from it? And no one is stoping anyone from creating a tool for OSX which will use 'MOD DATA'. You could even adapt you OS-X-Weidu-Launcher to make use of it. But you have to give something first to the potential developers. I'm sure that you don't expect that people will spend a year or more to develop a new tool only to hear 'nah, not goona support it'. So I ask again: will you provide fundamentals for new tools across you mods?

You rise a concern that BWS conflicts cold be biased by someone with administrator rights. I give you an exact example how anyone can avoid such situation if he thinks that you concerns are true. What I'm saying is that is impossible to have 'bad actor' as admin of the BWS because of it's open source. Then, you take my explanation as 'STFU and fork the project instead of offering suggestions or constructive criticism'? Seriusly? It's every easy to say something like above as a person who is not aware how much work you need to put into it and as someone who have no intention spending his time to do it. From my experience it works for 80% cases. Each time when it doesn't, it breaks exported/saved mod list/selections and conflict definitions. And guess what?Players will blame you/you tool! Then you will move guilt to the modders. I've did it enough times to say that it's not a solution which is worth serious investment. If you think otherwise, feel free to do it. We are talking about abstract because currently there are no fundamentals for new BWS. Those aren't in my hands. Modders can help but I wonder, how many of you would support something only for the purpose of the BWS/other external system. Wana try and see for yourself? I never announce anything. The only thing which I've mentioned across various discussions that the reason why next BWS can't be created is that it lacks strong fundamentals. If the old 'classic BWS' will still have BG2/BGT/other old games while new BWS-EE won't, the complain about the *missing* parts won't happen because you can redirect it to the 'Classic BWS'. I already said that I have nothing against such move if it can bring more quality/less work time.

Fantastic work! Yummy Goodberries

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. 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. 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.

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.