Automated description updates

[DavidW]

I've written a bit of code that tries to automatically update the 'STATISTICS' field of an item description. It automatically sets the standard weapon and armor features, the weight, and (on classic BG2) the 'usable by/unusable by' descriptions. The description is formatted in either EE or classic format, as appropriate. 

The code can't automatically build special details like bonuses to hit against certain creatures, on-equip powers, or special abilities, but it does leave them in place from the existing description.

I've packaged it as a mod for clarity, but there are really only 2 files: the code (lib_itemdesc.tph) and a tra file (dw_itemdesc.tra). You need to INCLUDE the former and put the latter wherever you keep your .tra files, and you need to set the variable 'sfo_tra_loc' to the path for your tra files.

Here's an example of use:

INCLUDE "%MOD_FOLDER%/lib/lib_itemdesc.tph" // includes the library
OUTER_SPRINT "sfo_tra_loc" "%MOD_FOLDER%/lang" // needs to point to wherever you keep tra files
LAM itemdesc_initialize // do once, to set the code up

COPY_EXISTING "chan03.itm" override // whatever your item might be
	LPF itemdesc END
BUT_ONLY

There's also a much more lightweight version that just updates the armor string:

INCLUDE "%MOD_FOLDER%/lib/lib_itemdesc.tph" // includes the library
OUTER_SPRINT "sfo_tra_loc" "%MOD_FOLDER%/lang" // needs to point to wherever you keep tra files
LAM itemdesc_initialize // do once, to set the code up

COPY_EXISTING "chan03.itm" override // whatever your item might be
	LPF itemdesc_armor END
BUT_ONLY

EDIT: I've moved this to github. Gibberlings3/itemdesc: Automated generation of item descriptions (this is a tool for mod-users) (github.com

 

[Bartimaeus]

Completely unrelated, but any time I download an attachment from Gibberlings 3, my browser (Firefox) tells me it's malware and I have to manually allow it. Whether it's just an .itm, a .spl, your .zip up there, it always flags everything attached here. I can even upload the same file somewhere else (e.g. my dropbox) without changing it and redownload it, and it doesn't flag it...and then I click on your attachment again, and once more, it is flagged. Really weird.

Right now, I'm trying to test the "LPF itemdesc END" with IR's whitelist of "approved" armors, but I'm running into piles of "SET_STRING out of range"s. These seem to occur on unusable .itms that exist in my game (including vanilla items!), such as vischan1, vischan2, et cetera, plat07, plat98, plat99, dleat01, et cetera, et cetera. I can't help but notice that these seem to be all items who have a full unidentified description set as if they were an identified, non-magical item with no identified description set. I removed the ones that exist in my game that break the game from the list, but I am a bit concerned about including this code in other people's games that have many more items in the approved whitelist than I do that will break their installation processes because of the same kinds of errors. This is a huge (+700) list of approved armors to patch, so similar errors are bound to occur...right?

Hmm, perhaps a safety measure would be that if there is no identified description, simply set the identified description to the same as the unidentified description (and if neither are set, simply skip the item in question entirely)? For the items that were problems in my installation, doing this in advance does appear to fix the issue. Actually, I'm pretty I can probably do this myself with a couple of byte reads and writes, to be honest, so maybe don't bother unless you think you could do it quickly and elegantly?

The "generate the 'not usable by' list" function does not currently include kits, which means e.g. a plate mail armor which originally said...

Quote

Not Usable By:
 Bard
 Druid
 Mage
 Monk
 Thief
 Archer
 Barbarian
 Beast Master
 Kensai
 Stalker

...turns into...

Quote

Not Usable By:
 Bard
 Druid
 Mage
 Monk
 Thief

Beyond those two issues, my tests on armor in both ToBEx and BG2EE games seems to suggest it works well. Thanks a ton, @DavidW, . I'll try to test weapons at some point later.

Edited September 25, 2021 by Bartimaeus

[DavidW]

