script error in plugins under /wine option

Posted by Cloud on Sun 17 Nov 2002 09:19 PM — 5 posts, 20,628 views.

Czech Republic #0
I very appreciate the /wine option, I can finaly switch freely between windows and linux and not fight with TinyFugue and build the triggers and aliases for each of the OS separately, but it still has one drawback:

Plugins fail to load due to script error under wine.

I decided to separate related groups of aliases and triggers into plugins for easier management and added few script routines when plugins first got in, and now I can't use them them without putting them back again into the world file.

I admit that many plugins are useless without scripts, but there are some useful and IMHO the usefulness should be decided by user who installs it. When the /wine disable scripting it should allow the plugin to load (maybe leave the warning message about failed to initialize the script engine and just do not consider it fatal error) - it may contain aliases/triggers that are useful without scripting.

I switch between both systems frequently so simple removing of the script part manualy is not the right option - it would loose the additional functionality under windows, and maintaining two versions of it also doesn't seem like good idea as they would quickly get out of sync.
Australia Forum Administrator #1
You can do that today. Just delete the script language line when creating the plugin (ie. highlight "VBscript" and hit the delete key). Then it will be saved "without a script language".

For plugins that already exist, edit the plugin file with Notepad or MUSHclient's editor, and delete the line:

language="VBscript"

Czech Republic #2
It seems I have exceptional talent to describe bugs so that you start replying to something else. Your suggestion disables the script completely and when I want to use it back under windows with the scripts enabled I need to edit the file again and re-add the script attribute.

The /wine option was said to disable scripting to enable running MUSHClient in linux. So I considered it natural part of it's functionality to also allow loading of plugins while ignoring their script parts.

Simple answer like "the plugins are written in a way that makes this impossible without completely rewriting the system" would suffice and I would just start searching for another way around - after all I managed to live without /wine completely and it is still great step forward as it is now (maybe I should have posted this one in suggestions, but I considered it to be more bug than a missing feature).

(One idea to go around it just came to me. I could probably put aliases in separate file and use include to put them into two different plugin shells, one with script and the other without, but I still think this would be nice to be able to do it directly within one file).
Australia Forum Administrator #3
Hey, I was about to suggest that. :)

Something like this inside the plugin:

<include name="blah.xml"/>

You could have two plugins, one with the script and one without, and include the bulk of it without the script.

My original reply assumed you had plugins that did not rely on scripts at all, but the idea of a plugin that had a script that wasn't really necessary was a bit of a novelty to me. ;)

I suppose the absence of a script could be a warning and not a failure but I assumed that if you put scripts into a plugin you would want them to run - wouldn't you?
Czech Republic #4
It looks like we understand eath other finaly :) As I said, I seem describe the bugs in a way that no one understands me the first time - I will try to be more specific next time.

If you want to know details, I have speedwalk aliases to different locations in a plugin and the script is onLoad function to push all their names into command history for easy Alt-Up completition.

Nice feature to have when possible, but definitely not something to worry about if not functional, I just have to type the names completely by hand.