Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
JQuilici
Adept


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

PostPosted: Tue Jan 20, 2009 6:26 pm   

[3.03a] Mapper object in shared package doesn't issue #OK
 
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):

  1. Start CMUD 3.03a
  2. Open a session in online mode, log in, all that stuff.
  3. 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.
  4. Step north back into inn. Mapper fails to track.
  5. Type #find. The 'look' command will be issued to the MUD, and the position will be updated correctly(!)
  6. Open Settings Editor. Drag-and-drop the Map object from the shared package into the main session package. Close Settings Editor.
  7. Walk around. Mapper will track the position correctly(!)
  8. Open the Settings Editor. Drag-and-drop the Map object from the main session package back into the shared package. Close Settings Editor.
  9. Walk around. Mapper will still track the position correctly(!)
  10. Close CMUD
  11. Start CMUD again.
  12. Open the same session.
  13. 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).
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you!
Reply with quote
gamma_ray
Magician


Joined: 17 Apr 2005
Posts: 496

PostPosted: Tue Jan 20, 2009 8:53 pm   
 
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.)
Reply with quote
JQuilici
Adept


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

PostPosted: Tue Jan 20, 2009 10:14 pm   
 
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.
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you!
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Jan 21, 2009 5:38 pm   
 
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.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Jan 21, 2009 7:12 pm   
 
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:
Code:
<trigger priority="1100" id="150">
  <pattern>There are three exits:</pattern>
  <value>#say trigger fired</value>
</trigger>

I move into a room with 3 exits, the trigger fires.
I move the trigger into the map object, by dragging it.
I move into a room with 3 exits, the trigger does *not* fire.
I move the map object, with the trigger, into my main session package, by dragging it to the tab.
I move into a room with 3 exits, the trigger fires.

It is possible that, when cmud tries to create an #ok trigger in the map object, and the map object is in a shared package, the trigger might not fire, just as in the above example.

[edit] I should note that the map object is enabled throughout the process. The map object is also pointing to the correct map file. It is marked Autoload on session start.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Fri Jan 23, 2009 7:08 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
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

© 2009 Zugg Software. Hosted by Wolfpaw.net