How do I get from Notecard lines to a Dialogue box?

I'm trying to figure out how to script a user-configurable HUD that will give its owner a way to open a dialogue box that the owner can use as "hot buttons" to toss lines to chat. To be specific, I want the user to be able to say some standard lines (giving directions, handing out a SLURL, saying a common greeting, ...) by clicking a dialogue button. My thought is to package the script and a user-configurable notecard in the HUD. When the user clicks on the HUD it opens a dialogue box and uses information in the notecard to label its buttons and define what it does. (Does that make sense?)

Anyway, I have programmed for a long time but I'm a real novice at LSL scripting, so I can't get my head around how to handle the operations that convert notecard lines into a list of parameters for llDialog. Anyone care to give me some pointers?

you'll want to take a look at one the many notecard reader scripts on the forum, in the dataserver event you save the line input into a list, best bet is to use two list, one for the button text, one for the stuff it spits out if you press that button... feed the button list to the dialog function, and in your listen, search the list, and use the matching index on the second list


yes you could use a strided list, but then you have to convert it before feeding it to the dialog function... and either seach buttons and text on the button press, or convert the list again for the stride... math, memory, and speed are all better with two lists

Excellent! That's just what I was trying to figure out, Void. I'm still not comfortable with LSL's way of handling lists, so I was having trouble figuring out whether I should split it that way, and just how to do it. So I can use llStringTrim to identify a leading token in the notecard line as the button text and then save the rest of the line as the text that the dialogue will feed out when the button is pushed? Do all of that in one event and then pass the complete lists to the llDialog function in a new listen event?

you could use my vk-dbms functions to handle the list processing for you, that way all you need in the dataserver event is to add the data to the table. The example programs included show how to use it for dialogue handling amongst others.

you can use split line tokens, or you can use selection tokens, or ordinal line numbers... there's other variations too.

lists for plain text aren't so bad, just some weirdness with other types on retrieval

with having users make their own, I susgest using a token system, on seperate lines, less chance of user error. something like

@B:My Button
@T:My text that gets spit out

if (!llSubStringIndex( NoteCardLine, "@" )){ //-- @ is first character
 if (1 == llSubStringIndex( NoteCardLine, "B:" ){ //-- button selector
    gLstButton = gLstButton + llGetSubString( NoteCardLine, 3, 26 ); //-- don't want button erros if too long
  }
 if (1 == llGetSubStringIndex( NoteCardLine, "T:" ){ //-- text selector
    gLstText = gLstText + lGetSubString( NoteCardLine, 3, 252 ); //-- limited by notecard line length
  }
}

might want to add a check on the buttons for blank data too, since that will also throw an error... I think NotecardLine.length > 3 should work

also make sure to check to make sure the button list doesn't go over 12, or use a multi page function for the dialogs (theres a few on the forums, incuding one by me w/ sequence correction)

Thank you for that, Very. I have looked at some of your earlier work but haven't been motivated enough to really dig in and learn how to apply it. This looks like something I can probably get my head around. I appreciate the pointer.



Yes, I can see that. It's hard to make a script idiot proof. Using separate lines might be the way to go. I've also given some thought to putting button labels and content on the same line but stuffing a delimiter between them, as in ....

My First Button = This is what button #1 does

Thanks again for your responses. This little script is not a major challenge -- at least it wouldn't be if I were more familiar with LSL -- but it is a nice learning experience. You have both given me good ideas to play with.