Zugg Software :: View topic - [1.29] *Urgent* Current scripts are broken and reformat does not fix them.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I was working on a package for someone who was having troubles and I came across this issue.

Posted: Sun Apr 22, 2007 4:09 pm

Confirmed. The problems seems to be with how the parser reads a line that is indented but begins with a number. The syntax highlights in green (suggesting a string literal or an operator).

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Just a note. As this is not my code I do not know WHEN this broke. I think this person went strait from 1.26 to 1.29 but, I haven't asked if this particular issue existed in 1.26 but certainly the auto format was not in that version.

Posted: Sun Apr 22, 2007 5:20 pm

Are "2dd" and "1dd" and "pdd" aliases that are defined? If they are not aliases, then CMUD is being confused by them starting with a number and doesn't know that you want to send them to the MUD. As usual, putting in an explicit #SEND command will probably help.

Posted: Sun Apr 22, 2007 5:22 pm

And btw, I'm not sure I would mark this as "Urgent". Reformat is never going to "fix" a script. In fact, it is designed to not make any changes to the script other than formatting and indenting. So if the script doesn't compile *before* using Reformat, it probably still won't compile *after* doing a reformat. I think the issue here is more with the syntax issue in your script and not with the Reformat command.

Novice Joined: 08 Feb 2007 Posts: 45

The code Arminas is referring to is my code. I have huge problems with my package since converting to 1.27. Varying from not being able to run new created aliases from the command line, new triggers not firing, old triggers not firing, old aliases not being known, macros no longer working, unable to save settings using settings editor, etc.... every time something different so it is hard to actually report what is going wrong.

"2dd" and "1dd" and "pdd" are indeed defined aliases, but they seem no longer to be 'known' by cmud, altho they are still visible and enabled in the settings editor.

And no, Arminas, I didnt move straight from 1.26 to 1.29, but also had the intermediate beta releases (I saw the editor features and wanted to try them).
I will try and go back in my backups till I find a package that isnt acting strangely under 1.29, but otherwise I am considering going back to 1.26

Posted: Sun Apr 22, 2007 6:05 pm

Actually, Zugg I would disagree. If you outdent the "2dd" and "1dd" etc it will actually compile and reformatting would break it. While that's not how it started out in this case, conceivably it could be. Also the issue here isn't really the reformat command but the parser. The reformat command does what it's supposed to, the parser just can't seem to make sense of it.

I always thought starting an alias with a number was a little odd, but I guess it's necessary for compatibility.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I was not concerned with with the reformat breaking it or not fixing it so bad as it was originally formatted nicely and it did not work in 1.29. So this is breaking some peoples scripts. If a script starts out all on one line and you hit reformat it then breaks it.

Zwartje's as an example. I placed the code in the one line format as a testing measure and that did work. But it was not that way when I opened the package. Since you marked 1.29 as a public version and numbers in aliases are supposed to work I thought you might be a little extra concerned.

Posted: Mon Apr 23, 2007 12:58 am

True, I *am* concerned, but the number of people using a number at the beginning of an alias should be pretty small, since most versions of CMUD didn't support this at all. So while it's definitely a bug, it's not something urgent that is preventing a lot of people from playing MUDs.

Novice Joined: 08 Feb 2007 Posts: 45

In zmud I always used aliases starting with a number, I even had aliases starting with = and +.

I bought the first public version and as I wanted to use the setup I was used to, I made aliases starting with numbers, which worked fine (i did change the + and = aliases as that was not supported by cmud).
Actually, I know quit some other zmud users who use them.

But to be honest, this is not my main problem right now. If i can solve it by placing it all in 1 line, i have a workaround and i am happy - but my whole package has problems since the upgrade to v1.27 which are not explained by the number aliases.

Even making a brand new session, using a package from the beginning of april or older didnt solve the issues I am having.
Latest issue is that none of my macros are working, not even the directional keys using the numpad.

Novice Joined: 08 Feb 2007 Posts: 45

ok, scratch the macro issue - I opened the corrupted session, not the new one - sorry for the confusion, but afraid i am rather confused with it all.

EDIT: Too bad, I can confirm it in the new session too. No macros are working - numpad gives numbers instead of directions.

Posted: Mon Apr 23, 2007 2:34 pm

