Lurker

I've added an example curated payload file and the resulting WeiDU.log to the topic. And since the resulting WeiDU.log is identical to the one previously sourced by the parser, I can happily claim that this stuff really works. I used the "nowarn" option and answered the remaining interactive prompts manually. My starting point is an archived EET-Core installation. That's why the payload actually begins with Ascension. This setup takes over 8 hours to complete on my machine (Xeon E3-1245 v3, comparable to i7-4770). I've never tried the Linux version of WeiDU, and would be interested to know if the native version works significantly faster?

The way I use awk here is also the only way I know how to use awk, although it's a bit more useful/powerful when dealing with multiple columns at once. I try to stick with bash builtins as much as possible, but ease-of-use, lazyness and readability are valid factors to include external helpers. The performance hit with so many calls to external applications inside the while loop is very noticable, can't deny that. My recent discovery of VAR="BLAbla" echo ${VAR^} ${VAR^^} ${VAR,} ${VAR,,} BLAbla BLABLA bLAbla blabla VAR="blaBLA" echo ${VAR^} ${VAR^^} ${VAR,} ${VAR,,} BlaBLA BLABLA blaBLA blabla filled me with joy.

I like grep. But I'll admit that the --help is maybe a bit terse.

Embarrassingly, this came to mind only very recently: weidu.exe --help 68 + 69 including comments. I think I'm safe for now. However, better not to think about why writing so few lines took so much time.

Damn, I asked for feedback. That's not something that I had on my radar at all. I don't think that's something I want to address from within the script. Have to say that I'm quite happy with the current result.

Can't answer from first hand experience because of having none yet, but having read way too much about related stuff lately, this indeed seems to be how it works. Might even be mentioned in the mod's readme? You might also be interested in this mod if you don't want to wait until Chapter 6. Just look at the readme for information regarding compatibility. From actual experience, @jastey is very good with documentation.

I'm inclined to guess that this isn't the most up-to-date documentation for WeiDU...? Thanks for the tip, I was unaware of this option. Right before reading this, HerThiMoney once again jump-scared me with its auto-open-pdf-at-end (there's an ongoing setup running on a second workspace.). Another worthy candidate for consideration, this option is. My current sanitycheck() is black-or-white, but that's an easy fix. Although I'm still hesitating to add more parameters to my scripts. getopts isn't the most accessible feature in bash... Nice thing exchanging ideas here, though.

Yep. Ugly caused ugly. Old habits die hard. Just recently started replacing all those setup-*-exe with symlinks to a single weidu.exe. The Wine being easy on case sensitivity thing was a nice learning experience, indeed. Thanks. cdtweaks I think had 4 different invocations in my last setup, so I was getting tired of having to remember to rename the setup log after each step. I like to keep these around. Any thoughts on my "parser"? EDIT: Sorry, the not-up-to-date?-download counter confused me. Noticing the d0questpack stuff would be quite a feat without looking at the parser first. I put the "" around parser because I'm still not sure if it really qualifies to be called as such. Well, the script doesn't care about its own name in the end.

Thank you. A pity. But at least I didn't miss something really obvious, so there's that.

I honestly couldn't find anything. For example, how does tagging a user (not a topic) work?

FWIW, I put my shit up here. EDIT: @mickabouille From looking at your README, I think I'll adapt your strategy to (manually) patch away ACTION_READLN (<-- whishing this wouldn't exist at all; just use an .ini for customization, please...). How do you catch deal with WeiDU warnings? Is there a (hidden?) option in WeiDU to suppress them, or to change the exit code? (<-- stupid question) Better question: Is there a way to prevent the "Press ENTER to exit." prompt after INSTALLED WITH WARNINGS (WeiDU exit code 3)? I'm also looking for a (simple) way to prevent interruption of an install sequence. EDIT: Not even sure if ignoring warnings is such a good idea? Guess "it depends". Without those (few) interrupts while testing my script, I wouldn't even be aware of some issues of my last big EET setup.

Changes (2023-05-02): wparse.bash added workaround/support for Oversight Changes (2023-04-26): wmodinstall-native.bash initial version minimal-effort switch to native weinstall, major performance increase Changes (2023-04-23): wmodinstall.bash will now also tolerate chitin.key in all uppercase Changes (2023-04-20): wmodinstall.bash added option to ignore warnings added WeiDU parameters --skip-at-view --no-exit-pause added references to g3 tried to improve general quality wparse.bash no major functional change see points 3. and 4. above

