Updating Item Descriptions Dynamically

[Luke]

Suppose I want to edit the base damage of daggers from 1d4 to 1d7 -> How can I update the description (unidentified and identified) to take account of my change?

Edited March 10, 2018 by Luke

[Mike1072]

I have a post here that's not specifically directed towards this, but it explains some of the concepts surrounding it. It includes an example that changes the description dynamically, which I've copied below.

READ_STRREF UNIDENTIFIED_DESC description

INNER_PATCH_SAVE new_description ~%description%~ BEGIN
  REPLACE_TEXTUALLY CASE_SENSITIVE ~armor~ ~armour~
  REPLACE_TEXTUALLY CASE_SENSITIVE ~Armor~ ~Armour~
END

SAY_EVALUATED UNIDENTIFIED_DESC ~%new_description%~

That code looks nice but it only updates the unidentified description. To modify both, you could repeat all of that but use DESC instead of UNIDENTIFIED_DESC. Or you could use a loop which lets you perform the same changes on both descriptions. This is the macro we use in IR to do that.

// stolen from BG2 Tweak Pack at G3
// modified to take parameter ~%text_update%~, the macro name of the REPLACE_TEXTUALLY to execute
DEFINE_PATCH_MACRO ~update_item_descriptions~ BEGIN
  FOR (index = 0x54 ; index >= 0x50 ; index -= 4) BEGIN // loop through descriptions
    READ_LONG index valid
    PATCH_IF (valid < 2147483646) AND (valid >= 0) BEGIN // verify description is valid
      READ_STRREF index description
      INNER_PATCH_SAVE new_desc ~%description%~ BEGIN
        LAUNCH_PATCH_MACRO ~%text_update%~
      END
      SAY_EVALUATED index ~%new_desc%~
    END
  END
END

It doesn't contain any of the REPLACE_TEXTUALLYs that determine what changes are made to the text. Those are defined in a separate macro. What you do is call this macro and provide it the name of another macro that has those, like this.

DEFINE_PATCH_MACRO ~update_dagger_text~ BEGIN
  REPLACE_TEXTUALLY ~1d4~ ~1d7~
END

TEXT_SPRINT text_update ~update_dagger_text~
LAUNCH_PATCH_MACRO update_item_descriptions

Both descriptions will then have all instances of 1d4 replaced with 1d7. Keep in mind that this might remove instances of 1d4 that you didn't really want to change.

 

The way we used to resolve this in IR was to instead look for a match of something like "Damage: 1d4" (but with regexp character classes to catch extra spaces and tabs and other stupid things that might otherwise prevent a match).

 

I don't have a good example of that in the current code because we now do all that in a giant macro that handles arbitrary changes to speed factor, THAC0, and damage. I've never looked too carefully at it because it's complicated, but it's in here listed as wc_update if you want to try to take advantage of it.

[subtledoctor]

I have a component with the simplistic version here:

https://github.com/UnearthedArcana/Scales_of_Balance/blob/master/scales_of_balance/components/102_IWO_weapons.tpa

 

The issue with using regexp to find and replace some text is, trying to do it in multiple languages can be a nightmare.

[Ardanis]

but it's in here listed as wc_update if you want to try to take advantage of it.

Macro alone probably won't be of much help without context.

 

Here is the component launched in tp2 https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/item_rev.tp2#L213

And here is the main installation code with links to other required files, so you can simply strip it of the stuff you don't want https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/components/weapon_changes.tpa

 

I've never looked too carefully at it because it's complicated

I remember that your unreleased v3 code for updated weapon speed factor component was very much similar to my version, which is basically a smaller variation of the general weapon changes.

 

The issue with using regexp to find and replace some text is, trying to do it in multiple languages can be a nightmare.

Yes, translators will need to understand the regexp to adjust the code to new language, but it didn't seem to be much of an issue with IR.

Edited March 11, 2018 by Ardanis

[Luke]

[solved]

Edited April 18, 2018 by Luke

[Luke]

On 3/10/2018 at 10:12 PM, Mike1072 said:

Spoiler

 

I have a post here that's not specifically directed towards this, but it explains some of the concepts surrounding it. It includes an example that changes the description dynamically, which I've copied below.

READ_STRREF UNIDENTIFIED_DESC description

INNER_PATCH_SAVE new_description ~%description%~ BEGIN
  REPLACE_TEXTUALLY CASE_SENSITIVE ~armor~ ~armour~
  REPLACE_TEXTUALLY CASE_SENSITIVE ~Armor~ ~Armour~
END

SAY_EVALUATED UNIDENTIFIED_DESC ~%new_description%~

That code looks nice but it only updates the unidentified description. To modify both, you could repeat all of that but use DESC instead of UNIDENTIFIED_DESC. Or you could use a loop which lets you perform the same changes on both descriptions. This is the macro we use in IR to do that.