Is it really NO macros that're working, or do all your macros use numpad keys? If it's just numpad keys, that'd suggest that the EnglishKeypad package that's loaded for all sessions by default has stopped being loaded. Editing the session and adding it to the list of packages on the Files tab should fix the problem.

Novice Joined: 08 Feb 2007 Posts: 45

No, it is definitely NO macro's at all that are working, no numpad, no F keys, no ALT- or CTRL- key combinations. No old macros, no newly created macros.

I had also looked at the directional keypad package, but those are correctly added in the session, as far as the files tab shows.

Posted: Mon Apr 23, 2007 5:06 pm

You need to send me your PKG file so that I can look at this. Nobody else is reporting any problems with Macros and I can't reproduce any of these problems. But it sounds like you have some corrupted packages from older versions.

Posted: Mon Apr 23, 2007 9:17 pm

Back to this code:

Posted: Mon Apr 23, 2007 10:44 pm

Wow this was a pain. All of CMUD is set up with the concept of a "CurrentModule", which is the module that the alias, trigger, macro, whatever executes within the context of. This is because the visibility (scope) of items. So, when you are in the Package Editor, it needs to check the syntax and highlight the syntax based upon the scope of the currently edited item.

But in the background, CMUD might be executing scripts, timers, etc. And when a script executes, it changes the scope to the setting being executed. So this messes up the package editor. The package editor can't change the "CurrentModule" because this might mess up scripts running in the background. And yet, all of CMUD was written to use this "CurrentModule" value. So now the package editor needs to search for other settings based upon a different context than the currently executing context.

This has required me to add an "OverrideModule" to a lot of routines. If it's not set, it uses the "CurrentModule" as before. But if the OverrideModule value is set, then that is used as the scope instead. All of the internal search functions have an OverrideModule added to them. The Package Editor passes the currently edited module as the OverrideModule to all of the syntax checking routines to override the normal scope context.

I hope this hasn't caused any side effects. I really hate adding huge kludges like this, but I couldn't think of any other way to handle it without breaking a lot of stuff.

Oh, and I *did* find some more corruption in the BISZwartje package that you sent me. The Parent/Owner/PkgID values for the main window are all set to zero (which is wrong). Looks like another result of previously dragging/dropping the window. I thought the new version would fix this, but it doesn't seem to be working in all cases, so I'm still debugging this to try and figure out why it didn't get fixed when the module was loaded.

Posted: Mon Apr 23, 2007 11:10 pm

OK, it was fixing the modules/windows internally, but wasn't writing these fixes out to the disk file. I think I've got that fixed now so that the next version will properly fix corrupted PKG files like this.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Very sweet Zugg! Here's hoping the kludges/fixes don't cause more headaches!

Novice Joined: 08 Feb 2007 Posts: 45

Not to pester you, Zugg, but do you have an idea when this fix will be available for use?

Just to know if it is worth making a package with only 1 module/window to overcome this issue so that I at least can play my MUD in the mean time

Posted: Wed Apr 25, 2007 5:55 pm

Hopefully today. I'm trying to decide whether or not to give up on the TextBox redraw problem that we've been discussing in the other thread in this forum.

Newbie Joined: 27 Apr 2007 Posts: 1 Location: California

My triggers etc will not fire since I upgraded from 1.26 to 1.29. I have since upgraded to 1.30 and still no luck.

I have had various levels of progress and failure along the way. When I first upgraded, my package was lost. I was able to make new triggers, and they would work, but would never save for the next time I started the software. I reinstalled 1.24 to no avial, got my old triggers back, but they would not fire and any new ones I would make did not fire. I upgraded from 1.24 to 1.29 and in addtion to the trigger problem, my mapper no longer follows me. I have now upgraded to 1.30. Mapper works but no triggers....

Do I have to do a complete uninstall and delete my trigger package and start all over?

Posted: Fri Apr 27, 2007 1:11 am

That would be a very good idea!

Novice Joined: 08 Feb 2007 Posts: 45

Posted: Fri Apr 27, 2007 8:45 pm

seebartrun: you need to create a new forum post to discuss your problem...it doesn't have anything to do with the problem being discussed in this thread.

Wizard Joined: 17 Jun 2006 Posts: 1201