|
cypren Wanderer
Joined: 03 Nov 2000 Posts: 59
|
Posted: Thu Feb 08, 2007 9:01 pm
Automapper rewrite feature request: verbose debug |
The zMUD automapper works pretty well on an MXP-enabled MUD with proper line tagging, but every now and again it will spontaneously decide to create a new room instead of moving to an existing known one. This problem happens in different rooms at different times, and seems nearly random in its locations and frequency. I've double-checked the raw MUD output (via a sniffer) and can find no difference in the actual bytes being sent for one move that triggers the creation of an "overlaid" room versus another that simply moves from room to room without a problem.
I realize the mapper is being completely rewritten for CMUD, so I'd like to insert one request: can we get an option in the configuration panel that lets us turn on a "verbose debug" mode, where the mapper displays the components it got, announces its decision for each room it moves into and gives the reason? For example:
Code: |
>n
[Gully, Rocky Creek]
The stony walls of the gully meet in a nearly dried-up creek bed here. A small trickle of water continues to flow.
Obvious exits: north, south
>n
[Gully, Slope]
The ground slopes upward here on a gentle enough incline that you think you can climb up the sides.
Obvious exits: south
> |
would produce output (probably to another window) like:
Code: |
Movement command "n" received. Moving north.
Room name: "[Gully, Rocky Creek]"
Room desc: "The stony walls of the gully meet in a nearly dried-up creek bed here. A small trickle of water continues to flow."
Room exits: "north, south" (N|S)
Decision:
movement "n" follows link 1392 from room 432 to room 433
name matches room 433
description matches room 433
exits match room 433
moving player to room 433
Movement command "n" received. Moving north.
Room name: "[Gully, Slope]"
Room desc: "The ground slopes upward here on a gentle enough incline that you think you can climb up the sides."
Room exits: "south" (S)
Decision:
movement "n" follows unexplored link 1393 from room 433
room name found
room description found
room exits found
creating room 434 |
Presumably all the decision tree logic exists already, so this is really just a request that you put some kind of "logging" mechanism into the mapper so we can see the outputs at each step.
I'm sure everyone who's used zMUD for any length of time knows about these kinds of frustrations with the mapper as a "black box", and this might help us to not only troubleshoot our own problems, but much more easily help people posting to the forums. |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Fri Feb 09, 2007 12:17 am |
Using #debug test.txt trace.txt do you notice any differences in text placement (ie, plain text that shouldn't be where it is or even extra tags that ZMud properly handles, thereby ensuring you no visual difference)? The mapper craps up a hairball even with the Simutronics GSL detection if there is more text in between the tags than normal.
For reference, rooms in Dragonrealms are coded up in roughly the following style (%e = whatever the escape characters are that Zugg picks up on):
Quote: |
%eGSo
[Shard, Sapphire Avenue]
%eGSp
%eGSH
The lane sweeps in a clean angle northeast and southwest. A curious, ramshackle two-story building juts like a growth waiting to be lanced amongst the other residentials. Something shadowy and heavy hangs from the shop's darkened porch, and a strange, ghostly clicking floats through the air around it, sounding for all the world like some spectre rattling its fingerbones to scare off unwanted guests.%eGSI
%eGSjBFH
Obvious paths: northeast, southwest, northwest.
%eGSq1170979838
|
This room doesn't have pre-movement messaging, but it is supposed to appear prior to the GSo tag. Sometimes it appears after, in which case no matter what #NOMAP trigger I might come up with the automapper will still create a new room (assuming I went back and fixed the room with a #LOOK).
Maybe you're experiencing a similar situation? |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
cypren Wanderer
Joined: 03 Nov 2000 Posts: 59
|
Posted: Fri Feb 09, 2007 1:04 am |
MattLofton wrote: |
Using #debug test.txt trace.txt do you notice any differences in text placement (ie, plain text that shouldn't be where it is or even extra tags that ZMud properly handles, thereby ensuring you no visual difference)? |
Yes, I've verified the actual bytestream to make sure there are no character differences beyond the timecode issued in the prompt. I'm actually not using GSL -- I wrote a custom proxy server that emulates the Stormfront protocol and translates it all into MXP, so I have extremely fine-grain control over every single byte that gets sent to zMUD and I can be absolutely sure of what it's receiving. (And I dump both the raw data sent from the server as well as the raw data sent to zMUD into long longfiles so I can verify anomalies like this.)
That's why I'm so confused over this whole thing: I know for certain there aren't hidden codes or other things that might explain why the automapper thinks there's a difference. And that's why a verbose output of its decision path would be so helpful. |
|
|
|
mr_kent Enchanter
Joined: 10 Oct 2000 Posts: 698
|
Posted: Fri Feb 09, 2007 7:12 am |
cypren wrote: |
I wrote a custom proxy server that emulates the Stormfront protocol and translates it all into MXP, so I have extremely fine-grain control over every single byte that gets sent to zMUD and I can be absolutely sure of what it's receiving...
That's why I'm so confused over this whole thing: I know for certain there aren't hidden codes or other things that might explain why the automapper thinks there's a difference. |
Woot! That's beautiful. Very nice cypren!
My question would be: Can you reliably cause zMUD to fail by refeeding the dumped data back through? If so, then I'm sure Zugg would want to know the conditions surrounding this abberant behavior so he could code a fix. Even if you can't reproduce it, an output display of the decision path might not neccesarily help (there could be some variable or something that doesn't get set because of another process or something).
Anyway, I like the idea and I'm happy to hear that I'm not crazy (I spent many hours in the past trying to find some difference in mud output that might cause that behavior).
Excellent suggestion even if it's only for a version or two, just to nail down the cause of the problem. |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Fri Feb 09, 2007 11:57 pm |
I am all for a mapper debugging screen. I have long contended that the code that that generates a configuration behaves differently then the code that makes use of that configuration. I recall on some mud I played that if I configured in the right room, stepped back, removed the room, then stepped into the same room it would be detected incorrectly. Too bad I never really recorded an example of this. So I would like to see that debugging be available more from the start. Perhaps if the same system of paragraphs and lines are used then having a display of captured text and configuration controls right in one 'advanced' window would be cool.
|
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
cypren Wanderer
Joined: 03 Nov 2000 Posts: 59
|
Posted: Sat Feb 10, 2007 12:00 pm |
mr_kent wrote: |
My question would be: Can you reliably cause zMUD to fail by refeeding the dumped data back through? If so, then I'm sure Zugg would want to know the conditions surrounding this abberant behavior so he could code a fix. |
Unfortunately, while I can debug a lot of interpretation/scripting issues this way, the mapper works off of both the user's commands and the data response from the MUD. And while I could write an emulator into my proxy server that lets it respond to commands with input from a canned file, that's a lot more trouble than I want to go through when the mapper that's having issues is about to get rewritten.
I asked for this feature not because of a specific problem, or because I think it will let us fix everything we've encountered with the zMUD mapper, but because I know that writing a generic automapper like the one Zugg built is an insanely complex task, and failures are (and always have been) hard to track down.
Some of the problems we'll encounter with the next generation mapper will be configuration errors, some will be MUD inconsistencies, and some will be genuine bugs in the mapper code. But this will help us sort out at the very least who is responsible for what, leading both to less blame placed on Zugg for the things that aren't his fault, and a greater likelihood that he can find the things that are and fix them faster, benefitting us all. |
|
|
|
Guinn Wizard
Joined: 03 Mar 2001 Posts: 1127 Location: London
|
Posted: Sat Feb 10, 2007 12:11 pm |
I think it's an excellent idea. Along with things like the compilation reports for scripts that don't compile it'll help power users trying to pinpoint bugs and to help others configure their mappers in the new version - and it'll be a good point to bring up as to why the new mapper is better than the old one. Black boxes are lovely when they work perfectly, but what ever works perfectly.
|
|
_________________ CMUD Pro, Windows Vista x64
Core2 Q6600, 4GB RAM, GeForce 8800GT
Because you need it for text... ;) |
|
|
|
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Sat Feb 10, 2007 3:01 pm |
I think it's a great idea too. Especially as I have ideas (as do many of us, I expect) for a lot of enhancements to the intelligence of the CMUD mapper, which would obviously require testing and debugging.
|
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|