EET's Bugs on new SoA campaign.

[Frenzgyn]

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.

 

[Graion Dilach]

Okay, I am starting to understand this and why this breaks. EET's underlying idea is that instead of allowing to fall back to the defaults for import, offer a customization on the imported items via pulling them from the ToB starting package and then letting the import tables attempt to import something out from it.

The main issue with this is that this setup option is undocumented. I presume your test character (which is the sole piece missing from this report) is a character whose ToB starting armor isn't part of the import01 list.

This wouldn't really break OH_IMPORT from what I'm seeing. If I read this right, OH_IMPORT actually tries to override the defaults, so the EET customization bypassing it is intended behaviour.

I'm a bit conflicted on this part, because I see two ways to resolve this:

• drop the logic altogether via restoring the default import rules to the import tables and forcing the BG1 starting equipment as you propose
• document the customization option in Modder's Notes and write a step into EET_End so that it goes over 25STWEAP.2DA and adds all the armors it can't find to IMPORT01.2DA (and maybe similar steps to the other two IMPORT tables)

I'm not sure which should be the path taken.

Edited November 18, 2023 by Graion Dilach

[Frenzgyn]

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

Edited November 18, 2023 by Frenzgyn

[Graion Dilach]

Yeah, I see it now, apparently OH_IMPORT02 is also used to generify the importable artifacts. I'd be willing to accept the compromise that for the additional unique artifacts handed out for mod-added kits, this functionality would be lost. (Vanilla stuff can be added during the EET import step as well and there we coulda also expand the OH_IMPORT values respectably to similarly degrade the added items in story.)

I'm really not sure what to do here. k4thos's intent is fairly clear now that I've looked into this and my second proposal is in line with his vision, but it is somewhat fragile due to the additional factors thrown in. Your solution is against k4thos's vision but it wouldn't change the current status quo. It's really the moral dilemma what sounds like the hardest take here and not the technical requirements.

Edited November 18, 2023 by Graion Dilach