Looking at how the text processor is implemented, I wonder if it could be made more flexible.

If you look in CoreOutput.aslx now, you'll see this function:

  <function name="ProcessTextCommand" type="string" parameters="section, data">
    if (StartsWith(section, "if ")) {
      return (ProcessTextCommand_If(section, data))
    }
    else if (StartsWith(section, "either ")) {
      return (ProcessTextCommand_Either(section, data))
    }
    else if (StartsWith(section, "here ")) {
      return (ProcessTextCommand_Here(section, data, true))
    }
    else if (StartsWith(section, "nothere ")) {
[···and so on···]

I was just thinking, it might be useful to put all those options in a script dictionary:

  <function name="ProcessTextCommand" type="string" parameters="section, data">
    params = NewDictionary()
    dictionary add (params, "section", section)
    dictionary add (params, "data", data)
    foreach (command, game.textprocessorcommands) {
      if (StartsWith(section, command)) {
        invoke (ScriptDictionaryItem(game.textprocessorcommands, command), params)
        if (HasString(game, "textprocessorcommandresult")) {
          result = game.textprocessorcommandresult
          game.textprocessorcommandresult = null
          return (result)
        }
      }
    }
    // If we haven't returned yet, the stuff from the final else clause goes here
    // to handle the {object.attribute} notation
  </function>

It's a bit of a hassle handling return values (as I don't think a script attribute can just return something; though I could be misremembering). But having a loop over a dictionary rather than a huge list of else if clauses would make it easier to add your own text processor commands; which I think might be useful in some circumstances.

It will be in Quest 5.8...

@ mrangel:

yep, good spot with how the text processor commands are coding (and where its coding is located in the core code, lol) !!!

as any long (numerous) 'if/switch' checking conditions, can (should) be done instread by list/dictionary iteration, making it easier on us humans

I need to get more familar with the core code myself... sighs... HK is lazy...

@ mrangel:

http://docs.textadventures.co.uk/quest/types/using_delegates.html

Script Attributes can function exactly like a Function (return, parameters) via using 'Delegates' (basically a Delegate is just like a 'Prototype' for a Function, but for a Script Attribute instead):

<function name="example_function"> parameters="example_string_parameter" type="string">
  return (example_string_parameter)
</function>

// scripting example: 

string_variable = example_function ("hi")
msg (string_variable)

// --------------------------------------

which you can see is the same (aside from the difference of an Object vs a Function, lol) as a Script Attribute using Delegates:

<delegate name="example_delegate" parameters="example_string_parameter" type="string" />

<object name="example_object">

  <attr name="example_script_attribute" type="example_delegate">
    return (example_string_parameter)
  </attr>

</object>

// scripting example:

// rundelegate: for NO return value
// RunDelegateFunction: for a return value

string_variable = RunDelegateFunction (example_object, "example_script_attribute", "hi")
msg (string_variable)