Ok, I'll throw in my two cents too. First off, Python can be linked in much the same way as Lua, instead of via Windows scripting, and it also has a wxwidgets version, so its more or less an interface issue with how/if you can duplicate some of the table tricks that are so handy when using Lua. If that can be overcome, then that is at least one added language that can be supported in a new design. Of course, what would really be nice is a "basic" clone that was wxwidgets capable, but... lol
MXP support - keep it. Mind you, I wouldn't mind having Zugg *at least* make a change to the implementation, such that you could do something like:
Can do MXP?
Will do MXP.
Supports strict?
Will do strict.
Where "strict" means the client acts like Mushclient does. So, no response would mean the behavior that Zugg's client has. There may be situations where having fallthrough is nicer than having to trap errors, but its a matter of taste, and it would lend itself to backward compatibility, with all the bloody muds in the prior MXP version that don't work right (since the default would be "fall through").
But in general, MXP is used by enough people that removing it isn't imho a good idea, especially when several of the recent posts on the TMS forums about clients have all been along the lines of, "What can we add to clients to help bring in more people?", not, "What should we remove from them?"
I happen to like the XML system. It means that other things can parse it, if needed. The only real problem we have right now is that if we are trying to hand code, nothing that exists *supports* the exact syntax of the functions for Mushclient (and adding that isn't entirely trivial in most of them), the internal editor is a control that doesn't work right (since its based on something that went out of useful application in Win 3.1, when 64k limits made sense, not that they did then either really), and there is no GUI system to edit things the same way as the ones in the main world. The later issue being imho, the biggest pain.
If we wanted to rework that, one might consider making the script in a parallel window to the triggers, etc. So that when you select a trigger, timer, etc. to edit it would also move to the "script" function called by that element, or show the code in its send field, if its not in the main script space. Cramming the whole mess into a single file, all of it script, just makes things worse for the casual user imho, and one of the things you are trying to do, by fixing some of the screwy function calls we have collected as things grew, is to make things simpler, not harder. ;)
Not sure how we deal with COM though. One of the biggest fracking pains in the rear using Firefox on Windows is its *lack* of COM support, which means most stuff won't work, and what does work only barely works, if it involves *using* anything that is based on COM. I have to open an IE tab 90% of the time to watch video clips in it, because 100% of all methods it has to handle running players fail too often to rely on it. One solution would be to support MONO, but that gets you into .NET, which means it might not run at all on machines earlier than 98, and I am not sure how/if it solved the problem of trying to use COM objects under Windows, where you *may* have situations where you want to talk to, and have talk back from, Windows applications that use COM to do that.
Also.. Some plugins *can't* be running solely in Mushclient, so some stable and straight forward means to get the plugin to talk to an external is needed. UDP and other solutions we use right now are neither straight forward, nor imho, entirely stable. Why do we need to do that? Because, not everything can run as a suspendable process, or as something that interrupts the client until it finishes. We sometimes **need** parallel execution, and short of creating a client script space that has restrictions on operation (like not being able to directly send anything to a mud itself), which can thus run in a separate thread, its just not possible to do some things using plugins, especially if it involves sockets and internet traffic, where delays may be in seconds, and responses can't be *held* until something checks for them.
I have to say, I agree with about half of your suggestions, mostly. The rest... I think is trying to fix issues by removing things that are complicated, rather than actually improving things by figuring out why they haven't worked right. The likely result is probably not a client I would use.
Oh, and one slight gripe. Mushclient uses Windows scripting, not WSH. The distinction might not seem like a big one, but WSH is a stand alone implementation, which includes several io functions not allowed in the embeddable version, and native event support, which is also not *natively* supported in the embedded version of any of their scripts. You can think of it as WSH-lite, or WSH-brain-dead. Much like other MS products, which work in one context, which 10% of the users actually find useful, but won't in the context that the other 90% are going to try it in. lol |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2 3
4
5
6
7
8
9
10
11
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top