Oh, yes, I missed the no-description possibility. I read the UNIDENTIFIED_DESCRIPTION field,  get -1, try to look up strref -1 in dialog.tlk, and hijinks ensure. New version fixes it. (I've put this on github to make it easier to update.)

As for kits: it would be very easy to add them to the usable/unusable list, but it looked to me as if classic BG2 usually doesn't do this? E.g armor isn't marked as unusable by kensai, potions aren't marked as unusable by wizard slayers. Happy to do whatever's more sensible here - I've made only a fairly cursory examination of classic BG2's display conventions.

[Bartimaeus]

30 minutes ago, DavidW said:

Oh, yes, I missed the no-description possibility. I read the UNIDENTIFIED_DESCRIPTION field,  get -1, try to look up strref -1 in dialog.tlk, and hijinks ensure. New version fixes it. (I've put this on github to make it easier to update.)

As for kits: it would be very easy to add them to the usable/unusable list, but it looked to me as if classic BG2 usually doesn't do this? E.g armor isn't marked as unusable by kensai, potions aren't marked as unusable by wizard slayers. Happy to do whatever's more sensible here - I've made only a fairly cursory examination of classic BG2's display conventions.

You're right, that seems to be an IR invention that I was not aware of. And of course, the EEs automatically handle it by having their own class/kit unusabilities automatically generated by reading the .itm directly. I'll try out the new semi-soon.

[Bartimaeus]

Doing some different tests. Now it installs on vanilla without crashing while still using the IR list of armors, so that's a good measure for its compatibility. However, vanilla Red Dragon Scale's description goes from...

Quote

Dragon Scale armor is light of weight, strong, and resistant to fire.  Because of these properties it is much sought after, but finding, let alone slaying, a powerful ancient dragon is near impossible.  It is usually easier to search for an existing suit, such as this one.  One should be careful wearing it near dragons, however, particularly red ones.

STATISTICS:

Bonuses: +50% Fire Resistance
Armor Class: -1
Weight: 30
Requires: 8 Strength
Not Usable By:
 Bard
 Mage
 Thief

...to...

Quote

 

STATISTICS:

Bonuses: +50% Fire Resistance

Armor Class: -1
Weight: 30
Requires: 8 Strength
Not Usable By:
 Bard
 Mage
 Monk
 Thief

I don't see anything particularly odd about Red Dragon Scale's description that would leave me to believe that the lore text should be stripped (also, lol @ Monk not being mentioned as an unusability in the original description), but there must be something. Similarly, armors with special bonuses/abilities tend to have said descriptions of bonuses/abilities shunted up directly to the STATISTICS like so:

Quote

STATISTICS:
   +50% Resistance to Cold
   Cast Cone of Cold 3 times/day

Armor Class: -2
Weight: 15
Requires: 8 Strength
Not Usable By:
 Mage
 Monk

I imagine this is because vanilla item descriptions are a little dumb and don't have enough separation between special bonuses/abilities like either IR or the EEs do (which, now that I think about it, the EEs actually adopted many of the same conventions IR uses, like "equipped abilities" and "special abilities" and including the kits in unusabilities...hmm). Quite frankly, I don't care about vanilla descriptions, though, but many mod-added items are sure to use similarly lax formatting standards.

An oddity in IRR's Pride of the Order occurred. From...

Quote

Usable By:
 Lawful Good characters

...to...

Quote

Usable By:
 Good-aligned characters
 Lawful-aligned characters
Not Usable By:
 Bard
 Druid
 Mage
 Monk
 Thief

I would say this is more the fault of my description of Pride of the Order, though, because simply saying "Lawful Good characters" is obviously a very incomplete description, but it does represent another vector where issues with others' descriptions may arise. Although...it's odd here, because while I originally wrote "Lawful Good characters" (which I'm going to change, by the way), your function split it into the two different lines and THEN also added the unusabilities.Weird. Regardless, this is leading me to believe that because of the variety of different formats offered between games and mods (many of which are sure to not have as strict formatting standards as e.g. IR or the EEs), it's probably not a wise idea to use the the full re-write indiscriminately, not when you do not already know what the results will be - there's just too many possibilities for errors and inconsistencies. I still need to test how this looks converting a non-EE IRR description to an EE description, though. The single line "Armor Class" rewrite, on the other hand, currently results in the same errors as I was getting before with the fuller re-write:

Edited September 26, 2021 by Bartimaeus

[DavidW]

OK: some of this is easy to fix. 

• the deleted dragon plate text was a dumb error: I was deleting too enthusiastically, and ended up deleting any text row starting with 'D'. (!)
• I hadn't anticipated complex alignment restrictions because the vanilla game seems to use only one set at a time, but they're not too hard to allow for.
• Extending the previous fix to the more minimal itemdesc_armor is easy enough.

These are all corrected on github now.

The other issues are a bit more fundamental. The converter generates basic details like AC, usability restrictions, weight, speed factor, etc. directly from the CRE file, and just deletes those details from the description before rebuilding them. (So your 'Lawful Good characters' line isn't being split up: it's just being deleted, and then the converter was adding 'Lawful-aligned characters' and 'Good-aligned characters' as a result of parsing the usability flags.) But it's not viable to auto-generate special abilities (or at the least: it's not viable in the time I was willing to give to the project!) so those are just left in place from the original description text. For the most part I couldn't work out any systematic conventions for where that information is supposed to go in the STATISTICS block - oBG2 seems to put it in any old place - so I just let it float to the top of the STATISTICS section and rebuilt the standard block underneath it.

(Exception: there seemed to be a systematic convention that 'Special: xx' or 'Bonus: xx' went underneath the Damage: line in weapon descriptions, so I think I do reproduce that.)

If you can describe (what you take to be) the actual conventions for how oBG2 STATISTICS blocks lay out special abilities, I can try to replicate them.

[Bartimaeus]

2 hours ago, DavidW said:

But it's not viable to auto-generate special abilities (or at the least: it's not viable in the time I was willing to give to the project!)

Yeah, please don't bother with that, haha. It can be hard enough to write special abilities/properties in a reasonably short yet human-readable format when you're hand-writing it, I would never want to see what might happen if you tried to machine-generate all of it.

Guess I'll go investigate vanilla descriptions some more. Okay, actually, I did find some examples of this - say, Shuruppak's Plate:

Quote

STATISTICS:
   +1 to Dexterity
   +20% Fire Resistance

I almost feel like this is a matter of ToB vs. SoA, because all of the SoA items I looked at seem to always place it in a "bonus", "special", or "special abilities", "equipped abilities", "combat abilities", or even just "abilities" field or something along those lines, while some ToB stuff like the aforementioned plate (among others) just do...whatever they want. Yeah, to be honest, I don't know what the right call is for vanilla descriptions - I suppose as long as it works for IR's purposes, it doesn't really matter that much. Non-EE's vanilla descriptions are an incredibly inconsistent disaster, it's probably folly to try to repair them. But it's actually for that exact same reason that I have to be careful when I would apply the full re-write, because just doing it on mod-added items en masse is sure to create similar sorts of inconsistencies. So it's probably a fool's errand to run that on anything where you don't already know how it will turn out, .

Thanks for the fixes, I'll do some more investigation and testing tomorrow.