[Question] Director String "interpolation" Issues

[RoverTX]

In the following I find a sector and try to store it at a variable name that will have no chance of conflicting with any other running version of a library script, which should only be run once per sector.

Code: Select all

<find_sector name="XenonWar.{param@X}.{param@Y}.sector" x="{param@X}" y="{param@Y}"/>
<incoming_message text="{sector.name@XenonWar.{param@X}.{param@Y}.sector}"/>

Does not result in the sector name being output but instead results in the following being written to the player log

sector.name@XenonWar.{param@X}.{param@Y}.sector

Also, I see a lot in Director code something like,

Code: Select all

this.sector

Is "this" a special keyword like in a lot of languages signify the current instance?

-----------

After writing this I realized having sector.name and then having periods in the sector object name was most likely causing some weird order of operations issue. So I replaced all periods with spaces resulting in the following working code.

Code: Select all

<find_sector name="XenonWar {param@X} {param@Y} sector" x="{param@X}" y="{param@Y}"/>
<incoming_message text="{sector.name@XenonWar {param@X} {param@Y} sector}"/>

[UniTrader]

Also, I see a lot in Director code something like,

Code: Select all

this.sector

Is "this" a special keyword like in a lot of languages signify the current instance?

may not apply to X3 but in XR this (lol) means in md the current cue (you can remotely access Vars in the form (md.)Mdscript.Cue.Var - or for the current cue in short this.Var - may be uses internally in libraries which are used as included code to keep their internal Vars seperate from the whole MD-Script which includes them for example.

dont count on this Post though - only used the XR MD so far which is diffrent in many aspects.

[RoverTX]

Was going through some old guides I have and found the following.

Next we use the <set_target> node to set the player‟s target as the marker we‟ve just
created. Note that because we‟re still in the same cue, the marker is still called
„this.marker‟.

Note the still in same que bit seems to suggest that it is a keyword.

[enenra]

Heyho!

As you've discovered, the additional dots are the issue. Personally I use underscores ( _ ) as delimiters and that works without issues.

this.variable refers to a variable saved to the next top level cue the variable is used in. Hence, if I had a cue named "test" and below it a cue named "variabletest", if inside of that "variabletest" cue I used "this.myvariable" it would equal to "variabletest.myvariable". If "this.myvariable" however was also used inside of the cue "test", it would there equal to "test.myvariable".

Both of those variables could be accessed by other MD cues (or files) by using the cue name in place of the "this".

Hope this helps, I can provide some more examples if needed.

[RoverTX]

No that makes perfect sense. I just hadn't seen clear documentation of the context to which this was referring too. Sometimes how it is used I thought it might actually be referring to the top level of the file, instead of the next top level cue.

Also, is there any documentation of the mission director variable/value scope?

Let's say I have three cues structured like so

Code: Select all

<cue name="cue l1">
  <cues>
    <cue name="cue l2 1">
      <cues>
        <cue name="cue l3">
        </cue>
      </cues>
    </cue>
  </cues>
  <cue name="cue l2 2">
  </cue>
</cue>

If I declare a value via <set_value> in "cue l2 1" will I be able to access that value in "cue l2 2" or would I have to "declare" it in "cue l1" in order to do so?

[UniTrader]

*reminder* refering to XR */reminder*

if its exactly like you have written it its the whole file which refers this Var - ecept you define a namespace="this" for some cue there (useful in combination with instantiate="true" if you want each instance to have its own vars) - then this cue and all its sub-cues will have seperate vars.
other way to explain this: the namespace, if not declared, has the same value as the parent cue (or whole md script if its a root cue), so its usually inherited from the rool to the last child cue

[RoverTX]

Sorry in the last example not talking about the keyword this, but just variables in general.

[UniTrader]

if its exactly like you have written it its the whole file which refers this Var

I did too... just added some info how to change the behavior if desired, which usually also makes use of the keyword this

[enenra]

No that makes perfect sense. I just hadn't seen clear documentation of the context to which this was referring too. Sometimes how it is used I thought it might actually be referring to the top level of the file, instead of the next top level cue.

Also, is there any documentation of the mission director variable/value scope?

Let's say I have three cues structured like so

Code: Select all

<cue name="cue l1">
  <cues>
    <cue name="cue l2 1">
      <cues>
        <cue name="cue l3">
        </cue>
      </cues>
    </cue>
  </cues>
  <cue name="cue l2 2">
  </cue>
</cue>

If I declare a value via <set_value> in "cue l2 1" will I be able to access that value in "cue l2 2" or would I have to "declare" it in "cue l1" in order to do so?

Assuming the variable is called "cue l2 1.myvariable".

In cue l2 2 you could refer to that variable by using "cue l2 1.myvariable". So yes, that is possible. Even across files as technically afaik the game doesn't differentiate between code in terms of files but in terms of cues. Which is why it's impossible to have good unique cue names.

You also have the option of declaring a global variable by not putting a cue name before your variable in its definition / initiation / declaration: <set_value name="myglobalvariable" exact="1"/> as opposed to the normal <set_value name="mycuename.mylocalvariable" exact="1"/>.

However, as mentioned before, technically any cue can access any variable so you wouldn't need global variables. For safety reasons I'd generally recommend transferring data through libraries, however, and not by using the local variable of another cue.

Note that some generic mission libraries do some pretty advanced trickery using these practices. For example, you can transfer the String of the name of a cue through a parameter and then use that parameter to name your variable and assign it to a variable cue. But that's a lot more advanced stuff than what you're likely currently trying to understand.