Should be a pretty quick and easy question.

Get Input
If Result = "Yes"
then
blah blah.

So I was wondering can you do...

Get Input
If Result = "yes;sure;okay;of course"
then
blah blah

Also, will the lower case letters cover capital letters too?


Thank you!

if (ListContains(Split ("yes;sure;okay;of course",";"),LCase(result))) {
  msg ("YES")
}

If you're using a switch, which I personally do almost every time I use a get input to ask a question, you can specify several triggers for a case.
ie:

get input {
	switch(LCase(result) ) {
		case("one", "two", "three"){
			//stuff happens
		}
		default {
			//stuff doesn't happen
		}
	}
}

This will 'do stuff' if the player enters either "one", "two, or "three". Any one of those responses triggers the case.
http://docs.textadventures.co.uk/quest/ ... witch.html

Also the 'LCase()' function helps to deal with capitalization issues, as it will convert the result into full lowercase before checking it against your cases, so it will treat everything as a lower case letter, otherwise the results will be case sensitive.
http://docs.textadventures.co.uk/quest/ ... lcase.html

TinFoilMkIV wrote:...
Also the 'Lcase()' function helps to deal with capitalization issues, ...

Some of them. You also need to capitalise LCase right!

The Pixie wrote:

"TinFoilMkIV"

...
Also the 'Lcase()' function helps to deal with capitalization issues, ...

Some of them. You also need to capitalise LCase right!

And this is what happens when I don't copy/paste my functions...

But yes, caps matter even when you're trying to make them not matter.

Thank you very much for all the responses everyone! I was just curious if this was the correct format. I double checked the explanation pages on "switch" as well.

get input {
ListContains(Split("sexy;sympathy;sarcastic;snoopy;serious",";")(LCase(result)) {
switch(LCase(result)) {
case(“sexy”) {
msg(““I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.”)
player.sexy = player.sexy + 1
}
case(“sympathy”)
msg(“"Err...that is, I'm not Rold, ma'am." you reply almost bashfully.”)
player.sympathy = player.sympathy + 1
}
case(“sarcastic”)
msg(““Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.”)
player.sarcastic = player.sarcastic + 1
}
case(“snoopy”)
msg(““I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.”)
player.snoopy = player.snoopy + 1
}
case(“serious”)
msg(““At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a very serious tone.”)
player.serious = player.serious + 1
}
default {
msg(“”)
}
}

^--- one thing I was curious about is the "default response". Is there a way to just repeat the choices?

The technique I use is to make all my get input scripts a script attribute of an object, then I have it run itself when it either defaults, or a response loops back to the same choice. ie:

//object 'combat', script attribute 'main'
msg ("You are in combat")
msg("")
msg("What would you like to do?")
get input {
	switch (LCase(result)){
		case("attack"){...}
		case("hit it really hard"){...}
		case("flee!"){...}
		case("wait"){...}
		default {
			msg ("invalid choice")
			wait{
			ClearScreen
			do (combat, "main")
			}
	}
}

Is the:

wait {

what causes it to repeat?

Also, did I set the rest up correctly?

no, the wait simply pauses till the player presses a key so they have time to read the "invalid input" message before the whole thing restarts

The 'do (combat, "main")' is what makes it repeat, however this requires that the object 'combat' has a script attribute called 'main'. The code I posted as noted in the commented line is the script itself.

you could just have

default {
	do (combat, "main")
}

and it would loop, tho it wouldn't be as clean, the extra stuff is just for looks and user friendliness.

So I wonder if I could do something like...

default {
do ("repeat")
or something like that would work. BTW Tin, I appreciate your feedback so far! It's interesting the way you use it for combat.

to call~activate~run (or RE-call-activate-run) a Function, in code, you simply type in the Function's name with parenthesis (and args in them if you got params), for example: test_function(), or: test_function (orc.strength). in the GUI~Editor, you simply choose the 'call function' Script, and then, set it up (type in its name into the skinny rectangle text box, and if you got parameters, add your arguments)

to call~activate~run (or RE-call-activate-run) a Script, in code:

'do' or 'invoke'

and again, the Script Attribute (Object_name and Attribute_name) is what you input for the 'do, just like with a Function.

for example:

do (orc, "fight")

the 'do' is more useful~versatile~powerful, so might as well just use~learn that, and not bother with 'invoke' at all.

get input {
ListContains(Split("sexy;sympathy;sarcastic;snoopy;serious",";")(LCase(result)) {
switch(LCase(result)) {
case(“Snarky”) {
msg(“”)
player.snarky = player.snarky + 1
}
case(“Sympathy”)
msg(“”)
player.sympathy = player.sympathy + 1
}
case(“Sarcastic”)
msg(“”)
player.sarcastic = player.sarcastic + 1
}
case(“Snoopy”)
msg(“”)
player.snoopy = player.snoopy + 1
}
case(“Serious”)
msg(“”)
player.serious = player.serious + 1
}


//player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
do (get input, "switch")
}
}
}

Something like that? I know this isn't a Function, at least I don't think "Switch" scripts are considered Functions since they are called "Switch Scripts" So a Script would apply in the case you pointed out HK. Good to hear from you again btw, are you on Fall Break too?

