Mod Compatibility List for EET

[Jarno Mikkola]

... except oh wait, go ahead and look at offset 0x60 on every enchanted armor and tell me what you see there. Yeah - nothing.

Well, I looked, and nominate the chain09-chain20.itm for your observation, they have appropriate enchantment levels... the 01-08 and 21 might be stupidity of itm maker, but what else is new. It's not like the files are 17 years old, ouh yeah, they are.... spoilers, they are likely to come strait from BG1. Well, I looked at BG2EE file, if that matters for you.

[Lightbringer]

 

Leather Armor of traladaladoom

 

I want it.

 

Yes. That and the Warhammer of Greater Potato, a great warrior maketh.

[DavidW]

 

... except oh wait, go ahead and look at offset 0x60 on every enchanted armor and tell me what you see there. Yeah - nothing.

Well, I looked, and nominate the chain09-chain20.itm for your observation, they have appropriate enchantment levels... the 01-08 and 21 might be stupidity of itm maker, but what else is new. It's not like the files are 17 years old, ouh yeah, they are.... spoilers, they are likely to come strait from BG1. Well, I looked at BG2EE file, if that matters for you.

 

I'm pretty sure that there's no reason for the enchantment field to be accurate: it's inert except for weapons.

[subtledoctor]

Well, the reason for the field to be filled out is that within the ruleset these items do in fact have an enchantment value, and this field is designed to represent that value. But yes, when the item also has a "base AC" field then the enclhantment value has no mechanical purpose. So it's not surprising that it is mostly left blank.

 

That function is nice - I really was being honest when I said "I'm all ears" if anyone had a good technique! - but it strikes me that those values might be subject to change by other mods. Whereas, I feel like very few people will bother changing the 0x08 value. Other than this discrete issue with EET, the mod has been working well.

 

But really with something like this, the more redundancies the better. So maybe it's worth adding code looking at AC vs. damage type to catch what my code misses. That would reduce the amount of corrections that need static item lists. But anyway, like I say, this is interesting but OT at this point.

[Jarno Mikkola]

Whereas, I feel like very few people will bother changing the 0x08 value. Other than this discrete issue with EET, the mod has been working well.

Have you ever heard of the fact that if "I won't do it, no body else will bother do it either ?" It's not like you couldn't bother to assign the values to the -known and well documented files in question, if they don't have a value assigned, they all have a +x in their names and all. Ouh but you can, actually. So long as won't with mod added, that's the line you shouldn't cross. Or shouldn't bother to try to.

 

I'm pretty sure that there's no reason for the enchantment field to be accurate: it's inert except for weapons.

And ? Iow. So what ?

[DavidW]

 

Whereas, I feel like very few people will bother changing the 0x08 value. Other than this discrete issue with EET, the mod has been working well.

Have you ever heard of the fact that if "I won't do it, no body else will bother do it either ?" It's not like you couldn't bother to assign the values to the -known and well documented files in question, if they don't have a value assigned, they all have a +x in their names and all. Ouh but you can, actually. So long as won't with mod added, that's the line you shouldn't cross. Or shouldn't bother to try to.

 

Not for the first time, I have no idea what this means.

 

I think it's a judgement call whether subtledoctor's way of detecting armor types or mine is better. Ultimately, there's no 100% reliable way.

 

I'm pretty sure that there's no reason for the enchantment field to be accurate: it's inert except for weapons.

And ? Iow. So what ?

 

So there's no real reason to think of it as an "enchantment" field and not a "weapon enchantment" field.

[Jarno Mikkola]

I think it's a judgement call whether subtledoctor's way of detecting armor types or mine is better. Ultimately, there's no 100% reliable way.

...

So there's no real reason to think of it as an "enchantment" field and not a "weapon enchantment" field.

