Graion Dilach

I can't drive, so I'm relying on public transport to commute. I see more than enough tweens on the bus, so my experience is as appropriate as what, extrapolating three cities worth of kids to the whole country. (No, seriously, Hungary's population is 9M and even here I can't take a representative survey involved less than 20,000 people serious, let alone for a country which has 35 times the population). In fact, my own view of ~450 kids on the public transport is closely equal to the percentage of population your survey works with.

Your other link is paywalled, so I can't comment on that.

The engine_name variable within engine.lua in the game folder defines the profile subfolder's name (aka the folder in Documents). Changing that one variable ensures that the entire duplicate is sandboxed if necessary. That's all there's to it.

Just never listen to Jarno. Guy doesn't know anything about the games at all, and tries to discredit everyone else instead of learning.

Grab NearInfinity.

https://gibberlings3.github.io/iesdp/appendices/area_lists/bg2aref.htm has the area list. Open the area file you want to restore the music of (filename.are). Also, drag it's counterpart from weidu_external/backup/jtweaks/330 into the tool. so you get it in a separate window. Scroll down to Songs on both entries and double-click on them. You'll see that the 4th entry from the top is called Battle Music. Select it on the active one and change it back on the bottom list to what the backup variant has. When you're done, close the popups and use the Save button at the bottom of the main ARE file window.

TBH, for thsi scenario, I'd moreso just leave the game as-is wrt mods, and just fix the individual boss ARE files to revert to their original music. You should be able to compare the AREs via weidu --change-log. 

The EEs are mostly portable, so you can copy them over and they will work from an external folder. Jarno's being wrong, as usual.

14 minutes ago, Thacobell said:

There's also the issue of Beamdog's launcher, required by them, just doesn't work on Linux because it used libs so old, they are flagged as security risks. No modern OS can run it.

https://forums.beamdog.com/discussion/comment/1202594/#Comment_1202594

6 hours ago, subtledoctor said:

Meanwhile according to some recent example numbers, lately 87% of teens are using iOS.

Sauce? According to my example numbers derived from my social connections, iOS is 5% and that's already artifically boosted due to one of my prior workplaces enforcing iPhones as company phones. Besides, we're in a recession, so 87% of the households couldn't afford it anyway. It just doesn't add up.

The prefixes are part of MiH's implementing P&P aspects - that's how the spells are called there exactly.

9 minutes ago, subtledoctor said:

Changing the string instead of just renaming the spell is an odd choice. 

Quote

If Spell.ids already contains a spell named idsName, but of of different type and/or level than the one you’re adding, then the current reference is removed from spell.ids, and then the action proceeds as usual. In this case, if there is the ON_DISABLE section, the patches declared there will be applied to the older spell.

That's supposed to be the trick behind the idea.

Regarding Faerie Fire, that's actually more complex and the responsibility isn't that clean cut.

Faerie Fire is a Beamdog SoD spell. It is SPPR116 in SoD, but it isn't exposed to the player. EET, trying to be friendly to modders here tries to free up that locked spellslot and moves it from 116 to 100. SoD2BG2IU sees that it was moved and attempts to move it back via relying on a broken weidu ADD_SPELL workaround - literally installing a level 2 variant first then installing a level 1 variant afterwards immedaitely, so taht the level 2 overwrites SPPR100 in spell.ids and the level 1 variant overwrites the resulting sppr2XX.

It's basically one solution trying to be too nice for his own good and another on top of this being an absolute hulabaloo.