no... I'm just burnt out from school work... last week after this thanksgiving holiday (I didn't get any extra days off from normal weekend, grr), and then finals... I'm sick of doing programming labs (been doing C++, Java, and Python labs non-stop for this entire school symester)... just too burnt out... sighs.

now that I'm taking programming classes, I'm learning the technical lingo, lol.

so, if you want to be bored in technicality meaningless nonsense:

a Function is not attached to an Object, it is an Element (Quest's OOP~OOD 's OBJECTS~CLASSES~INTERFACES) ~ it exists on its own, for example: function_1 ()

a (non-generalized usage of) Script, is a Script Attribute, which is an Attribute (which is a global VARIABLE) as it is attached to an Object (and thus it can't exist on its own, ie: fight ---> Error), for example: orc.fight

----

err... maybe in quest, a 'switch' is a Script... not sure if it's programmed to be a Script or Function... but in programming languages, 'switch' is a Function.

It's my first time using a "switch" script. I simply didn't need one before...but I figure if I'm delving deeper into the "Get Input" function now I need to learn it and incorporate it. I feel like I've learned a ton from Pertex, Tin, Hk (you), and Pix. Though I think I annoy, Pix with all my questions! I'm learning a lot though and am now better equipped to figure things out. I've fixed a ton of problems without having to ask, but the more complicated stuff and new things, I still really need help with, so I lean on you guys a ton. I do apologize for that! But I've been trying to make it up to everyone by passing on what I know to others! At least when I can.

//let's say player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
do (get input, "switch")
}
}
}

I was wondering if I have the rest of the "Switch" Script set up correctly though --- and regarding this little portion here. I was hoping to have it repeat the Switch Script. I feel like it makes sense 'do' get input (again), lead into switch script, if the response doesn't match the criteria.

Good for you though taking those classes, I wish they were offered where I go to college but it's primarily a teaching college.

the 'switch' is merely a different structure~design~look~feel, but everything the 'switch' does, an 'if~if else~else' block can do too. So, it's just a matter of which one you like better and~or works better (or just looks better or makes more sense, lol) for what you're doing. The 'switch' is able to do everything that the 'if' can do, and the 'if' is able to do everything the 'switch' can do, they just have different looks to them.

In some other languages, the 'switch' has some extra functionality and~or different programming, which I don't think exists in quest ('break' and 'continue' and definately not that the 'switch' does each~every 'case' until~unless there's a 'break' statement, as this would be too confusing for non-coders, laughs).

//let's say player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
do (get input, "switch")
}

you're close, but you're using 'do' incorrectly there. The first parameter needs to be an object, and the second, the string, is the name of the attribute script to run. It's a lot like how 'player.serious' is a two part reference, the object name, and then the attribute within it you want to look at. The 'do' needs to first know the object, and then the name of the attribute, and the rest is up to the script you have stored in that attribute.
http://docs.textadventures.co.uk/quest/scripts/do.html

EDIT: the whole thing about calling functions vs scripts isn't really in relation to what you use in your code. Technically a lot of the code we use in quest are pre coded functions, really a function is just a named chunk of code that will activate whenever the code comes across it's name. You can create your own custom functions in quest and call them from your code ie: MyTestFunction(), will do whatever code I happen to include in the function itself. Anything with the parenthesis after it is a function, the persistent denote where the parameters go, though not all functions need to use parameters.

Anyways when HK refers to "calling a script" in this case we specifically mean a 'script' type attribute. Honestly it works almost identically to calling a custom function however functions are global so I prefer to avoid creating a function unless its something I plan to use pretty frequently. The big difference is using parameters, which you can use in a script attribute but its generally more work to do so vs a function.


As for your switch code

get input {
ListContains(Split("sexy;sympathy;sarcastic;snoopy;serious",";")(LCase(result)) {
switch(LCase(result)) {
case(“Snarky”) {
msg(“”)
player.snarky = player.snarky + 1
}
case(“Sympathy”) 
msg(“”)
player.sympathy = player.sympathy + 1
}
case(“Sarcastic”) 
msg(“”)
player.sarcastic = player.sarcastic + 1
}
case(“Snoopy”)
msg(“”)
player.snoopy = player.snoopy + 1
}
case(“Serious”)
msg(“”)
player.serious = player.serious + 1
}

I don't believe the 'ListContains(Split("sexy;sympathy;sarcastic;snoopy;serious",";")(LCase(result)) ' part is necessary. For one you don't have an 'if' to do anything whether your list contains statement is true or false, so it doesn't really accomplish anything as its written. It might actually throw an error since its the equivalent of just having a line of code that reads 'true'.

The switch already compares your parameter value, which in this case is the 'LCase(result)', to the case values, and then executes them if it finds a positive match. As said above, a switch is basically a different format for a multi layered if/else statement. your switch would look something like this as an 'if'

if (LCase(result) = "snarky"){
msg(“”)
player.snarky = player.snarky + 1
}
else if (LCase(result) = "sympathy"){
msg(“”)
player.sympathy = player.sympathy + 1
}
else if (LCase(result) = "etc"){...}

Cases tend to be more preferable when you want to compare the same thing to bunch of different things, since as you can see you have to type it out for every comparison with the 'if'.

I don't know that I've ever used a get input without a switch that followed. Even if it is only one choice. It's either easy, I understand it, or both.

Haha, yeah I've only very rarely used "Get Input" scripts because my game didn't have enough of stuff at the time for the player to make impacts on anything except the character they play. Now that I have a bit more written, I can start putting in "personality" based choices which will raise particular values. So now I'm trying to get the hang of these now.

My problem is, Tin said that the "Switch" default response needs to be attached to an object in the game and a string but I believe everything I use is attributes. For example,

//let's say player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
do (get input, "switch")
}

