Jump to content

Lurker

Members
  • Posts

    196
  • Joined

  • Last visited

Everything posted by Lurker

  1. It was my very first posting on Reddit. My thoughts exactly.
  2. @mickabouille Small heads-up: I exposed both of our tools on Reddit.
  3. @mickabouille I always had a soft spot for XFS, but could never justify using that instead of ext4 for my usual use cases. Maybe this might be it? XFS supports ASCII only case-insensitive filename lookup and Copy-on-write (CoW). Using "cp --reflink" then should be a nice and very effective way for dealing with test-installs. Alternatively, ext4 + casefolding for Unicode support, and OverlayFS to add CoW. Okay, now I'll have to agree that your idea regarding Samba is really strange.
  4. Hmm, I noticed that the string tables differ slightly in size and number of entries (in Near Infinity). The Wine setup has 319124 entries, the native setup 319130. Generally, how much reproducibility can be expected from repeated builds with WeiDU on an identical baseline? EDIT: To answer my own question somewhat, a binary diff between two consecutive setups using the same recipe and environment is annoyingly huge. But the resulting dialog.tlk are identical. Also annoying, native weidu ignores umask and creates files with all bits set for ugo.
  5. Apropos stranger thoughts: Maybe if weidu on Linux was more popular, it would be better adapted to actually deal with the idiosyncrasies of the environment it's supposed to work in...?
  6. Attached new wmodinstall-native.bash to topic. weidu/weinstall has to be present somewhere in $PATH.
  7. Timed installation, full auto, payload from topic minus the three interactive components, Wine+weidu.exe: real 446m3,296s user 0m2,207s sys 0m3,681s As above, but with a loop-mounted JFS (case-insensitive support enabled) on top of ext4, native weidu/weinstall: real 23m52,318s user 20m8,322s sys 3m39,623s Disregarding the line terminators, both installations end with identical WeiDU.logs. Speedup factor ~18.
  8. Sorry to have devolved your mod's thread somewhat, but since you and D5 are still discussing the bard song issue, I thought maybe tagging @The Artisan might be okay? I'm not active on SHS.
  9. I didn't mean to imply anything else, though "yours vs. mine" applies simply by yours doing native and mine going through Wine. I'm still flabbergasted by the huge difference in runtime and if I understand your metrics correctly. So 21 minutes start-to-finish for a whole payload with native weidu, but anything thereafter you reported was slow-boating the same payload with Wine-weidu? I know from experience that some mods install exceptionally slow, I guess due to inefficient libraries. Yes, but it's reported as implemented since late 5.13.9, while the userland is already there in Bullseye (defaults to 5.10). I was able to create a fs with the feature enabled, but then couldn't mount it. Will test it in the future, I guess. It fits the "going native" approach in the end, whereas an approach like described here wasn't in the least compelling to go native instead of just sticking with Wine. So, in the end it seems that migrating my script to weinstall could be less effort than adapting the work environment. No matter, thanks anyway.
  10. Grmph. Since I can't get (native) weidu or weinstall to do anything but spitting out nonsensical error messages about supposedly missing files, a bit of waiting for a working result isn't so bad. EDIT: Okay, so just to enable the ability to actually USE the native binaries to cope with the "creative" way this environment + EE "improvements" deal with FiLeNaMeS, in my case (Debian Bullseye, ext4), I'd need to: upgrade to a kernel with CONFIG_UNICODE=y from backports enable the "casefold" feature for the file system and remount does that even work on an existing fs? chattr +F on an empty directory and then dump the game files into it Yeah. Sure.
  11. Just to be sure: Your tool installs a payload comparable to mine in 21 minutes, whereas my solution takes 8+ hours? That's really hard to grasp. I don't get a cohesive impression from all of this right now...?
  12. Ugh. I'm clearly not in the mood to learn the intricacies of the native tools right now. tolower? Disk images? Special file system mount options? Having argued against vendor lock-in in the other thread just before, I need to admit how comfy the golden cage of Wine feels right now.
  13. Thanks, I added the missing "v3" to the posting you quoted. Not significantly different. Game is on a SATA SSD, local ext4, writeback and 16 GB RAM, so shouldn't matter. I was suspecting that I might shoot myself in the foot for staying with Wine for WeiDU, but that's a dramatic difference. Like WTF?!? I called for it. You sniped me (back).
  14. Do you mind to elaborate on this a bit further? In my case, I'm currently a bit obsessed with combining tweaks of different mods to see what emerges. And also on mutilating mods to fit my special... urges. So I merged the Templar from your kitpack into the Champion of the Silver Flame (by mod-modding), further pimped the paladin class with MESPELLS spellcasting, combined some components from SKILLS-AND-ABILITIES with others from SCALES_OF_BALANCE (and some more other stuff), planning to support the CotSF++ with 5 different bard kits from Bardic Wonders and using the Back Pits to see what's the result. I picked party support kits (Skald/Troubadour/Dancer/Abettor of Mask/Strategist), and the CotSF++ was supposed to be a main "protagonist". The bard kit auras mostly stack. And constantly re-apply their effects, I guess per round. Until (roughly simplified, didn't look too deep into it) the boosted things max out, which happens way before the end of 1 Turn. All PCs end of with 5 APR, THAC0 between 2 and 5, 15-19 damage with a Longbow (if bard kit), 200+ Pick Pockets (if unrestricted bard kit), and -19 AC (without modifiers) in case of Dancer. At Level 1, 0 EXP. I don't mind cheese and fun OP stuff, but that's a bit much even for me.
  15. Everything has to begin somewhere. For a first learning experience, going through a manual install is what most people do? Also helps to learn to appreciate anything that eases future reinstalls. And finding a provided WeiDU.log in some forums isn't the hardest thing to do. Sensibly tweaking it requires a bit more previous knowledge. I have to admit, when I got back into all of this (and deeper in than anytime before), I used that BWS thingy for a short while. That also doesn't work on Linux (as in installing anything at all), but the GUI did launch, and I used it as a way to get an initial mod order. When the initial work (and learning) is done, I find nothing easier than to edit a simple text file and then to let another tool do the remaining work after that. GUI or not.
  16. If I may chime in. Some points, in no overtly particular order: I like the approach to have core functionality separated from presentation. A well designed GUI can make daunting tasks more accessible, especially for technically less inclined users. Well designed CLI tools are usually a better fit for automation. Forced interactivity might be fitting for some or even many use cases, but breaks automation. Managing more than just a few mods on IE game setups is especially tedious, thanks to its onion-like layer of dependencies, though I can't say if this is due to the way WeiDU handles the engine, or the engine design itself. WeiDU isn't very good with uninstall/reinstall cycles. That makes rollbacks to previous breakpoints by whatever other methods or tools almost a given. Stacking layers of abstraction can [lead to long-winded philosophical ramblings, which is why I deleted several efforts to complete this sentence.|happen and brings its own challenges.] At some point, one may come to the conclusion that reliable automation is maybe the biggest form of usability improvement when reinstalling on a regular basis. The deal-breaker with PI for me is/was that I cannot even run it. Since this is a hobby, everybody tackles its challenges with the tools they are most comfortable/familiar with, but, sorry to have to say this, the dependency on .NET is a literal killer-feature when not on Windows. (Yes, I detest vendor lock-in and try to avoid that whenever reasonably possible). And just the other day I was asking myself if setting up a local Jenkins instance to deal with my BG setups would be either reasonable or a sign that things are getting a bit out of hand.
  17. [urge to communicate] "Bard Songs Last 1 Turn" + "Bardic Wonders" kitpack = completely bonkers
  18. Don't know. But it does break the selectable Black Pits campaign in EET. EET core + mih_eq component 30 (arbitrarily chosen) + EET end -> same as with BG:EE. The installation also throws a "WARNING: No rule to identify SOD".
  19. @Angel mih_eq breaks The Black Pits (BG:EE). Najim has no dialogue after the introductory fight. Following the transition to the next area and Baeloth's speech, the scene centers on Najim, again without dialogue, and doesn't continue. Not apparent from the WeiDU.log: Classic BG UI v1.6 is present in override. I can also provide a setup log on demand, but that's 609K gz-compressed. EDIT: I tried onion-peeling the installation, to identify the relevant component, right down to component 0. Unfortunately, The Black Pits is only fixed after complete deinstallation of mih_eq. EDIT 2: I'm guessing that this is related to whatever always.tpa entails. Here's another log of a more advanced setup (without mih_eq) that doesn't show the above misbehaviour.
  20. Shameless self-promotion: It didn't, but I did. Sadly, the super-witty 5-times-alliteration didn't carry over.
  21. It's a display of my goodwill. Or that I'm an idiot. Spending extra effort on the perhaps universally most disliked NPC, instead of just disabling it. Otoh, shame on Argent77 for not including the, without any doubt, most reasonable choice.
  22. My premise when building this particular setup was to have a "stable baseline", that would be fine without relying on EEKeeper for "convenience tweaks". I consider NPC_EE as an in-game replacement for EEKeeper. But, aside from some very half-assed tests for basic functionality, I have no experience with how well NPC_EE works in a "serious" playthrough. So it's a win-win that is has to be installed so very late. If I relied on NPC_EE alone, I would/could also have omitted the other NPC-related mods. I'm aware of the dual class caveat. For Imoen, it doesn't apply, because if I use her, I already have full control over her development right out of Candlekeep. This is EET, after all. For Anomen, I dont' want to mess with his first class anyway, because of npckit. And Nalia I turned into an Adventurer with npckit, which boosts her open locks and find traps a bit. I suffered though SoD (as part of EET, but without further content changes) only once, and that wording should make it obvious how well I liked it. The only Beamdog NPC that I actually like and would have around for a whole saga run is Baeloth(*). Hexxat, no thanks. Neither for her personality, nor for her class(**). But when the choice popped up, I thought "What would make me at least think about the possibility to take her, maybe when hell froze over?" So I changed her class to Sorcerer, TRUE CLASS. A very fitting drop-in for Baeloth, at least mechanically. In my current game, I EEKeepered Aerie into a Sorcerer, with Baeloth's MR. She has almost no kills, but she ensures that my Archer charname is a one-elf-show, with the remaining companions only for flavor or to block doors. Oh, almost forgot, Haer'Dalis as an invisible Skald (<-- Rogue Rebalancing) is also very nice. (*) Both for his class and his voice acting - gives Edwin a run for his money. And he's completely un-romanceable, so less cringe. (**) In my current game, my Archer got a "roleplay epiphany" and destroyed her in her tomb on the spot. A fitting place, and the game also ensures that you have to close the door on your way out.
×
×
  • Create New...