Zugg Software :: View topic

Posted: Tue Jul 15, 2008 8:24 pm

I split this from the other thread: http://forums.zuggsoft.com/forums/viewtopic.php?t=31211
because it got a bit off-track from the actual bug report.

I tried logging into Aardwolf to test this script:

Posted: Tue Jul 15, 2008 11:00 pm

Zugg, it does appear on the screen. But it appears the script itself is psubbing it out, so that may be why you're not seeing it. Here is an example of what I see when I type 'look' in my manor:

Posted: Wed Jul 16, 2008 12:03 am

Heh, DOH! Yes, Charneus, you are correct. I guess this means that the PSUB is working fine for me. But yeah, I had forgotten the script was active and was therefore doing it's job.

Is there any particular place where the PSUB problem shows up more than others? I was in the main square in town when I tested it.

Enchanter Joined: 10 Oct 2000 Posts: 698

Adept Joined: 27 May 2008 Posts: 299

There were other steps needed to actually make the PSUB fail.

Then turn on the mapper, and do a fresh configure. Then stack commands. The PSUB no longer works properly.

This was just tested in a fresh session in 2.30.

Open up a fresh map. Configure the map based off the #TAGS and #NOMAP's made above. Then with the mapper still in create mode. do n;n;n;n... Or something along this fashion. Make sure they are valid dir's before you perform them.

Ill post example output that I get.

Posted: Wed Jul 16, 2008 5:10 pm

OK, I've got it to fail now.

Actually, I can get it to fail a lot and gag the room name entirely even with normal walking and even with the mapper turned off. So I should be able to track down the problem.

Posted: Wed Jul 16, 2008 5:26 pm

Btw, someone needs to find out why Aardwolf is using LF CR as the newline instead of CR LF. That means that Aardwolf isn't even following the normal Telnet protocols! It almost makes me want to quit playing Aardwolf entirely. I *hate* MUDs that can't conform to such a simple protocol rule. I don't know who started using LF CR instead of CR LF, but I'd find it really embarrasing to be in charge of a MUD that still does this.

There isn't any reason for this. No existing client is going to fail if you switch from LF CR to the correct CR LF. And maybe some other clients will work better with the MUD when it actually follows the proper telnet protocol.

Anyway, this was just something I noticed when I was looking at the raw data being sent from the MUD. Don't know if this is causing the problem or not. What seems to be happening is that the PSUB on the {rname} line is somehow combining the line with the following {rdesc} line, which then fires the rdesc trigger and gags the entire line (the room name). Still trying to figure out why it's doing that.

Posted: Wed Jul 16, 2008 5:39 pm

OK, I found the bug. PSUB was failing once the scrollback buffer was full. Doing a few Ctrl-Q to fill the buffer would reliably cause the entire room name to be gagged (because the PSUB was messing up).

So yes, there was a bug in PSUB.

However, the actual problem caused by "chaining" commands, like n;n;n is that when chaining movement like this, Aardwold displays the intermediate lines with the room name after the MUD prompt, like this:

[ 2083/2083hp 1510/1510mn 1679/1679mv 650tnl] > {rname}The Grand City of Aylor (G)

and the {rname} trigger that you gave above has the ^ at the beginning, which means that it will only trigger at the beginning of a line.

When someone on Aardwolf looks into the LF CR issue, they might also want to consider implementing the IAC EOR or IAC GA protocol standard to mark the end of a MUD prompt. Both zMUD and CMUD have support for this and can ensure that the text after the prompt appears on it's own line.

But until then, you'll need to modify your script to handle {rname} when it isn't the first thing on the line. Of course, that opens up the issue of people on the MUD abusing this by putting {rname} into the middle of their chat messages. This is exactly why MXP was invented in the first place. With MXP you can mark the line from the MUD with the RNAME tag as "secure" so that it can be parsed in the middle of the line without opening up your triggers from abuse from people who put the RNAME tag in their chat (since chat lines are *not* marked as secure).

Anyway, that's something you guys can discuss with Lasher. In any case you need to handle the {rname} in the middle of the line somehow, or deal with the MUD prompt so that the room name appears on it's own line when chaining movement commands.

Posted: Wed Jul 16, 2008 6:15 pm

Another problem with the scripts that are trying to handle the {rname}...

The #PSUB command changes the text on the screen. But it does *not* change the text that is being triggered on by other triggers. Other triggers still see the original text (with the {rname} tag).

I bring this up because when in Follow mode, the mapper normally creates an #OK trigger to verify the step and normally puts a ^ anchor at the beginning of this trigger. Because the line being matched by other triggers still has the {rname} at the beginning, the #OK trigger for the mapper doesn't match. So, the mapper doesn't follow you when in Follow mode.

The workaround for this is to go into the Mapper config and turn off the "Match room name at start of line" option. This is also required for speedwalk "chaining" since as I mentioned in the previous post, the room name will be shown on the same line as the MUD prompt when speedwalking.

Just wanted to bring this up in case anyone else was trying to test this.

The #SUB command works differently from the #PSUB command. While the #PSUB command only changes the text on the screen and not how other triggers match the text, the #SUB command *does* modify the text that other triggers will see.

In general, unless you need to modify text on a different line, it's better to use #SUB instead of #PSUB. For example, in the {rname} trigger, you could have this:

