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
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Mon Sep 20, 2010 12:35 am   

[3.27] [Fixed in 3.28] Issues renaming 'other' exits. Orphaned links.
 
I'm trying to change my other type exits "in" to "i" and "out" to "o".

1) Using %roomlink(,"in", -1) to delete the old links... Check!
2) Using %roomportal(,"i",roomnum) to create the new link... Check!
3) Repeating steps 1 and 2 for the other side of the link... Check!
4) Getting rid of the resultant orphaned links... No solution.

Now I'm left with 2 orphaned links which were created when I used %roomportal to create the links to the other room. When I use %roomportal it works great for the source room, the source room has the appropriate link name and destination. But at the same time the destination gets a no-named blank link back because it lacks the information to know what type of return link it is. When I repeat the process with the destination, instead of linking up with the new link it creates the same no-named blank link back the the room I created it from.

So when all is done I have these extra link orphans that I can't seem to get rid of with %roomlink. If I use %roomexits to get a list of exits the blank no-named links erroneously show up as repeats of other exits present in that room.

Is there some way to create the link supplying the return information at the same time to prevent it from creating these orphans? This can be observed by following this procedure:

Code:
1) Create a new room, named 1 here.  Create an exit stub to the 'n'.
2) Create a new room, named 2 here.  Create an exit stub to the 's'.
3) Create the first half of the 'i' link with:  %roomportal(1,i,2)  # Use your actual room numbers.
4) Create the second half of the 'o' link with:  %roomportal(2,o,1)  # Use your actual room numbers.
5) Type: #say %roomexit(1)  -> Results: n|i|n
6) Type: #say %roomexit(2)  -> Results: s|s|o


Examining your data for the room 1 you'll see that the second 'n' listed is actually an orphaned stub which is masquerading in the roomexit data as 'n'. Likewise the second 's' in room 2 is the orphaned stub.


Last edited by ReedN on Tue Sep 21, 2010 5:33 am; edited 1 time in total
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 5:37 pm   
 
My guess is that you'll need to look into using the COM-based mapper scripting to do this. This isn't something I can add/fix this close to a public release, sorry.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Mon Sep 20, 2010 5:43 pm   
 
My guess is that if %roomportal were to create links that were properly marked as 'One-way' then these orphans wouldn't occur. The issue is that when you use %roomportal it seems to be creating them as 'normal' links which have a return. However the return information isn't present and so it is in error and creates an orphaned exit stub. It should either use the user defined return to create the proper return link in the destination if it creates it as a 'normal' link or it should create it as a proper 'One-way' link and so as not to leave the stub.

This is more than likely one of the reasons why when I created my perl script to clean up my mapper database I discovered thousands of orphaned stubs. As it is now anytime someone uses %roomportal they are creating an orphaned exit stub in their map.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 5:48 pm   
 
Quote:
The issue is that when you use %roomportal it seems to be creating them as 'normal' links which have a return.

Mmm, that's a possibility. Let me look into this to see how easy it is to fix.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Mon Sep 20, 2010 6:09 pm   
 
I just did some testing. When %roomlink(source, e, destination) is run it creates two exits, an 'e' exit in the source and 'w' exit in the destination. This is all proper as 'e' is a standard exit type and Cmud knows that the return exit type is 'w'.

The %roomportal issue is that it needs to utilize my custom direction definitions so that it creates the appropriate return link in the destination:

Code:
<dir name="i" reverse="o" dir="other" id="2379">in|swim in|leap in|tumble in|crash in|burrow in|gallop in|mountjump in</dir>
<dir name="o" reverse="i" dir="other" id="2380">out|swim out|leap out|tumble out|crash out|burrow out|gallop out|mountjump out</dir>


I've defined that the reverse for 'i' is 'o' above, so when roomlink is used to create 'i' in the source, it needs to utilize that return information to create a return exit of 'o' in the destination. Currently is just leaves this information blank which is the cause of the whole orphaned exit link issue.

If %roomportal is creating a link that is user defined and has a defined reverse it should utilize that information to correctly setup the exit of the destination as well. This would make its operation exactly the same as the functionality of the %roomlink command. If the link %roomportal is given isn't user defined then it should only create a 'One-way' link as there is no defined reverse information for it.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 7:37 pm   
 
The %roomportal function is not intended to create exits based upon your custom directions. It is intended for creating "other" exits with custom exit names. Now, I agree that these should probably be one-way. But when creating "i" and "o" exits, you should be using %roomlink and NOT %roomportal.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 7:48 pm   
 
