Zugg Software :: View topic - [3.03a] Mapper object in shared package doesn't issue #OK

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

For background on this, see this thread. In short, I want to share a map between several characters, each of which has its own session. Thus, I have converted my 2.x map in one session, then moved the resulting Map object into a shared package that is imported into each session.

However, the mapper seems to get confused and stop tracking moves under certain circumstances. Here is the current behavior, assuming that the setup above has been done (Map object is in the shared package):

Start CMUD 3.03a
Open a session in online mode, log in, all that stuff.
Step south from inn. Mapper will fail to track the move, and 's' is left on the queue. Typing #ok at the command line will update position correctly.
Step north back into inn. Mapper fails to track.
Type #find. The 'look' command will be issued to the MUD, and the position will be updated correctly(!)
Open Settings Editor. Drag-and-drop the Map object from the shared package into the main session package. Close Settings Editor.
Walk around. Mapper will track the position correctly(!)
Open the Settings Editor. Drag-and-drop the Map object from the main session package back into the shared package. Close Settings Editor.
Walk around. Mapper will still track the position correctly(!)
Close CMUD
Start CMUD again.
Open the same session.
Walk around. Mapper will fail to issue #ok, and will not track, but #find will still work.

The odd part is that the mapper seems to work perfectly fine after the two drag-and-drops, until CMUD is restarted, at which point it punts again. The ONLY thing that appears to be failing is the automatic #ok to confirm a step.

(Note: I haven't yet tested with multiple sessions or quitting-to-session-screen without quitting CMUD. This seemed the simplest test case).

Magician Joined: 17 Apr 2005 Posts: 496

Try doing a quick

#track;#track NameOfYourObjectGoesHere

There have been problems reported with the map -updating-, even though internally it tracks OK.

(Also try clicking to shift focus on your map--just on the background, not on a room or anything--and see if that causes a sudden update.)

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

It appears to be a real failure to track. No amount of #track;#track <char> has any effect, nor does clicking in and out of the mapper window. In addition, the room number as reported by %roomnum() does not change unless/until I issue #ok manually as shown, in which case it changes to the correct room.

Posted: Wed Jan 21, 2009 5:24 pm

Looks like the mapper isn't making a connection between the shared map object and the actual session window to send the #OK command to.

If you do a #LOC command, does it show the proper location object? And if you select View/Locations in the main menu, is the location object connected to the correct shared map object? Also make sure that CMUD isn't creating any new map objects in the session window.

I've added this thread to my bug list and will try to play around with it myself. Having the shared map definitely hasn't been tested very much yet.

Wizard Joined: 22 Mar 2007 Posts: 2320

I have been trying to track down some similar odd behavior. Unfortunately, I am having trouble getting it to occur consistently. I, too, have my map object in a shared package. Up to this point I had thought the problem might be due to the size of my map (over 14,000 rooms), but perhaps it is the shared map object. Here is the behavior I am seeing:

I go into mapping mode.
I have a room with unexplored exits east and west.
I move east.
The mapper does not show the new room and does not follow me.
Typing #ok does *not* cause the mapper to update. The east direction is still listed in the queue.
I move west (back to the first room).
Suddenly the mapper creates the room to the east and puts the location marker there, and a fraction of a second later it creates a new room *west* of the first room, and moves the location object there.

I've been trying to get a procedure to show the problem consistently because I thought it was related to another problem I have been trying to track down: http://forums.zuggsoft.com/forums/viewtopic.php?t=32602 which I also have not been able to demonstrate consistently. It hadn't occurred to me it might be related to the shared map package. I'll poke at this some more, but my experimenting time is a bit limited right now.

Wizard Joined: 22 Mar 2007 Posts: 2320

Aha! I think I have found a possible cause of some #ok problems.

I have a package containing my map object, and a module containing most of my mapping triggers.
In the module I create a simple trigger:

Wizard Joined: 22 Mar 2007 Posts: 2320

Here is a procedure to demonstrate it with the untitled session.

Click on the untitled session window
Open the map, so it creates the map object
Open the Package Editor
Within the map object, create a trigger with pattern "This is a test" and value "#say test succeed"
In the command line, type: #show This is a test
The trigger fires
In the Package Editor, create a new package
Drag the map object to the new package
In the command line, type: #show This is a test
The trigger does not fire
In the Package Editor, drag the map object back to the main session package
In the command line, type: #show This is a test
The trigger fires again

Triggers within the map object do not fire if the map object is in a package other than the main session package.

Posted: Mon Jan 26, 2009 5:49 pm

Yep, definitely looks like a scoping issue for triggers within a Map object that is in a different package. I've added this to the bug list. Thanks for the simple procedure to reproduce it in a blank session.