So here's the question, I'm using a Switch to check the result from a 'get input', I have a working method but ideally I'd like the case keys to just be "whatever text the input is", and I'm not sure what a good/the best method for this is.

What I'm using currently is this

msg ("enter a command")
get input {
  switch (true) {
    case (IsRegexMatch("option1",LCase(result))) {
      msg ("do stuff here")
    }
    default {
      msg ("invalid input")
    }
  }
}

normally, the 'switch' use looks like this:

<function name="example_1_function">
  msg ("Type in 'red', 'blue', or 'yellow', please.")
  get input {
    // for 'get input', the quest engine automatically (hidden from you) sets a built-in variable: result = your_typed_in_input
    // for 'show menu' (if you were to use this instead of the 'get input' thingy), the quest engine automatically (hidden from you) sets a built-in variable: result = your_selected_choice_option
    if (result = "red" or result = "blue" or result = "yellow") {
      // switch (your_Variable_name: result)
      // per case: case (your_individual_Values_for_your_Variable)
      // double quotes for String Values
      // no double quotes for Object and Integer Values)
      // no double quotes on the special~reserved 'true' and 'false' for Boolean Values
      switch (result) {
        case ("red") {
          msg ("You get an apple.")
        }
        case ("blue") {
          msg ("You get a berry.")
        }
        case ("yellow") {
          msg ("You get a banana.")
        }
      }
    } else {
      ClearScreen
      example_1_function
    }
  }
</function>

---------------

I'm not sure if there is code to allow the 'switch' to handle dynamic or non-specified~defined Values (this is why I put in the 'if~else' check code lines), as I've still not dabbled in more complex code lines, such as your 'regex', and testing them in such Scripts~Commands~Functions~etc, like the 'switch' thingy.

but, there's always the 'if~if else~else' Scripts for that anyways.

(remember the 'switch' thingy is just a more limited {me assumingly} but more 'user-friendly' design~structure of using multiple 'if~if else~else' Scripts)

-----------

here's link:

http://docs.textadventures.co.uk/quest/ ... witch.html

(ah, indeed there's a 'default' option, and I'm sure your 'regex' works too, as you said it does, that your 'switch' code, is functional)

now, I'm confused as to what are you asking about in your OP, lol.

Sorry it seems I wasn't entirely clear. The way you set it up does work. I was attempting to use pattern matching, so that either additional info added after the command or slight variations would just throw back an unknown choice.

I'm essentially building a scenario which only accepts relevant commands, but I'd like it to be somewhat lenient on exactly what you enter they way you can use the pattern matching in the actual 'command' type object.

I may actually opt to just go back to requiring an exact input though. I guess I'll look more into this before I decide.

TinFoilMkIV wrote:So here's the question, I'm using a Switch to check the result from a 'get input', I have a working method but ideally I'd like the case keys to just be "whatever text the input is", and I'm not sure what a good/the best method for this is.

I do not think switch allows that, I think the case values need to be string or integer literals (specifical values, not function calls, etc. Try this instead:

msg ("enter a command")
get input {
  if (IsRegexMatch("option1",LCase(result))) {
    msg ("do stuff here")
  }
  else if (IsRegexMatch("option2",LCase(result))) {
    msg ("do different stuff here")
  }
  else {
    msg ("invalid input")
  }
}

using "IsRegexMatch("option1",LCase(result))" is actually allowed as a case key, but it's a lot of typing per key with more opportunity for errors and you can't actually read the fully key in GUI mode to see what options you already have entered. Even in code view you have to look through the key to determine which one you're actually looking at.

I was hoping to simplify it to make reading the code easier as well as less opportunity for errors, but that may not be possible with this method without restricting the accepted input to be more specific.

TinFoilMkIV wrote:using "IsRegexMatch("option1",LCase(result))" is actually allowed as a case key...

So it is, I am surprised.

it has to be checked against "switch(true) { } however, and that's not exactly easy to decipher when going back over code to check for errors. Makes it a bit tricky to easily find which block of code is doing what. Especially when all the keys are "IsRegexMat...."

Not sure if this seems better, but it's an alternate way: use a script dictionary (maps strings to scripts). Then loop through the keys in the dictionary and see if any matches (regex or otherwise). If so, invoke the corresponding script. The following sample game shows the technique.

<!--Saved by Quest 5.5.5328.26617-->
<asl version="550">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />
  <game name="sdtest">
    <gameid>e36b8c02-0b58-4d62-b130-520286181f49</gameid>
    <version>1.0</version>
    <firstpublished>2015</firstpublished>
    <matches type="scriptdictionary">
      <item key="option1">
        msg ("This happens for option1")
      </item>
      <item key="option2">
        msg ("Option 2 seems nice.")
      </item>
      <item key="option3">
        msg ("Third time's the charm.")
      </item>
    </matches>
  </game>
  <object name="room">
    <inherit name="editor_room" />
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
  </object>
  <command>
    <pattern>test</pattern>
    <script>
      msg ("Enter an option")
      get input {
      	foreach(key, game.matches) {
      		if (IsRegexMatch(key, LCase(result))) {
      			invoke(ScriptDictionaryItem(game.matches, key))
      		}
      	}
      }
    </script>
  </command>
</asl>

HIghlights: "game.matches" is a script dictionary. And there is a "test" command that asks for input and then tries to match an entry in the dictionary,

Hmm, yea not sure if it's actually "better" per se for code readability, but I think that method may at least keep things more organized and at least a bit easier to debug once you're used to how it's setup

Ideally what I'd want would be the code to create what is essentially a limited scope 'command'. The argument against just using normal commands and flag checking if you're in the scope of where it should do anything is mainly ui clutter while editing the game. I really don't want to have to deal with sorting through a list of 300 something commands where every other command has a similar name with different patterns.