you're close, but you're using 'do' incorrectly there. The first parameter needs to be an object, and the second, the string, is the name of the attribute script to run. It's a lot like how 'player.serious' is a two part reference, the object name, and then the attribute within it you want to look at. The 'do' needs to first know the object, and then the name of the attribute, and the rest is up to the script you have stored in that attribute.

I have an object called "Personality"
and then a "String List"
"Snarky"
"Curious" etc.

So I'm not sure how to attach the default to the String List and have the "reply" thing to repeat xD (which is qouted above). Even if I made it an "if" statement though I still don't know how to get this...

//let's say player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
do (get input, "switch")

to work lol.

the 'do' is for Script Attributes (Verbs): the 'do' calls upon (does~activates~runs~executes) Verbs, (like calling upon a Function)

the 'do' does ACTIONS

for examples:

http://docs.textadventures.co.uk/quest/scripts/do.html

do (Object_name, "Script_Attribute_name_which_is_the_same_as_a_Verb_name")

do (orc, "fight")
do (sword, "wear")
do (cookie, "take")
do (coin, "drop")
do (ball, "kick")
do (door, "open")
do (door, "unlock")
do (pizza, "eat")
do (flower, "smell")
do (player, "heal")
do (fireball, "cast")
do (fireball, "learn")

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

for altering~changing~setting~re-setting~etc Non-Script Attributes, you use the 'set', see examples below:

(the 'set' for the most part is the same as, for example: player.strength = 75)

http://docs.textadventures.co.uk/quest/scripts/set.html

set (Object_name, "Attribute_name", Attribute_Value)

set (player, "alias", "HK")
set (player, "strength", 100)
set (orc, "strength", 25)
set (orc, "dead", true)
set (player, "class", "warrior")
set (player, "race", "human")
set (player, "sex", "male")
set (wall, "color", "green")

the above is the same as the below (for the most part)

player.alias = "HK"
player.strength = 100
orc.strength = 25
orc.dead = true
player.class = "warrior"
player.race = "human"
player.sex = "male"
wall.color = "green"

Oooohhhhh, so "Do" is literally "Do" this verb. I guess that should have made sense. Now I feel like a derpaderp that you had to explain it like that. Ugh.

So set seems to be the one I should use.

set (Object_name, "Attribute_name", Attribute_Value)

//let's say player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
set (get input, "switch")
}

The only problem is it seems like you still need an object name: Maybe....

default {
msg(“What was that? Can you choose your response again, please?”)
set (get input, "switch", result)
}

"Do" can call a verb, that's not the only thing it does. The key reason we use it here is to call a 'script' type attribute to make the code in it run.

I threw together a demo for you to take a look at so you can see it in action and what the script looks like.

http://www.mediafire.com/download/5zo1l ... pDemo.aslx

@ neonayon:

actually, you're still trying to use scripts, so you'd need to use 'do', and something like this, for example only:

<game name="blah">
  <start type="script">
    do (creation, "character_creation")
  </start>
</game>

<object name="creation">
  <attr name="character_creation" type="script">
    msg ("What is your name?")
    get input {
      player.alias = result
      switch (player.alias) {
        case ("HK") {
          msg ("Your name is HK")
        }
        case ("Neonayon") {
          msg ("Your name is Neonayon")
        }
      }
    }
  </attr>
</object>

or, for example, if I wanted to do~run the 'start' script again later in the game in some scripting, you'd do this:

do (game, "start")

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

@ Neonayon:

using my example above, if you actually want to do a specific segment~part within a larger code~scripting block... a way to do that is to put that segment~part into a Function, and then have the function call be in-place-of that segment~part in the larger code-scripting block, but this gets into more complex Function and~or Looping usage, which is riddled with order of operation issues, as it's easy to mess it up the design needed ...

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

@ Tin:

how else or what else can 'do' be used for? I didn't know it could be used for other stuff besides activating~invoking a Script Attribute. Learned something new, laughs.

HegemonKhan wrote:@ Tin:

how else or what else can 'do' be used for? I didn't know it could be used for other stuff besides activating~invoking a Script Attribute. Learned something new, laughs.

Uh yea, ignore that part, I was not entirely paying attention when I typed that. Pretty sure I was making incorrect assumptions tho I don't even remember what else I was thinking you could call with it now.

Wow the sample game made it a lot clearer as well. Thank you so much.

so it's

//let's say player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
do (control, "SwitchLoop")
}

and that'll keep the choices repeating.

Thank you so much Tin and HK. I understand the concept a lot better I think! I really appreciate that!!

Yep, although you don't have to name them the same thing, I just tried to keep the names straight forwards.

So I have one more question about the "control" object.

What is it exactly, and how does it make the script repeat. I ask because in the demo it has...

("")
get input {
switch (LCase(result)) {
case ("option1") {
msg ("You chose option1, clearing screen and restarting loop")
wait {
ClearScreen
do (control, "SwitchLoop")
}
}
case ("option2") {
msg ("You chose option2, restarting loop without screen clear or wait")
msg ("")
do (control, "SwitchLoop")
}
default {
msg ("invalid choice, please try again...")
msg ("(this is the default for the switch)")
msg ("")
wait {
do (control, "SwitchLoop")
}
}
}
}

