Zugg Software :: View topic - [3.33a] Room triggers sometimes are not able to send text to mud.

Wanderer Joined: 25 Feb 2004 Posts: 98

Hey all,

I have some room triggers to resend e,s,w,n if the movement fails. However sometimes these triggers fail to send the text to the mud. I have #SAs in the triggers and they will go off, but the additional direction doesn't. Also I tried changing it to #SEND s, etc but that still has the issue. The Trigger is very simple such as
#SA Should go s
#SEND s

I see the Should go S SA, but then no s is sent to the mud.

Thanks!

Robert

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Try enclosing any literal text you wish to do stuff with in quotes. #SEND allows for the parsing of variables, so perhaps it's being affected by the by-reference variable functionality. If @s exists and is blank, or doesn't exist, #SEND would essentially have nothing to send.

The use of quotes has essentially stopped being optional, so you will probably be best served in general if you went through and enclosed all your literal text in quotes even if things already work.

Wanderer Joined: 25 Feb 2004 Posts: 98

I redid the room scripts to do #SEND "s" and such. It still sometimes doesn't send the text to the mud. Also it seems other triggers after the room trigger fires sometimes fails to send to the mud like my #OK trigger fails to send the next direction even though the mapper location is updated and there is more directions to send.

Posted: Tue Jan 04, 2011 5:26 pm

Do you have other windows (like capture windows) in the session? If so, try changing those window properties so that they share the network connection of the main session window. If one of those other windows somehow has the context when #SEND is run, then nothing will be sent (since CMUD doesn't think the window has a connection).

You can also try firing an event instead of using #SEND directly and then have your event within the main session window issue the #SEND.

Wanderer Joined: 25 Feb 2004 Posts: 98

There are no other capture windows running when this occurs in this session or in CMUD. There is only the main session window and the map window open. I can try the event fix for the room trigger, but I am worried that the following #OKs will not work still. It seems like once I send input manually every thing works for a while again, and then sometime a room trig will mess it up again. This only occurs when room triggers fire. There are no #WAITs or #ALARMs in these room trigs. Only the #SA and the #SEND.

Posted: Tue Jan 04, 2011 8:56 pm

have you tried a more generic trigger that will cover all instances instead of room triggers?

Wanderer Joined: 25 Feb 2004 Posts: 98

I tried Shalimar's more generic trigger. I admit this is my first ONINPUT trigger. :) I also disabled all of the room triggers, but the issue still happened. I grabbed the failure with the script debugger, and it showed the trigger firing, the #SA(I added #SA trying @lastDir), then the ONINPUT firing again for the #SEND @lastDir showing that s(the direction that failed) is being inputed, but then nothing to the mud.

Future debugging plans:
1. Not just disable the room triggers, but remove the room from the map script lists entirely. I still think it has something to do with the room having a script right now as this is the only time I believe I am experiencing this issue.
2. Create a loop to repeat going over the same room again and again to try to make this easier to reproduce.
3. If still reproducible, start disabling and/or removing other code(after backed up) to eliminate causes until cause is found.
4. Also can verify if Zugg's event firing works. I haven't done my own event but it would be something like sendDir Event that just does #SEND %1, and then #RAISE sendDir @lastDir

Maybe I will get to this tonight. :) Thanks for the help!

Wanderer Joined: 25 Feb 2004 Posts: 98

Well, I deleted all of the room triggers and it still happens. Unfortunately it doesn't seem to like to reproduce itself when I just walk over the room again and again, so there is some other event that is occurring prior which is causing the directions not to be sent. I haven't tried the event yet however to try to work around it. Although I have no other windows, I do update a status bar which maybe eating the input.

I did however find one reproducible issue. If the get stuck trigger gets hit to go n again and there are multiple norths in a row, but it is trying to walk just to the next room my #OKs get messed up. The %destroom changes from doing the "n" in the get stuck room to the next room north, and it then requires 2 #OKs to get %inwalk to clear even though I am in the room and no directions are sent. To try to resolve this I put a #STOP before the #OK if I entered stuck directions, but this doesn't completely stop the walk either:
Before Stop: nextdir = n lastdir = n inwalk = 1 destroom = 19097 roomnum = 19095
Slow walking aborted
After Stop: nextdir = n lastdir = n inwalk = 1 destroom = -1 roomnum = 19095
Before OK: nextdir = n lastdir = n inwalk = 1 destroom = -1 roomnum = 19095
n
After OK: nextdir = n lastdir = n inwalk = 1 destroom = -1 roomnum = 19096

Only the destroom was cleared. nextdir is not, and neither is inwalk. When I do a #OK after the #STOP it still sends a n which I don't want. Is this how #STOP is supposed to function? I would assume the #OK should do nothing and %inwalk should have been cleared.

Wanderer Joined: 25 Feb 2004 Posts: 98

I worked around this previous issue by doing a #MOVE %lastdir. I think the #STOP should have worked, but at least the #MOVE did.

However the Event to send the direction didn't work either. The direction is still sometimes not sent to the mud. It also seems to take a while to reproduce and nothing odd shows up on the script debugger.

Wizard Joined: 22 Mar 2007 Posts: 2320

From the documentation on #STOP:

Wanderer Joined: 25 Feb 2004 Posts: 98

Ah, I guess so Rahab. Is there a command then that is for clearing the walk completely? Seems like #NODIR 1 would be what you would use for that then. I just took from the command name that the walk would have been completely stopped, not paused with the previous direction unconfirmed. Sorry about that.

I added a #THREAD in my "You failed to go that way." trigger to see if there are multiple threads running at the time of execution. Maybe I do have some #WAITs somewhere still that are leaving bad threads hanging around which is causing this mess.

Wanderer Joined: 25 Feb 2004 Posts: 98

I have not reproduced the issue yet, but when the trigger does #THREAD, %threadid, and %threadname and works, #THREAD says there are no threads, and the others return nothing. Is the main thread not considered one? When I enter #THREAD in the command line, I get 1 thread with the id of 1.