Zugg Software :: View topic - TAG Queue stalling and Undockable Settings Editor

Novice Joined: 12 Oct 2000 Posts: 32 Location: USA

I made a post regarding this problem a while ago, and since then have attempted
to do some further experimentation with the #TAG command to see exactly what
the problem is. Sample mud output follows:

(Vnum:12001 Invis:104 Cloak:102)
look
Chapel Anteroom
Vnum: 12001 Sector: inside Flag:indoors safe no_summon_from
[Exits: north east west up]
The smooth marble walls and columns are simple, the gleaming perfection of the
stones needing no adornment for beauty, their clean lines rising gracefully to
the vaulted ceiling. The floor is white marble, and in its center is a mosaic.
You may enter the Sanctuary through the arched doorway to the north, or return
to the courtyard Cloister east or west. A narrow stairway leads outside and up
in a spiral around the outside of the Training Tower.
(White Aura) The Protector stands guard with his hand on his sword hilt.

(Vnum:12001 Invis:104 Cloak:102)

Using the automapper wizard, I'll get:
Chapel Anteroom as the Room Name (Correct)
Vnum: 12001 Sector: inside Flag:indoors safe no_summon_from as the
Room Description (Incorrect)
[Exits: north east west up] as the Room Exits (Correct)

Here's where the #TAG command would be useful, since a trigger that looked like
#TRIGGER {^Vnum:%s(%d)} {#TAG vnum {%1}} {AutoMapperAll}
should get the job done and used to in 6.12 beta.

However, now in Zmud 6.13+, this is what the AutoMapper now does: (tested in
6.13, 6.14, 6.15, 6.16, 6.20, 6.25, 6.25a in online mode)

Testing was conducted using the following settings on a new character on a
clean installation of Zmud to a new directory:
#CLASS {System} {"enable"}
#CLASS 0

#CLASS {System|Automapper}
#CLASS 0

#CLASS {System|Keypad} {"enable"}
#CLASS 0

#CLASS {System|AutomapperAll} {"enable"}
#TRIGGER {^Vnum:%s(%d)} {#TAG vnum {%1}}
#CLASS 0

#CLASS {System|Directions} {"enable"}
#CLASS 0

#CLASS {System|DirectionsDiag} {"enable"}
#CLASS 0

#CLASS {System|KeypadDiag} {"enable"}
#CLASS 0

#CLASS {Autolog} {"enable"}
#CLASS 0

With this running and using the autoconfigure wizard with the command to move
me in a safe direction being: "look" capture settings of 1 second (localhost
mud used to test)

The capture settings are identical to that of the previous autoconfigure without
the #TAG trigger. However, the room is created with the proper information,
except for a correct room description. Furthermore, if I save the settings
(saved as Master with New Name: testing.zfg) and then erase the newly created
room by the automapper wizard when it looked via the wizard, thereby leaving the
map bereft of all rooms, follow this up with a look (click the look button in
the automapper) the automapper will generate the room assign it the next logical
vnum and stall. A room name, desc, vnum, all will not be assigned. The
automapper will also sit there with the look command still in its Queue, seen by
the bottom right hand corner saying Queue: look and not do anything else until I
click on the map to clear the queue, in which case it continues to sit there.

Disabling all triggers (I only have the #TAG one), makes the automapper
considerably happier and it proceeds to properly update the room (albeit with
the wrong description as it still thinks the Vnum: line is the proper
description. I can offset that by going into the configuration settings and
manually changing the Room Description line to start on line 3, and check the
box labeled multiline description in which case the room name, room
description, and room exits are appropriately grabbed, yet still denying
me the grabbing of the room's vnum.

Here, I begin a more complicated testing procedure and modify the commands
of the Vnum: trigger.

I try a variety of different combinations to a) get the mapper to parse
the description properly while b) not freeze when it encounters the #TAG
command.