Unless you make it as such, which you can with updating this field (if it's unused, aka vanilla zero). Easy ?

The BG2 Fixpack/Tweakpack/EET/etc could easily handle these kinds of updates ... but any regular mod can do the same, if they are not intrested, as seems.

And again, most of the items that don't have a(the correctly) assigned values are ones that never were likely programmed to the current protection system featured in BG2, but to the BG1's.

[subtledoctor]

It's not like you couldn't bother to assign the values to the -known and well documented files in question, if they don't have a value assigned, they all have a +x in their names and all.

A number of armors do *not* have a "+x" value in their identified name (especially in IWDEE, I'm still collecting those). And some may be changed by mods like IR that are installed first. But yes, the mod already error corrects in its first phase, assigning the proper strref at 0x08 to vanilla armors with a known type, and it assigns an enchantment value at 0x60 to all armors (reading from the identified name, and using a static list for vanilla armors known to be missing it in their identified name. Then in the 2nd phase, it uses the armor type and enchantment value to set characteristics like AC, DR, thieving penalties, etc.

 

I think it's a judgement call whether subtledoctor's way of detecting armor types or mine is better. Ultimately, there's no 100% reliable way.

Yes, each would likely work well enough. I talked with the IR folks about the virtues of using static lists vs. dynamically reading item stats (in an environment of renewed interest in creating mods). I mean, literally the only reason I made this mod is because FPPS uses static lists but is no longer being maintained. But dynamic code like this will never be 100% reliable when considering what modders might add. Heck, even some of Beamdog's new items in SoD are not coded 'properly' (wrong values in 0x08 etc.).

 

The ideal would be to apply several systems in a redundant way, and then capture any items that slip through the net(s) with a static list based on user reports. I haven't yet found it necessary to add a 2nd 'net' but it's a good idea in the abstract.

[Roxanne]

For information - work for BG2EE/EET compatible Longer Road has started.

http://www.shsforums.net/topic/59126-longer-road-for-ee-lree/

 

Should be available in a few weeks after regression testing has been done.

Edited February 26, 2017 by Roxanne

[Brunardo]

Hey Everyone I need some help as downloaded BWS and tried with start set up: update if Needed VBD but Script show instead got Line 15/Char 5 Error: the system cannot find the file specified, code 80070002 Source (null)...started find with set up without update but then realized the downloads were never happening, any help on what Im doing wrong?

[Brunardo]

Hey Everyone I need some help as downloaded BWS and tried with start set up: update if Needed VBD but Script show instead got Line 15/Char 5 Error: the system cannot find the file specified, code 80070002 Source (null)...started find with set up without update but then realized the downloads were never happening, any help on what Im doing wrong?

[Roxanne]

Hey Everyone I need some help as downloaded BWS and tried with start set up: update if Needed VBD but Script show instead got Line 15/Char 5 Error: the system cannot find the file specified, code 80070002 Source (null)...started find with set up without update but then realized the downloads were never happening, any help on what Im doing wrong?

Questions about BWS itself are best asked here http://www.shsforums.net/topic/56670-big-world-setup-an-attempt-to-update-the-program/.

[Jarno Mikkola]

 

It's not like you couldn't bother to assign the values to the -known and well documented files in question, if they don't have a value assigned, they all have a +x in their names and all.

A number of armors do *not* have a "+x" value in their identified name (especial

 

Well, I was talking about these items..."the chain01-chain08.itm and '21.itm" they are all vanilla items that have a +x in them. And I did indicate that you should not try to build your arguments on mod added item, like those that would be included if you import Icewind Dale into this game.

But then again you would need to read more than one post of mine to understand this.

Edited March 2, 2017 by Jarno Mikkola

[Brunardo]

Thanks for the link Roxanne, Had another question more for this thread I think - EET set up with BWS was telling me couldnt find SOD so I download BGEE/SOD from Beamdog and was fine after finding the folder but I noticed some of the mods that were on BGEE such as BP, solaufein etc were not coming up on EET any more...guessing its not compatible for the trilogy although if I take out SOD and had only BGEE/BG2EE then its ok? should I download them before/after?

[Roxanne]

Thanks for the link Roxanne, Had another question more for this thread I think - EET set up with BWS was telling me couldnt find SOD so I download BGEE/SOD from Beamdog and was fine after finding the folder but I noticed some of the mods that were on BGEE such as BP, solaufein etc were not coming up on EET any more...guessing its not compatible for the trilogy although if I take out SOD and had only BGEE/BG2EE then its ok? should I download them before/after?

That is more an error in BWS again (if your memory is correct) since BP or Solofein should never be on BGEE (Solaufein is a BG2 mod). And none of them are EET compatible. (refer to the first post of this thread). There is a new Solaufein mod you find on that list (Alpha status). On that list you also see that some mods install on BGEE prior EET and some on BG2EE after you installed EET - however if you use BWS then the tool will do all of this for you.

 

PS - to use EET you ALWAYS need SoD.