Although mickabouille definitely beat me to it, I nevertheless hacked together two simple scripts to ease the installation of a larger number of mods. Since right know I'm really tired but can't sleep, I'll try to make this brief, because foggy brain because really tired. And as it turns out, I also got really rusty in writing bash, so please bear with me. My personal use case: I'm on Linux and I use Wine. So no Project Infinity. I'm used to getting mods the old fashioned way by manual downloading and dumping them into the game directory. This usually results in several files like "setup-<modname>.exe" and their respective directories. wmodinstall.bash sources another file, that mostly should contain a mod name plus a number of components per line, and tries to install these. wparse.bash takes an existing WeiDU.log and converts it into a file format (dumped at stdout) that wmodinstall.bash can source. The output should be curated before as needed, obviously. Still better than having to type all that shit in manually. The functionality of both scripts is pretty basic, and while I tried to catch some most(?) of the stuff that some people (like myself) tend to mess up, there's obviously still some room to do really stupid stuff. It's a crutch triwalker(*), not a Swiss army knife. I put some comments in, but cannot really estimate how self-explanatory it is. I'll create an empty reply after this posting, so that I can put the code there into code tags, if desired for changelog/update information. Won't start using git just because of two simple shell scripts (see bottom of this comment). Although none of the available syntax highlighters are really fitting, at least they add some color. Feedback is appreciated. There's a rooster roaring outside. I hate that critter. (*) As the feeling of accomplishment for creating something that does exactly what it is supposed to do settles in, I decided that this metaphor deserved an upgrade. And I'm fully aware that my method of self-advertising really sucks. Download links: (the most recent version is currently determined by the "latest update:" tag of this topic and the changelog.) wmodinstall-native.bash preferred method; expects linux weidu and weinstall present and executable somewhere in $PATH wmodinstall.bash initial method; using windows binaries for installation; slow wparse.bash generates installable "payload" data from an existing WeiDU.log wmodinstall.payload example "payload" WeiDU.log corresponding to above "payload" KNOWN ISSUE(S): "debug" option only applies to "core" functionality, since the payload is simply sourced by bash any shell commands in the payload file will be executed every time the installer script is invoked Mods containing whitespace in their name aren't accounted for so far, the only mod that I know of with where this applies is Black Hearts, which can be easily fixed on the mod's side sloppy reset of IFS might be an issue

I was thinking about using links myself in some way, perhaps even with rsync, but coudn't figure it out before my patience ran out. The solution with --compare-dest turned out to be good enough, especially compared to always making a full .tgz, which I did before. Ouch. The catch is I don't know how to do an "incremental delete", that's why I bite the bullet and do a full .tgz after biffing. Still good enough. I haven't got a clue about using git. The last time I used a VCS, Subversion was still a thing. But since the dawn of 2023, when I got back to BG, I'm slowly getting used to browsing github. It's the other way around for me. I never bothered learning anything else, as long as I either got the job done with bash, or until I decided that it's not worth to bother at all... Making that stuff robust enough to be used by other people is something else. Way too much responsibility... I wish I was as quick to (re-)learn things as I am to unlearn them when being idle.