Fun fact - EET only moves out Faerie Fire (alongside Darkness 15" Radius and Dancing Lights, the other two SoD-specific spells) from the available-from-player slots, if it doesn't detect the spells already existing in BG2EE. So, because EE Fixpack adds the three spells in a disabled copied form from SoD to BG(2)EE, EET won't even move it out when the game's fixpacked, and SoD2BG2 IU could only need to resort to enabling the spells in HIDESPL.2da. 

Other mods also add Faerie Fire back (DSotSC-Trilogy, SR to name a few). None of them does this though. DSotSC-Trilogy only handles HIDESPL.2DA on EET, because I assumed EE Fixpack will be already rolled out by now and I wanted to simplify my code here (the DSotSC-Trilogy spell components assume that if a spell they'd add is already added. then the existing spell should be kept and it shouldn't overwrite). SR probably does a full rewrite but skips the level 2 spell addition.

So that above hulabaloo is dedicated to SoD2BG2 IU on EET pretty much.

Guys, could you actually not assume things about Beamdog's state on the IE games literally within the 24 hours they fixed up Android?

Sure, I have my doubts on the 64 bit PSTEE conversion promised there as well (although it would be cool if that Modron Maze issue would get a fix), but eh, if they only concentrate to the engine issues, that would be enough.

My guess would be RNG bias. I'd presume that imposing a maximum on the roll would round up values outside it to into it than to reroll the dice.

17 hours ago, Lurker said:

Dark Side of the Sword Coast (DSotSC) v4.2 only:

DSBOOT01.ITM (Boots of the Forest) are usable by Druids, but not by Fighter/Druids. Intentional or oversight?

Quote

Boots of the Forest, one of the many gifts bestowed upon the protectors of the forests. These boots provide the wearer with a little extra speed, stealth, and the ability to avoid getting trapped.

STATISTICS:

Stealth Bonus: +15%
Grants Free Action
Weight: 4

Only usable by:
 Druid (Single Class Only)
 Ranger (Single Class Only)

The below quote is from the oBG1 mod item description. It is intended, although i can understand why it sounds like a bug, with the EE dynamic generation making the restriction less obvious.

TBH, that component needs another recode anyway, because it also overwrites the text.

20 minutes ago, Lurker said:

I'm very picky when using Artisan's mods. Some components from HouseTweaks caused severe lag and where hard to track down for me back then, [...] In current versions of HouseTweaks, the component to restore the reputation increase sound effect all of a sudden will only install on BG2:EE, not on EET. I patched the (working!) component from an earlier release (good luck figuring out which version is which) into the version installed here, locally. His work is too sloppy, in my opinion.

The lagginess only happened  - it's fixed now -, when EEEx was installed alongside HouseTweaks, a non-EEEx run wouldn't experience it (HouseRules' previous way was triggering too many EEEx hooks), which is why it remained there for long. The reputation sound limitation is new to me, I'm not sure why that change was oversimplified. And yes, the lack of tagging releases results with some releases being skipped by the website links, but I honestly never noticed that.

I don't have that impression from Artisan's output being sloppy though overall. Especially when there's a modder here with a past issue history including unsellable bastard swords, armors preventing innates to be casted and similar nondescript issues enough grating that figuring them out was my biggest inspiration to pick up modding outright.

The Manual of War notes you cite are my notes from two years ago. I adopted klatu to TGP. TBH, TGP is fine wrt forks and if issues come up, they will be taken down anyway. It's not as bad as the history of Pecca's UI mods.

3 hours ago, Lurker said:

Could you be a bit more verbose, please? Or provide links? I've a collection of accumulated links to various GitHub repos, but usually try to stay with the "official" versions of mods.

The Manual of War worked fine in my last, but terminally doomed ToB-only game. At that point, it also doesn't feel overly overpowered. I've a link in my notes about the general issue, but that points to SHS forums, and I guess we sadly all know how useful the information buried there currently is...

I also get the feeling, regardless how much I like all those really cool gameplay tweaks and the possible options in how to combine them, when I see the increasing number of stacked effects on my individual party members in Near Infinity, I'm less and less surprised about the increasing number of crashdumps in my game save directory...

The-Gate-Project; https://github.com/The-Gate-Project/klatu-tweaks-and-fixes/commits/master

Tip is the latest commit on the primary branch in Git terminus. Using MiH_EQ tip is fine and actually better than v5 here.

That klatu install looks to be the last SHS version instead of the TGP version with the manual of War-on-EET fix. Also, if you use the tip of MiH_EQ, you don't need FIX_CRE.

Regarding split mod suggestion, I find the "main" definition vague. If a mod is supposed to be split, then I'd prefer the more exact "everything excluding X" over it. Regarding, SCS, I would call the "main" slots AI enhancements, because the spelltweaks should be before kits anyway, due to selected kits (Artisan Troubadour, S&S Chorister) able to inherit the healing/restoration spell buffs.

Yeah, I mixed that up. I'm having a long week here. And yeah, if you really want to debug these, attempt rolling with --change-log. That does help. At worst, just don't trim the output.

2 hours ago, Lurker said:

EDIT: That conclusion makes no  sense; I added the previous result to the spoiler above, because it's a much better fit context-wise. The output from the --change-log starts counting at zero, but the generated LUAs start counting at 1. Off-by-one issue? So it's really BG1NPC?

The count difference comes from the fact that 0 isn't backed up, because it's the starting file in the base biffs. 1 is the snapshot between 0 and 1, 2 is the snapshot between 1 and 2 and so on.

So that's actually a BG1NPC bug. And it indeed is:

See https://github.com/Gibberlings3/BG1NPC/blob/b90822b39066c9d4261deb4aed215f141e50b3b7/bg1npc/phase2/tpa/bg1npc_kagqst.tpa#L135 - this isn't changed for EET, unlike say, Kivan's: https://github.com/Gibberlings3/BG1NPC/blob/b90822b39066c9d4261deb4aed215f141e50b3b7/bg1npc/phase2/tpa/bg1npc_kivan.tpa#L34-L42.

In fact, only that latter Kivan block is handled correctly, all the other BG1NPC ADD_JOURNAL EXISTINGs don't check against EET. Thanks! Will fix.

EDIT: https://github.com/Gibberlings3/BG1NPC/pull/127

19 minutes ago, Delior said:

@Graion Dilach: Out of curiosity, do you use EET master for your own personal builds? I'm still new at this and so I'm generally hesitant to use anything but official releases, but I couldn't help but notice that it has been a long time since the last EET official release and a lot of commits since then.  

I do, but keep in mind that I own ca. half of the patches submitted to EET since 13.4, so my own motivation is partially to betatest my own patches.

12 minutes ago, JohnBob said:

Since K4tos mentioned a release soon, waiting seemed safer. (But it's been a long time...)

I actually missed this comment. I'll prolly file a patch to revert the EE Fixpack compat then. I really wouldn't let that bleed into a release for now.  (Ideally, I would attempt getting a new EET release tagged and tied to EE Fixpack.) Thanks!

@JohnBob @Alywena I offered a solution to this issue already - use EET master. ArcaneCoast these days also primarily use EET master with the Russian language packs (they also patch compat.tbl with their language pack, which actually was rejected by k4thos in https://github.com/Gibberlings3/EET/commit/9d6a8bd4d3bee3bb067aa144a9ccefe6063e1873 although that could only be because it also added back a ton of natively compatible mods back to the compat list) over 13.4 for their installs.

The problem isn't that EE Fixpack is offered or that EE Fixpack and EET are attempted to be combined (although I didn't actually looked at how are you installing EE Fixpack, to see if you install it to both games before EET). Actually, having beta reports could be useful in some cases, I accepted Arcanecoast bugreports about my EET patches.

Just don't combine EET 13.4 with EE Fixpack, really. 

Also, you'll soon run into problems with BWP anyway... because Microsoft announced the depreciation of VBScript.

EDIT: I even agreed with adding correctBG1fr to that list back then: https://github.com/Gibberlings3/EET/pull/84#issuecomment-1409238953

36 minutes ago, JohnBob said:

EET, it's a patch for the CorrectFr being integrated on the compat.tbl (Pull request sended and pending by the game creator)

I did look at the patches. That's why I know the EET entry also adds the EE Fixpack. Yes, that change is in master already, but that's only a preparation step and depite the fact I filed that months ago, I know that the end result back then led to EET installed with warnings (although atleast that allows installing) and I am still waiting for the first release to review what are the warnings and how to resolve them. That's exactly the kind of change which necessitates the transparency, because that shouldn't be backported to 13.4. Use master if you want EE Fixpack compat or if you already install the EE Fixpack through it.

EDIT: This is relevant because master has the SoD dragon breath fix after 13.4 and EE Fixpack also touches that (to fix sectypes on dragon breaths), so that is one clear case where this difference can already snowball.

Could IWDification random weapons cause the Black Talon issue? We already had reports that SCS didn't generate the ranged attack block for the dummy random ITM files currently.

Oh, it isn't installed here. Then I have no idea either.

Regarding the list - Extended Animations should be depreciated outright, it's in EE 1.3 format. Deep Gnomes should be deleted, that's a trimmed version of Aurora's Shoes and Boots.

m7multikit should be before Dual-to-Kit and/or even replaced with sg_multikits. Dual-to-Kit should be after EET_end.

2 hours ago, Alywena said:

The aim is definitely not to have a BWPFixpack v2, but rather to be able to include patches for mods that haven't been updated for a while.

Chaos Sorcerer? EET? NPC_EE? Refinements? MiH_EQ?

From my quick glimpse, the amount of mods whose authors are active enough to merge patches vastly outnumber the actually abandoned mods you're attempting to patch so I'm not buying this at all. I don't want my mods involved in this BWS-FR.

59 minutes ago, suy said:

Please, pretty please, whatever you choose, don't go with allowing multiline entries. This is not the default behavior, and as I've shown, I've tried different INI parser libraries out there and no one supports it. It means throwing away perfectly good code that already exists in battle tested libraries, and that follows the loosely specified conventions. Going that route is a huge incentive to not support those files at all for me.

PS: the criticism of TOML is unfair. No one should care that TOML supports times and dates, because every field of a mod metadata would only contain strings. So the mod metadata of any given mod that I've ever seen is just the same as no, but with quoted values. PI should have no issue in adding a new library and linking statically, which I assume is what you are doing already for having the application in a single file. But anyway, let's ignore TOML or other formats entirely, and instead focus on fixing the INI definition, please.

Call the format PI-INI which supports multiline and bam, you defined a new format which works. Case solved.

OpenRA did this same. It has it's own YAML-derivate which uses tabs instead of spaces and lacks half of the more complicated scenarios of the format. They ended up calling it MiniYAML in the end and even filed PRs at one point to GitHUb's own parser because the syntax highlighter just rendered all the config files being marked as wrong. Yet they didn't reverted from MiniYAML to regular YAML.

Being pedantic just for the sake of being pedantic doesn't add anything to the table. The PI metadata is a moreorless a community standrad by now, and widely adopted.