Trigger combinations and results:
#TRIGGER {^Vnum:%s(%d)} {#NOMAP;#TAG vnum {%1}}
No good, queue freezes. Even when the wizard runs it obtains and parses the
room description proeprly since the Vnum: line is no longer visible to the
mapper, however the queue still freezes in the room creation when using
the automapper wizard in addition to a normal look.

#TRIGGER {^Vnum:%s(%d)} {#OK;#TAG vnum {%1}}
No good, doesn't set anything in the room anymore. The automap wizard
incorrectly identifies the room description like before and the queue does not
freeze either; however, the automap wizard and subsequent look/delete room only
result in an empty room with no exits, name, or description.

#TRIGGER {^Vnum:%s(%d)} {#NOMAP;#OK;#TAG vnum {%1}}
No good, same problem as above, although now the automap wizard properly
detects the rooms since the Vnum line is hidden, it still creates a blank room.

#TRIGGER {^Vnum:%s(%d)} {#NOMAP}
No good, this properly detects the room but the vnum information now is
completely lost.

#TRIGGER {^Vnum:%s(%d)} {#TAG vnum}
Wizard improperly detects the room and builds an improper room. After manual
reconfiguration wizard properly detects the room but the vnum still isn't set.
At least here the Queue isn't stuck in its loop.

#TRIGGER {^Vnum:%s(%d)} {#TAG vnum 12001}
Wizard improperly detects the room but is able to build it nonetheless.
Manual reconfiguration of the descriptions yields a Queue freeze on subsequent
delete room/looks.

Now I start thinking, perhaps it's just the vnum command that's gone awry. So
I did some more testing with the following triggers:

#TRIGGER {^Vnum:%s(%d)} {#TAG flag {%1}}
Wizard improperly detects room and builds incorrect room. Deleting the room
and relooking produces Queue stall.

#TRIGGER (^~(Vnum:(%d)*~)$) {#TAG vnum {%1}}
Here's an attempt to try to snarf the vnum from my prompt the automapper
doesn't Queue freeze anymore but it doesn't #TAG the vnum either.

If I have the automapper make a correct room with no vnum and then enable
one of these triggers that stall the queue, and instead use a valid directional
command to get a new room desc, name, exits the mapper queue will also stall
saying Queue: west (if west was the direction I went) and subsequently ignore
all other directions including look.

The offline mode parsing either nets me no vnum via #NOMAP'ing the Vnum line or
it generates the improper room desc using the Vnum line as a room description
and when brought to online play generates the same results as before.

Conclusion:
Something seems awry with the #TAG command and providing it with settable
arguments while in the middle of parsing a room description. I guess this
turned out to be a long bug report detailing a quirk with #TAG. I would
like to be able to set the roomvnum via #TAG but I may resort to using
%roomnum(%roomnum(),%1) instead, however the problem with this is that
by the time it has encountered the Vnum: line the room still hasn't been
created yet.

Note: Also on my fresh install of Zmud 6.25a I'm having an awfully hard time trying
to get the editor to undock from the bottom window (ie it won't). The
option for Lock Layout is UNCHECKED in the Settings->View->Lock Layout option
and I've been sitting here clicking and dragging on the blue bar to get it to
undock. In 6.16 all I had to was click and hold on the blue bar and it'd move.
Now it's stubbornly sitting in place. In addition the x in the top right in the
blue bar doesn't seem to want to close the window either.

-Phazic
6.12/6.16/6.25a on Win2k

SubAdmin Joined: 18 Nov 2001 Posts: 5182

In my experience #TAG VNUM has never worked. I would suggest you use the #NOMAP with the first vnum line and save any info you want for yourself out of that line. Then add to your prompt trigger:
#IF (%pos("V",%roomflags)=0) {
#NOOP %roomnum(%roomnum,%1)
#NOOP %roomflags(%roomnum,%concat(%roomflags,"V")
}

Technically this post should prolly be on the beta forum.