Frenzgyn

Nah, neverming, already installing, no bothering. I'll post here a few screens of the Montaran and Xzar conversation, so we could check together if it was what you were experiencing. If that is the case, is it the way the mod was created, with Imoen overenthusiastic that try to steal words from the main character.

Very strange. I used BG1NPC with LeUI, UB, QE, Tweak Anthology and plenty of other mods and I never noticed it. Could you be a little more descriptive about the issue? I ask because, if memory serves me well, at the beginning (I guess till Beregost?) Imoen will be quite intrusive in the dilogue, interrupting or superseding the main char, but it's a prank of sort and is quite noticeable. Meanwhile, I will try to reproduce the issue with your mod order, just in case. Is it a BGEE+SOD install, right?

The code for the Nymph Key is M#BKEY and it should indeed Then there is a second key (M#LKEY) to access the lab in one of the closets in the bedroom. Do you remember the version of the mod you were using? Hey, @CamDawg it seems there is indeed a bug in version 8 (version 7 was ok) with some .cre files having their inventory pointing to corrupted items, i tracked theese: m#yclbm1.cre m#ycmcm1.cre m#ydemon.cre m#ygsbm1.cre m#ygsbm2.cre m#ygsbm4.cre m#ygspm1.cre m#ygspm2.cre m#ygspm3.cre m#ygspm4.cre m#ygspm5.cre m#ygswm1.cre m#yguna1.cre m#yimp.cre m#ynymp1.cre m#ynymp2.cre As an example:

Confirm the error. I tried with BG2EE skins. WIth version 4.6 it works. Here anotherr DEBUG file + UI.menu EEUITWEAKS DEBUG+UI-menu.zip

This. It saddens me too see such conflicts arise due to reasons more or less arbitrary or shallow compared to the big picture. I am convinced that half the times a tad of kindness and politeness would go a long way to avoid or sweeten such things. The other half... well, reality is not perfect.

Fuck yes, that's (too) often considered implicit, but any single "thank you" go a long way.

Hey, DavidW I thoght it's better to avoid PMs, so the link to "Speciality Priest" page is wrong, it points locally to the file on your disk, the correct one should be this: https://gibberlings3.github.io/Documentation/readmes/subdocuments_dw/all_priest_desc.html

Lol, I think most of us got it a bit to the extreme, don't know why. It seems much more on the "jastey's almost dead! (in a figurative way)" nuance, than "she will take care of less stuff, less often due to not having as much time anymore". "Press F to pay respect",

