STATE_WHICH_SAYS

[cmorgan]

OK.

I read the docs, and I have looked at crossmod materials - and I think I am having a mental block.

STATE_WHICH_SAYS text FROM String returns:
fails the installation if it can’t evaluate the text (an @x reference out of bounds)
-3 if the text is not currently in the tlk or in the list of strings to add
-2 if the text is spoken (= SAY ~Foo~) at least twice in the file String (String must be an in-game or in-override .dlg file)
-1 if the text is never spoken in the file String (String must be an in-game or in-override .dlg file)
otherwise it returns the number of the state in which text is spoken in the file String (String must be an in-game or in-override .dlg file). @x references are taken from the loaded TRA files (the ones defined in the Language part).
or
STATE_WHICH_SAYS value IN String1 FROM String2 As above, except that @x references are taken from the String1 tra file.


Now.

I have a whole ton of I_C_Ts and some REPLACE_STATE_TRIGGERs that are hard calls to vanilla states in various dialogue files. This has served us well in Tutu, mostly because few mods really messed around with stuff.

But.

Now we visit BG2 (and BGT) land, where even base dialogues can change and add states. And more folks add on thier own ideas. So our nice little program of SPRTINTing specific state numbers from Tutu to BGT can suddenly be thrown for a loop - for example, trying to shut down an "always true" state in Viconia's dialogues to allow PIDs on a Fixpacked BGT install suddenly means we have missed the state and are instead shutting down Viconia's Watcher's Keep fix materials.

So I have a whole ton of things that need to move from hardcoded state numbers to a manipulation where

Could someone please tutorialize/step me through a simple change from the following code to a code that seeks and uses the correct state using S_W_S?

On Tutu,
REPLACE_STATE_TRIGGER ~_VICONJ~ 0 ~Global("X#JCleanViconia","GLOBAL",1)~ 1

the same code on BGT,
REPLACE_STATE_TRIGGER VICONIJ 183 ~Global("X#JCleanViconia","GLOBAL",1)~

because on another install, the state has moved to 189

Code: [Select]

IF WEIGHT #10 /* Triggers after states #: 191 197 209 219 220 even though they appear after this state */
~HappinessLT(Myself,0)
GlobalLT("ENDOFBG1","GLOBAL",2)
~ THEN BEGIN 189 // from:
  SAY ~A welcome release.  Your weakling surface ways have left a bitter taste in my mouth.  Perhaps I should seek shelter back under the cover of the earth.  I understood my fellows there.~ /* #75761 */
  IF ~~ THEN DO ~LeaveParty()
EscapeArea()
~ EXIT
END

and we end up killing the 183

Code: [Select]

IF WEIGHT #12 /* Triggers after states #: 189 190 191 197 209 219 220 even though they appear after this state */
~Global("X#JCleanViconia","GLOBAL",1)
~ THEN BEGIN 183 // from:
  SAY ~There is... something in this place, abbil.  A most disturbing presence.  Walk carefully and trust nothing.~ /* #70503 */
  IF ~~ THEN EXTERN ~GORDEMO~ 2
END


Or even better, one which shows me step by step how to patch

/* MINSC */
REPLACE_STATE_TRIGGER ~_BMINSC~ 7 ~InteractingWith("dynaheir") RandomNum(2,1) Global("X#BIOMI1","LOCALS",0)~
REPLACE_STATE_TRIGGER ~_BMINSC~ 8 ~InteractingWith("dynaheir") RandomNum(2,2) Global("X#BIOMI2","LOCALS",0)~

ADD_TRANS_ACTION ~_BMINSC~ BEGIN 7 END BEGIN END ~SetGlobal("X#BIOMI1","LOCALS",1)~
ADD_TRANS_ACTION ~_BMINSC~ BEGIN 8 END BEGIN END ~SetGlobal("X#BIOMI2","LOCALS",1)~

into STATE_WHICH_SAYS...