I don't want to derail, but perhaps somebody finds the following useful. I'm kind of in the same boat (Linux+Wine), and was thinking on doing something comparable, but on a much, much smaller/simpler scale (just a bash script), especially without builtin download functionallity. I think the greatest pain is the time needed if one uses WeiDU interactively. And I'm on EET, so some added complexity, more to process, and I've got a rather old CPU. My current workflow (more like "running the gauntlet") is something like this: I have a "bg2ee.eet-core" directory as baseline (with just the base EET, dlcmerged-BG1+BG1UB, and HQ_SOUNDCLIPS_BG2EE) I have a prepared .tgz with all mods I plan to apply, and a download directory with the individual mods, prefixed with "nn_" for install order reference, or later use a WeiDU.log from a previous install I rsync the "bg2ee.eet-core" to a new WIP directory and also extract the "mod.tgz" into it semi-manually apply some mods (--force-install--list [component1] [component...]) use "rsync -av --compare-dest=/full/path/to/bg2ee.eet-core/ bg2ee-wip/ diff/[named_step]/" to have a differential "snapshot" directory at arbitrary points create a .tgz from such a differential snapshot directory for archiving/"rollbacking" to roll back the bg2ee-wip, "rsync -av --delete-before bg2ee.eet-core/ bg2ee-wip/" and then e.g. "rsync -av diff/55_after_quests/ bg2ee-wip/" last step is always "Generalized Biffing -> Biff all files", and I keep a snapshot.tgz from directly before biffing create a complete .tgz of bg2ee-wip/ after biffing I usually include the output of `date -I` in the name of the final.tgz and the respective mod.tgz I didn't want to go too much into detail, so a bit of abstraction was necessary in the steps above. Hope it's comprehensible. As a side note, having multiple working directories can also save time when e. g. testing how some tweaks work together, or if my manually mutilated mod works as intended, because I can run multiple installation processes (and even game instances) in parallel. All in all maybe not overly sophisticated, but since I'm happy on the command line and badly abuse my bash history, the manual labor part isn't overly painful. The time waiting for WeiDU to install mods often is. To automate the installation, I'd create a bash script that just calls WeiDU as (often as) needed, with parameters for "mod name", "--language 0" (almost always english, else ) and "--force-install--list [components]". That script maybe doesn't even need to be parameterised, just change the script as needed. Less complexity. Going into overengineering territory a bit, a bash script that parses a WeiDU.log to generate said script from the last paragraph as a template for easy editing should also be doable. Eh, this may come off as a rant or an empty promise (which I definitely didn't do!), but perhaps posting this publically motivates me enough to actually putting money where my mouth is. Sometime.

I swear (ambiguity pun retroactively intended), the whole process is like becoming enchanted with a modded form of Polymorph Other in real life. I'm currently an old greek guy, trying to push a rock up a hill. Before I was just an old guy. Lots of mods recently got updated, which should be a cause for joy, but maintaining a (heavily) modded Infinity Engine game is something like being back in Windows 95 times. "Re-installeritis"? Then I always make the mistake to read more and more about mods from different sources, which sooner or later leads to the discovery that one of the installed components silently breaks another one or would have needed manual patching before installation (currently looking at you, Manual of War). And since I'm on Linux, no Project Infinity(*) for me. That situationally suitable superhelpful shell script, that parses that last WeiDU.log to ease re-installs just doesn't want to write itself. And recently having successfully merged some tiny things from one mod into another locally, opens up the tragic tale of "Now that I can do some things myself, I have even more options to consider." Tragic, indeed. (*) but happy happy joy joy that Near Infinity is written in Java and EEKeeper runs on Wine - or rather, "Please no .NET, I beg you!" (sorry )

Nevermind, was confused. I guess the game just uses the higher value of either class. Sorry for the noise.

Err, I just noticed that Enforce PnP Proficiency Rules on Dual-Classed Characters doesn't seem to work at all in my installation. I had installed that component after EET_end; currently testing if it works before EET_end. EDIT: Oookay, how do I explain this mess without appearing like a complete idiot or using too many words...? Enforce PnP Proficiency Rules on Dual-Classed Characters works like intended - mostly. If you "skip" levels by using the console to gain XP or accumulate enough XP without leveling, and surpass your old class (I tested with a fighter), then it's possible to allocate pips like an unrestricted/single class fighter. For further level-ups, the PnP restrictions apply. But it's possible to allocate 3 pips for Two Weapon Style. Installing before or after EET_end doesn't matter. This was a guess, because just today I learned that installing new kits before or after EET_end *does* matter (kit names don't use new strings for the BG1 part of EET in the character record if installed after EET_end). So in the end it's working exactly like I wanted it to be, but I don't understand why. *sigh*

In a normal interactive install, Weapon Styles for All (#2060) comes up before Enforce PnP Proficiency Rules on Dual-Classed Characters (#2450). This results in a WEAPPROF.2DA where the added dummy kits D5FIGHT, D5RANGE and CDSK[0..n] all have their respective 2WEAPON entries set to 2, which might be PnP-appropriate, but counter-intuitive with what one might expect to get after purposely installing WSfA (#2060). I was expecting #2450 to only limit going above 2 pips for weapon profs, but not to also limit Two Weapon Style to 2 pips. Therefore, I'd propose to place #2450 before #2060, or at least mentioning this functional conflict in the readme.

Hi, I'm using SoB component 201 "SBO - Stat-based Bonus Spell Slots: v5.40" as the only component from SoB in a current EET install. On the in game character record screen, when clicking on "Wisdom", the default text is replaced with information about saving throw adjustments (which aren't even present in this case) and bonus spells for clerics and druids (don't know based on what; I'm also using cdtweaks component 2580, installed before SoB). Which is strange and should not really be the case, because Wisdom is the ability that is explicitly NOTfunctionally altered by this component. So far, it seems to be just a minor cosmetic thing. EDIT: Added some more info, downgraded some assumptions to sound a bit more modest.

Hi, I've been lurking around for a while, messing with my EET installs and spending way more time tinkering with my installs than actually playing the game. Oh, well. Some more feedback regarding HouseTweaks components 2 and 10 ("Expanded Racial Bonuses" and "INT/WIS/CHA-based Bonus Spell Slots"). Both components caused severe lag on my installations. Cannot recommend using them just because of that. Also component 3 ("Rebalanced Proficiencies") didn't enable clerics to accept bolts as ammunition, so is only usefull for the edge case of crossbows that provide their own ammunition. Haven't tested with a mage yet. And finally, curse all you damn modders that caused me to waste so much time with all this stuff. Which is my weird way of saying "Thank you all for all your work." I'll also provide my current master install WeiDU.log because why not.