Zugg Software :: View topic

Novice Joined: 08 Feb 2007 Posts: 45

I was wondering, since I currently have severe problems with my package on CMUD v1.29, would it be possible to have older (public) versions of CMUD available for download?

Beginner Joined: 10 Jan 2004 Posts: 28

look in your temp directory ,there are old installation packages.

Posted: Mon Apr 23, 2007 2:24 pm

Alternatively, if you're like me, you may delete your temp directory on a daily basis. Zugg posted this link:

http://www.zuggsoft.com/files/cmud124.exe

for v1.24. It's still active, so you can download it from there.

Or, if you want, you can even change it so the last part reads cmud126.exe instead of cmud124.exe ... that'll give you 1.26. :P

Charneus

Posted: Mon Apr 23, 2007 4:51 pm

And actually, I'd much rather figure out how to fix your problems with v1.29. I'm not getting very many reports of "severe problems", and going back to v1.24 could just end up corrupting your package even more.

So perhaps you can post what specific problems you are having, and send me your package file. If you have already posted the problems, let me know what thread they are posted in.

As Charneus mentioned, you can always get some older versions via the manual URL that he gave, but if we don't fix your problems now, then it's not likely that you'll be able to use any future version, and that pretty much defeats the whole purpose of using CMUD.

Novice Joined: 08 Feb 2007 Posts: 45

The problems I am having are somewhat described in the threads:

[1.29] *Urgent* Current scripts are broken and reformat does not fix them.

This is a thread started by Arminas who had a look at my package.

However, I have a hard time describing what is wrong (hence the rather chaotic posts)

It started with aliases and triggers not being known on command line level. At some point I was unable to create new settings using the command line - later I was unable to create any using the settings editor (save button wasnt responding). The problems seemed to change every day, due to my fiddling around with copy/paste, recreating, reloading, what not I all tried to fix it. Sometimes everything worked fine, then next time I opened my session something else would be behaving strangely.

After Arminas told me my package was badly corrupted, I restarted from a new session, using a backup package from beginning of april. The problem disappeared, but now none of the macros are working, not even the directional numpad keys.

I know it would be best if you could detect what is wrong and fix it - but I prefer spending my free time playing my MUD instead of cursing on my settings, that is why I was considering going back to version 1.26 where i never had this kind of weird problems.

Posted: Mon Apr 23, 2007 5:35 pm

Is the 070419_FAZwartje.zup file that you sent me the one that shows all of these problems, or does it only have the command line alias problem?

It would be good if you could give me a list of the exact commands that you are using on your command line that do not work. But I'll try the macros in that package to see if they have any problem and will post here to let you know what I find.

Novice Joined: 08 Feb 2007 Posts: 45

The package you mention did not have the macro problems, only the command line aliases - I think (sorry, have been trying so many things lately) that in the 070419_FAZwartje the problems were mainly located in the enlist classes.

The package which now has issues with the macro keys was a backupped pkg file - I just sent it to you (BISZwartje.pkg)
And in that package there is no macro key working at all: so try F12 or alt-L or ctrl-1 or ... You can find most of the macro's together in class 'Macrokeys'
Also the numpad sends just numbers, no directions.

I really really hope you can reproduce it now, cause frankly this is giving me grey hair

Posted: Mon Apr 23, 2007 8:00 pm

OK, I found the problem. And it's pretty serious.

It seems that when you have another module or window in your package, the routine that checks for a macro key doesn't look in the proper default class when searching for a macro. The default class was set to your "autocuring" module, and pressing a key from the main session window wasn't resetting this to look in the main session window, so it was only looking for the macro in the "autocuring" module, which it couldn't find.

This is definitely a bug. It was supposed to be looking in the window that the keypress occured in for macro searching. So this might effect anyone that has more than one window or module in their package.

I couldn't reproduce any problem with the command line aliases after fixing this, so it might have been related. But I also couldn't find any "enlist" class in this package. I'll see if I can get some other things fixed and get another version released today or tomorrow. Thanks for sending the file.

Novice Joined: 08 Feb 2007 Posts: 45

great!

So, for now I could change the default class using #class to fix it?

The enlist class was not in the last pkg file i sent you, but in the 070419_FAZwartje.pkg that I sent you earlier - when i feel brave enough I might reload that pkg and see what happens.

Thanks anyways

Novice Joined: 08 Feb 2007 Posts: 45

hmm, making a window or module default isnt so easy as using #class it seems.

I did get back the use of my numpad by enabling the english directions/numpad also in the autocure module - but the custom macro keys i didnt manage

Anybody can tell me how to make a module/window the default?

Posted: Mon Apr 23, 2007 11:17 pm

Nope, using #class won't fix it. You'll need to wait for the update...I can't think of any workaround for this corruption.