listed on the control.object's attributes. But I don't understand the function of it for the code. I mean...does a switch script need this object anchor which represents nothing in order to repeat? I know in the previous conversations we were talking about...

do (object, "SwitchLoop")

But ...why can't it just be...

do ("SwitchLoop")

It seems like connecting it to an object is completely pointless unless you have an object in your game that it needs to be connected to for a purpose. So I guess I just create an object called "SwitchLoopResponse" and then put......I don't know...

I haven't looked at Tin's code, but yes, I believe that's the point of Tin creating and using an Object, that he~she decided to name as 'control' and its Script Attribute that he~she decided to name as 'switchloop'. The name of an Object and~or Attribute doesn't matter, aside from helping the human out with understanding what it is and~or is doing and~or with~for organization.

the 'do' Script~Function (and many others as well, such as 'set') REQUIRE an Object, as it uses an Attribute (and as an Attribute is contained inside of an Object or other Elements, to call upon that Attribute, you must specify the Object that contains it, in order to call upon it and activate it, right? does this make sense?)

the confusion is that with normal scripting (code lines), the syntax is:

orc.fight // you use a period to separate the Object from its Attribute

but when your using a Script~Function such as 'do' or 'set', it's:

do (orc, "fight") // you use a comma to separate the Object from its Attribute, and the Attribute must be in double quotes too. The reason is that these are parameter inputs, which are separated by commas, as opposed to a direct scripting code line which just requires the dot~period separator for it.

set (orc, "life", 100) // you use a comma to separate the Object from its Attribute, and the Attribute must be in double quotes too. As you can see, 'set' has a 3rd parameter position, also separated by a comma, for setting~re-setting the Attribute's Value. The reason is that these are parameter inputs, which are separated by commas, as opposed to a direct scripting code line which just requires the dot~period separator for it.

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

to explain this further... gets into programming knowledge and terminology~lingo, which would probably confuse you even worse, as I'd be explaining the difference from a standalone Function Element vs a Method~Member (Attribute) OF an Object-Class, and etc programing stuff, lol

so, I hope the above explanation helps... otehrwise, you're just going to have to memorize the syntaxes, and ignore not understanding it, lol.

Thank you for clarifying that they need an object to use the attribute of. That makes perfect sense.

But on the object's attribute...if the "Switch" is for different conversation responses throughout the game, what needs to be put to have the responses repeated if the player mistypes something? I got the entire script working EXCEPT for the default situation.

I added-edited in a bit more stuff to my previous post, so you may want to refresh and look at it again

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