Adept Joined: 27 May 2008 Posts: 299

Adept Joined: 27 May 2008 Posts: 299

Posted: Wed Jul 16, 2008 8:01 pm

Hmm, why did you use a reparse condition like that? Is there a reason you choose that over the simpler:

#SUB {%2};#TAG name %2

that I showed above? Your trigger is going to call the PCRE routine twice (once for the first pattern and once for the (*) second pattern) and it's essentially as slow as having 2 different triggers instead of one.

I didn't know about the %c option on the MUD prompt, but I'll look into that. I don't remember when I set my prompt (it's been a long time), but I'm not sure %c is in there by default. So I'm not sure it's something that is "commonly" known. Unless this was changed for new players since I joined.

It still wouldn't be a bad idea to look into supporting IAC EOR at the end of your prompts. Most modern MUDs support this and it makes it a lot easier for clients to deal with fragmented packets and other complexities like that. Otherwise the client never knows if it has received a complete MUD prompt or not vs a network packet boundary.

I guess I could understand if it might have some weird side-effect on some other clients, so it's something to look at on the Test server first.

Edited: Btw, I also recommend not including the (G) flags in the room name. If I remember correctly, people can add "grafitti" messages to rooms, and putting that flag in the room name would prevent the mapper from matching the room if the flag was later removed or changed.

Adept Joined: 27 May 2008 Posts: 299

Zugg, you can check out what your current prompt looks like by typing auto. It is at the bottom of that command. Both regular and battle prompt.

Also, I used the reparse option because it is what one of the GURU's suggested when I asked for suggestions lol. I certainly like your idea better as it doesnt take calling the PCRE twice.

Also, I thought about trying to remove the (G) from tag but not sure how I would do that. Most rooms these days are grafitti'd if they are ever going to be but its still a good idea.

What would the pattern look like?

Adept Joined: 27 May 2008 Posts: 299

I now remember why I used the reparse. It keeps the color of the line. If you use #SUB to redisplay the actual room name it strips the color from the line when it redisplays it. If you use sub to just replace the tag with "" it keep the color of the rest of the line for the reparse.

Posted: Wed Jul 16, 2008 8:39 pm

Almost:

Adept Joined: 27 May 2008 Posts: 299

Posted while you were posting heh, Read above for the reasons for using reparse condition. The question is how to remove the (G) and still keep the color like the reparse condition does. Also, you cant use the endline $ due to the fact that sometimes [**> PK <**] is sometimes added even after that and THAT I do want to be included in the room name.

Adept Joined: 27 May 2008 Posts: 299

I think this works best and would allow me to keep the color of the line as well.

Posted: Wed Jul 16, 2008 8:47 pm

Ahh, yes, you are correct about the line color. So actually, that's a really good reason to go back to using #PSUB then I think. Even doing #SUB with a reparse option might cause color problems on the line potentially. I'll try to think of a way to support #SUB in the future without losing color information somehow.

Also, you could use #PSUB again and still use the trick in my last post on removing the (G) before calling the #TAG command.

#PSUB should be working in v2.32, which I hope to release later today.

The original issue with PSUB is avoided by turning off the "Match room name at start of line", which is a good idea for most people anyway.

Posted: Wed Jul 16, 2008 8:48 pm

heh...we keep posting at the same time ;)

Yes, I think your solution is a good one.

Adept Joined: 27 May 2008 Posts: 299

Hmm on second thought this would NOT work. here is why. Say this is your room name

{rname}This is the coolest Room (G) [**> PK <**]

with the above your going to get this output

This is the coolest room (G) [**> PK <**]

but your tagged room name is going to be this

This is the coolest room [**> PK <**]

Hence no match on your temp #OK trigger created by the mapper.

I dont see any fix for this except maybe...

Posted: Wed Jul 16, 2008 9:23 pm

Hmm, yuck, you are right. Your idea might work...certainly worth a try. But now I'm maybe thinking that just including the (G) in the room name is ok. Especially since grafitti is usually only *added* and not *removed* from rooms.

Also, I can see some adventuresome person who might want to loop through all of the room names in their map to display which rooms have grafitti in them. I know that I've been interested in that myself in the past just for kicks.

Adept Joined: 27 May 2008 Posts: 299

Well this still holds true tho. If its ADDED to a pk room, its still going to destroy your temp #OK trigger.

The above code does work btw so I think in my case I will just use it to eliminate any problems that (G) could have. After all I could give a flip if a room has grafitti and if/when its added/removed. The only time it even helps is in places the grafitti tells you which pool is which and also in a few mazes there are problems here.

But in general concensus I think leaving (G) is the best, like I said its VERY rare that it changes these days and if it does you can just fix manually when you happen apon it.

Novice Joined: 20 Apr 2008 Posts: 39 Location: Sweden

Add a check for Graffiti or PK that does a sub before the real roomcheck?

Posted: Thu Jul 17, 2008 8:28 pm

Well, this discussion is mostly moot anyway. The new mapper in CMUD is going to use the result of the #TAG command to verify room movement instead of using the #OK trigger anyway (when the #TAG information is available). So in the new mapper it will all work just fine.

Beginner Joined: 07 Jul 2008 Posts: 14 Location: Orlando