Can't say I agree with your "don't need" list, and not just because I use a few of them or like how they currently work. Half the discussion of *new* clients, both hear and on TMS have been about *adding* features, not removing them, so when you start talking about how notepad isn't needed, or MXP isn't needed, or chat isn't needed, etc. you are seriously going the wrong way. Same with multiple open worlds. You do know that a **lot** of people that use these clients are admin right, and they often have 2-3, or even 4, worlds open at once, tied to different ports of the same mud, or even some to the main mud and others to a test server, etc.
Going the way of accelerators... Well, there are some benefits I guess, but right now, since doing that eliminates the ease of looking to see what they are set to via the macro list, they are a pain in the ass imho. Making them more so, by removing that list entirely, including for the keypad, which for most people is the *only* thing they are going to use at all, and which they are not going to be happy about having to script the settings for, is a bad idea imho. If one where to go that way, they *need* to be in a functional list that someone can edit without script, and they still need to contain "some" defaults, for some of the basic functions like the keypad commands.
Sort of agree with the event management, but only in the sense that such a system would, in theory, provide the means to also deal with object events from ActiveX (though that would "break" the ability to make it portable). The only problem being that its still going to require some fiddling to get it to work with the client as written, or a rewrite, so its supported properly from the start.
The careful here - Bad, bad, horrible idea. It takes extra time, even when using Lua, to execute script, instead of just handling normal output. Only allowing script therefor would tend to slow the client down. The only way you might do that is if you had triggers, etc. as part of the event system and required everything they did to fire a function in the script space, which would not have to thus be loaded, run, then unloaded every time. But, that would just make the learning curve higher *and* make those features less accessible. The only other alternative I could see would be to auto-create functions in the script space, containing the script you had in "send to", so its semi-permanent. This would mean that you would also have to automatically set the function to have parameters, which would have to match the number of wildcards in the original, so that something like:
if "%1" = "fred" then
send "say Hi Fred!"
end if
becomes something like:
function F1AF3(12342)
if 12342 = "fred" then
send "say Hi Fred!"
end if
end function
This obviously becomes a tad more complicated to do in cases where the %1 is intentionally left outside of quotes, so that its treated as a variable name, like counting the number of times you see Fred, by doing %1 = %1 + 1. How you would manage to project "that" into a semi-perm script space, so that you don't have the overhead from it I have no clue.
Point is, its not a good idea to do this, not without making changes that are possibly and even worse idea.
As for your list of improvements... The only one I think is a tossup is the simplifying of the script interface. This would a) break backward compatibility and b) make it even harder for someone to go from something like zMud or TinTin to this client, since half the stuff that is complicated involves things like CreateTrigger, which has two versions, but *still* requires you set some things indirectly, which is confusing to someone used to just typing in something like "#t blah". Heck, its confusing to me sometimes, and I am used to the client. A big chunk of the problem though arises from two factors. A) the original design is based on a limited library, which can't handle overloading and b) I am not sure Nick knows how to do that anyway. Strictly speaking, he is correct that you shouldn't change and interface "after" creation, but there are methods for overloading a function, which let you do something like:
fizbug(a) -> Calls original fizbug function.
fizbug(a, b) -> Calls fizbug 2.0 function.
fizbug(a, b, c, d) -> Calls fizbug 2.5 function.
The interface determines "which" one is called, based on the number of parameters. It can even tell the difference between a call that has a number, or a string, etc., and call a different internal function based on that. The whole, fizbug, fizbugEx, fizbugEx2 BS was a very early attempt to deal with this mess, and it caused huge problems for applications like databases, where the input needed to change, to handle new features, but where no one in their right mind wanted to have to recode billions of lines of programs that used it, just to use fizbugEx, instead of fizbug, just to get at that one feature.
But, as I said, there may be inherent limitations in MFC that prevent this kind of overloading, and result in us being stuck with the mess where you can't just tack on some more parameters, and have the function interface figure out "which" call to make. |
![[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