Zugg Software :: View topic - [Fixed] Lack of exit stubs for type 'other' exits

Posted: Mon Jul 13, 2009 5:09 pm

Deleted my unclear initial procedure.

Use the updated procedure below.

Posted: Mon Jul 13, 2009 6:17 pm

I just tried manually creating a room in a blank session and this seemed to work fine. When you create an 'other' exit you get a small circle to the lower right of the room.

If this is not what you mean, please post exact steps to recreate the problem. Also note that if you're using custom rooms, it's possible you custom room definition may obscure the circle icon.

Posted: Mon Jul 13, 2009 6:34 pm

Sorry Tech, not what I was saying. I'll try to clear it up in the original post.

If I create an 'other' exit link then the dot shows up fine. I'm just talking about when room exits aren't linked yet. The normal directions have exit link stubs that show up whereas 'other' exit type directions such as 'in' or 'out' aren't getting an unlinked stub created.

Wizard Joined: 22 Mar 2007 Posts: 2320

I just created a new direction, i, type other. I opened the Room Properties for a room on my map. I added a new exit, entered the direction i, and did not specify a destination room. When I saved the change, the map updated with an 'other' exit circle by the room. It looks like it works to me.

Posted: Mon Jul 13, 2009 7:33 pm

You can do it manually, I agree.

However, it should create the stubs automatically for 'other' exits just like it does for the predefined exits (n,s,e,w, etc).

I'm having a hard time explaining myself on this one. It boils down to Cmud automatically generating unlinked exit stubs for standard directions but not for 'other' defined directions.

Wizard Joined: 22 Mar 2007 Posts: 2320

Is the problem then in the automapper and generation of exits from the exit line? Curious. Perhaps it is not recognizing the exit name in the exit line? You said in another thread you were having odd problems with your in and out exits. I can't think offhand of a way to tell whether the automapper is recognizing an exit name.

Posted: Tue Jul 14, 2009 1:19 am

It is recognizing it. I specifically #tag the info.

Apprentice Joined: 10 Apr 2009 Posts: 145

I've noticed the same thing before..

Posted: Tue Jul 14, 2009 4:24 pm

The #tag command just sends the info to the same parser in the mapper that would normally be looking for the exit information automatically. The mapper compares the words in the exit line with the command words listed for each custom direction. If this is related to your other post and you are trying to auto-detect "in" or "out", try changing the command assigned to these custom directions to just "in" and "out" respectively and then see if it works. It might be related to the same bug that is causing the full list of commands to be shown for the exit Name field.

Posted: Tue Jul 14, 2009 4:30 pm

I can't change them to just 'in' or 'out' because them if I 'leap out' or 'leap in' it doesn't recognize that I've moved. Changing it to that big list of commands was the only way I could get it to recognize all the movements.

Posted: Tue Jul 14, 2009 7:24 pm

I could change it to simply 'in' or 'out' if there was a mechanism to tell Cmud I'm performing a movement other than it seeing the movement command. I don't think anything like that is available, but if it was it would sidestep the whole issue.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Make sure you have direction settings for all the basic directions and other general directions as single words. Then this simple trigger should pick up all the special movements and inform the mapper.
#ONINPUT {^%w (%t)$} {#QUEUE %1}

Posted: Thu Jul 16, 2009 5:30 am

Are you saying that the only thing Cmud does to prepare for the movement once it sees me try to move a direction is to put the direction in the movement queue?

I thought #queue was a LIFO (last in, first out) always putting the new item as the item next up to be popped off the list. In actual walking you'd want a FIFO (first in, first out) as hitting n and then w, I'd want it to move north first, then wait for the 'w' to complete. Putting them both at the head would have me waiting for 'w' first then 'n'.

Posted: Thu Jul 16, 2009 6:01 am

SubAdmin Joined: 18 Nov 2001 Posts: 5182

You are quite right #QUEUE does stick things in the front making it LIFO. The trigger I provided would work only when sending the directions one at a time. After checking things out #MAP is the correct command to add to the end of the queue.

I think both have become broken in the current betas, but I can't write a full report right now.

Posted: Thu Jul 16, 2009 3:11 pm

I'll give it a try this weekend. The hotel I'm currently in on a business trip seems to block telnet so I won't be able to do any further testing until this weekend.

I'll give #map a try as well, that might be an interesting work-around.

Posted: Thu Jul 16, 2009 4:42 pm

Hmm, I haven't touched the code for #QUEUE or #MAP as far as I can tell, so definitely let me know how they are broken when you can. Thanks.

Posted: Sat Jul 18, 2009 10:31 pm

Deleted the old procedure for 3.09.

Use the updated procedure below.

Posted: Sun Jul 19, 2009 9:36 pm

Not sure why but the test code doesn't execute for me, and I tried it twice. On the other test you have for the in/out tests, the stubs showed up properly.

Posted: Sun Jul 19, 2009 9:48 pm

The two issues were just split-offs from each other, very similar and I used basically the same instructions and code for each. However, the setup for this one is more complex.

Be sure of the following before you execute the test code:

1) You have the map in slow walk mode.
2) You have the map in edit mode.
3) You have created a room with an exit stub to the north
4) Your present position is in that room.

That's what I can think of off the top of my head. I imagine it has to be something in the setup not properly prepped. The only thing this shows is that the 'other' stub isn't created for the 'other' type exit.

Posted: Tue Jul 21, 2009 6:09 pm

Zugg: Where you able to observe the issue from the procedure? I can clarify it if needed. It should be pretty similar to the other procedure I posted regarding the mapper.

Posted: Wed Jul 22, 2009 2:40 am

I had trouble with this one, and it's not high on my priority list. I'm hoping that it's related to your other post that I did reproduce, so you'll need to try it again in v3.10. But this particular topic is not a critical issue for most people.

Posted: Wed Jul 22, 2009 4:46 pm

Could you at least point out which step held you up, or where your results diverged from my procedure?

Posted: Tue Jul 28, 2009 4:35 am

-- Testing done on 3.10 Pro --

New Procedure to show lack of 'other' stubs:

1) Create a new session, enter it off-line
2) Import the 'in' and 'out' directions:

Posted: Tue Jul 28, 2009 4:46 pm

Thanks for the detailed procedure. That should help me track down the problem.