Jump to content

Symbolic labels in D files


Skye

Recommended Posts

Is there a way to resolve symbolic labels inside D files without recompiling all of the interconnected dialogue files?

 

I have an optional component that appends to a DLG that was previously compiled from my own D file and has references to its states for transitions. Changing all of the numeric state references every time I happen to change the main dialog's state order is becoming a massive pain and I would like to know if there's an easier way to go about it.

 

I would settle for being able to pre-set the labels at the start of the file if there's no way to resolve the references without recompiling.

Link to comment

There is none unless you have a stable part in your main dialogue (which you do not have, if I understand correctly).

 

I would do it this way -

Include the optional dialogues into the main dialogues and add an additional trigger for them.

Use the install option to set this trigger in a way that those optional dialogue lines only happen if the optional component is installed that sets the value for them.

 

Better give an example -

You create the optional component with EXTEND_TOP of a suitable BCS file from your mod with this

 

IF

Global("OptionalTriggers","Global",0)

THEN
RESPONSE #100

SetGlobal("OptionalTriggers","Global",1)

END

 

in a way that when the user selects the option, this block is added, it triggers as soon as your script is valid and it sets

Global("OptionalTriggers","Global",1)

 

Now all the dialogue states or responses etc in your d-file that belong to the option contain the condition Global("OptionalTriggers","Global",1) - this way they only appear if the option is chosen and you can refer criss and cross to all internal labels at will.

Link to comment

Yeah, I've done that before (except I chose a slightly more destructive method). I'm halfway tempted to have my partner in crime recompile WeiDU with the necessary changes...

If the options in the d-file are related to crossmod contents, you have another option, provided that your mod installs after the other one. You can do that directly in your d-file

 

e.g.

INTERJECT_COPY_TRANS IF_FILE_EXISTS F_DRIZZT 0 FDrDuMeetUlg

or

== IF_FILE_EXISTS BSUFINCH IF~ InParty("Sufinch") ~ THEN ~

Link to comment

Both of the components are part of my own mod and the second one requires the first one to be installed. There's nothing stopping me from joining the files, I just want to keep things segmented.

 

I find it a little odd that you cannot at least pre-define the required labels. Having to work with magic numbers is always a horrible idea when writing code.

Link to comment

This solution may help:

 

You can reference internal labels between files if they are compiled within the same component.

 

Try this

In your addon file use

Instead of GOTO InternalA >>> EXTERN Mainfile InternalA

 

In your tp2 use install option instead of components

 

Do you want to install dialogue with addon option or without?

Select 1 - without

Select 2 - with

If 1 >>> COMPILE mainfile

 

If 2 >>> COMPILE mainfile

COMPILE addon

Link to comment

Thanks for your help, but as I said in the original post, I would have liked to have seen an option to do it without having to compile an entire chain of interconnected dialog files.

 

For now, I'll settle with disabling parts of the dialog with flags, but it just feels dirty.

Link to comment

I am modding a French game and it works fine:

 

 

Looking for my own French strings :

OUTER_SET GW_Uhmer01_state_remise1 = STATE_WHICH_SAYS 11105624 IN ~Diamant_Eternel/tra/%s/GWQueleL.tra~ FROM UHMER01

Looking for English strings from other mods :

OUTER_SET GW_Mazzy_state_Stivan = STATE_WHICH_SAYS 232 IN ~stivan/tra/%s/tb#stivj.tra~ FROM MAZZY    // @232  = ~I'd say we shouldn't wait any further and open our way in
Link to comment

I use it too, but actually I wonder how does it work with non-english games?

STATE_WHICH_SAYS basically does an equality check between what's in the state's SAY (as a strref) and the strref your string resolves into, so yeah, it's not fool-proof and if the text is not an exact match, it will fail.
Link to comment

 

I use it too, but actually I wonder how does it work with non-english games?

STATE_WHICH_SAYS basically does an equality check between what's in the state's SAY (as a strref) and the strref your string resolves into, so yeah, it's not fool-proof and if the text is not an exact match, it will fail.

 

It can also lead to wrong results for the case that the text is not unique in a dialogue, which can often be the case (so make sure before using).

Link to comment

STATE_WHICH_SAYS is a TP2 action though. How would I use that in a D file? Can I do OUTER_SET myvar = STATE_WHICH_SAYS @123 FROM MYDLG in my TP2 file and then do EXTERN MYDLG myvar in the D file?

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...