 |
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
 Posted: 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 |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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? |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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 |
|
|
|
|
oldguy2
Wizard
Joined: 17 Jun 2006
Posts: 1201
|
Posted: 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.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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'?
|
|
|
|
|
oldguy2
Wizard
Joined: 17 Jun 2006
Posts: 1201
|
Posted: 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".
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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"
}
|
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Tue Sep 21, 2010 5:33 am
|
Confirmed fixed in 3.28.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: 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.
|
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: 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. |
|
|
|
|
|
|
|
