Concatenation

[subtledoctor]

Just now, Lauriel said:

Oh my goodness!  What we will do to bash Weidu over the head to let us do what we want to do!  LOL

It is useful in specific circumstances, like building .d files where you might need to dynamically append to different parts of the dialogue before putting the whole thing together. I don’t use that for basic text handling, though. 

[Lauriel]

Oh my goodness!  Inexcusable!  I'm so sorry!  A big thank you to @subtledoctor for the final solution!  belated...

[grodrigues]

It is late, so excuse my tiredness and going for the hardest solution first. To concatenate two strings (in a patch block say), stick them in a variable and just TEXT_SPRINT new_var ~%var1%%var2%~. As for expanding a tra reference I use the following piece of black magic stolen from IR (or SR) -- so credits to their authors:

DEFINE_PATCH_FUNCTION GET_STRING_FROM_TRA_REF STR_VAR ref = "" RET str BEGIN
    INNER_ACTION BEGIN
        ACTION_IF (~%ref%~ STRING_COMPARE_REGEXP ~^[@#]-?[0-9]+$~ == 0) BEGIN
            <<<<<<<< .../inlined/MI_FS_%ref%.tpp
              OUTER_SPRINT string >>>>>>>>
            SILENT
            COPY - ~.../inlined/MI_FS_%ref%.tpp~ ~.../inlined/MI_FS_%ref%.tpp~
                INSERT_BYTES SOURCE_SIZE (STRING_LENGTH ~%ref%~)
                WRITE_ASCIIE SOURCE_SIZE ~%ref%~
            VERBOSE
            INCLUDE ~.../inlined/MI_FS_%ref%.tpp~
        END ELSE BEGIN
            OUTER_SPRINT string ~*~
        END
    END
END

If you have the tra reference itself in a variable, in the format say @10000, send the variable to the function preceded by EVAL (unless you have AUTO_EVAL or watcha ma call it on).

I confess I really do not understand this code entirely, subtledoctor's seems to be way more manageable. The regexp part is easy, but the inlining throws me off track. Oh well, it works and that is all.

Edited January 26, 2020 by grodrigues

[Lauriel]

Thank you, @grodrigues!   I can't say I understand that either. LOL  Some day...

[Mike1072]

I'm the author and can try to explain.  It creates an inlined file with contents:

OUTER_SPRINT string @1234

Then, it INCLUDEs the inlined file, which executes that code.

Its purpose is to fetch the text for either a TRA ref (@1234) or a strref (#1234).  You must include the @ or # symbol as part of the ref variable.

WeiDU does have built-in tools that deal with fetching only TRA refs (AT) and only strrefs (GET_STRREF).  Here are examples of their usage.  In these cases, the ref variable should contain just a number, no symbol.

SPRINT string (AT ref)

GET_STRREF ref string

The home for my function (named FETCH_STRING) is here.  There is a companion function named RESOLVE_REF in the same file, which is what Item Revisions actually uses.  It behaves similarly, taking either a TRA ref or strref, but instead of returning the associated string, it returns the associated strref.  In the case of a TRA reference, this involves adding the string to dialog.tlk.  This would be more useful for a situation where the .tra file contains complicated entries that need to be preserved, like associated sound effects or male & female lines for the same reference.  That extra information is normally lost when putting the string into a WeiDU variable.

[Lauriel]

Gotcha!  I think.  Thanks @Mike1072!

[Lauriel]

On 1/27/2020 at 1:49 PM, Mike1072 said:

The home for my function (named FETCH_STRING) is here.  There is a companion function named RESOLVE_REF in the same file, which is what Item Revisions actually uses.  It behaves similarly, taking either a TRA ref or strref, but instead of returning the associated string, it returns the associated strref.  In the case of a TRA reference, this involves adding the string to dialog.tlk.  This would be more useful for a situation where the .tra file contains complicated entries that need to be preserved, like associated sound effects or male & female lines for the same reference.  That extra information is normally lost when putting the string into a WeiDU variable.

This leads me to a question.  Will the stock strings always use the same strref?  Right now I'm doing a mod only for EET.  In a couple dialogues, I am referencing stock strings via their strref as they show up in my game.  Do I need to use your RESOLVE_REF function.  Like I said, I only use it for stock strings, i.e., those that come with the game before any mods are added.  But I'm starting to feel like that might not be a good idea.

[Mike1072]

It's safe (and preferred) to re-use strrefs that are part of the vanilla game, but it's not safe to rely on strrefs that are added by mods, since these can change depending on installation order.  For EET, this would mean only using references to strings that exist in unmodded BG2EE.

For strings that don't exist in the vanilla game, you should include them fully in your mod just like any brand new strings you plan to add.

My RESOLVE_REF function wouldn't really factor in here.  It's main purpose is to allow you to store a mixture of string references and TRA references for eventual conversion into just string references.  For example, in Item Revisions, we have a table that includes the names and descriptions of all of the items.  Some of them are defined using strrefs from the vanilla game, like #6976 ('Potion'), and others are defined using TRA references to new strings added by IR.  During installation, the mod retrieves the mixed references from the table and converts them all into strrefs so they can be assigned to the items.

[Lauriel]

Ahh, gotcha.  Thanks @Mike1072!