Zugg Software :: View topic

Posted: Tue Aug 28, 2007 6:11 am

My settings got corrupted somehow so i backed out of the session and closed it down, then went int the package list to delete out the bad package.

After saving I logged back in (without closing CMUD) and managed to get things going again fine, and started recreating my settings (all of 8 items, before i noticed this issue).

I have no idea why it is even trying to parse this beyong face value, i have to l alias nor any onimput triggers.
It even did it when i tried to quit out.

I got it to stop by cycling around through all three parsing states with the icon in the lower right and back to the default (which is what it was on when it happened.

Very odd.

Posted: Tue Aug 28, 2007 8:08 am

Well, after a bit more testing and adding more settings.. it seems that cycling through the parsing states doesn't fix it, although closing out the session and restarting it does.

Furthermore, it only affects commands send from the command line, commands from aliases and triggers are working properly.

Posted: Tue Aug 28, 2007 6:41 pm

It's possible you accidentally entered Lua parsing mode by clicking on the scriptingicon or doing 'Ctrl-.'

Check that and see if it helps.

Posted: Tue Aug 28, 2007 7:10 pm

'=' expected is indeed a Lua error - but it's Ctrl-' and not Ctrl-. to change between Lua mode and zScript mode. You'll see the scripting icon change between a computer (zScript) and the Lua icon.

Posted: Tue Aug 28, 2007 7:15 pm

Yes, i saw that when i was cycling through the parsing states... but its happening when the icon is still a little computer and not the blue circle with the halo.

So explain that.

Posted: Tue Aug 28, 2007 7:21 pm

Easy - it's knackered :P

Did you do anything unusual to get it into that state, though? I've been using the Lua-zScript shift quite a bit and haven't seen this problem. Using the #verbatim command, maybe?

Posted: Tue Aug 28, 2007 7:54 pm

nope, i have yet to ever use #verbatim

It seems to only spring up when i get my combat script going though.

#ALIAS kill {
#VAR target {%params}
#VAR dostuff {attack @target}
draw @weapon
advance @target
}

#TRIGGER {You stop advancing, since you're about as close to {a|an} (*) as you could hope to get.$} {
#IF (@target!=%1) {#VAR target {%1}}
#RAISE onRT
}

#EVENT onRT {#FORALL @dostuff {#EXEC {%i}}}

#TRIGGER {Roundtime: (%d) sec.$} {
#GAG
#ALA "rtTimer" +%1 {#RAISE onRT} {Roundtime}
}

#TRIGGER {{@cStart}, you thrust * @weapon at {a|an} @target.%s} {#SUB {<color dodgerblue>You Attack! </color>}}

#TRIGGER {{@cEnd} land {a|an} (%w) hit to {his|her|its} (*) as {a|an} @target fails to dodge the attack.} {#SUB {<color firebrick> %proper(%1) hit to @target's %2.<color>}}

#TRIGGER {{you|he|she|it} {dodge|dodges} the attack} {#GAG}

There is more for one the thing dies... but for some reason, its messed up before that.

I just tested and just 'l' on the command line was working fine for about 5 rounds of combat, then i descided to look at what i was fighting and the error had sprung p again.. all while still in zscript parsing mode. The creature wasnt even close to dead.

I closed and and reopened cmud... managed to login to the game, then when i went to select my charector it had bugged out on me again, before any of my settings had a chance to go off.

Posted: Tue Aug 28, 2007 8:06 pm

Oh, just so you know logging in to this mud uses the following syntax:

login <accountname> <password>

then you get a menu of options

select <#>

so it bugged out after the first command line entry i sent in, i hhave no autologin or atconnect set

Posted: Tue Aug 28, 2007 8:14 pm

Okay now things are getting even more screwy.

It seems to be randomly expecting Lua parsing from me, yet if i keep clicking the close button and reentering the same command (and doing nothing else), after half a dozen or so such error prompts the issue goes away and the same command that failed goes through and im fine for awhile, then the issue crops up again.

It only seems to be happening for the one session, but i dont see how it can be a corrupted .pkg file when i deleted it out and recreated it from scratch only to have the issue persist.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

I was having the same issue, couldnt find a cause for it though but so far I have only had about 10 min's to play with 2.01 :(

Posted: Wed Aug 29, 2007 1:36 am

i did find a way to get around it without restarting... if i use a macroed command first, it seems to get the command line working again, at least til it wants to mess up again

although if i let the error go past to many timed itll eventually get to the 'wants to crash' pop up.. i sent in a bug report via that of course and referanced this thread

Posted: Wed Aug 29, 2007 8:26 pm

I'm not sure what to do with this once, since I can't reproduce it either. But I'll check the command line code to see how it determines whether to execute the command line in Lua mode or zScript mode.

Edited: Looks like when a thread is re-used, it might not be getting initialized properly. So the thread can get stuck in "Lua mode" even when the command line is toggled off.

Posted: Thu Aug 30, 2007 7:50 pm

OK, I can't reproduce this. I looked at the code and the thread *is* getting initialized properly. So I can't see any way for it to run in Lua mode if the icon on the command line shows the computer instead of the Lua icon.

If anyone gets more information on this one, let me know.

Posted: Thu Sep 06, 2007 3:06 am

I think this may be related to custom events.
In another session where this had never happened a made a new event and after the #RAISE fired from a trigger, it started showing up there as well.

Posted: Thu Sep 06, 2007 3:21 am

It's possible. I do use events. I also realized it's not a Lua thing. At one point I cycled through all modes several times and everything resulted in an error command (although I don't recall getting a pop-window). But nothing I typed made it to the MUD.

Posted: Thu Sep 06, 2007 5:32 pm

Well, 2.01 had the problem where using Abort could cause the threads to stop working, which means that nothing would work or get sent to the MUD.

Is this problem still happening in 2.02?

Posted: Thu Sep 06, 2007 8:01 pm

Yes its still happening in 2.02, i should have mentioned.. but its definitely from the #EVENT, after reworking my scripts so im no longer #RAISEing events, the issue goes away.

Posted: Thu Sep 06, 2007 11:55 pm

Can you give me a specific set of text to test this with. This thread has gotten a bit confusing, and I can't reproduce any problem with the event that you gave. Please give me instructions for reproducing it in a blank session window.

Posted: Fri Sep 07, 2007 11:10 pm

well... i did find a way to make it freeze up attempting to do just that

#EVENT onTest {#ADD test 1;#SHOW @test}
#ALARM -1 {#RAISE onTest}

that did nothing so i opened the settings and changed -1 to *1 and it went unresponsive...

after closing and restarting i did this:

#EVENT onTest {#ADD test 1;#SHOW @test}
#ALARM *1 {#RAISE onTest}

Now it starts working properly, and if you spam any line of text (I used 'hmm bah') the error pops up as mentioned. Sometimes the text goes through fine, thats why you have to spam it.

Posted: Sat Sep 08, 2007 1:33 am

Confirmed. I'll look into this to see what's causing the error...it's very weird. Thanks for the procedure to reproduce it.

(changing -1 to *1 didn't make it unresponsive in 2.03, but the second test did give the error when spamming text)

Posted: Sat Sep 08, 2007 2:00 am

I think I found the problem and I have it fixed in 2.03 (which should be released later tonight).

Posted: Sat Sep 08, 2007 2:42 am

Sweet.