Just as as side note on the conversation responses. For a MD script of mine I had to do the same and I tried it myself - and it works! But I didn't use {
object.race.name@this.station} but rather {
object.race@this.station}, because its more portable (using object.race.name would result in different names for different languages).
Dang it, that's excellent it does work, I have a whole bunch of code to re-write now
Just one thing, I thought the problem was that the xml expression evaluation wasn't consistant within the command attributes and that combined with the non existant text/string handling meant you couldn't do what you did.
I was a lot wrong and a little bit right, I just verified what is actually going on. I had only ever tried expression evaluation using strings, i.e. "conversation.argon" not stuff like "conversation.1" and then mistakenly assumed the expression evaluation was borked, it isn't as you found out, what's actually borked is the text/string handling.
So this will never work as it results in a string.
Code: Select all
<conversation_completed actor="..." conversation="MyConversation_{object.race.name@this.station}" outcome="..."
But this does work as it results in an integer, as you found out.
Code: Select all
<conversation_completed actor="..." conversation="MyConversation_{object.race@this.station}" outcome="..."
And yet another question:
Did anybody (Shush? ) already use library cues in combination with instances? I'm asking, because I tried to put the <conversation_completed> condition from above into a library cue, to use it for several other cues, but I just didn't get it to work. I guess the problem was, that the actor name, which was "parent.MyActor" before, didn't work inside the library-cue.
Ok, I've tried using library cues in instances and never gotten them to work, no matter where I put the library cue, i.e. whether it was a local cue within the instance or a global cue in a top level instance. One thing I haven't tried though is using the instantiate="static" attribute with a library, I am guessing they are an invalid combo but it's worth a long shot.
One thing that does work though, but has limited use is the <cue ref="blah"/> and <action ref="blah"/> commands, you can call reused cues and action components of cues within an instance without using the library command, but they must be at the same cue level to make any sense if you are using this. or parent. etc, hence the limited use inside instances.
I'll try and give you a psuedo example as I am doing a poor job of explaining this.
Code: Select all
<cue name="Blah.Cue0">
<action>
<set_value "this.blahCheck"/>
<set_value "this.blahAction"/>
</action>
<cues>
<cue name="Blah.Cue1">
<condition>
<blah_condition "parent.blahCheck"/>
</condition>
<action>
<blah_action "parent.blahAction"/>
</action>
</cue>
<cue name="Blah.Cue2">
<action ref="Blah.Cue1"/>
</cue>
</cues>
</cue>
Blah.Cue2 executes the action of Blah.Cue1 as if it was a library, for this to work Blah.Cue1 has to be in scope, (which it is for this example), and importantly the "parent.*" have to make sense. In this case because the two cues are at the same level "parent.*" makes sense for both of them, but if Blah.Cue2 was a sub cue of Blah.Cue1 it wouldn't work as Blah.Cue2 would need "parent.parent.*" instead of "parent.*" :/
*Edit fixed the example