(Though i am gioing to cry alot now, as it looks like the most compatible code needs every I_C_T to use S_W_S as well, and I don;t know how to account for vanilla vs GTU vs Baldurdash vs everyone's SET STRING changes to make this universal )

[Kulyok]

Okay, let's stop and take a deep breath.

Mods have dialogues, dialogues have states. States are fixed. If a modder, say, deletes an existing state, he needs(and usually receiveth) a good talking-to.

(BG2 platform or Tutu platform or BGT platform - no matter what the platform is, what I've written above is true).

However, dialog.tlk is a very flexible thing. From BGT to GTU to Valygar Romance to SCSII to Aerie.ru to Clan Dlan, "only the lazy", as we say in Russia, hasn't bothered to update it. As such, dialog.tlk strings are NOT fixed, and never will be.

Given that, why would you want to go from fixed state numbers to ever-changing dialogue strings? That's running BG1 NPC straight to an early grave.

[jastey]

As far as I understood, cmorgan is talking about changed state numbers due to changes made by BGII fixpack, not by Random Mod X.

But, isn't the state after the fix a fixed one again? I mean, wouldn't it suffice to detect the installed component instead using S_W_S. just a thought.

[Kulyok]

As far as I understood, cmorgan is talking about changed state numbers due to changes made by BGII fixpack, not by Random Mod X.

See my post above - it comes to the same thing. Changing an existing dialogue state is just too dangerous - there are too many mods which work with dialogue at this point. Sure, a mod which relies on Irenicus' ogre soundset is silly. A mod which relies on an existing dialogue state, and which, therefore, will be broken if this state will disappear, is not.

[jastey]

Then I don't understand your point, sorry. What do you suggest, then? Working purely with weights?

[Kulyok]

Not using STATE_WHICH_SAYS in BG1 NPC interjections.

[jastey]

Because the line could have been changed by a mod?

[CamDawg]

Not using STATE_WHICH_SAYS in BG1 NPC interjections.

BGT tacks BG dialogues at the end of BG2 dialogue files. Guess what--you're already targeting fluid states, which is why interjections to these dialogues interject to a state number based on a variable.

Using STATE_WHICH_SAYS to get the proper value for that variable is probably a lot smarter than assuming you know the state number from the platform.

[Kulyok]

My love for BGT knows no bounds. But... wait. Maybe, just maybe, they are doing it wrong? Let us assume for a moment that the right thing to do is... something else. A BGT prefix for existing dialogues for BG1, for one.

BGT is already, as it's been said a thousand times before, changes Xan to BGXan for absolutely no reason, except for accomodating NEJ, which makes every effort to be incompatible with everything, including BGT, and will be banned one day for using more than 25% of IWD graphics anyway. This makes no sense, just like fluid dialogue states. If BGT uses prefixes to accomodate NEJ, I don't see why it continues to use fluid states to inconvenience every BG1-related dialogue-enhancing mod out there.

[CamDawg]

My love for BGT knows no bounds. But... wait. Maybe, just maybe, they are doing it wrong? Let us assume for a moment that the right thing to do is... something else. A BGT prefix for existing dialogues for BG1, for one.

BGT is already, as it's been said a thousand times before, changes Xan to BGXan for absolutely no reason, except for accomodating NEJ, which makes every effort to be incompatible with everything, including BGT, and will be banned one day for using more than 25% of IWD graphics anyway. This makes no sense, just like fluid dialogue states. If BGT uses prefixes to accomodate NEJ, I don't see why it continues to use fluid states to inconvenience every BG1-related dialogue-enhancing mod out there.

Yep. So once you get that changed, let BG1 NPC know so they can use I_C_Ts with static state numbers.

[the bigg]

S_W_S was more aided towards Crossmod, to allow (EG) Aqualung to I_C_T into Minsc's UB dialogue.

tp2:

Code: [Select]

ACTION_IF MOD_IS_INSTALLED ~setup-ub~ 0 BEGIN // minsc's kidnapping
  OUTER_SET wwminscub_652 = STATE_WHICH_SAYS 652 IN ~ub/tra/%s/wwminscub.tra~ /*@652  = ~Ahh, this is a fine place for an adventure, isn't it, Boo? So many holes for a hamster to snuffle in, especially a miniature one such as yourself!~ */ FROM minscj
  OUTER_SET wwminscub_656 = STATE_WHICH_SAYS 656 IN ~ub/tra/%s/wwminscub.tra~ /* @656  = ~BOO?! You are not there!! Where has Boo gone?!~ */ FROM minscj
  COMPILE ~aqualung/d/crossmod/boo-kidnap.d~ EVALUATE_BUFFER
END

d:

Code: [Select]

INTERJECT_COPY_TRANS MINSCJ %wwminscub_652% wwminscub_652
  == AQUALUNJ   IF ~IsValidForPartyDialogue("Aqualung")~ THEN ~Why did nobody kidnap that hellish hampster already?~
END

INTERJECT_COPY_TRANS MINSCJ %wwminscub_656% wwminscub_656
  == AQUALUNJ   IF ~IsValidForPartyDialogue("Aqualung")~ THEN ~Victory!~
  == MINSCJ     IF ~IsValidForPartyDialogue("Aqualung")~ THEN ~So it's been you who robbed Boo, eh?~ = ~DIE VILLAIN!~
END
To deal with multiple possibilities, you can do something atrocious like the following (if Var.get_string is implemented, something I'm not too sure about):

Code: [Select]

OUTER_SET result = -1
ACTION_FOR_EACH string IN ~plain game~ ~BGT~ ~GTU~ BEGIN
  ACTION_IF result < 0 THEN BEGIN
    OUTER_SET result = STATE_WHICH_SAYS ~%string%~ FROM minscj
  END
END
Or, if it doesn't work, put the three versions in mymod/tra/LANG/BGTSucks.tra (from @200 to @202) and

Code: [Select]

OUTER_SET result = -1
OUTER_FOR (ref = 200; ref <= 202 AND result < 0; ref +=1) BEGIN
  OUTER_SET result = STATE_WHICH_SAYS ref IN ~mymod/tra/%s/BGTSucks.tra~  FROM minscj
END


[Ascension64]

My love for BGT knows no bounds. But... wait. Maybe, just maybe, they are doing it wrong? Let us assume for a moment that the right thing to do is... something else. A BGT prefix for existing dialogues for BG1, for one.

BGT is already, as it's been said a thousand times before, changes Xan to BGXan for absolutely no reason, except for accomodating NEJ, which makes every effort to be incompatible with everything, including BGT, and will be banned one day for using more than 25% of IWD graphics anyway. This makes no sense, just like fluid dialogue states. If BGT uses prefixes to accomodate NEJ, I don't see why it continues to use fluid states to inconvenience every BG1-related dialogue-enhancing mod out there.

You give me a completely working solution where all joinable NPCs that appear canon in both BG1 and BG2 have access to their J and P dialogues from both games without the use of fluid states and a might put it in.

P.S. There is nothing wrong with Xan in regards to fluid states. Don't confuse this with something else.

[Kulyok]

And I just posted a topic at BGT forum at SHS, too.

[cmorgan]

Dudes, dudettes -  please go from specific to general. BGT is not the problem, my understanding and usage of states is the trouble --  and whether it is for BG1NPC or any other, the whole thing revolves around the idea that while we can't completely make everything work with every mod we should be at the top of the leaderboard in trying. Do No Harm, and all that.

Personally, as I am getting into building BG2 mods, I want a solution that is drastically less install-order dependent for I_C_Ts.

If I understand correctly, this means that anything which comes before my mod can change the original vanilla state numbers. If I am mistaken in this, and it is restricted to a small set of mods, please someone correct me again - if BG2 and Tutu  and EasyTutu cannot really be messed with much, then the fix is much easier, as I simply detect for the relevant mods and borrow code from Ascension64's work making BGT compatible with NeJ, etc. and the bigg's code here.

As a side note, if most states remain static, we just dropped the challenge by a huge order of magnitude, and I am a much happier man.

[cmorgan]

Okay, let's stop and take a deep breath.

Good advice, good idea. I have stopped having a panic attack.

Mods have dialogues, dialogues have states. States are fixed. If a modder, say, deletes an existing state, he needs (and usually receiveth) a good talking-to. (BG2 platform or Tutu platform or BGT platform - no matter what the platform is, what I've written above is true).

   I have misunderstood this point from the beginning. In Tutu (NOT EasyTutu) both sttref and state can be "fluid" to a point, because Tutu is a mod.

   If somebody uses a non-Weidu mod like The Vault, they can (and many do) change the fundamental files. The fix for this is to detect them and account for those changes, as Ascension64 does for BGT when someone uses one of the "pre bgt" mods. On the Tutu side, EasyTutu fixes this by simply not allowing pre-Tutuification mods access. The intact override drop prevents mods that overwrite the original.dlg with a new set of custom state numbers from ever being referenced. It literally shotguns them out of existence.

   On the strref side, the Tutu strrefs will be different on a Tutu conversion based on a SoA install than one based on a ToB install, because the BG content strrefs "float" on top of the BG2 sttrefs - and ToB has many more sttrefs than SoA. EasyTutu does not combat this; Macready bypasses this by creating two separate installers.

  In addition, as you point out below quoted from above, Kulyok, sttref *numbers* might be static by platform, but their *contents* are not. Using STATE_WHICH_SAYS is subject to everyone's whim, and either heavy coding stuff from the bigg or a list of all normally expected sttref contents for a particular state you want to find placed in .tra for reference, so that ~I am a strref~ vs ~[MYMOD] I am a stref~ vs ~  I am a strref~ vs ~ I am a string reference~ all are accounted for.

However, dialog.tlk is a very flexible thing. From BGT to GTU to Valygar Romance to SCSII to Aerie.ru to Clan Dlan, "only the lazy", as we say in Russia, hasn't bothered to update it. As such, dialog.tlk strings are NOT fixed, and never will be.
Given that, why would you want to go from fixed state numbers to ever-changing dialogue strings? That's running BG1 NPC straight to an early grave.

Apparently, I don't want to do that for the vast majority of cases on both Tutu and BGT. Ardrouine, for example, has only BG content. If you folks are telling me that state numbers remain static for both BG and BG2, then we are all good - all of our materials will drop into place for almost all conditions.

To be clear, if I make a "Sexy Ardrounine Romance Mod" and install it on Tutu, then put it before BG1 NPC, the state numbers in _ARDROU.DLG should not change, just get added on to. If I make an "Add Town Crier Dialogue About Wandering Maids Mod" for BG2 and install it before my newly minted "Chanelle The Wandering Maid Romance", the original materials will still be intact and available to me (let's ignore what other folks can do with falsing out, etc. - the state numbers themselves are still static).

BUT - if I am attempting to interject into someone else's mod (rarely done except crossmod, and not recommended in any case for both politeness and functional reasons), THEIR state numbers are FLUID. They may be 501-599, or if placed later in the install, 601-699. This makes MY mod's state numbers fluid, too, based on install order, so if I for some stupid reason decide to I_C_T into my own added dialogue (pretend I couldn't grok CHAIN), I would need to use STATE_WHICH_SAYS.

OR - if I am modding for BGT/BGT compatibility, and something is added BEFORE the BGT conversion, then any >>PDIALOG.2da participants<< (party-joinable NPCs) who share dialogue J and B files (possibly P as well) between BG and BG2 need to have any manipulation of state transitions, triggers, I_C_Ts, etc. use STATE_WHICH_SAYS. This is because the BG states "float" on top of any additions to those files. Other mods may be added before BG1 NPC, but they won't matter; the problem is the addition to BG2 states BEFORE BGT gets them. Once BGT has installed, the states are static from that point on.

(Please remember that though I talk a good game and synthesize alot of information from a large number of sources, at heart I am the equivalent of a self-trained tech support person. I may indeed lack basic understandings - for instance, I_C_T4 still truly eludes me even though the bigg has personally lead me through it by the nose. And I am very happy when my flailing results in something that allows others to learn from my misery, even when it is self-induced).

Is this accurate? Is there something that I am not understanding?

Are there any conditions under which an original distribution >> state number << in BG2 will change?

[the bigg]

Are there any conditions under which an original distribution >> state number << in BG2 will change?

Stupid mods like IA or the older IUs do.

[cmorgan]

Got it - and for those, if I want to be nice to Mega-install people, I need to understand that I need to create a separate section of installer the way Ascension64 does to make BGT be able to be applied over NeJ, etc. where he has to
do heavy stuff like

Code: [Select]

// Compatibility with NeJ: Custom Imoen Kit
ACTION_IF
  NOT FILE_EXISTS_IN_GAME ~CLABCHRG.2DA~
THEN BEGIN
  COPY_EXISTING ~IMOEN2J.DLG~ ~override/IMOEN2J.DLG~
    READ_LONG 0x8 num_states
  BUT_ONLY_IF_IT_CHANGES

  COPY_EXISTING ~IDRYAD1.DLG~  ~override~ //updates IMOENJ to IMOEN2J dialogue trans
                ~IGOLEM2.DLG~  ~override~
                ~ISHADMT1.DLG~ ~override~
                ~JAHEIRA.DLG~  ~override~
                ~JAHEIRAJ.DLG~ ~override~
                ~MINSCA.DLG~   ~override~
                ~RIELEV.DLG~   ~override~
                ~YOSHIMO.DLG~  ~override~
    READ_LONG 0x14 off_response
    READ_SHORT 0x10 num_response
    FOR( i=0;i<%num_response%;i+=1 ) BEGIN
      READ_ASCII (%off_response% + %i%*0x20 + 0x14) next_dialog
      READ_LONG (%off_response% + %i%*0x20 + 0x1c) next_state
      PATCH_IF (("%next_dialog%" STRING_COMPARE_CASE "IMOENJ")=0) BEGIN
        WRITE_ASCII (%off_response% + %i%*0x20 + 0x14) "IMOEN2J"
        SET %next_state% = %next_state% + %num_states%
        WRITE_LONG (%off_response% + %i%*0x20 + 0x1c) %next_state%
      END
    END
  BUT_ONLY_IF_IT_CHANGES

  COPY + ~BGT/Compat/BGT/Replace/aIMOEN2J.D~ ~BG1D/IMOEN2Ja.D~
  COPY + ~BGT/Compat/BGT/Replace/aIMOEN2P.D~ ~BG1D/IMOEN2Pa.D~
END
or more simply (because that is way out of my league)

Code: [Select]

// Compatibility with NeJ: Custom Imoen Kit
ACTION_IF
  NOT FILE_EXISTS_IN_GAME ~CLABCHRG.2DA~
THEN BEGIN
  COMPILE ~BGT/Compat/BGT/Replace/Replace.D~
END
ELSE BEGIN
  COMPILE ~BGT/Compat/NeJImoen/Replace/aIMOEN2P.D~
END
They only do that through a straight COPY of a custom dialogue file, right?

[the bigg]

You neededn't worry - if your mod has troubles with the Mega Platform (and it will, even if you're adding a new spell or anything), somebody will update your tp2, upload it somewhere in China, and not bother to notify it to you.

[cmorgan]

You have a good point there.

[the bigg]

Sad but true. In 200 -> 201, removing weidu.lock broke Leonardo's auto install for a mod (guess which). I learned this three months after the first discovery, and just because I stumbled upon the Big World Instructions topic. After a quick exchange with LW, I was told that weidu.lock was accidentally blocking that mod's stupidly convoluted install routine.
EDIT: at least LW was too scared of the 400 steps required to recompile WeiDU (and the fact that the code to weidu.lock was removed, not just commented out), otherwise we'd have had a WeiDU version war, which would have been... not pretty.

To your face, my dear Russian hacker, I might add   

[Kulyok]

You mean, "You, Kulyok, weren't as important as LW, and I replaced weidu.lock feature not because of your 'Waaah, users won't understand weidu.lock!' nagging, but because of his big and cool 400-steps autoinstall, so there?" Heheh.

You neededn't worry - if your mod has troubles with the Mega Platform (and it will, even if you're adding a new spell or anything), somebody will update your tp2, upload it somewhere in China, and not bother to notify it to you.

Nah, it doesn't work like that. They have to notify users, because if users don't know, there's no point, see? And if users know, then modders know, too, and eventually we have kovarex number three and so on.

Anyway, seeing how you're not going to introduce Weidu 204 in the next ten minutes, I'm off to bed.

[the bigg]

You mean, "You, Kulyok, weren't as important as LW, and I replaced weidu.lock feature not because of your 'Waaah, users won't understand weidu.lock!' nagging, but because of his big and cool 400-steps autoinstall, so there?" Heheh.

Not quite, because removing weidu.lock broke the autoinstall, and I became aware of the problem after three months anyway. What I mean is "Look Kulyok, your nagging broke that autoinstall!" 

Nah, it doesn't work like that. They have to notify users, because if users don't know, there's no point, see? And if users know, then modders know, too, and eventually we have kovarex number three and so on.

I wasn't notified, that's for sure. kovarex is a mispel of koveraS or am I missing something?

Anyway, seeing how you're not going to introduce Weidu 204 in the next ten minutes, I'm off to bed.

203.01 is on the beta location, if that's what you're asking. There should be about thirty threads with the link in the beta forum.

[Kulyok]

I wasn't notified, that's for sure. kovarex is a mispel of koveraS or am I missing something?

[cmorgan]

OK, Edwin's materials were not as bad as I thought, if I understood correctly (not a given)

ACTION_IF MOD_IS_INSTALLED ~setup-bgt~ 0 BEGIN // checking Edwin's states
  OUTER_SET BGTEdwinJState193 =  STATE_WHICH_SAYS  ~Why do you stay the killing blow?!  Kill her!!~ FROM edwin
  OUTER_SET BGTEdwinJState199 = STATE_WHICH_SAYS  ~(If they'll not do the deed then our deal is forfeit!)  You side with the witch then you will die with her!  Beware my return!~ FROM edwin 
END
COMPILE ~mymod/mymodfile.d~ EVALUATE_BUFFER

(Or do I need to specify IN from BGT's .tra?)


but one significant challenge in Viconia:

OUTER_SPRINT "BGTViconiaState575" "575"  SAY ~Greetings, darthiir. I know that you look upon me as an enemy, but perhaps we could ignore our differences.~ [VICON27] /* #75228 */
OUTER_SPRINT "BGTViconiaState583" "583"   SAY ~Greetings darthiir; I know that you look upon me as an enemy, but perhaps we could ignore our differences.~ [VICON27] /* #75233 */
OUTER_SPRINT "BGTViconiaState584" "584"   SAY ~Greetings darthiir; I know that you look upon me as an enemy, but perhaps we could ignore our differences.~ [VICON27] /* #75233 */
OUTER_SPRINT "BGTViconiaState585" "585"   SAY ~Greetings darthiir; I know that you look upon me as an enemy, but perhaps we could ignore our differences.~ [VICON27] /* #75233 */

In our files, of these are REPLACE actions with different (one word) responses. And we shut down the linkage to Kivan's responses:

REPLACE ~%VICONIA_BANTER%~
IF ~~ THEN BEGIN %BGTViconiaState575% // from:
SAY @0
IF ~~ THEN EXIT
END
END




The easiest would be to drop them into a contingent file, and not update BGT.

[the bigg]

OK, Edwin's materials were not as bad as I thought, if I understood correctly (not a given)

ACTION_IF MOD_IS_INSTALLED ~setup-bgt~ 0 BEGIN // checking Edwin's states
  OUTER_SET BGTEdwinJState193 =  STATE_WHICH_SAYS  ~Why do you stay the killing blow?!  Kill her!!~ FROM edwin
  OUTER_SET BGTEdwinJState199 = STATE_WHICH_SAYS  ~(If they'll not do the deed then our deal is forfeit!)  You side with the witch then you will die with her!  Beware my return!~ FROM edwin 
END
COMPILE ~mymod/mymodfile.d~ EVALUATE_BUFFER

(Or do I need to specify IN from BGT's .tra?)

The IN is better, since you can use BGT/tra/%s/file.tra and search in all languages. You might also want to do this for Tutu as well (so that you can have a single .d file, using the variable).

but one significant challenge in Viconia:
<etc>

Without knowing what the dialogues are like or what you're trying to accomplish, I can't help you. But you're likely wrong and anyway there's no way to achieve compatibility in less than 10 KLOC (1 KLOC in 204 with ADD_PRINGLES and an added Var.get_string)