Mod Compatibility List for EET

[subtledoctor]

Any idea why EET might be messing up my armor mod? It doesn't use static item lists, it filters by properties like item type, equipped appearance, unidentified name string, enchantment, etc. The way it is designed, I thought it would be guaranteed to maintain compatibility.

 

Full user report here:

https://forums.beamdog.com/discussion/comment/849073/#Comment_849073

[K4thos]

Any idea why EET might be messing up my armor mod? It doesn't use static item lists, it filters by properties like item type, equipped appearance, unidentified name string, enchantment, etc. The way it is designed, I thought it would be guaranteed to maintain compatibility.

 

Full user report here:

https://forums.beamdog.com/discussion/comment/849073/#Comment_849073

if you need some files uploaded for comparison than let me know. Things like item type, equipped appearance, enchantment properties are not affected by resource importation (the only thing that may be changed automatically is "Disable display string" so that items from BG:EE prevents displaying equivalent BG2:EE strings).

 

If you are basing it on string number without using READ_STRREF than keep in mind that resources imported from BG:EE / SoD uses original string number + 200000 as discussed in the other topic about merging TLKs. This can be changed for general item names to use BG2 string numbers if you can provide a list for this (in such case those strings will added to the strref_tlk array, like general item descriptions that are already listed there in order to unify them for both games using BG2:EE descriptions as a base).

 

edit: in other words strings listed in strref_tlk array are using BG2:EE string values rather than BG:EE + 200000. No problem with expanding it as long as the same string exists in both BG:EE and BG2:EE (doesn't matter if it's under the same string number or different one).

Edited February 12, 2017 by K4thos

[subtledoctor]

Oh, interesting. I don't use static strings, I read the strrefs. For example, for chainmails, I read the strref value at 0x08 for basic unenchanted chain armor, chan01.itm. Then I look for any other armors that use the same strref for their unidebtified name; this should capture all chain armors and omit all scale/splint armors and other non-chainmail armor that uses the chainmail equipped appearance.

 

Ordinarily this will work with other mods, since even if they change that string, there will still only be one strref with that string and it should still be valid for those armor types.

 

But EET creates a situation that Weidu generally tries to avoid: multiple strrefs with identical strings. And various items will be coded with different values at 0x08, even if the string they use there is the same. That's... not good.

 

Maybe EET could 'normalize' things by reading the strref at 0x08, reading the string in that strref, and then SAY that string whenever the item's text STRING_EQUAL_CASE the text in the strref.

 

I suppose one way to get around it in the meantime is to run my mod on BGEE before EET, and then run it again on. BG2EE after eet_core. Just have to code it somehow to skip an item if it has already been affected. Maybe set some useless flag, or something.

 

Does the weidu.log carry over from BGEE? If it is installed in each game, would the mod see itself as already present and mistakenly treat it as a reinstallation?

[Roxanne]

Does the weidu.log carry over from BGEE? If it is installed in each game, would the mod see itself as already present and mistakenly treat it as a reinstallation?

 

EET puts a copy of BGEE's weidu.log into the BG2EE folder (There it is named WeiDU-BGEE.log - The Weidu.log in the BG2EE folder is the one for the part2 after EET, EET is thus the first mod in this one), A mod installing in BG2EE part can check for any mod component in the BGEE part.

 

Example

