Zugg Software :: View topic - [3.03a] Erratic behavior when outputing walking direction

Posted: Tue Jan 06, 2009 3:43 pm

This code is to handle issues that make me stop speed walking. It loads up the move_command key inside the flag variable with the necessary information to continue the walk and then uses it in this code when it gets a prompt that shows I have balance to move. It should #exec the direction I want to go, but it only does it correctly when the direction is not a nw, s, or w. The following is the code of interest:

Wizard Joined: 22 Mar 2007 Posts: 2320

I don't see anything obvious either. Do you have any aliases for s, nw, or w?

The only thing I can think of to try is to use '#send $moving' instead of '#exec $moving'

Posted: Tue Jan 06, 2009 4:18 pm

No, there are no aliases for those directions. In general if I had something happening to some directions, I'd do it to all directions as well. I've never singled out s, nw, or w.

Posted: Tue Jan 06, 2009 6:12 pm

How is the PromptBalanced event getting triggered? In your first example showing the MUD output it looks like "s" is sent to the MUD first and the MUD responds with "Now now, don't be so hasty! ". So are you somehow trying to grab the movement direction in some other OnInput trigger, or what? If CMUD is running your PromptBalanced event within an OnInput trigger, then CMUD takes the data normally sent to the MUD and saves it to see if it should be replaced by other output from the OnInput trigger. So it might be some sort of timing issue.

I'd also use Rahab's idea and try changing #exec to #send. In general, if you want to send a command to the MUD, use #send, and if you are trying to execute an alias or some other script, use #exec. #exec takes it's arguments and runs it through the compiler and parser which is a lot slower than just using #send.

Posted: Tue Jan 06, 2009 6:26 pm

PromptBalance is raised when I see a prompt that has 'ex' as part of the text flags at the end. It is a regex trigger that fires on 'prompt' type lines matching the prompt text.

Directions such as 's|n|e|w|ne|se|sw|ne|nw' trigger a 'command' type trigger which doesn't replace the text, but does setup some flags so that my system knows that I'm moving. I've noticed that when Cmud executes the directions the 'command' type trigger fires, but when my code executes the command it doesn't, so I do the "#raiseevent Movement $moving $movement" manually to accomplish the same thing.

If the direction was being gobbled up by some OnInput trigger wouldn't that show in the debug window? Also, it isn't happening with all directions, which is what I would expect to happen if an OnInput trigger was eating it.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Actually for this specific item you don't want the mapper to be aware that you are sending the command. The mapper doesn't really understand retrying the last direction. Hrm, there is a thought #REPSTEP.

Also your flags are already set up since that is where you are retreiving the data from, so you don't want to activate that #ONINPUT again; all you have to do is not delete the information.

The command I would suggest is #SENDRAW.

Posted: Tue Jan 06, 2009 11:14 pm

Have you tried copying a subset of your scripts to a new session to see if it works there? Just the stuff that you posted here. I tried playing with this (even without your other command trigger) and couldn't get it to fail. Which makes me think there is still something buried in your current session files that is overriding the s,nw,w directions somehow.

But I still don't understand why "s" is getting sent to the MUD before your trigger fires in your first MUD output example. You haven't really explained that.

Posted: Tue Jan 06, 2009 11:19 pm

Vijilante, I think you misunderstood what I was doing with the information.

Upon moving various things might occur:
1) I'm prevented from moving and I need to modify and resend the direction command to proceed
2) I'm vulnerable to several attacks and items only while moving.
3) I discover through the failure message that I've been disabled from moving in some way.

When I referred to using the information for my system, I wasn't referring to the mapper, I was referring to my curing tracking system. I utilize the knowledge that I'm in the middle of a movement to set various states and such in my system. Also if I'm prevented from moving by something I utilize the information to send a new command to overcome the problem. Say someone is blocking the exit, then I would want to replace 'ne' with 'leap ne'. I can only do that if I record the direction I was going. That is why I use the onInput command trigger so when one of the directions is input I record the information for my own personal use.

Posted: Tue Jan 06, 2009 11:23 pm

Posted: Tue Jan 06, 2009 11:31 pm