// stolen from BG2 Tweak Pack at G3
// modified to take parameter ~%text_update%~, the macro name of the REPLACE_TEXTUALLY to execute
DEFINE_PATCH_MACRO ~update_item_descriptions~ BEGIN
  FOR (index = 0x54 ; index >= 0x50 ; index -= 4) BEGIN // loop through descriptions
    READ_LONG index valid
    PATCH_IF (valid < 2147483646) AND (valid >= 0) BEGIN // verify description is valid
      READ_STRREF index description
      INNER_PATCH_SAVE new_desc ~%description%~ BEGIN
        LAUNCH_PATCH_MACRO ~%text_update%~
      END
      SAY_EVALUATED index ~%new_desc%~
    END
  END
END

It doesn't contain any of the REPLACE_TEXTUALLYs that determine what changes are made to the text. Those are defined in a separate macro. What you do is call this macro and provide it the name of another macro that has those, like this.

DEFINE_PATCH_MACRO ~update_dagger_text~ BEGIN
  REPLACE_TEXTUALLY ~1d4~ ~1d7~
END

TEXT_SPRINT text_update ~update_dagger_text~
LAUNCH_PATCH_MACRO update_item_descriptions

Both descriptions will then have all instances of 1d4 replaced with 1d7. Keep in mind that this might remove instances of 1d4 that you didn't really want to change.

 

The way we used to resolve this in IR was to instead look for a match of something like "Damage: 1d4" (but with regexp character classes to catch extra spaces and tabs and other stupid things that might otherwise prevent a match).

 

I don't have a good example of that in the current code because we now do all that in a giant macro that handles arbitrary changes to speed factor, THAC0, and damage. I've never looked too carefully at it because it's complicated, but it's in here listed as wc_update if you want to try to take advantage of it.

 

 

What if I didn't want to generate a new string for the new description via SAY_EVALUATED?

I tried replacing that line with

STRING_SET_EVALUATE index ~%new_desc%~

but it's not working.... Is there a way to update the existing description without creating a new string?

[Jarno Mikkola]

40 minutes ago, Luke said:

 Is there a way to update the existing description without creating a new string?

You can set the string to an existing one... but why, would you do that. The evaluate does try to find exact match ... so. If you use this as a larger funtion to cover multiple items they get the exact description string assigned to each ... so you add one... not 1000 for 1000 items.

[Luke]

22 hours ago, Jarno Mikkola said:

... so you add one... not 1000 for 1000 items.

This.

I was wondering if there's a way to achieve that without generating 1000 new strings pretty much identical to the old ones but a minor detail (e.g., a 1d5 changed into a 2d6 or something like that....)

To sum up, I'd like to overwrite the existing descriptions and avoid generating new strings (I don't think it makes sense in this case.......)

Edited September 22, 2019 by Luke

[Jarno Mikkola]

1 hour ago, Luke said:

To sum up...I don't think

Yeah, you sure didn't think. If you want to cheese your own game, you sure can do it with Near Infinity, but don't cheese anyone elses game.

See one, uninstalling is impossible. And weidu doesn't support such features, so unless you really want to -curse words disgusting enough to not be printed on this page- the other peoples games, you don't do this ... you just, don't.

[Luke]

1 hour ago, Jarno Mikkola said:

See one, uninstalling is impossible.

No.

If a certain mod overwrites an existing string via STRING_SET (or STRING_SET_EVALUATE) and then you uninstall that mod, the original content of that string is restored.

Edited September 22, 2019 by Luke

[Jarno Mikkola]

Well, see, if you use weidu's STRING_SET_EVALUATE to a .itm, you will add in the new description string to the dialog.tlk, and you are not overwriting it(the description string, you move the .itm index-number to the new one), so you can undo that change easily and the uninstall won't even remove the string either... but if you forcibly open the dialog.tlk with say Near Infinity and rewrite the string to be something else, then you can't uninstall that change. Without uninstalling the game.

That's what we were talking about.

Edited September 22, 2019 by Jarno Mikkola

[DavidW]

Jarno, that's not how STRING_SET or STRING_SET_EVALUATE works. They change the actual string in the tlk file. They don't alter the index number of the itm file (they can't - they're action commands, not patch commands.)

[Luke]

13 hours ago, Jarno Mikkola said:

That's what we were talking about.

I was talking about replacing this line

SAY_EVALUATED index ~%new_desc%~

with something else so as not to generate a new string (e.g., via using STRING_SET_EVALUATE).

But as @DavidW said, that command is an action command, not a patch one: that's why it's not working (and probably there's no alternative.....)

[DavidW]

If you want to do it that way:

- read the index of the string from the item file

- read in the text of the string

- patch it

- use STRING_SET_EVALUATE to set the new string.

Generally it’s simpler just to make it a new string, though. It’s not as if there’s any meaningful constraint on the size of your dialog.tlk.

 

[Jarno Mikkola]

1 hour ago, DavidW said:

- use STRING_SET_EVALUATE to set the new string.

Isn't this useless, when the "patch it" already pust the created string into the dialog.tlk ? Unless you do the patching in a non-writing state. Or more concretely you make a list file.

And I bet that will take a lot more computing resources than the patch as is, one.

Edited September 23, 2019 by Jarno Mikkola