 |
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
 Posted: Mon Feb 01, 2010 12:30 am
[3.13] Parse Argument bug
|
Ran a compatibility report in 3.13. Found out that a couple of my aliases seemed to have screwed up, though I don't know how. At any rate, two that concerned me are the following:
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<alias name="nodeal" copy="yes">
<value>#SWITCH (@casecount) (20) {dtalk "No deal! Please choose @W5@Y more cases."} (15) {dtalk "No deal! Please choose another @W4@Y cases!"} (11) {dtalk "No deal! Please choose another @W3@Y cases."} (8) {dtalk "No deal! Please choose @W2@Y cases."} (6) {dtalk "No deal! From this round on, you will choose @W1@Y case."} (5) {dtalk "No deal! Please choose @W1@Y case."} (4) {dtalk "No deal! Please choose @W1@Y case."} (3) {dtalk "No deal! Please choose @W1@Y case."} (2) {dtalk "No deal! There is only one other case besides yours. You can either switch cases now, or keep what you originally had. Do you wish to switch cases?"}</value>
</alias>
<alias name="dtalk" parsearg="false" copy="yes">
<value>#SEND @dondchannel "@B<@W-@B)@Wlight@B(@W-@B>@w @Y"%-1"@w"</value>
</alias>
</cmud>
|
If you do the 'nodeal' by itself (without the dtalk alias) the script returns no errors. But when you add the dtalk alias, it screws up the nodeal for whatever reason. However, if you check the 'Parse Argument' option under the dtalk alias, it goes back to normal. Odd bug indeed...
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Feb 01, 2010 6:17 pm
|
When you delete the "dtalk" alias, then the parsing of the "nodeal" alias is changed because "dtalk" just gets treated as plain text instead of an alias call. I'm not sure why this would cause a problem, but I'll add this to the bug list. However, from what I can tell this error is not new to v3.13. And it doesn't effect the running of your scripts, it's just a bug in the CheckSyntax parser.
|
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Mon Feb 01, 2010 7:05 pm
|
It does prevent the running of the nodeal alias, though. And if it happened in other versions, that's news to me because a script that I was able to use in 3.12 no longer works for me now. In fact, just found another thing it broke:
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<alias name="dboard" copy="yes">
<value> dtalk "Cases: @W["%replace( @caselist, |, ~] ~[)"]"
dtalk "Amounts: @W["%replace( @amountlist, |, ~] ~[)"]"</value>
</alias>
</cmud>
|
If you notice, with the dtalk alias from above, for whatever reason, the dboard alias is treated as dtalk "string" regardless of functions being in it. However, make 'Parse arguments' active again, and it goes back to standard form.
So, in short, scripts are being broken with parse arguments now, or at least, mine are.
Charneus |
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Tue Feb 02, 2010 6:17 pm
|
As a side note, the reason why I have parse arguments off for the dtalk alias is so that I can do things like:
dtalk That's the wrong answer! ;)
Otherwise, it parses the ; as a command separator.
Either way, it has a potential to break a lot of scripts because yeah, it doesn't work. Typing 'nodeal' will return an error command.
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Feb 02, 2010 6:32 pm
|
I'll look into this when I can, but it's not a new bug as far as I can tell. I entered your script into 3.12 and it still gave the same syntax error in the "nodeal" alias.
|
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Tue Feb 02, 2010 9:14 pm
|
Very odd. I hadn't noticed it in 3.12. I wonder if it's actually a file that came with 3.13? I know for a fact that this script worked flawlessly in 3.12 before upgrading to 3.13... In a few days, I'll check on my pc that has never been upgraded to 3.13.
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Feb 03, 2010 5:23 pm
|
Maybe there are multiple problems here. Maybe the syntax error isn't the same as the error that causes the execution problem. Can you try to simplify your test example to help determine if the problem is with the #switch command syntax somehow?
|
|
|
|
|
|
|
|