As in the report of the issue, it should be (can't check, not have it installed atm) BW05FFAP

If you're not already using the latest bet with the fix, I suppose here you could find your problem and how to solve it: https://github.com/K4thos/TGC1e

That repo is mostly deprecated, still at V1. The last release is 3.1 on G3's website. Github link should be removed from the mod page, or at least it needs a disclaimer.

Well, contacting you in regard to your own mods has still lot of potential and give much choices . Thank you for how you steamrolled issues no matter what till now, will still vouch for you when we will finally get 72h days, so you could easily be on 16h every day of the week in a confy way.

Thank you, I was going mad, I wrongly assumed it was fixed alongside the other EEs.

Sorry for the necroposting, but can anyone confirm that in PSTEE PickPocketFailed() still doesn't work as intended, passing by an Attackedby?

I had a similar problem with RR (if I remember correctly it was component 7) and The Artisan's Kitpack, precisely Warhorn Shaman Kit. RR, due the old DS version purge duplicated entries in STAT.IDS when resorting the file (the destructive behavious was changed in v4) and so the parse errrors popped, in my case it was due to LEVEL_DRAIN_IMMUNITY and DEFENSIVE_MODIFIER missing. I merged CamDawg's and TotorR's forks with Selphira's update to DS and it worked. aTweaks could potentially cause the same issues, but being installed usually very late, it has a low chance to pop during the install.

Oh, shit! I feel... I feel... HYPE!

Strange, they are the exact same files since 2004, with same SHA-1 hash of 5.1. m#ydemon.cre: 6D7C2E2326705FF5A3687A2FD4E51E4B8695A593 m#yimp: F455C3B839933DFFE6C2DBC3BEA21D8123658AC5 Did the two mods you mentioned installed fine before? Any chance your download was somewhat corrupted?

Yes, you're corrrect. I've done lots of test with different classes while undertanding the mechanic, at the end I set on unkitted cleric with pip in warhammer. I was expecting an hammer in Table3, and I always got Varscona+2. Looking a 25STWeap, Cleric wear HELM07 (and that's why I always got Helm of Balduran) and have Varscona+2 in Bag26. Didn't check every single case and every single bag, but probably yes, no class have any of the five armor in import01, so that's why you get lemons. Import02 is a bit more convoluted. If you have one of the items present in the table, fine, if not in vanilla it gives you a SW2H99. SW2H99 is used as a placeholder in OHIMPORT.bcs: if it is present in Table3, It starts checking all the various conditions based on class and proficiencies, in order. Don't know why it sets for Arla's Dragonbane +3 if no condition is met. Is it possible it trips and just sets for the last one? IF Contains("SW2H99","Table3") // Cursed Berserking Sword +3 Global("OH_IMPORT02","GLOBAL",0) THEN RESPONSE #100 SetInterrupt(FALSE) DestroyItem("SW2H99") // Cursed Berserking Sword +3 CreateItem("SLNG05",0,0,0) // Arla's Dragonbane +3 SetGlobal("OH_IMPORT02","GLOBAL",8) SetInterrupt(TRUE) END If you'll go for the second solution, adding the various items in 25STWEAP to the various tables, keep in mind that in OHIMPORT.BCS the global var "OH_IMPORT02" is determined, and it's then used in different scripts - AR0204.BCS, for example - to remove some (unique?) items if the PC already got them during the import: IF HasItem("hamm03","Container3") // Ashideena +2 HasItem("hamm08","Container3") // War Hammer +2 Global("OH_IMPORT02","GLOBAL",2) THEN RESPONSE #100 ActionOverride("Container3",DestroyItem("hamm03")) // Ashideena +2 SetGlobal("OH_IMPORT02","GLOBAL",100) END IF HasItem("hamm03","Container3") // Ashideena +2 HasItem("hamm08","Container3") // War Hammer +2 !Global("OH_IMPORT02","GLOBAL",2) THEN RESPONSE #100 ActionOverride("Container3",DestroyItem("hamm08")) // War Hammer +2 END So, if I am getting it right, ideally every unique item in 25STWEAP should be checked against to avoid duplicates...

I know, why in the Hell one should use EET to start a new SoA campaign? Well... sorry, but since I spotted this, it's worth mentioning. I am aware it's just a nuisance that happens in specific conditions, so a fix it's very low priority. How to repro: Launch a new SoA campaign, create your PC (not imported) and venture forth. AR0602.BCS kicks in: ActionOverride("Table3",TakeItemListPartyNum("IMPORT02",1)) ActionOverride("DuegarClanChief",TakeItemListPartyNum("IMPORT01",1)) ActionOverride("Shelf1",TakeItemListPartyNum("IMPORT03",1)) ActionOverride("DuegarClanChief",TakeItemListPartyNum("IMPORT01",1)) should put the "default" item from import01.2da - Mail of the Dead (CHAN03) - in Ilych droplist. It seems EET change (don't know if it's intentional or not) import01.2da, import02.2da and import03.2da putting null values "*" in place of the three "default" items: CHAN03, SW2H99 and HELM07. Here's an import01.2da of a fresh stripped down EET install: just dlcmerger on BGEE and EET, LEUI-BG1EE and EET_end, all installed with PI): 2DA V1.0 * ITEMS 1 LEAT03 2 CHAN03 3 PLAT02 4 LEAT06 5 CHAN07 And here's the one before installation: 2DA V1.0 CHAN03 ITEMS 1 LEAT03 2 CHAN03 3 PLAT02 4 LEAT06 5 CHAN07 Adding it back seems to fix the issue in EET: Mail of the Dead is back where it should have. As a control, if I edit the three tables with three "*" in an unmodded BG2EE, all three items are gone (and "Oh_import02" is correctly 0). All is well and we could call it a day, right? NOPE. Helm of Balduran is ALWAYS imported and the other item in Table3, that should be based on PC class, profiencies and items (following Ohimport.BCS) is somewhat "broken": it's always Varscona+2 or Arla's Dragonbane+3, depending on class. In EET generated PCs get equipped by 25STWEAP.2DA following CAMPAIGN.2DA (SOA have a "*", so it probably fallback on "default" 25STWEAP of TOB portion). I assume that in vanilla BG2EE campaign.2da is not used at all. Since most of the classes come equipped with HELM07 (Balduran Helm), it oftend supersedes the "default" importing of IMPORT03.2da. Incidentally it was also the "default" item, so it tooks a while to spot for me. For similar reasons (didn't check every single item or bag) it probably break the series of check in OHIMPORT.BCS, and you end up always with the sling or the sword. As a workaround to fix the issue: a) restored import01.2da, import02.2da and import03.2da; b) edited campaign.2da to use "STWEAPON" and not "*" for SOA. I have no idea if this will break anything else, I was just experimenting.