you could have the 'switch' (which is scripting INSIDE of the, using Tin's example, his~her 'switchloop' Script Attribute of the 'control' Object) scripting's default response be a (re) call upon of the 'control' Object's 'switchloop' Script Attribute:

the 'switch' scripting's 'default response:

do (control, "SwitchLoop")

which will do the entire thing over again

(this is bad code design though, as it's recursion, which eats up memory, as it stores every re-run of the 'SwitchLoop' scripting, not removing this storage until you move past this entire scripting, to entirely new scripting)

(but, it probably~hopefully won't effect your game, as long as the person playing the game doesn't mess up a bunch of times... laughs)

(to avoid the memory "gluttony" of recursion, you'd have to not use re-calling of the 'SwitchLoop', and instead use a 'while', 'do-while' (not sure if quest has this type of loop or not, as it's not really necessary as you can easily do the same with a 'while' loop), 'for', or 'foreach' loop, as these don't eat up your memory.

(I still got to learn exactly why they don't... as best as I think I understand, these loops are like literal 'goto' code line calls, but I still don't understand why memory isn't being used up, regardless, but meh, hopefully I be learning this in future programming classes ~ you can ignore all of this technical wondering on my part, lol. Note I do understand that an Object~Element uses up much more memory to store the scripting due to all the extra "metadata" needed and~or etc stuff, than does storing just script-code lines, but this still uses up some memory too, just a lot less, but as you can see, I don't really understand how the loops are working compared to how recursion is working, laughs).

This seems way overly complicated for a simple....repeat the question process lol. I've already been trying to figure it out for at least 3 hours today, and several the previous days when the problem first came up. I'd rather the game not eat up memory....so would I do...

So how would the "while" work in terms of the default of the switch script? I'm not familiar with "foreach", or "do-while" or "while"

//let's say player mispells choice
default {
msg(“What was that? Can you choose your response again, please?”)
do (control, "SwitchLoop")

actually, you wouldn't use the 'switch' default response to repeat, as this is what the 'while' loop is for, it'll do the repeating for you.

(using Tin's example)

<object name="control">
  <attr name="SwitchLoop" type="script">
    // possibly your scripts (depends on what your scripts are in whether they go inside of the 'while' loop block or outside of it)
    flag = false
    while (!flag)
      // possibly your scripts (depends on what your scripts are in whether they go inside of the 'while' loop block or outside of it)
      // your 'switch' block
        // your 'cases' of the 'switch' block
        // optional: the 'switch' default response

       // put in this script line, flag = true, for when you want to end the while loop's 'looping' and continue on with the game, into (depends) whatever 'cases' and~or the 'default response. Based on what you've posted, it sounds like if any of the cases happen, you want to end the looping and move on, so you EACH~ALL of your cases, you'll need this script line in them: flag = true // or via GUI~Editor: set variable flag = [expression] true 

  </attr>
</object>

-----------

how the while loop works (in my example above):

the 'flag' local~temporary Variable (this is NOT an Attribute) is set to 'false'

this ensures that the while loop initially runs (aka: it'll run at least once: this is the same effect as the 'do while' loop), as this is due to the while loop's condition is, while (!flag), which is saying: as long as 'flag' is set to 'false', the while loop will keep repeating itself (will keep looping).

Thus to stop this endless repeating, we just need to set~re-set the 'flag' to 'true', which will end the while loop's repeating and the game will continue onwards.

So, somewhere in whatever combination of cases (none, one, which one, some, which some, and~or all) and~or the default response, one of these, must have this script line, flag = true, or else you'd have an endless~infinite while loop, which will crash your game, as the game~quest~computer~cpu can't endlessly~infinitely loop (you don't have infinite memory and machines do break down too from even normal usage), lol.

I'll give it a shot. Will the "switch" script work if I delete the "default" part of it? I mean, isn't that like the "else" in the "If" scripts?

the default response of a 'switch' Script~Function, is completely optional, indeed it is just like an 'else' in an 'if' Script~Function block, acting as an optional "catch all", aka: if everything else fails, then do or msg this... lol

So I'm curious...

I have an object "SwitchLoopResponse"

Attribute name: SwitchLoop

Script:

flag = false
while (!flag) {
}
flag = true

But how do I connect this code to the switch scripts in the game?

May I see a sample of a case or two? Here are what mine look like...

switch (LCase(result)) {
case ("sexy") {
msg ("<br/>“I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.<br/>")
player.sexy = player.sexy + 1
}
case ("sympathy") {
msg ("<br/>\"Err...that is, I'm not Rold, ma'am.\" you reply almost bashfully.<br/>")
player.sympathy = player.sympathy + 1
}
case ("sarcastic") {
msg ("<br/>“Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.<br/>")
player.sarcastic = player.sarcastic + 1
}
case ("snoopy") {
msg ("<br/>“I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.<br/>")
player.snoopy = player.snoopy + 1
}
case ("serious") {
msg ("<br/>“At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a very serious tone.<br/>")
player.serious = player.serious + 1
}

Unfortunately Quest doesn't play terribly nicely with any kind of delayed response and active scripts, which is why I used the recursion method. If you put a 'get input' or something similar inside a 'while loop' you're going to get errors, because it will keep running the loop without waiting for the player input.

ie:

while(flag){
	get input {
		//do stuff
		//turn flag off when a case that ends the loop happens
	}
	//this part of the script will still run while waiting on the get input
	//...
	//you now get an error because the loop will try to constantly re-run your get input while the first one is still waiting.
}

EDIT: Also yes you can remove the 'default' from a switch and still be okay. If you want your menu to account for invalid inputs and such you'll probably want one tho. It literally is the 'else' of the switch, the thing that happens if no cases are matched. Not required but as far as menus and non-optional inputs its probably a good idea.

I guess that makes sense ---- hopefully then the player just doesn't type a bunch of misspellings lol!

So okay, I have the object: SwitchLoopResponse (in place where you had "control")
and an attribute on it called: SwitchLoop

Now when I looked at the code on your demo, it had...

("")
get input {
switch (LCase(result)) {
case ("option1") {
msg ("You chose option1, clearing screen and restarting loop")
wait {
ClearScreen
do (control, "SwitchLoop")
}
}
case ("option2") {
msg ("You chose option2, restarting loop without screen clear or wait")
msg ("")
do (control, "SwitchLoop")
}
default {
msg ("invalid choice, please try again...")
msg ("(this is the default for the switch)")
msg ("")
wait {
do (control, "SwitchLoop")
}
}
}
}

So applying it to my game would look like...?

switch (LCase(result)) {
default {
do (SwitchLoopResponse, "SwitchLoop")
}
}

Which I would have to apply to all the default "switch" scripts correct? And as an attribute script on my "SwitchLoopResponse" object?

gah...I totally forgot about the 'get input' issue... sorry for the code using 'while'... my bad

-----------

though for future reference if you ever want to use the while loop, here's how it should be (I wasn't clear enough, sorry, neonayon):

(ignoring the issue with 'get input', of course)

flag = false
while (!flag) {
  msg ("xxx")
  get input {
    switch (LCase(result)) {
      case ("sexy") {
        msg ("<br/>“I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.<br/>")
        player.sexy = player.sexy + 1
        flag = true
      }
      case ("sympathy") {
        msg ("<br/>\"Err...that is, I'm not Rold, ma'am.\" you reply almost bashfully.<br/>")
        player.sympathy = player.sympathy + 1
        flag = true
      }
      case ("sarcastic") {
        msg ("<br/>“Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.<br/>")
        player.sarcastic = player.sarcastic + 1
        flag = true
      }
      case ("snoopy") {
        msg ("<br/>“I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.<br/>")
        player.snoopy = player.snoopy + 1
        flag = true
      }
      case ("serious") {
        msg ("<br/>“At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a veryy serious tone.<br/>")
        player.serious = player.serious + 1
        flag = true
      }
      default {
        msg ("Wrong input, try again...")
      }
    }
  }
}

Neonayon wrote:I guess that makes sense ---- hopefully then the player just doesn't type a bunch of misspellings lol!

So okay, I have the object: SwitchLoopResponse (in place where you had "control")
and an attribute on it called: SwitchLoop

Now when I looked at the code on your demo, it had...

...

So applying it to my game would look like...?

switch (LCase(result)) {
default {
do (SwitchLoopResponse, "SwitchLoop")
}
}

Which I would have to apply to all the default "switch" scripts correct? And as an attribute script on my "SwitchLoopResponse" object?

Yes you have that right as far as the script setup. Generally yes you want whatever the current input code to be the attribute getting called. Think of it this way, when you use 'do (ThisObject, "ThisLoop")', you're basically saying, "restart this script". So at any point where you want to loop or just reset the menu or whatnot, then you call your script attribute, which in this case will likely be as the 'default' case more often than not.

But yea that's also part of why I try to keep my control objects names fairly simple, less room for error and less typing when I reference them a lot.

Also you don't strictly need a control object for this sort of thing, I just like them for organization purposes. If you're running a bunch of these for conversations with npcs and such I'd probably give the script attribute to the relevant npc.



Somewhat offtopic stuff:

I actually thought of a way to use a while loop without breaking everything, tho it kinda gets to the point where I'm not sure it ends up actually being any better than using recursion. You can use a second flag to denote when the 'get input' should be checked, so that it doesn't try to run it till the current one is done.
ie:

flag1 = true
flag2 = true

while(flag1){
	if (flag2){
		flag2 = false
		//this makes sure the input doesn't repeat while the current one is active
		get input{
			switch (LCase(result)){
				case(1){
					//do stuff
					//loop ends
					flag1 = false
				}
				default {
					//redo input
					flag2 = true
				}
			}
		}
	}
}

Also I think based on the behavior that causes the looping error to begin with, Quest may actually be somewhat recursion friendly in this sort of situation. Keep in mind this is strictly guessing off what I think it's doing, but since Quest runs all the code outside the 'get input', and if that's where the current script ends, it should run through the script and finish it while the second instance is being called.

So unless heavy use of recursion and/or user silliness starts causing major issues I'm in favor of recursion. I feel like it's a lot cleaner and easier to read code wise when you understand what its doing

So I tried to run the loop with all the current stuff:

SwitchLoopResponse object, SwitchLoop Attribute with this script.

switch (LCase(result)) {
default {
do (SwitchLoopResponse, "SwitchLoop")
}
}

and it came up with this error.

Error running script: Error compiling expression 'LCase(result)': Unknown object or variable 'result'

So...should I just remove the LCase part from the script since it wont matter what they type in for the loop?

switch () {
default {
do (SwitchLoopResponse, "SwitchLoop")
}
}

Like this?

the 'result' Variable came from the 'get input' Script~Function (it, along with the 'show menu' Script~Function, automatically sets your input or selection to the 'result' Variable), so that's why you're getting the error, as your 'switch' is trying to find the 'result' Variable, but it doesn't exist as you removed the 'get input'.

here's a sample game of the while loop in action:

(obviously, there's infinite implementations~applications~designs of the while loop, this is just a single simple example)

(hopefully, this works... laughs)

<asl version="550">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />
  <game name="while_loop_sample">
    <gameid>paste or generate your own</gameid>
    <version>1.0</version>
    <start type="script">
      fast_food_function
    </start>
  </game>
  <object name="room">
    <object name="player">
    </object>
  </object>
  <function name="fast_food_function">
    flag = false
    while (!flag) {
      msg ("Fast Food Menu:")
      msg ("(1) hamburger")
      msg ("(2) pizza")
      msg ("(3) chicken")
      msg ("(4) exit")
      get input {
        switch (result) {
          case (1) {
            msg ("Here's your hamburger!")
          }
          case (2) {
            msg ("Here's your pizza!")
          }
          case (3) {
            msg ("Here's your chicken!")
          }
          case (4) {
            msg ("Have a good day, Sir/Ma'am.")
            flag = true
          }
          default {
            msg ("Wrong input, try again")
          }
        }
      }
    }
  </function>
</asl>

As HK said, 'result' doesn't exist until you use a 'get input', it's a hidden attribute that gets created to store the input. So without the 'get input' it won't work.

Also technically the 'LCase()' isn't needed for your script to work, but keep in mind if the player is typing, and you give them "option1" and they enter "Option1", it won't match without the LCase() function.

So I tried removing the "get input", result portion of the script ...making it...

switch {
(SwitchLoopResponse, "SwitchLoop")
}

which auto turns it into this...

switch (SwitchLoopResponse, "SwitchLoop") {
}

and this error popped up. Sigh. Apparently getting a Switch to loop is impossible lol.

Error running script: Error compiling expression 'SwitchLoopResponse, "SwitchLoop"': SyntaxError: Unexpected token ","; expected one of <EOF>Line: 1, Column: 19

you're getting confused more and more I think unfortunately... as we're throwing all these explanations at you for why things are going wrong as you try on your own to get it to work, it's just confusing you worse and worse.

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

here's it as recursion (this may not work as I'm not as knowledgeable with how to get the 'get input' and~or 'show menu' to work with recursion, as Tin and Pixie are), so just use this (assuming it works ~ if not, have Tin or Pixie craft the correct recursion design for you that works):

(try to study and understand these 3 designs: 1A, 1B, and 2 -------- ask if you need help with understanding them!)

1A. using an Attribute for recursive looping~repeating:

<game name="xxx">
  <start type="script">
    do (SwitchLoopResponse, "SwitchLoop")
  </start>
</game>

<object name="SwitchLoopResponse">
  <attr name="SwitchLoop" type="script">
    msg ("What is your personality?")
    msg ("Your choices are (type one of these in): sexy, sympathy, sarcastic, snoopy, or serious")
    get input {
      switch (LCase(result)) {
        case ("sexy") {
          msg ("<br/>“I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.<br/>")
          player.sexy = player.sexy + 1
        }
        case ("sympathy") {
          msg ("<br/>\"Err...that is, I'm not Rold, ma'am.\" you reply almost bashfully.<br/>")
          player.sympathy = player.sympathy + 1
        }
        case ("sarcastic") {
          msg ("<br/>“Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.<br/>")
          player.sarcastic = player.sarcastic + 1
        }
        case ("snoopy") {
          msg ("<br/>“I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.<br/>")
          player.snoopy = player.snoopy + 1
        }
        case ("serious") {
          msg ("<br/>“At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a very serious tone.<br/>")
          player.serious = player.serious + 1
        }
        default {
          msg ("Wrong input, try again.")
          do (SwitchLoopResponse, "SwitchLoop")
        }
      }
    }
  </attr>
</object>

1B. using an Attribute for recursive looping~repeating variation for hopefully better understanding:

(hopefully you see how the 'game.start' is a Script Attribute, just as 'SwitchLoopReponse.SwitchLoop' is a Script Attribute, both able to be used to call upon themselves for recursive looping~repeating)

(see the switch's default scripts, notice the difference in this 1B, vs 1A's switch's default scripts, ???)

<game name="xxx">
  <start type="script">
    do (SwitchLoopResponse, "SwitchLoop")
  </start>
</game>

<object name="SwitchLoopResponse">
  <attr name="SwitchLoop" type="script">
    msg ("What is your personality?")
    msg ("Your choices are (type one of these in): sexy, sympathy, sarcastic, snoopy, or serious")
    get input {
      switch (LCase(result)) {
        case ("sexy") {
          msg ("<br/>“I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.<br/>")
          player.sexy = player.sexy + 1
        }
        case ("sympathy") {
          msg ("<br/>\"Err...that is, I'm not Rold, ma'am.\" you reply almost bashfully.<br/>")
          player.sympathy = player.sympathy + 1
        }
        case ("sarcastic") {
          msg ("<br/>“Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.<br/>")
          player.sarcastic = player.sarcastic + 1
        }
        case ("snoopy") {
          msg ("<br/>“I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.<br/>")
          player.snoopy = player.snoopy + 1
        }
        case ("serious") {
          msg ("<br/>“At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a very serious tone.<br/>")
          player.serious = player.serious + 1
        }
        default {
          msg ("Wrong input, try again.")
          do (game, "start")
        }
      }
    }
  </attr>
</object>

2. using a Function call for recursive looping~repeating:

<game name="xxx">
  <start type="script">
    SwitchLoopResponse
  </start>
</game>

<function name="SwitchLoopResponse">
  msg ("What is your personality?")
  msg ("Your choices are (type one of these in): sexy, sympathy, sarcastic, snoopy, or serious")
  get input {
    switch (LCase(result)) {
      case ("sexy") {
        msg ("<br/>“I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.<br/>")
        player.sexy = player.sexy + 1
      }
      case ("sympathy") {
        msg ("<br/>\"Err...that is, I'm not Rold, ma'am.\" you reply almost bashfully.<br/>")
        player.sympathy = player.sympathy + 1
      }
      case ("sarcastic") {
        msg ("<br/>“Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.<br/>")
        player.sarcastic = player.sarcastic + 1
      }
      case ("snoopy") {
        msg ("<br/>“I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.<br/>")
        player.snoopy = player.snoopy + 1
      }
      case ("serious") {
        msg ("<br/>“At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a very serious tone.<br/>")
        player.serious = player.serious + 1
      }
      default {
        msg ("Wrong input, try again.")
        SwitchLoopResponse
      }
    }
  }
</object>

<game name="xxx">
<start type="script">
do (SwitchLoopResponse, "SwitchLoop")
</start>
</game>

<object name="SwitchLoopResponse">
<attr name="SwitchLoop" type="script">
msg ("What is your personality?")
msg ("Your choices are (type one of these in): sexy, sympathy, sarcastic, snoopy, or serious")
get input {
switch (LCase(result)) {
case ("sexy") {
msg ("<br/>“I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.<br/>")
player.sexy = player.sexy + 1
}
case ("sympathy") {
msg ("<br/>\"Err...that is, I'm not Rold, ma'am.\" you reply almost bashfully.<br/>")
player.sympathy = player.sympathy + 1
}
case ("sarcastic") {
msg ("<br/>“Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.<br/>")
player.sarcastic = player.sarcastic + 1
}
case ("snoopy") {
msg ("<br/>“I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.<br/>")
player.snoopy = player.snoopy + 1
}
case ("serious") {
msg ("<br/>“At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a very serious tone.<br/>")
player.serious = player.serious + 1
}
default {
msg ("Wrong input, try again.")
do (SwitchLoopResponse, "SwitchLoop")
}
}
}
</attr>
</object>

I get the three different ways and it seems like this one is what I've been trying to make happen. But before I mess with it, will this work for any "switch" switchloop? I ask because the "answers" above happen multiple times. The five personalities never change, but the responses made by those personalities does depending on what topic they are on

you have an OBJECT, which you just happen to name it as "SwitchLoopResponse"

you have a SCRIPT ATTRIBUTE of the OBJECT (see above), which you just happen to name it as 'SwitchLoop"

For my variations, you also got the built-in SCRIPT ATTRIBUTE of the 'game' Game Object, named: 'start'

what you're repeating is the SCRIPT ATTRIBUTE (SwitchLoopResponse.SwitchLoop or game.start).

the 'switch' within your SCRIPT ATTRIBUTE has nothing to do with the repeating (aside from its default having the call line of the SCRIPT ATTRIBUTE, which is what does the repeating). So: any incorrect input will cause it to repeat, for the person to try again to put in the correct input.

-------

does this make sense?

-------

any of my variations~examples should work (aside from any human mistakes I've made or overlooked in my typing of it, lol), though for your own game, if this stuff comes further in the game progression~play, then obviously you'd not be using my variations that use the 'game.start' stuff.

"I ask because the "answers" above happen multiple times. The five personalities never change, but the responses made by those personalities does depending on what topic they are on (neonayon)"

what you've got, just sets your player's personality with a message about it. Everything is working as it should. (if you don't input a correct personality, then it'll repeat until you do input in a correct personality: it'll repeat until you get a personality set to your player)

as for later in the game play, if you want different events~msgs~actions~etc to happen based upon your choosen~setted personality, that's completely separate... from just setting...

HK edit: see below

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

HK edit:

err... I've written~coded for you is a hybrid that can be used at the beginning of the game for raising one of your personality attributes and later for (say for example) when you level up, choosing which personality attribute to increase... as I never paid attention to what you wanted this for doing, lol.

what did you particularly want this thing for? the beginning of the game's raising of your personality attribute(s) or later in the game play such as leveling up and raising your personality attributes ???

Oh! No no, I just need this specific thing for the "switch" to loop in case of misspelling. The player chooses the personality at the beginning of the game.

object: Personality
attribute: list
player.object
sexy: integer
sympathy: integer
sarcasm: integer
snoopy: integer
serious: integer
CreationCallBack Function
If Attribute ='s Personality "oneofthepersonalities"
+5 toward personality

does this make sense?

Yup! Gotcha.

default {
msg ("Wrong input, try again.")
do (SwitchLoopResponse, "SwitchLoop")
}
}
}

The only thing is, last time I did this, it didn't work

the only difference this time seems to be...

<game name="xxx">
<start type="script">
do (SwitchLoopResponse, "SwitchLoop")
</start>
</game>

this.

since you jsut want this for the beginning of the game, then use this:

(you can adjust my "improv~fudging" msg scripts as I'm not you - I didn't know what you wanted for them lol, to make it better for what you want)

(an option is to use an actual popup menu, via 'show menu', if you prefer this to the self made one via msg scripts I made in the example below ~ I can quickly adjust the code for this format design using a popup menu)

(or, you could put your personality choices into a stringlist, and use the 'DisplayList(game.neon_personality_list, true)' to display your choices as a list of numbered choices for you ~ I can quickly adjust the code for this format design)

<game name="xxx">
  <start type="script">
    do (SwitchLoopResponse, "SwitchLoop")
  </start>
</game>

<object name="SwitchLoopResponse">
  <attr name="SwitchLoop" type="script">
    msg ("What is your personality?")
    msg ("Your choices are (type one of these in): sexy, sympathy, sarcastic, snoopy, or serious")
    get input {
      switch (LCase(result)) {
        case ("sexy") {
          msg ("<br/>“I’m not your husband, darling --- but I can see that he is a very lucky man.” you reply in a naturally sultry voice.<br/>")
          player.sexy = player.sexy + 1
        }
        case ("sympathy") {
          msg ("<br/>\"Err...that is, I'm not Rold, ma'am.\" you reply almost bashfully.<br/>")
          player.sympathy = player.sympathy + 1
        }
        case ("sarcastic") {
          msg ("<br/>“Well, either you can disguise your voice very well, or you’re not the one who let me in here…” you say with a sarcastic inflection.<br/>")
          player.sarcastic = player.sarcastic + 1
        }
        case ("snoopy") {
          msg ("<br/>“I’m sorry, I’m not he. But maybe you’d like to tell me who YOU are and what I’m doing here.” you say with curiosity.<br/>")
          player.snoopy = player.snoopy + 1
        }
        case ("serious") {
          msg ("<br/>“At least have the curtesy of turning around before addressing me. I’m not sure we’ve been properly introduced.” you say in a very serious tone.<br/>")
          player.serious = player.serious + 1
        }
        default {
          msg ("Wrong input, or you made a typo as you typed in your choice, please try again.")
          do (SwitchLoopResponse, "SwitchLoop")
        }
      }
    }
  </attr>
</object>