ACTION_IF NOT (FILE_CONTAINS ~WeiDU-BGEE.log~ ~BG1NPC\.tp2. #[0-9]+ #16 ~) BEGIN

// checks for component 16 of BG1NPC mod

Edited February 12, 2017 by Roxanne

[K4thos]

Maybe EET could 'normalize' things by reading the strref at 0x08, reading the string in that strref, and then SAY that string whenever the item's text STRING_EQUAL_CASE the text in the strref.

 

Strings are not always exactly the same between BG:EE and BG2:EE, especially in non-English versions of the games (Beamdog spent tons of time unifing English text, I doubt it's the case in other languages), so such comparssion wouldn't be 100% accurate. That's the reason why strref_tlk array already has all general items descriptions listed there (to unify them for both games during installation using BG2:EE string numbers). If you can provide a list of strings that you're using than they can be added into strref_tlk array without any issues or save compatibility problems (which would be the case if you use SAY).

 

I suppose one way to get around it in the meantime is to run my mod on BGEE before EET, and then run it again on. BG2EE after eet_core. Just have to code it somehow to skip an item if it has already been affected. Maybe set some useless flag, or something.

no, that doesn't make sense. Unifying string numbers for general item names in BG:EE and BG2:EE content directly in EET is better approach if there are mods that need it.

Edited February 12, 2017 by K4thos

[subtledoctor]

Unifying string numbers for general item names in BG:EE and BG2:EE content directly in EET is better approach if there are mods that need it.

Agreed. I didn't understand that EET already does something like this.

 

I don't use any particular strref in the mod, since I want it to work equally in different games. But it's not hard to figure out the particular strrefs it would return in unmodded BGEE and BG2EE. Here is the relevant code:

 

COPY_EXISTING ~leat01.itm~ ~override~
	READ_LONG 0x08 leather_strref
COPY_EXISTING ~leat04.itm~ ~override~
	READ_LONG 0x08 studded_strref
COPY_EXISTING ~leat10.itm~ ~override~
	READ_LONG 0x08 hide_strref
COPY_EXISTING ~chan01.itm~ ~override~
	READ_LONG 0x08 chain_strref
COPY_EXISTING ~chan04.itm~ ~override~
	READ_LONG 0x08 splint_strref
COPY_EXISTING ~plat01.itm~ ~override~
	READ_LONG 0x08 plate_strref
COPY_EXISTING ~plat05.itm~ ~override~
	READ_LONG 0x08 fullplate_strref
ACTION_IF FILE_EXISTS_IN_GAME ~plat18.itm~ BEGIN
	COPY_EXISTING ~plat18.itm~ ~override~
	  READ_LONG 0x08 scale_strref
END

Edited June 14, 2017 by subtledoctor

[Jarno Mikkola]

...

Or you could do the sensible thing and just write the line you like into the item, not read it from every freaking idiot file out there and dingdong it around as a variable around with weidu.... until you need to clear all variables cause you are an idiot, for doing so.

[subtledoctor]

Umm... write what line? My mod doesn't write anything. What are you even talking about?

 

If you have better code to distinguish studded leather armors from leather armors, and full plate armor from plate armors, I'm all ears...

[K4thos]

done (via printing your code in both BG:EE and BG2:EE), looks like both games uses the same strrefs.

    2890 => 2890   //Leather Armor
    6664 => 6664   //Studded Leather Armor
    22714 => 22714 //Hide Armor
    214 => 214     //Chain Mail
    6677 => 6677   //Splint Mail
    267 => 267     //Plate Mail
    6642 => 6642   //Full Plate Mail
    6686 => 6686   //Ankheg Plate Mail

I will add them in the next version. If you need to reinstall EET now with this change simply add above strings to lib/strref_tables.tph strref_tlk array before installation. Ideally all general items names could be included but I'm too lazy to check the strings now. Will be done in future.

Edited February 13, 2017 by K4thos

[Jarno Mikkola]

Umm... write what line? My mod doesn't write anything. What are you even talking about?

You know, if the file has a ~Leather Armor~ line in it, you can actually code it in the copy phase, not rely on the cheapass export function to reliably retrofit the copied content, as that will eventually not happen ... so yeah, when you said "My mod doesn't write anything." That's the problem. Learn TO.

This is needed for all the strings that the file needs... so for example, if you have an item which lore value is zero/it's already id'ed, you can write ~rats ass~ to the unidentified line, but if you know that it's not that when you set the value to be higher, well then you don't write ~rats ass~ to the file.

Edited February 13, 2017 by Jarno Mikkola

[subtledoctor]

Again, othing is written to that line. You're not understanding what the mod does. And I still don't know what you're talking about with 'export functions' etc.

 

In order to patch leather armors differently from studded leather armors, you need to tell them apart. I.e. Before you can write anything to any line, you need to know which items you are going to patch. There is nothing in the .itm files to reliably distinguish leather from studded leather - go ahead and look.

 

But, most leather armors will have the same string as leat01.itm at 0x08. So I need to read it from the base armor, and match it to other armors. Wherever there's a match, apply the patches. Originally I used STRING_EQUAL_CASE, which would actually work fine with EET, but then it could not be traified. So instead I match the strref. Which worked great until EET's combination of both .tlk files made it unreliable. With k4thos' strref_tlk array, it looks like the issue will be fixed.

[Jarno Mikkola]

In order to patch leather armors differently from studded leather armors, you need to tell them apart. I.e. Before you can write anything to any line, you need to know which items you are going to patch. There is nothing in the .itm files to reliably distinguish leather from studded leather - go ahead and look.

 

But, most leather armors will have the same string as leat01.itm at 0x08.

Hmm, tell me, if the item has a leather armor as the correct animation, it's enchantment is +3 and it's AC is ...12, is it a traditional Leather armor, and thus should you patch it as if it were a Leather armor ? All the while it has distinctively ~Leather Armor~ set at the offset 0x08, cause... the source file had it ?

In reverse, if it has AC of 5 or 6(different cases, so the answer should reflect that), and it has all the other values, which one is it and how should you patch it ? Distinct enough for you ? And if it's out of the bounds, just don't patch the item. As it's out of the bounds.

Enchantment level is the offset 0x60, animation is 0x22, and the AC is one, and multiple of the effects, as there can be plenty of side effects plah plha plah.

 

Now, of course the above thing about writing the values... is when you make new items, say Leather Armor of traladaladoom... when you make it, you need to actually edit the file from something, even if it's a leat01.itm, just renamed, and exported to the mod files... or even weidu cloned. You shouldn't just stop at copy.... you need to write stuff to it so it's actually a distinct item, and not a clone of leat01.itm with -1 in all the string references, though most of the time, that's better than not have them set to -1. As lerks like you usually assume AC values and prefer to use delete/clone effect without reading the actual value the item HAD before your edits.

Edited February 13, 2017 by Jarno Mikkola

[Blash2]

Leather Armor of traladaladoom

 

I want it.

[subtledoctor]

The mod doesn't add any armors, so your concerns sbout writing to new files are null.

 

You proposed technique is clever, so clever there's no way I could have already considered it... except oh wait, go ahead and look at offset 0x60 on every enchanted armor and tell me what you see there. Yeah - nothing.

 

So I could look at the "+x" value in the identified name string... except tons of armors don't include that. I actually need to know the enchantment level - it's one of the variables in my .ini file and the mod actually fills out the missing value at 0x60. But to determine the enchantment level based on the armor type and AC score... you need to know the armor type... chicken, meet egg.

 

As for ALTER_EFFECT and CLONE_EFFECT... if there were a READ_EFFECT function I would happily use it. But there isn't. ALTER_ and CLONE_EFFECT are specifically coded to filter themselves according to input criteria. That's why they have all of those "match_value" variables. You want people not to use that?? If BWS reacts spastically to literally harmless errors, that's hardly my fault.

 

Anyway this has been interesting but very off-topic. Let's give the thread back to its intended purpose.

Edited February 13, 2017 by subtledoctor

[DavidW]

The "enchantment" field at 0x60 is really just for weapons - it's what spells like Mantle use to determine if you can hit the creature. So it's not usually set for armor.

 

If you want something more robust than checking the string, you can look at the AC bonuses vs specific types. (So leather armor gives a 2-point AC penalty vs piercing and missiles, while studded leather gives bonuses.) The following works, I think (tested, but not that thoroughly):

 

////////////////////////////////////////////////////////////////////////////////////////
/// Armor-type-finding function
///
/// use example: LAF armor_type STR_VAR item=chan01 RET success type END
///
/// success=1 if we find the armor type, 0 if we don't
/// type is one of: file_does_not_exist, not_armor, robes, leather, studded_leather, hide, chain, splint, plate, full_plate, scale, unknown
///
/// if we can't work it out, but it is armor, we try to guess (but still set success=0)
////////////////////////////////////////////////////////////////////////////////////////

DEFINE_ACTION_FUNCTION armor_type
STR_VAR item=""
RET type success
BEGIN
OUTER_SET success=0
ACTION_IF FILE_EXISTS_IN_GAME "%item%.itm" BEGIN
COPY_EXISTING "%item%.itm" override
// start by looking at the category, to confirm it's actually armor
PATCH_IF !((SHORT_AT 0x1c)=2) BEGIN
SET success=1
SPRINT type not_armor
END
PATCH_IF !success BEGIN
// look at the animation type
READ_ASCII 0x22 anim_type (2)
PATCH_MATCH "%anim_type%" WITH
2W 3W 4W BEGIN // robes
SET success=1
SPRINT type robes
END
// end of 2W 3W 4W section
2A BEGIN // leather armor - could be ordinary,studded,hide
LPF read_armor_bonus_vs_type RET slashing piercing crushing missile END
PATCH_IF (piercing="-2" && missile="-2") BEGIN // either leather or hide
PATCH_IF (SHORT_AT 0x26)=6 BEGIN // if you need strength 6 (rather than 4), it's hide
SET success=1
SPRINT type hide
END ELSE BEGIN
SET success=1
SPRINT type leather
END
END ELSE
PATCH_IF (slashing=2 && piercing=1 && missile=1) BEGIN // studded leather
SET success=1
SPRINT type studded_leather
END ELSE BEGIN
SET success=0
SPRINT type leather // guess leather
END
END
// end of 2A section
3A BEGIN // chain or splint
LPF read_armor_bonus_vs_type RET slashing piercing crushing missile END
PATCH_IF (slashing=2 && crushing="-2") BEGIN // chain mail
SET success=1
SPRINT type chain
END ELSE
PATCH_IF (piercing=1 && missile=1 && crushing=2) BEGIN
SET success=1
SPRINT type splint
END ELSE BEGIN
SET success=0
SPRINT type chain // guess chain
END
END
// end of 3A section
4A BEGIN // plate or full plate
LPF read_armor_bonus_vs_type RET slashing piercing crushing missile END
PATCH_IF (slashing=3 && missile=0 && piercing=0) BEGIN // plate mail
SET success=1
SPRINT type plate
END ELSE
PATCH_IF (piercing=3 && missile=3 && slashing=4) BEGIN
SET success=1
SPRINT type full_plate
END ELSE
PATCH_IF (slashing=3 && missile=1 && piercing=1) BEGIN // scale male - just a couple of dragon armors
SET success=1
SPRINT type scale
END ELSE BEGIN
SET success=0
SPRINT type plate // guess plate
END
END
// end of 4A section
DEFAULT
SET success=0
SPRINT type robes // guess robes
END
END
BUT_ONLY
END ELSE BEGIN
OUTER_SET success=0
OUTER_SPRINT type file_does_not_exist
END
END

////////////////////////////////////////////////////////////////////////////////////////
/// Helper function. Returns the vs-type bonuses for armor
////////////////////////////////////////////////////////////////////////////////////////


DEFINE_PATCH_FUNCTION read_armor_bonus_vs_type
RET slashing piercing crushing missile
BEGIN
DEFINE_ASSOCIATIVE_ARRAY type_map BEGIN
1=>crushing
2=>missile
4=>piercing
8=>slashing
END
PHP_EACH type_map AS discard=>value BEGIN
SET "%value%"=0
END
GET_OFFSET_ARRAY offsets ITM_V10_GEN_EFFECTS
PHP_EACH offsets AS discard=>offset BEGIN
PATCH_IF (SHORT_AT offset)=0 BEGIN // is an AC modification
READ_LONG (0x8 + offset) type
PHP_EACH type_map AS key=>value BEGIN
PATCH_IF type=key BEGIN
READ_LONG (0x4 + offset) modifier
SET "%value%"=modifier
END
END
END
END
END

Edited February 13, 2017 by DavidW