|
Obyron Novice
Joined: 29 Jan 2006 Posts: 40 Location: Aardwolf
|
Posted: Wed Apr 22, 2009 6:00 pm
Two Zones Report the Same Zonenum |
Not really sure what's going on here, since I don't think it should be technically possible. I converted my ZMud map for Aardwolf (which didn't exhibit this behavior) into CMud. I now have two areas that seem to be reporting the same zonenum.
To wit:
#LOOP %numzones {#SHOW %i -- %zonename(%i)} returns:
Code: |
1 -- Faerie Tales II
2 -- Eighteenth Dynasty
3 -- Art of Melody
4 -- Orchard
5 --
6 --
7 --
8 -- Midgaardian Publishing House
9 -- Hotel Orlando
[...]
73 --
74 --
75 -- Ultima
76 -- Gilda and the Dragon
77 --
[...to the end]
|
This is fine. However, #SHOW %zonenum(Gilda and the Dragon) returns 1. To complicate things, #SHOW %zonenum("Gilda and the Dragon") returns 76. This doesn't happen with any other area. ie: #SHOW %zonenum(Midgaardian Publishing House)-- with no quotes-- correctly returns 8.
And just to keep things even more interesting, #SHOW %zonename(76) returns Gilda and the Dragon, but #SHOW %zonenum(%zonename(76)) works. ;)
Is this something I'm screwing up? |
|
|
|
charneus Wizard
Joined: 19 Jun 2005 Posts: 1876 Location: California
|
Posted: Wed Apr 22, 2009 6:35 pm |
Interesting. While I can produce somewhat of the same effect, it's a little different on my end.
I don't think the 1 from Gilda and the Dragon is referring to a zone number. I'm not sure what it is referring to, but when I do #SAY %zonenum(Gilda and the Dragon), it correctly (supposedly) returns a value of -1, since Gilda and the Dragon is not a string, therefore it shouldn't find anything mapper related. However, doing #SAY %zonenum("Gilda and the Dragon") correctly returns 39.
CMUD is much more pickier with strings than zMUD ever was. Anything listed as an argument should always be encased by quotation marks. It's one thing a lot of newer CMUD users have to get used to. However, this is still interesting, to say the least. I'm not about to go through all 255 zones, but some of the ones I tested returned the zone number, others something completely different.
By the way, unless your zones are numbered sequentially, %numzones will never show you all the zones you have. Annoying, since I don't know of any other way to loop through all the zones in the database. *sigh*
Charneus |
|
|
|
Fang Xianfu GURU
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Thu Apr 23, 2009 2:28 am |
charneus wrote: |
Anything listed as an argument should always be encased by quotation marks if it is a literal string |
Fixed. |
|
|
|
Obyron Novice
Joined: 29 Jan 2006 Posts: 40 Location: Aardwolf
|
Posted: Thu Apr 23, 2009 3:52 am |
As opposed to a proverbial string?
I have it working now. I didn't actually change the code. I'm guessing that zscript functions can handle variables as arguments without putting them in quotes as long as the variable type is set as string?
What's the difference in the string types? |
|
|
|
Fang Xianfu GURU
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Thu Apr 23, 2009 9:12 am |
As opposed to a string that contains variable references or function references, which should be surrounded by {} if you want them expanded. I believe it's called an "expanded string" to contrast it with a literal string.
test="lol"
#say "This is @test"
prints This is @test.
test="lol"
#say {This is @test}
prints This is lol.
No quotes at all is ambiguous and changes depending on what you're doing with them. With functions this can be especially problematic - it depends on what the default argument type for the function is, which varies across functions.
One thing that might shed some insight on this is if you compare the compiled code for the two scripts, with "" and without. It's probable that the "Gilda and the Dragon" part of the code will be of a different type when it doesn't have "" around it (STRING when it does have them round it, who knows when it doesn't). If that's the case, then that's probably part of the trouble. It's good practice to use "" everywhere you mean a literal string, anyway. |
|
|
|
|
|