Jump to content

llDialog script not properly executing if/else/else if logic blocks


Lilac Melodious
 Share

You are about to reply to a thread that has been inactive for 1116 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Evening everyone,

I've recently ran into a problem creating the following script.

The else/if logic is mostly unresponsive, other than the main and cancel segments. No llRegionSayTo calls (or even llSay) are being executed. See below;

//=================================//
//============Variables============//
//=================================//
integer gListener; //Don't change
integer dialogChannel; //Don't change
integer dialogHandle; //Don't change
integer rstChannel = 99; //llRegionSayTo channel for communication to the slave scripts.
integer mem = 16384; /*Reccommended value 16384; Lower values may not work, causing the script to take 64k (65536) instead of your limited amount, or to shout "Stack Heap Collision".*/
string abrv = "\nWhat part would you like to hide?";
string abrvA = "\nWhat arm would you like to hide?";
string abrvA1 = "\nWhat would you like to do with 'RightArm'?";
string abrvA2 = "\nWhat would you like to do with 'LeftArm'?";
string abrvC = "\nWhat would you like to do on 'Chest'?";
string abrvW = "\nWhat would you like to do on 'Waist'?";
//string abrvL = "\nWhat leg would you like to hide?";
list menuSelect = ["Chest", "Arms", "Waist", "Cancel"];
list menuSelectA = ["Show RArm", "Hide RArm", "Show LArm", "Hide LArm", "Main"];
list menuSelectC = ["ShowC", "HideC", "Main"];
list menuSelectW = ["ShowW", "HideW", "Main"];
//list menuSelectL = ["Right", "Left", "Main"];
key id;
/*
===================================
===========STATE CONFIG============
===================================
*/
memory()
{
    llSetMemoryLimit(mem);
    llOwnerSay("DEBUG; MEMORY: "+(string)llGetUsedMemory()+" used of "+(string)llGetMemoryLimit());
}

open_menu(key inputKey, string inputString, list inputList){
    dialogChannel = (integer)llFrand(DEBUG_CHANNEL)*-1;
    dialogHandle = llListen(dialogChannel, "", inputKey, "");
    llDialog(inputKey, inputString, inputList, dialogChannel);
    llSetTimerEvent(45.0);} //Time in Seconds before listen timeout.
    
close_menu(){
    llSetTimerEvent(0); //0 is used here in place of 0.0 to save memory.
    llListenRemove(dialogHandle);}    
/*
===================================
===============CODE================
===================================
*/


default{
    on_rez(integer start_param){
        llResetScript();}
    state_entry(){
        memory();
        llOwnerSay("DEBUG: Memory allocated; Script booted.");
        llOwnerSay("I'm in JoMo Griffin mode...");}
        touch_end(integer total_number){
            key id = llDetectedKey(0); //Find who touched me.
            //key id = llGetOwner();
            llListen(dialogChannel, "", llGetOwner(), "");
            close_menu(); //Destroys my active ears.
            open_menu(id, abrv, menuSelect);}
        listen(integer channel, string name, key id, string message){
            //if(channel != dialogChannel)
                //return;
            //close_menu();
            
            if(message == "Chest")
            {
                open_menu(id, abrvC, menuSelectC); return;
                {
                    if(message == "ShowC")
                    {
                        llRegionSayTo(llGetOwner(), 99, "topon");
                    }
                    else if (message == "HideC")
                    {
                        llRegionSayTo(llGetOwner(), 99, "topoff");
                        llOwnerSay("touched.."); //debug, where the problem was noticed.
                    }
                return;}
            }
            else if (message == "Arms")
            {
                open_menu(id, abrvA, menuSelectA);
                {
                   if (message == "Show RArm")
                   {
                        llRegionSayTo(llGetOwner(), 99, "armRoff");
                    }
                    else if (message == "Hide RArm")
                    {
                        llRegionSayTo(llGetOwner(), 99, "armRoff");
                    }
                    else if (message == "Show LArm")
                    {
                        llRegionSayTo(llGetOwner(), 99, "armLoff");
                    }
                    else if (message == "Hide LArm")
                    {
                        llRegionSayTo(llGetOwner(), 99, "armLoff");
                    }return;
                }
            }
            else if (message == "Waist")
            {
                open_menu(id, abrvW, menuSelectW);
                {
                    if(message == "ShowW")
                    {
                        llRegionSayTo(llGetOwner(), 99, "waiston");
                    }
                    else if(message == "HideW")
                    {
                        llRegionSayTo(llGetOwner(), 99, "waistoff");
                    }
                return;}
            }           
            else if(message == "Main"){
                    open_menu(id, abrv, menuSelect); return;}
            }
            timer()
            {
                close_menu();
            }
}

To answer any common questions, yes, I am on land that has scripts enabled, and it does compile. I've also read around on some similar problems on here.

If anyone can help out, that'll mean a lot! Also, this is interfacing Alpha slave scripts, which I've already checked, and tested in local using /(channel)(message) format, like everything else, as well as using with other scripts like togglers that also use llRegionSayTo. they indeed work.

Edited by Lilac Melodious
Missing descripter.
Link to comment
Share on other sites

11 minutes ago, Wulfie Reanimator said:

What problem?

Thought I had added the problem in the main post, I'll get that added after this.

The issue revolves around the response from the llDialog command, which is set up as it should. Either the llListen call is somehow messed up without me knowing, as the if/else logic is mostly being ignored, besides the main and cancel buttons.

Link to comment
Share on other sites

3 minutes ago, Lilac Melodious said:

Thought I had added the problem in the main post, I'll get that added after this.

