I am attempting to have NPCs have a dialog path that results in diffrent outcomes, or just general information/fluff. I want to give the player options to choose from but I don't wish the player to type out exactly what thier character says, just simply a number (ie: if an NPC has 3 dialog options, and the third options went: "3. Where did you last see detective Ashly?" the player can simply type in 3) to futher the dialog.

Below is what I have tried so far with no success.

Print "Hi how can I help you?[NEW LINE][NEW LINE]1. Option One[NEW LINE]2. Option Two[NEW LINE]3. Option Three";
Wait for the player to press a key with prompt "Choice?";
Put what the player types next into the "dialogchoice" string variable;
If "dialogchoice" is equal to "1" Then Print "You Chose Option One!";
If "dialogchoice" is equal to "2" Then Print "You have Chosen Option Two!";
If "dialogchoice" is equal to "3" Then Print "You have Chosen Option Three!"

I belive the issue has to do with inputing what the player types; into the variable. Upon testing, once "Choice?" appears, entering a number and hitting enter produces no result (or new line), typing in the same or another number then hitting enter has the same result, upon the third time a new line with the number appears. However the script does not produce any results.

What am I missing (or am doing wrong) to passdata to a variable (from the player) and refrencing it for use?

After poking around I discoverd I can use Menus to perform this! I can perfome branching selections by creating a submenu for each menu selection for further path choices, however I can see that even a simple conversation of two paths deep can become monolithic :/

Well, the first error is that you don't have to wait for the player to press a key. That more like saying:
'Print this message, wait for a key-press, then ask for the players input'

When what you want is:
'Print this message and ask for the players choice'

Your second error is that the variable (dialogchoice) in your "conditional" isn't infact checking the variable.

When you're saying 'If "dialogchoice" is equal to "1"' you are infact asking if dialogchoice = 1, which it never will.
What you need to do is put #'s around dialogchoice, so it replaces it with the value of the variable. Like so:
'If "#dialogchoice#" is equal to "1"' This will ask if 1 = 1 etc...

And yes, I think menu's were a nice little idea, but they aren't implemented quite 'correctly'.

Hi 'Stalker'

Firstly, let me establish that I understand the requirement here.

You want to create a menu 'tree' to simulate conversation between the player and an NPC, where you have a single start menu and potentially a few layers of sub menus.

If that's what you are trying to do, I would suggest you put all your menu options into an array and write a procedure which displays sub-sections of your array as a menu of choices. You'd need to make a control variable to keep the player 'in the menu loop' until he has navigated to a conclusion.

The coding of 'proper' Quest menus is too restrictive for this, but you can 'brew your own' and ought to be able to wrap loads of on screen menu choices up into one quite small procedure. You'll still have to test for and action lots of possible results of course, but that is inevitable.

Al (MaDbRiT)

Thanks for that Al.

I just remembered an old tree-navigation lesson somewhere. Might look into coding it in ASL. Very interesting...

[EDIT]
Actually Al, I'd be very interested in your way of doing things, because I started looking into variables and about 5 minutes in (planning stage) I remembered that 'node's (in tree's) need 3 basic properties. Their name(index)=link to data, their children=other nodes coming from them, and their parent so you can navigate back up the tree when you propogate (right choice?) it.

Yet a variable can only hold 2 - it's name and it's children - and I don't fancy 2 tree's, one with children and one with var's.

I reckon objects would be a good idea. Each object with 2 properties (3 if you want to hold the data in the object). You can then use a "control" variable to control the form of the tree,and use properties from there.

Your opinion?

Using # and % are new to me, I just examined what they are used for. # is used around strings variables, while % is around numric variables. Now I did quick check for arrays and found some info.

Change the contents of string "bobdialog[1]" to "You've picked option 1!"
Change the contents of string "bobdialog[1]" to "You've picked option 2!"
Change the contents of string "bobdialog[1]" to "You've picked option 3!"
Print "Hi how can I help you?[NEW LINE][NEW LINE]1. Option One[NEW LINE]2. Option Two[NEW LINE]3. Option Three";
Put what the player types next into the "dialogchoice" string variable;
If "#dialogchoice#" is equal to "1" Then Print "#bobdialog[1]#!";
If "#dialogchoice#" is equal to "2" Then Print "#bobdialog[2]#!";
If "#dialogchoice#" is equal to "3" Then Print "#bobdialog[3]#!";

On another note "Wait for the player to press a key with prompt" would be simply used as a delay only? For example to break up alot of text, the prompt could say "Press anykey to continue", so the player has time to digest the current block of text before the next one is created?

Tron,

I'm sure you could do it with objects and properties, but I think I'd like to try to do it with an array of strings because it makes presenting subsets of elements to the player as a menu, and making selections just an exercise in simple loops and maths.

Don't flame me if this isn't fully thought through, I'm winging it here, but I envisage something like the following.

Have an array (strings) called 'menu[index]'

Now logically these strings would hold the menu item description. I still propose they would do that, but I'd have the description start at the 12th character position in each element.

e.g.

menu[1]="ppp-aaa-cccChoice #1"

ppp would then be used to hold the parent group for this element, aaa to hold the element's actual group and ccc would hold either the child group or a code to actually DO something rather than present another menu.

So we'd actually have something like;

First Menu presented (actually array elements 1-4 but 'found' by looping through the array and looking for elements belonging to group 000)

menu[1]="000-000-001Choice #1" 'Obviously, we'd only show 'Choice #1' on the actual menu
menu[2]="000-000-002Choice #2"
menu[2]="000-000-003Choice #3"
menu[4]="000-000-004Choice #4"

A selection of '2' would cause us to check the ccc (child/target - third batch of 3) section, this returns "002" which means we need to call the 'display a menu loop' again but finding those elements that have element group = "002". This might find the following subset...

menu[9]="000-002-020Choice #1"
menu[10]="000-002-025Choice #2"
menu[11]="000-002-030Choice #3"
menu[12]="000-002-999Choice #4"

Basically the 'target' part of the chosen element from the first menu is being used to point at its 'children'. As you can see more easily in this second menu, each element is also carrying information for its 'parent' (group 000 in this case) and so going back up the tree is just a case of reading the parent section of an array element, call the 'display a menu loop' and so on.

Of course this second level menu can also have children, which would point at it as a parent, for instance

menu[91]="002-030-080Choice #1"

Now I threw in menu[12] with a child/target value of 999. I would use this as an indicator that the player has chosen to do something that takes him out of the menu. This could be tested for and action taken depending on the index value of the element (or by varying the 'exit menu' value)

For the above to work, the menu structure would need to be prepared on paper first (it ought to be anyway!), but once 'encoded' the actual presentation and selection loops - and maths required to make this all function - ought to be relatively easy stuff unless I've missed something.

Al