upgrade problem

After a few months away from mudding, I've recently returned and upgraded from v3.34 to 3.42

I can't figure why, but when I attack a mob and then use an alias to cast a spell (ie: fw), I see the result of the alias in the main output window in full (ie: cast 'firewind') but then it starts to repeat the alias a few times until MC freezes altogether.

Any idea what's going on here? Is there some sort of auto-repeat I'm not aware of?


---later---


damn. uninstalled the new ver & reinstalled the old vers and have the same problem.. seems that new ver rewrote part of my world files???

Even when I do a simple action such as a casting aegis on myself.. I have a trigger that sees "You are surrounded by a radiant light." as a result of casting egis and then grouptells that my aegis is on.. and then starts to repeat it until MC freezes.. everything seems to be looping.. anyone know wtf is happening - this is the vers that was working fine before..

When I opened my world file there were a HUGE amount of XML import warnings as well...

Here's something else.
When I cast aegis the trigger sends a grouptell to the world and also calls a script which resets a timer.. This starts it repeating and freezes.

When the aegis falls another trigger sends a grouptell and that is fine.. So it appears to be something to do with trying to send to world as well as call a script on the same trigger..

But that doesn't explain why a basic alias was repeating as well.

Maybe something in the global settings? but what????? HELP I don't want to rewrite a script that took many months to develop... *sneef*


---later---


damn.. even a simple alias such as 'stab *' which sends 'backstab %1' is freezing everything up.. it appears to effectively send a carriage return (enter key) 3 times, then sends what it should send twice (or more) but freezes MC at that point.. Nick where are you?

hmm.. might be the rescue script which attempts to repeats the previous command if a rescue fails, but that doesn't explain the aegis up repeating.. damn it I give up I'm going to play some golf.

It's probably a script acting up, try tracing ("Game > Trace") to see which triggers match what.

Hmm - import warnings. Perhaps pasting a couple of them?

There should be no "auto repeat" of commands - I never heard of such a thing.

Email me the world file if you like, I'll try to work out what is going on.

The script is huge - hundred of aliases, hundreds of triggers and a large vbs file.. I wouldn't put you through the torture of trying to go through it all Nick hehe, but thanks :)

I'm rebuilding from scratch; it's about time I did that anyway - some of the routines were written a long time ago and have superfluous functions or just have twice as much coding as they need to have.

Import warnings were huge when I first opened the world, (many of them related to colours btw) but it's not giving those warnings anymore, it was only the first time I opened the world file with the new client ver.

The autorepeat type thing might be a small rescue script I had when tanking for a group which rescues when someone else is hit and repeats three times if rescue fails using the previous command sent.. it's possibly that anyway. I'll post again if I continue to have problems after the rebuild. Wish me luck :)

As someone else who has a huge script and supporting aliases, I thought I might offer some advice:

Use Plugins as much as possible.

Personally, I feel a "World" file should actually be used as a "Character" file. That is, only script and aliases/triggers, etc that are unique to your character should be in the main file. Put everything else you possibly can into plugins. That way, if you want to play alts, it's much simpler to share script.

Naturally, try and assemble your script projects into individual plugins. For example, I put all my speedwalks in one plugin, my monitoring scripts in another plugin, my EQ handling scripts in another plugin, etc.

Thanks Magnum and I'll look at doing that. For now I'm just getting it running correctly on my main char all on a single world file with associated vb script. Once I've tested it for a few days and am satisfied it doesn't spin out on me, I'll start working on integrating it with my other chars as you suggested... especially when I'm going to have to rewrite the others anyway :)

Further to this thread, I haven't (yet) used plugins at all until now. I plan to do as you suggested Magnum and have separate world files for each character (as I do atm anyway) but then set up plugins for all the aliases/triggers/timers/scripts/ that are common to all the characters. This will make it a whole lot easier for adding new things to the plugin as well that will be common to all my characters.

Before I go ahead I just want to check something about variables though. Many of the variables I have are char-based, so if I have triggers/aliases etc in a plugin that set variables, will the variables save to the world file or the plugin file? Obviously I don't want them to save to the plugin file as the vars will be different for each char...

I plan to use the plugin wizard just to pull everything from my existing world file(s) that are common to each world (character) if you need to know that.

Also can the plugin wizard be used to edit existing plugin content or only to create new ones?

thanks.

..and yes, I've RTFM but still need to clarify these points :) "Plugins can also save their 'state' (ie. remember variables) so that variables that are set in one session will be remembered in another. This happens on a per-plugin, per-world basis." ..same plugin, different world.. where do they save to?


btw Nick, on page http://www.gammon.com.au/mushclient/plugins/
the url for Magnum's plugins is
http://www.magma.ca/~magnumsw/MUDs/Index.htm
:)

The state files and variables are local to the plugin, to avoid collisions. Surprisingly this technicallity hasn't come up.. Note that you can probably do something like:

dim wnm
wnm = worldname
dim tworld
set tworld = getworld(wnm)

then use tworld.setvariable and getvariable for character specific stuff. ;) The other would be to get the world name and use that to open a database or even just import and export a text file with the stuff you need to save in it.

Neither. (Read Below)
As far as I know, it's only really practical for making new plugins. I tend to use a text editor and do it all manually to make sure it's done neatly as I prefer it to be.
This is the answer to your previous question. The data gets stored in a third, "state" file.

Where-ever the default path for your plugins is, a subdirectory called "state" will exist in that directory. The "state" directory is where transient plugin data is stored:

Since each of your characters uses their own "World" file, they will also each have their own "state" file for each plugin. IE: You will have several files where the first ID varies, but the second ID is the same (One plugin being used by several characters)

Note: A plugin will only create a state file if the save_state="y" option is set within the plugin.

You can change the default directory for plugins from the "File" pulldown, Global Preferences, Worlds [tab].
Argh. I recently switched ISP's as I moved up to DSL from Dialup. My new ISP hosting system is CASE sensitive in regards to file names. (I find that rather annoying - "Index.htm" and "index.htm" can co-exist). Not only is the subdirectory name partially caps ("MUDs"), the index file also is capitalized ("Index.htm").

I think this is something for me to fix, not Nick. He can leave my URL the way it is. I've been wanting to update my whole site, and even just the muds page itself. I'll try and get off my lazy ass and do that very soon. I'll have to make sure I stick to all lowercase file names to avoid confusion.

ahh ok thanks, now I understand :)

One more question. If one of the aliases (for example) in a plugin calls a variable (using @variablename), does it matter where the variable it calls is located? (ie: will it matter if the variable is in the world file rather than the state file)..

"My new ISP hosting system is CASE sensitive in regards to file names"
Hell yes that could really get annoying. I guess they don't give you the option to switch off case-sensitivity.

Thanks again! :)

Hmm never mind. It seems a variable needs to be within the plugin file to be able to be called by that plugin file. Since something like @target would be called by several of what I would have as separate plugins, this really is becoming more work than it was just keeping everything in the one worldfile (for each character) for me unfortunately. Duplicating the same alias & vars etc in each plugin (or writing a bunch of additional code to pull it from the worldfile instead if that's even possible) is for me defeating the purpose of using the plugin in the first place. Thanks for the help anyway.

The variable in the alias/trigger is local to the plugin, because you never know what other plugin authors are likely to be doing, and you could have multiple "target" variables for instance.

You could always use CallPlugin to notify a plugin that a variable has changed, and GetPluginVariable to find the value of a global variable.

"The variable in the alias/trigger is local to the plugin, because you never know what other plugin authors are likely to be doing, and you could have multiple "target" variables for instance."

Very true, thanks.