It seems the issue was caused by doing BOTH things jastey suggested in the thread I linked, not one OR the other. All "ee.tra"s already in UTF-8 --> exclude ee.tra fron conversion. (being text used only in EEs, no backporting issues). All "ee.tra"s in ANSI --> let weidu convert them all. Weidu is not a place for compromise . By the way STILL HATE all the encoding/keyboard layouts and what the like stuff. Sorry for al the fuss.

Sorry if it is a stupid comment, but the english traified files (ee, dialogs) are already in UTF-8, with the en dash, after the installation it got the odd ANSI equivalent –. Spanish and German ee and dialogs are in ANSI. This happens because the two file are read assuming to be ANSI and then converted back to UTF-8? That's the codeblock: ACTION_IF GAME_IS ~bg2ee eet~ BEGIN OUTER_SET ee_game = 1 // convert strings to UTF-8 for BGEE/BG2EE ACTION_DEFINE_ARRAY cdreload BEGIN dialogs ee END ACTION_DEFINE_ARRAY cdnoconvert BEGIN setup END // List of tra files that contain ONLY strings for the WeiDU installer and NOT game content LAF HANDLE_CHARSETS INT_VAR infer_charsets = 1 STR_VAR tra_path = ~amber/tra~ noconvert_array = cdnoconvert reload_array = cdreload END END ELSE BEGIN I suppose it is related to this Now, if it is the case how should it be fixed in a solid way? a) Converting english ee.tra into ANSI and let weidu convert it back to UTF-8 when installing on EE/EET? Or b) Purging ee.tra, replacing the various "–", "é" (in "protégés") and "ō" (in "Ninjatō") with something else, for example keeping the oBG2 item description "Nija-to"? "dialogues.tra" is in UTF-8, but have no symbol that create issues. Sheesh. I HATE this stuff.

@CamDawg@jastey Since Amber is not on G3's github, it's a bit clumsy to do bug reports or propose pulls, I usually don't like to ping people, but I assume you two are the mantainers of the mod, so sorry for this exception. 1) BUG (possible leftover of 5.0 encoding-odditiy fixed in 5.1?): Many (if not all) item descriptions have the " – " added. It seems and encoding error. The culprits seem to be english tra. That's what happens in game: 2) In EEs the artworks of quest NPCs (and Vampirized Amber) look *REALLY* awful, since the engine upscale the tiiiny res images created with oBG2 in mind. I've took the time to do a bit of resampling/upscaling. Far - ETREMELY FAR - from perfect, but at least they don't make my eyes bleed anymore, so yeah, I suppose it could be considered an improvement. I've done the same to Amber's portraits, they always looked a bit too blurry to me, but it's barely noticeable. Here is a comparison of the various resolution. In game the smaller pictures looks just the same, the bigger ones are just a tiny bit sharper. And here are the "NPCs", the reason I did all the stuff (sorry Michelle Yeoh, don't have the guts to rework it from the source image ). I've them properly renamed and packed HERE, dropping the three npc files in "ee" folder will just overwrite the low res version during installation on EEs together wit item images, so no change to setup or folder structure is needed. Amber's portait could just be overwritten (or not) by the slightly reworked version. I don't know if this could be integrated in the mod when/if a new version will be released, it's not strictly a "technical update", but it's not *really* a content change either, I tried to preserve the original images (sorry again Michelle), so no - at least - no harm done in sharing, I think. If there are any problems or issues about it, I'll take down the stuff, just let me know.

It seems that droidek, who forked the Neera Banters, also fixed a small typo in ay#redwiz.d, line 41: "AY#NeeraEdwinInParty" was miswritten as "AYNeeraEdwinInParty", so Neera rejoining the party if you kick out Edwin was bugged.

Don't know if it could be useful, but I have a downoload (from the source, not release) of ChattyImoen V15 from last Feb. Usually I do that when there are some fixes in the master not yet released, but can't remember in this specific case. I should name them more carefully in the future. At a glance, looking at the setup of V15, it doesn't have the doubled folders, put labels on some components and (maybe?) removed the component to change Imoen's portraits to BG/SOD/BG2 versions.