I know I've commented previously on the structure of the text processor; and how it could be more extensible.

But I'm looking at it now, and I've got another issue I'm thinking is particularly bad. It occurs in quite a few of the functions, so here's an example from ProcessTextCommand_either.

The offending code:

    condition = Left(command, colon - 1)
    if (not game.text_processor_this = null) condition = Replace(condition, "this", game.text_processor_this.name)
    result = eval(condition)

So ... it extracts the condition, then does a Replace() to turn this into the object stored in game.text_processor_this.

There is no check to make sure that the four letters "this" aren't a substring of an object name, attribute, or something else in a condition which is going to be passed to eval.

It would be much more sane (and not produce extremely-hard-to-debug errors) to replace those lines with:

    condition = Left(command, colon - 1)
    params = NewDictionary()
    if (not game.text_processor_this = null) {
      dictionary add (params, "this", game.text_processor_this)
    }
    result = eval(condition, params)

(and at the same time, wouldn't it make sense to allow the user to set a dictionary like game.text_processor_variables? It could be passed to all the eval()s in the text processor, allowing users an easy way to let the text processor see any set of variables currently in scope)

Another thought:

The {random:} command uses a function called Tsplit to split up its arguments, rather than Split. This means that, for example, in {random:{b:bold}:{i:italic}:regular}, it will pick one of {b:bold}, {i:italic}, or regular rather than choosing from {b, bold}, {i, italic}, or regular.

Would it be reasonable to expand the use of this split function to other text processor functions? Notably, {either would be a lot more useful if it could be nested. I've been wondering about this for a while; but only just noticed that the function already exists.

(It would also be nice if there was some form of escaping; though that would likely be more effort than it's worth)

These are all good ideas, and will appear in Quest 5.8, which may be out at the weekend with luck. I had not noticed Tsplit myself; now applicable to both either and select.

With regards to escaping, you can already use @@@open@@@ and @@@close@@@ for { and }.

i Like that

I use br and i with the<> in my randoms.