Although when testing this, it seems that %roomlink isn't working with this either, so I've added that to the bug list.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 9:03 pm   
 
Actually, the problem wasn't with %roomlink. The problem was with your user-defined directions.

Look at the standard "north" direction for example:
Code:
  <dir name="n" reverse="s" dir="n" id="2">n|north</dir>

Notice that the "short name" of "n" is included as the first command in the n|north list. Your "in" direction looks like this:
Code:
<dir name="i" reverse="o" dir="other" id="2379">in|swim in|leap in|tumble in|crash in|burrow in|gallop in|mountjump in</dir>

Notice that "i" is missing from your command list. Thus, you cannot use "i" as the name of the exit. The "i" shown above is only for speedwalking with the . dot character. When using %roomlink, you must use a direction command that is in the in|swim... string list. So your correct direction should look like this:
Code:
<dir name="i" reverse="o" dir="other" id="2379">i|in|swim in|leap in|tumble in|crash in|burrow in|gallop in|mountjump in</dir>

Then you can use "i" in %roomlink.

Although honestly, I'm not sure why you are going to this trouble. You should really just use
Code:
#CALL %roomlink(,"in",123)

for in/out links. Why are you trying to use "i" for the exit name to begin with?
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Mon Sep 20, 2010 10:39 pm   
 
Yep, it works now that I adjust the direction definitions.

You will still probably want to make the adjustment to %roomportal so that it creates proper 'One-way' links, but it can wait until after the public version.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Mon Sep 20, 2010 10:41 pm   
 
Zugg wrote:
Why are you trying to use "i" for the exit name to begin with?

To match Achaea's GMCP exits. I was using 'in' and 'out' they use 'i' and 'o'. It's just easier to use the same names as they do, otherwise I'm forever coding around the fact that we use similar but slightly different names for the same exits.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Sep 20, 2010 11:17 pm   
 
Quote:
You will still probably want to make the adjustment to %roomportal so that it creates proper 'One-way' links

That one was actually easy and is fixed for the next update
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Mon Sep 20, 2010 11:44 pm   
 
Isn't "i" also is an in game alias to show inventory? I use in and out with no trouble at all in my map. By the way, they removed the "crash" ability so you could probably take that out of your directions as well.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Mon Sep 20, 2010 11:50 pm   
 
oldguy2: yeah, you're right. What do you do, modify the received GMCP data to use 'in' and 'out' replacing their 'i' and 'o'?
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Tue Sep 21, 2010 12:05 am   
 
I used the i|in and o|out as well in the direction. I was just pointing out that sending "i" doesn't make you go "in" it pulls up inventory. I think it is odd they use i and o and i also does inventory. Unless I am confused and you are actually putting "in" in the name when creating the new link and not "i".
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Tue Sep 21, 2010 12:13 am   
 
Perhaps I'll use this:

Code:
#if (%iskey( %gmcp.Room.Info.exits, "i")) {
  #addkey %gmcp.Room.Info.exits "in" %db( %gmcp.Room.Info.exits, "i")
  #delkey %gmcp.Room.Info.exits "i"
  }
#if (%iskey( %gmcp.Room.Info.exits, "o")) {
  #addkey %gmcp.Room.Info.exits "out" %db( %gmcp.Room.Info.exits, "o")
  #delkey %gmcp.Room.Info.exits "o"
  }
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Sep 21, 2010 12:23 am   
 
Hmm, I should probably notify IRE about this. They are only supposed to send valid directions in the GMCP data. If "i" is for "inventory" and not "in" then it's a problem on their end.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Tue Sep 21, 2010 12:33 am   
 
Zugg wrote:
Hmm, I should probably notify IRE about this. They are only supposed to send valid directions in the GMCP data. If "i" is for "inventory" and not "in" then it's a problem on their end.

I agree. I can't believe I didn't think about that before changing over my map, doh! The 'o' works for out, but 'i' will pull up inventory. Luckily I saved a copy before I did anything so it was easy to switch back. But yeah, there is definitely a problem with it if it's supposed to be a valid direction.

Changing the GMCP data with the above commands seems to work fine for me in any case.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Tue Sep 21, 2010 5:33 am   
 
Confirmed fixed in 3.28.
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Sep 21, 2010 4:20 pm   
 
I also got a message from IRE that they will be fixing their GMCP to use "in" instead of "i" for the direction. Should be fixed the next time the games reboot.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Tue Sep 21, 2010 5:47 pm   
 
That's awesome!

I envy your contacts. When I try to get stuff fixed like the recent MXP bug they introduced I reported it via their bug system the day it occurred but it took them almost 3 months to fix it.
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