Do you have message "n" enabled in the Script Debugger (show all script executions)? If not, turn that on. It will show you if "s" is being executed as an alias or something.

And I assume you have checked the obvious to make sure those directions haven't gotten disabled somehow? In the Package Editor, do a View/Show/Directions and make sure there isn't any strikeout line indicating that they are disabled. You probably checked this first, but just in case ;)

Posted: Wed Jan 07, 2009 6:00 am

I'm revising my opinion. After a lot of testing I think there are several bugs associated with the latest version of Cmud. Various erroneous things occurred during testing:

1) I copied the class folder containing the triggers/events/variables to a different location in the package (ctlr-c/ctrl-v) and shortly after the contents of the class folder disappeared. I closed Cmud and opened it again, but the class folder was still gone, however all the triggers/events/variables the folder once contained were now located at the root of the Module. I had to recreate the containing folder and move them from root back into a new folder.

2) Later on: The class folder disappeared again, this time all the triggers/events/variables appeared under a trigger as if the trigger were a class folder. I again recreated the appropriate class folder and moved the triggers/events/variables back into the proper folder.

3) Still later on: I created an alarm that raised an event (#raiseevent) along with a corresponding event set to the event being raised in that alarm, so that it should fire when the event was raised. Even though the event was raised, the corresponding event would not fire. I restarted Cmud and the non-firing event suddenly wasn't there.

I was running into crazy stuff like this all night long while trying to reproduce the issue in this topic. I can't make a way to reproduce this when crazy stuff like the above keep happening on a regular basis.

In an attempt to root cause this I did an export/import to make sure it was a clean and ran into yet more issues I've outlines in other topics. I'm getting pretty frustrated at this point and I'll probably just go back to 2.37 until things are a little more stable in version 3.

Posted: Wed Jan 07, 2009 5:49 pm

OK, first we need to get the terminology straight here because your post is very confusing.

What do you mean by "directory"? Are you talking about a file directory in Windows? CMUD doesn't have anything called a "directory", but it sounds like maybe you are talking about moving a "class folder"? You need to be more clear on this.

Posted: Wed Jan 07, 2009 6:28 pm

Sorry for the ambiguous language in the previous post. I went back and edited the prior post for clarity so if you still want to understand the particulars they should be a little clearer now (though I doubt you'll come to any conclusions from it). I was in a very poor state of mind by the time I wrote that post so I'm not surprised I was less than clear. It seemed like I was running into one gating bug after another, I was originally trying to determine why #send wasn't actually sending and triggering the command trigger, then all the sudden I'm debugging a corrupt package, I try to fix the corrupt package by export/import and now I find yet another problem that prevents me from cleaning it up with export/import. I try to clean up the export/import issues and I can't even get my layout to save because of another bug. So I was pulling my hair out at that point in that I was about 4 bugs out and every time I tried to solve something another thing happened.

I'm in a glum mood about this whole situation. I was really hoping to be able to go back to 2.37 to avoid these bugs until you get around to bug fixes again. If I go to unknown hours of effort to fix my now corrupt package, there is no guarantee it won't corrupt again 5 minutes after I finish the fixes. Nor do I have any reproducible way of showing you the problem so it may corrupt again in future versions. There's nothing that makes me want to pull my hair out like silent data corruption. Dozens of hours of work thrown into disarray with no way of knowing what's been affected nor what's causing the problem.

Posted: Tue Jan 27, 2009 5:53 pm

I was thinking about this bug again and was wondering. Would it help if I was able to send you a package with instructions to reproduce this?

Novice Joined: 26 Jan 2009 Posts: 32

Posted: Wed Jan 28, 2009 3:57 pm

Yes, all of my triggers are set to "trigger on trigger".

Posted: Sat Mar 07, 2009 5:47 am

Now that I can import again I tested to see whether I had corrupt settings and this would go away if I re-import.

It didn't go away. I did some further testing on this and found that this only occurs when the mapper is slow walking me to a location. When I enter the directions myself this never occurs. So this is a weird Cmud/Mapper interaction in slow walk mode. I've already found plenty of bugs in the mapper slow walk interactions, hopefully this will disappear when the mapper work is done.