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
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Fri Apr 07, 2006 7:11 am   

How to send captured-text to a variable without phrasing?
 
Is there a way to send some text captured by a certain pattern straight to a variable before phased by Cmud/zmud?

e.g.
trigger {^the wolf is traped by a weapon like (%*)} {#va weapon %1}

if the text is "()" which match the pattern (%*) in the trigger, how to #va it straight to the variable @weapon without phrased by cmud/zmud?

I wish there an option added to #va/=/#additem/@variable etc. to switch on/off phrasing when we use the #va/@variable command to put-in or get-out a certain value,is it there?
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Apr 07, 2006 6:32 pm   
 
In CMUD this shouldn't be a problem. CMUD won't parse or expand the %1 coming from triggers. This is due to a difference in how the compiled parser works compared to the old zMUD parser.

In zMUD, the %1 variable was done first as a string substitution. Then the resulting #VAR command was executed. This caused expansion of the %1 contents.

In CMUD, %1 is treated as an "argument" (like in a function or method) and is replaced when the #VAR command itself is executed. It pulls the argument from the current runtime stack and performs the variable assignment. Since the trigger variables like %1 are strings, there is no expansion or evaluation of %1 when it is assigned.

This should make triggers work more like expected.

In zMUD to accomplish this, you can try putting quotes around the %1 like

{#va weapon "%1"}

and that should prevent the parsing. But this shouldn't be necessary in CMUD.
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Sat Apr 08, 2006 3:28 am   
 
that's ok,zugg,thanks for your replication!

but a more question about parse, is there a way in cmud or zmud to use @weapon or %item(@weapon,n) straightly get-out the value of variable "weapon" or the nth item of "weapon" without parsing it(the value)?

I thought it is powerful to make cmud/zmud's command&function to set/ get-out the very text(or anything else) which captured by a trigger straighly to/from a variable without parsing, this can make it more suitable for any cases whether the text captured by a trigger contains a wildcard or not, isn't it?
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Sat Apr 08, 2006 4:51 pm   
 
wwwfisher, I'm not sure I understand what you're asking... Are you trying to find an easy way to access ith item in a list?
_________________
Asati di tempari!
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Sun Apr 09, 2006 2:02 am   
 
Not exactly, I want a way to prevent the "@" or "%item(,)" etc. operater prasing the value in variable or itemlist when getting it out, only get-out it as what it(the value,wheter it contains a wildcard or not) is.

Sorry for my poor english.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Apr 09, 2006 6:51 am   
 
doesn't %expand() do this already? I know you can nuke the parser down to just <> and [], but I dunno if functions or variables are handled before this step or not.
_________________
EDIT: I didn't like my old signature
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Sun Apr 09, 2006 7:52 am   
 
whether you use %expand() or <> or [], once you use "@" or %item(,) operater to get-out the value of a variable or an itemlist, the default operation of "@" or %item performs phrasing it(the value).

I want a way to prevent the operater prasing the value when it was got-out, as default,the operater performs prasing ation on it when it was got out.

is there a way to do so?
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Apr 09, 2006 5:35 pm   
 
please read the helpfile, wwwfisher. %expand() does exactly what you want. If not, make a new topic and show a code example of what you're trying to do.
_________________
EDIT: I didn't like my old signature
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Mon Apr 10, 2006 1:07 am   
 
Sorry for my poor english, it was too bad to be understood! Sad

I have read zmud's help, and get some knowledge that %expand() or <> or [] performs such action as below: whether to return the "@variable" format as a string or treat it as an variable and reurn the value of it).Am I right?

but what I talked is the VALUE of a variable or the nth item in an itemlist, I wish there's a way to prevent the command to prase the value (not the format of varialbe-name/text) when we got it out use a command or function.

As the {#va weapon "%1"} which used "" to stop #var prasing the value in %1 and straightly assigns it into an variable. Can we use {@"weapon"} to get-out the value stored in variable weapon and prevent @ prasing it(the value of %1 in this example)? the answer is NO. that's what I want.

Maybe there's no answer for this,unless zuggsoft makes an upgrade of the commands and functions which manipulate values in/out a variable or an itemlist. OR CMUD already does so! As zugg talked above. Rolling Eyes
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Mon Apr 10, 2006 2:56 am   
 
Quote:

Can we use {@"weapon"} to get-out the value stored in variable weapon and prevent @ prasing it(the value of %1 in this example)? the answer is NO. that's what I want.


Provide a real example of what you are trying to do. Something you are actually doing within ZMud and getting frustrated that it's not working. Based on what you are saying in this thread, I'm %90 sure what you need is %expand() and it's just a matter of explaining how to do it.
_________________
EDIT: I didn't like my old signature
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Mon Apr 10, 2006 3:33 am   
 
ok,try to test below, as someone else early posted:

#va test %char(191)
#va test1 %char(191)zmud
#sh @test
you will get
@test=
#sh @test1
can you get {@test1=zmud}?

I think the @ operater do prasing on "zmud", and makes us not got the expected value, I want a way to prevent @ do the prasing,only get the value "zmud" out.

am I right?
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Mon Apr 10, 2006 5:35 am   
 
The following code produces the following results. I'm not sure why 191 produces different output, however. Regardless of how I worked with it, there was no way to get %char(191) to display the hispanic opening question mark when concatenated to anything else (including whitespace), so I'm guessing some sort of bug or legacy meaning for that character. Not sure if a bug would be possible without also affecting more than just that one character, however.

Quote:

#loop 1,255 {#show %i -- %char(%i) %char(%i)zmud}


1 -- zmud
2 --  zmud
3 --  zmud
4 --  zmud
5 --  zmud
6 --  zmud
7 -- zmud
8 --zmud
9 -- zmud
10 --

zmud
11 -- zmud
12 --



zmud
13 -- zmud
14 -- zmud
15 -- zmud
16 --  zmud
17 --

zmud
18 --  zmud
19 --  zmud
20 --  zmud
21 --  zmud
22 --  zmud
23 --  zmud
24 --  zmud
25 --  zmud
26 --  zmud
27 -- mud
28 --  zmud
29 --  zmud
30 --  zmud
31 --  zmud
32 -- zmud
33 -- ! !zmud
34 -- " "zmud
35 -- # #zmud
36 -- $ $zmud
37 -- % %zmud
38 -- & &zmud
39 -- ' 'zmud
40 -- ( (zmud
41 -- ) )zmud
42 -- * *zmud
43 -- + +zmud
44 -- , ,zmud
45 -- - -zmud
46 -- . .zmud
47 -- / /zmud
48 -- 0 0zmud
49 -- 1 1zmud
50 -- 2 2zmud
51 -- 3 3zmud
52 -- 4 4zmud
53 -- 5 5zmud
54 -- 6 6zmud
55 -- 7 7zmud
56 -- 8 8zmud
57 -- 9 9zmud
58 -- : :zmud
59 -- ; ;zmud
60 -- < <zmud
61 -- = =zmud
62 -- > >zmud
63 -- ? ?zmud
64 -- @ @zmud
65 -- A Azmud
66 -- B Bzmud
67 -- C Czmud
68 -- D Dzmud
69 -- E Ezmud
70 -- F Fzmud
71 -- G Gzmud
72 -- H Hzmud
73 -- I Izmud
74 -- J Jzmud
75 -- K Kzmud
76 -- L Lzmud
77 -- M Mzmud
78 -- N Nzmud
79 -- O Ozmud
80 -- P Pzmud
81 -- Q Qzmud
82 -- R Rzmud
83 -- S Szmud
84 -- T Tzmud
85 -- U Uzmud
86 -- V Vzmud
87 -- W Wzmud
88 -- X Xzmud
89 -- Y Yzmud
90 -- Z Zzmud
91 -- [ [zmud
92 -- \ \zmud
93 -- ] ]zmud
94 -- ^ ^zmud
95 -- _ _zmud
96 -- ` `zmud
97 -- a azmud
98 -- b bzmud
99 -- c czmud
100 -- d dzmud
101 -- e ezmud
102 -- f fzmud
103 -- g gzmud
104 -- h hzmud
105 -- i izmud
106 -- j jzmud
107 -- k kzmud
108 -- l lzmud
109 -- m mzmud
110 -- n nzmud
111 -- o ozmud
112 -- p pzmud
113 -- q qzmud
114 -- r rzmud
115 -- s szmud
116 -- t tzmud
117 -- u uzmud
118 -- v vzmud
119 -- w wzmud
120 -- x xzmud
121 -- y yzmud
122 -- z zzmud
123 -- { {zmud
124 -- | |zmud
125 -- } }zmud
126 -- ~ ~zmud
127 --  zmud
128 -- zmud
129 -- zmud
130 -- zmud
131 -- zmud
132 -- zmud
133 -- zmud
134 -- zmud
135 -- zmud
136 -- zmud
137 -- zmud
138 -- zmud
139 -- zmud
140 -- zmud
141 -- zmud
142 -- zmud
143 -- zmud
144 -- zmud
145 -- zmud
146 -- zmud
147 -- zmud
148 -- zmud
149 -- zmud
150 -- zmud
151 -- zmud
152 -- zmud
153 -- zmud
154 -- zmud
155 -- zmud
156 -- zmud
157 -- zmud
158 -- zmud
159 -- zmud
160 -- zmud
161 -- zmud
162 -- zmud
163 -- zmud
164 -- zmud
165 -- zmud
166 -- zmud
167 -- zmud
168 -- zmud
169 -- zmud
170 -- zmud
171 -- zmud
172 -- zmud
173 -- zmud
174 -- zmud
175 -- zmud
176 -- zmud
177 -- zmud
178 -- zmud
179 -- zmud
180 -- zmud
181 -- zmud
182 -- zmud
183 -- zmud
184 -- zmud
185 -- zmud
186 -- zmud
187 -- zmud
188 -- zmud
189 -- zmud
190 -- zmud
191 -- mud
192 -- zmud
193 -- zmud
194 -- zmud
195 -- zmud
196 -- zmud
197 -- zmud
198 -- zmud
199 -- zmud
200 -- zmud
201 -- zmud
202 -- zmud
203 -- zmud
204 -- zmud
205 -- zmud
206 -- zmud
207 -- zmud
208 -- zmud
209 -- zmud
210 -- zmud
211 -- zmud
212 -- zmud
213 -- zmud
214 -- zmud
215 -- zmud
216 -- zmud
217 -- zmud
218 -- zmud
219 -- zmud
220 -- zmud
221 -- zmud
222 -- zmud
223 -- zmud
224 -- zmud
225 -- zmud
226 -- zmud
227 -- zmud
228 -- zmud
229 -- zmud
230 -- zmud
231 -- zmud
232 -- zmud
233 -- zmud
234 -- zmud
235 -- zmud
236 -- zmud
237 -- zmud
238 -- zmud
239 -- zmud
240 -- zmud
241 -- zmud
242 -- zmud
243 -- zmud
244 -- zmud
245 -- zmud
246 -- zmud
247 -- zmud
248 -- zmud
249 -- zmud
250 -- zmud
251 -- zmud
252 -- zmud
253 -- zmud
254 -- zmud
255 -- mud
_________________
EDIT: I didn't like my old signature
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Mon Apr 10, 2006 7:17 am   
 
I thought the #va command here or %char function performs a prasing action on the value which got out by @ or % operater, In such cases, switch off parsing(within those commands and functions which manipulate values in/out a variable or an itemlist) maybe more suitable for us to get the very thing we want.

would this be applied in CMUD?
Or an upgrade for zmud in future?
Rolling Eyes
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Apr 10, 2006 5:16 pm   
 
Also, as people have said, the %expand function will do this if you use a 1 for the argument.

#va test1 %char(191)zmud
#show %expand(@test1,1)

Normal variable expansion performs recursive expansion of the value. Using the %expand function you can control exactly how many recursions are performs. Using a 1 as the argument to expand performs the initial expansion of @test1 to it's value but then stops and doesn't expand the value.
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Tue Apr 11, 2006 1:00 am   
 
oh? let's try it in zmud

#va test1 %char(191)zmud
#show %expand(@test1,1)

anybody got the result {@test1=zmud}?
I do not got it!

for %expand(), I have read zmud's help, and get some knowledge that %expand() or <> or [] performs such action as below: whether to return the "@variable" format as a string or treat it as an variable and reurn the value of it.

and in the above example, there's no "@variable" format contained in the returned value "mud", the %expand(@test1,1) dosen't fire.

if we use

{#va test %char(191)
#va test1 "@testzmud"
#show %expand(@test1,-1)}

we will get "@testzmud" , and if we use

#show %expand(@test1,1)

"@test" in "@testzmud" which we got using{#show %expand(@test1,-1)} will be treated as a variable, and %expand will fire 1time and return the value in @test instead(in theory according to %expand function's explanation). but this not happened, the %expand function do nothing again! the "@testzmud" was traited as a variable by the name of "testzmud",bug and bugs again?! Evil or Very Mad

Back to our topics, %expand() function performs action on "@variable" format, not the phrasing of the value returned (here in zugg's example, I thought the phrasing performs action on "zmud" and make us get an unexpected result "mud"). Am I right?

zugg tested it in CMUD? Rolling Eyes
if it is, that's would be GREAT!!!!!!!!!!!! Very Happy

stick to my topic please
I thought the @/% operater do phrasing on "zmud", and makes us got the unexpected value "mud", I want a way to prevent @/% doing the phrase, only get-out the value "zmud" as it is. IS IT THERE?
Rolling Eyes Rolling Eyes Rolling Eyes Rolling Eyes
If it's a bug, Please fix it and make it more robust!
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Tue Apr 11, 2006 9:43 am   
 
To be totally clear %expand is behaving exactly as advertised.

A small series of tests for you to preform with zMud v 7.21
#SHOW {%char(191)zmud}
Displays "mud".
#VAR test {%char(191)}
Sets the variable test to "" confirmed in the settings editor.
#VAR test1 "@testzmud"
Sets the variable test1 to "@testzmud" confirmed in the settings editor.
#SHOW @test1
Displays a blank line, due to @testzmud being null, recursive expansion.
#SHOW %expand(@test1,-1)
Displays "@test1", no <> or [] notation is present in the string "@test1".
#SHOW %expand(@test1,1)
Displays "@testzmud" again correct expanded 1 step so the value of of the variable test1 was displayed.
#VAR @test1 "@{test}zmud"
Sets the variable test1 to "@{test}zmud" confirmed in the settings editor.
#SHOW @test1
Displays "mud" due to full expansion again.

Now here is the real pickler problem that your actually having; and I believe this is a Windows thing.
#LOOP 255 {#SHOWP %rightback("00%i",3) %char(%i) '%char(191)%char(%i)'%char(32);#IF (%mod(%i,8)=0) {#SHOW {}}};#SHOW {}
Gives a lovely output of:
Code:
001  '' 002  '' 003  '' 004  '' 005  '' 006  '' 007  '' 008 ''
009      '' 010
 '' 011  '' 012


 '' 013  '' 014  '' 015  '' 016  ''
017
 '' 018  '' 019  '' 020  '' 021  '' 022  '' 023  '' 024  ''
025  '' 026  '' 027 '' 028  '' 029  '' 030  '' 031  '' 032   ''
033 ! '' 034 " '' 035 # '' 036 $ '' 037 % '' 038 & '' 039 ' '' 040 ( ''
041 ) '' 042 * '' 043 + '' 044 , '' 045 - '' 046 . '' 047 / '' 048 0 ''
049 1 '' 050 2 '' 051 3 '' 052 4 '' 053 5 '' 054 6 '' 055 7 '' 056 8 ''
057 9 '' 058 : '' 059 ; '' 060 < '' 061 = '' 062 > '' 063 ? '' 064 @ ''
065 A '' 066 B '' 067 C '' 068 D '' 069 E '' 070 F '' 071 G '' 072 H ''
073 I '' 074 J '' 075 K '' 076 L '' 077 M '' 078 N '' 079 O '' 080 P ''
081 Q '' 082 R '' 083 S '' 084 T '' 085 U '' 086 V '' 087 W '' 088 X ''
089 Y '' 090 Z '' 091 [ '' 092 \ '' 093 ] '' 094 ^ '' 095 _ '' 096 ` ''
097 a '' 098 b '' 099 c '' 100 d '' 101 e '' 102 f '' 103 g '' 104 h ''
105 i '' 106 j '' 107 k '' 108 l '' 109 m '' 110 n '' 111 o '' 112 p ''
113 q '' 114 r '' 115 s '' 116 t '' 117 u '' 118 v '' 119 w '' 120 x ''
121 y '' 122 z '' 123 { '' 124 | '' 125 } '' 126 ~ '' 127  ' 128 ''
129 '' 130 '' 131 '' 132 '' 133 '' 134 '' 135 '' 136 '
137 ' ' 138 '
' 139 '' 140 '


' 141 '' 142 '' 143 '' 144 ''
145 '
' 146 '' 147 '' 148 '' 149 '' 150 '' 151 '' 152 ''
153 '' 154 '' 155 ' 156 '' 157 '' 158 '' 159 '' 160 ' '
161 '!' 162 '"' 163 '#' 164 '$' 165 '%' 166 '&' 167 ''' 168 '('
169 ')' 170 '*' 171 '+' 172 ',' 173 '-' 174 '.' 175 '/' 176 '0'
177 '1' 178 '2' 179 '3' 180 '4' 181 '5' 182 '6' 183 '7' 184 '8'
185 '9' 186 ':' 187 ';' 188 '<' 189 '=' 190 '>' 191 '?' 192 '@'
193 'A' 194 'B' 195 'C' 196 'D' 197 'E' 198 'F' 199 'G' 200 'H'
201 'I' 202 'J' 203 'K' 204 'L' 205 'M' 206 'N' 207 'O' 208 'P'
209 'Q' 210 'R' 211 'S' 212 'T' 213 'U' 214 'V' 215 'W' 216 'X'
217 'Y' 218 'Z' 219 '[' 220 '\' 221 ']' 222 '^' 223 '_' 224 '`'
225 'a' 226 'b' 227 'c' 228 'd' 229 'e' 230 'f' 231 'g' 232 'h'
233 'i' 234 'j' 235 'k' 236 'l' 237 'm' 238 'n' 239 'o' 240 'p'
241 'q' 242 'r' 243 's' 244 't' 245 'u' 246 'v' 247 'w' 248 'x'
249 'y' 250 'z' 251 '{' 252 '|' 253 '}' 254 '~' 255 ''


As you can see '' is actually used as a toggle for the high bit of the next character, either add or subtract 128 from the next character.
Interestingly though if type in
#SHOW "zmud"
It does display perfectly, so I am not sure which Windows function is causing the problem.

Hope this clarifies everything for you.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Tue Apr 11, 2006 3:20 pm   
 
Oops, posted before noticing a second page.... What Vijilante said... Smile
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Wed Apr 12, 2006 1:09 am   
 
oh, thanks for your great post,Vijilante.

but there's one point I disagree with you, as you said
Quote:
#SHOW "zmud"
It does display perfectly, so I am not sure which Windows function is causing the problem.


I thought it's a bug of zmud's phrasing which performed by @/% operater.

as we see when we use directly #show command {#SHOW "zmud"}, it does the very thing, that's means it's not a Windows function's problem, it's zmud's command/function's phrasing (on values in variable/itemlist) problem, and obviously in the command {#SHOW "zmud"} we use "" prevented zmud's phrasing doing expansion on zmud, and when we use command/function by @/% operater, we have no way to stop zmud's phrasing on the returned value, am I right?

If what I said is true, a fix for the problem would be applied in CMUD or an upgrade for zmud in future?


Last edited by wwwfisher on Wed Apr 12, 2006 1:27 am; edited 2 times in total
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Apr 12, 2006 1:22 am   
 
Any "fix" to this will only be applied to CMUD. As mentioned in the other post about Variables Types, CMUD handles parsing in a completely different way that should solve this problem. No changes are planned for zMUD.
Reply with quote
wwwfisher
Beginner


Joined: 03 Apr 2006
Posts: 12

PostPosted: Wed Apr 12, 2006 1:34 am   
 
Quote:

Any "fix" to this will only be applied to CMUD. As mentioned in the other post about Variables Types, CMUD handles parsing in a completely different way that should solve this problem. No changes are planned for zMUD.


WOW, delicious CMUD!!!!!!! Mr. Green Mr. Green Mr. Green

Too delicious to wait! will it released out in the next week?
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Wed Apr 12, 2006 1:52 am   
 
Not likely, view the ETA thread. It has just been updated and points to end of April or later.
_________________
Taz :)
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