The issue revolves around the response from the llDialog command, which is set up as it should. Either the llListen call is somehow messed up without me knowing, as the if/else logic is mostly being ignored, besides the main and cancel buttons.

There are a few odd things about the code you've posted.

Firstly, your indentation/braces are very hard to follow because it's not entirely consistent. You've also got a lot of redundant returns in your code an if-else tree won't test the remaining conditions if one of them passes.

Your first if-check also has this line:

if(message == "Chest")
{
    open_menu(id, abrvC, menuSelectC); return;
    {
        ...

This means that it will open a menu, and then exit the event. The following braces (which don't mean anything) are dead code -- never executed.

In the other conditions, the braces still mean nothing. They're executed immediately after the open_menu function is called, it's impossible to receive any input from the dialog that was opened during the current event.

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Wulfie Reanimator said:

There are a few odd things about the code you've posted.

Firstly, your indentation/braces are very hard to follow because it's not entirely consistent. You've also got a lot of redundant returns in your code an if-else tree won't test the remaining conditions if one of them passes.

Your first if-check also has this line:


if(message == "Chest")
{
    open_menu(id, abrvC, menuSelectC); return;
    {
        ...

This means that it will open a menu, and then exit the event. The following braces (which don't mean anything) are dead code -- never executed.

In the other conditions, the braces still mean nothing. They're executed immediately after the open_menu function is called, it's impossible to receive any input from the dialog that was opened during the current event.

Noted. I'll fiddle around with the hierarchy of these starements.

Link to comment
Share on other sites

why none of the RegionSay statements get executed:

Each time you call llDialog and then subsequently listen to what the user does, a listen event occurs and the processing starts afresh, at the top of the listen event, not immediately after your call to open_menu

You enter a block where message == "Arms", but then start off a fresh dialog, which might result in the user pressing "Show RArm", which then gets sent to the listener as a new message, but that message cannot be recognised because the code that would respond to it is inside a block that can only be entered by the message being "Arms".

Move all the lower-level tests up into the top-level, so there will be loads of tests for message matching things like "Show RArm", but only some of those messages then result in a call to open_menu.

Habitually, if within a listen event there is going to be an llDialog or llTextBox call, I try to move that the the very end of the listen event so it is the last thing that will be executed within that listen event. I do not know how rapidly listen events are actioned, or whether if there is trailing code after a call to llDialog and it's subsequent listen that is actioned before the new listen event starts, or whether it gets dropped due to the new listen event. (*)

If you have already got a listen open for a particular id or channel that uses the same filtering, there is no need to call llIsten after llDialog.

Instead, at the very start of the listen event, set a variable more = FALSE;

within the listen event, if any llDialogs or llTextBox calls are made, set more= TRUE; and set buttons and prompt strings as appropriate

at the very end of the listen event,

if more == TRUE make the call to llDialog or llTextBox using the list of buttons and prompt string set up previously

else  (more == FALSE), remove the listen handle.

* I am confident this question will be answered soon

Link to comment
Share on other sites

2 hours ago, Profaitchikenz Haiku said:

Habitually, if within a listen event there is going to be an llDialog or llTextBox call, I try to move that the the very end of the listen event so it is the last thing that will be executed within that listen event. I do not know how rapidly listen events are actioned, or whether if there is trailing code after a call to llDialog and it's subsequent listen that is actioned before the new listen event starts, or whether it gets dropped due to the new listen event. (*)

* I am confident this question will be answered soon

Events are never interrupted by other events or anything that isn't a return. You can call llDialog and execute as much other code as you want before the event ends and you get the next event from the event queue (with the llDialog response).

Edited by Wulfie Reanimator
  • Thanks 1
Link to comment
Share on other sites

Lilac, as has been mentioned already, open_menu shows the user a dialog menu. The listen event doesn't fire until the user presses a scripted button on the dialog. Showing a dialog doesn't pause execution of a LSL script (the script doesn't wait until the scripted button is pressed as we expect in a non-event language)
with LSL (being event driven) there is a number of ways to script this, some more efficient than others. But sticking with your coding style then can be written like this:
 

// global
string body_part; // in [Chest, Arms, Waist]


listen(integer channel, string name, key id, string message)
{
   if (message == "Cancel")
   {  // do nothing
      return;
   }
   if (message == "Main")
   {  // show main menu
      open_menu(id, abrv, menuSelect);
      return;
   }
 
   if (~llListFindList(menuSelect, [message]))
   { // message is in menuSelect
     // show body part menu  
     body_part = message;  // track which body part we are working with
     if (body_part == "Chest")
        open_menu(id, abrvC, menuSelectC);
     else if (body_part == "Arms")
        open_menu(id, abrvA, menuSelectA);
     else if (body_part == "Waist")
        open_menu(id, abrvW, menuSelectW);
     return;
   }
   
   if (body_part == "Chest")
   {
     if (message == "SHowC")
        llRegionSayTo(id, 99, "topon");
     else if (message == "HideC")
        llRegionSayTo(id, 99, "topoff");
     return;
   }
   
   if (body_part == "Arms")
   {
     if (message == "Show RArm")
        llRegionSayTo(id, 99, "armRon");
     else if (message == "Hide RArm")
        llRegionSayTo(id, 99, "armRoff");
     else if (message == "Show LArm")
        llRegionSayTo(id, 99, "armLon");
     else if (message == "Hide LArm")
        llRegionSayTo(id, 99, "armLoff");
     return;
   }     
     
   if (body_part == "Waist")
   {
     if (message == "SHowW")
        llRegionSayTo(id, 99, "waiston");
     else if (message == "HideC")
        llRegionSayTo(id, 99, "waistoff");
   }     
}

 

Edited by Mollymews
typd
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1116 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...