listen sometimes not getting dialog messages

I have a thorny problem. In a child prim I use touch_end to switch to a dialog state that sets up llListen and llDialog, both using the same negative channel number. I also set a timer and if the dialog is not used after 10 seconds I cancel the listen by changing back to the state with the touch_end in it. This all worked fine, until I rezzed a copy of the build later. The rezzed version gets the touch_end, changes state and the dialog box appears, just like normal. HOWEVER when I click on one of the dialog buttons then the listen event never gets the message. If I reset the script, then everything works OK again. I'm using reset to do some one-time initialization and don't want to have to do that every time the build is rezed.
I built a pared-down version of the script to post here, and it never has this problem! I looked in all the other scripts in the build, and none of them even has a llListen in them. I tried this stripped down version of the script in the root or in a child prim and it still works. In the complete build, I tried putting a llSleep(0.2) after the llListen to see if it needed time to get ready for the llDialog. This still did not make the full version work after a rez.
Does anyone know if there is something I could be doing that prevents listen from getting messages from dialogs?

without code it's hard to tell, but you can stick a reset in the on-rez handler as a quick fix.

/me nods!

I'd be suspicious of the state changes and timers - my bet is something is happening there that you don't expect to happen. For example, a state change will kill any llListen you have and timers, IIRC, survive state changes and trips through inventory. Maybe you don't need a full reset in on_rez but I'd bet you need to do something there to make sure you're in the right state and such.

Well, I'm starting and canceling the timer in the state_entrys, and I'm counting on the change of state to cancel the llListen for me. OK, below is the stripped down code, but unfortunately this is the code that always works! That is part of the thornyness of the problem. There is something ELSE that I'm doing that prevents this from working right. To make this example as short as possible, I've removed all my specific initialization. But those are just llSetPos and llSleep calls, honest! I also removed code that set a set a sit position and did an animation on change. I removed code that put more buttons in, code in the listen that looked at the message and sent llLinkMessage's to other prims. None of those things should have messed up the listen so that it cannot hear the dialog box. Right? I suppose I can put them all back in one at a time until it fails again...

integer dlgchan=-419430;   //communication channel for dialog boxes


default
{
    state_entry()
    {
            //one time initialization
        state normal;
    }
}
state normal
{
    state_entry()
    {
        llSitTarget(<0.6,-0.8,5.7>,llEuler2Rot(<0,0,-PI_BY_TWO>)); 
        llSetTimerEvent(0);
    }
    on_rez(integer param)
    {
            //different initialization
    }
    touch_start(integer num)
    {
        llOwnerSay("start");
    }
    touch_end(integer num)
    {
        llOwnerSay("end");
       state dodialog;
    }
} //state normal

state dodialog
{
    state_entry()
    {
        llSetTimerEvent(10);    //give them 10 seconds to do something
        llListen(dlgchan,"",llGetOwner(),"");
        list buttons=["Press","one","now"];
        string mess = "Press one now";
        llDialog(llGetOwner(),mess,buttons,dlgchan);
    } //state_entry
    on_rez(integer param)
    {
            //same initialization as the normal state
        state normal;
    }

    listen( integer channel, string name, key id, string message )
    {
        llOwnerSay(message);
        state normal;
    }
    timer()
    {
        llOwnerSay("Timeout, dialog box disabled, press ignore");
        state normal;
    }
}//state dodialog

Well, it's good that this code works because it looks fine to me.

Have you tried compiling it with and without mono to see if that makes any difference? I don't expect it would but you never know...

My only comment is on how you do the dialog.. Personally, I would start the timer as the last thing in this block of code instead of at the start. It's probably unlikely that anything else in there would stall for large amounts of time but I'd go for "start the timer once the dialog gets sent" instead of "start the timer then do the dialog". Again, not likely to fix the problem but that's the way I'd do it.

there is no guarantee that a timer event won't be queued before the timer is stopped and started, although it holding between states would be odd although it could be because you are exiting it straight from the timer event.

you should definitely clear your timer in state exit of the dodialog state

Well, if a timer event happens out of order, the worst that can happen to me is a false message about the dialog timing out when a message had already been sent. Or perhaps the message about the timeout appearing before I have time to press the buttons. I have plenty of time to press the buttons, the message never arrives, then a long time later the timeout happens.
I tried moving the llSetTimerEvent(10) to the very end, that had no effect.

I tried the following experiment:
I tested that sample code in my last post by placing it in a 2-cube object. In that configuration, it worked fine. This time I replaced the full version of the script with this stripped down code in the final build. Result: After it is rezed, the dialog messages never get to the listen state! So there is something else in the build that is causing this. If I had listens in the root object, I might guess that they eat messages before child prims can see them, but this is the only listen in my whole build!

OK, some background: This script is intended to work in an offsim piece of landscaping. I pack it for installation with all the prims on top of each other and when you rez it, they each move themselves out to the final position.
It turns out that if a child prim is more than 20 meters away from its root prim, it can no longer hear its own dialog boxes! Once I figured this out, I found the documentation in the Wiki that should have clued me in to this. Apparently the server thinks that dialog boxes all speak from the root prim and in my case the child prim was too far away, even though it was the source of the dialog. I moved it 0.25 meters closer and everything works again!

glad you got that fixed. although my point with the timer, is that it needs to be started and stopped in the same state, otherwise coming into a state you could have it timer queued before you turn it off or set it to a farther time...

it's always best if you can turn your timer off from the timer event, or check a switch value before running code in one to prevent timers that get queued before they are stopped (stopping one doesn't clear it from the event queue)

in your code, just move the timer stop from the state entry of "normal" to the timer event in "dodialog" just before the the return to "normal"

you should probably move that sit target to, since it's being called only once with no variable change... to the default state entry.