Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ Calendar
Calendar

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Linda   Sweden  (164 posts)  Bio
Date Wed 13 Nov 2002 10:34 PM (UTC)
Message
As someone with admin/staff duties on a couple of MU*s, I was thinking that a calendar (ideally with some ability to automatically call attention to due dates) might be a useful addition to MUSHclient.

It could be either on a per-world basis, or just a general calendar for all of MUSHclient. Perhaps something that can optionally be displayed as you open MUSHclient, and/or at set intervals/times during the day?

I think this would be one enhancement that could make MUSHclient an even more useful tool for MU* admin/staff.
Top
Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #1 on Wed 13 Nov 2002 11:01 PM (UTC)
Message
I am trying to avoid adding extra non-core features, especially things like that which can be easily added as COM objects. You could probably find a calendar control that could be easily instantiated in a script.

Alternatively, someone could use the database example I did a few days back and make some sort of calendar system (with data in the database).

I don't want to bloat MUSHclient by directly adding that sort of thing into it, especially now plugins let you do that sort of thing easily, so that others can install them with a single click.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #2 on Wed 13 Nov 2002 11:21 PM (UTC)

Amended on Wed 13 Nov 2002 11:50 PM (UTC) by Linda

Message
I understand that reluctance, although it does leave those of us who are utterly scripting-clueless a bit out of it (what a COM object is, or how one could be included, I have no idea, for example), or rather, at the mercy of the coders. ;)

I guess that's no different from being at the mercy of you in regards to whether a new feature will be implemented or not, but it does feel a little like MUSHclient is turning into a bit of an 'advanced' client in the sense that there isn't much new for those who can't code.

Many (most?) of the plugins/scripts which are being done also also seem to focus primarily on MUD features. Natural, perhaps, but it may lead to MUSHers feeling a bit 'left out'. I also think that some things, perhaps not necessarily a calendar but something like the frequently suggested separate window for chat messages, are better off as features of the client than plugins.

After all, if someone compares feature lists for two clients, the average (non-coder) user will in general consider only the built-in features. There was a brief dicussion about this a while back on some MUSH message board, and the general consensus seemed to be that few MUSHers were attracted to the scripting/plugin capacities, and in comparing MUSHclient and SimpleMU mentioned among other things the lack of a separate chat window.

So, in short I think that the average user in general doesn't see plugins/scripting as a great asset, especially not compared to built-in features. I do agree that adding more features that slows the client down or makes it use much more memory isn't a good idea if those features are just frills, but some of them may be considered as something every client should have. And then I do think they should be built-in.

(edited to add a bit more of an explanation)
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #3 on Thu 14 Nov 2002 02:14 AM (UTC)
Message
And one more comment. ;)

As far as the 'separate window for chat/page messages' suggestion goes, I think it is a clear-cut case of where the existing option simply isn't enough. I may misunderstand how it works (if so, someone please correct me), but as far as I understand the current option of pulling chat/page messages into a notepad window means the following:

a) The window isn't easily accessible from the world list toolbar. You need to use the menu option or, which I personally never use for any navigation, a key combination. This, for me, means the option isn't any use as it will simply hide the messages away and make me forget about them.

b) You cannot type your reply in the same window where you see the messages.

For me personally, a useful implementation of this feature would look something like this:

For each world where it is enabled, a tab bar is added somewhere (perhaps on top of the output window). This tab bar allows switching between several output windows for one and the same world, for example one 'regular' window, one with all chat messages and one with all pages. The input window could be the same or separate (if separate for each sub-window, it would allow you to more easily start typing up a page message for someone while still talking over a channel in the other window).
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #4 on Thu 14 Nov 2002 02:41 PM (UTC)
Message
Regarding the target audience of scripts & plugins, It seems to me, that other than Nick, it's basically the audience themselves doing the writing.

Right now, there aren't a lot of programmers active in the forums. Perhaps 10, being generous (people with at least mediocre skills). This community is still in it's infancy. Frankly, if you aren't capable yourself, you'll have to wait for someone else who has an interest in writing Admin related plugins, etc. Nick is quite generous with his time, and may offer to program certain projects... but I imagine he already must have plenty on his plate.

It seems wise to me, that he spend his time creating MUSHclient tools that can be utilized further by creative programmers. With those tools, we can build the functionality we want. We can bloat our clients the way we see fit. :)

There is already a tremendous amount of programming power available under the hood of MUSHclient, through scripting. Yes, I agree, we the users could use just a few more, and I think you touched on one tool that is frequently requested. From my own viewpoint:

A programming tool that would allow interactive use of "child" windows to a world environment. These windows could be programmed in assorted sizes, and declared "always on top" when MUSHclient is active. The windows could present graphics and clickable "buttons", etc. As you stipulate, there should be an index toolbar that allows the user to select a child window, making it active.

With such a tool, projects such as the one you suggest could be programmed by users. Also things like icons that change according to mud events, and could be clicked to perform mud actions. (Health icons, spellcasting icons, etc.)

Such an endevour would likely be complex to write for the average programmer, yet still feasible. Some of these projects are already possible, but require workarounds that are so complex that nobody has taken on the task. Also, the nature of the workarounds means they can't function specifically in the manner we would like them to.

Getting back to your request... I think it would be currently possible to create a 'dummy' world for the purpose of displaying specified chat lines. The dummy world and the main world would communicate in the background, transfering the content back and forth. You could click the world toolbar to activate the window of your choice, and it already changes colour when there has been activity. Also, as Nick mentioned, a calender of sorts could be programmed using the current tools.

Regarding you comment about the attractiveness of a client based on it's feature set:

My reasons for using this client are specifically that it's fast (not bloated), and that it's vastly customizable, particularly through scripting. It is the strong feature of this client, that no other client comes close to matching. As trite as this sounds, if it's features you want, then investigate using zMUD. Yes, it's slow. Yes, it's buggy. It's the price you pay.

In an ideal world, every MU* would have at least a couple of people well skilled in programming MUSHclient plugins. Those people would write plugins specific to that environment, which the rest of the population could use at their leisure. It's the sensible way to go, since all MU* vary in their functionality anyway.
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #5 on Thu 14 Nov 2002 04:30 PM (UTC)
Message
I think our differences in opinion was summed up quite well by your reasons for using MUSHclient. :)

Yes, I like a fast client too. But, extensible via scripting doesn't matter one bit to me since I can't do any of it myself. So, that is not a feature that makes me pick MUSHclient over another client.

In fact, if I wasn't so used to MUSHclient, I am not so sure I would have picked it over SimpleMU (which has, for example, the chat window option and some interesting mailing options as well) today, because it seems that most of the recent advances made in MUSHclient have been entirely within an area (scripting) which doesn't matter to me and that these advances have been made instead of additional built-in features.

I don't personally know a single person on any of the MUSHes I play that utilizes MUSHclients scripting abilities, and when clients come up in public discussions, no one (or very few people, anyhow) claims to find scripting a good reason to pick MUSHclient over SimpleMU.

Now, as the developer, Nick can obviously choose to take his client in whichever direction he wants. But, as a longtime user who has always recommended (and still do so) MUSHclient, I just felt it was worth nothing that as far as I can see, MUSHers are seeing MUSHclient as a less and less interesting choice for client because the trend seems to be to put less and less functionality into the client and instead put it on the users to create what they need.

And while that approach makes sense for more obscure/MU* specific features, I don't think it makes sense for something like the separate chat/page window, because I see enough people saying that 'if it wasn't for the lack of that, I might consider MUSHclient over SimpleMU'.

Finally, I suppose I should note that I obviously think it s great that the scripting capabilities are there for those who can do great stuff with it. But I don't like the idea that its presence makes new built-in, standardized features that everyone can use more unlikely.
Top
Posted by Meerclar   USA  (733 posts)  Bio
Date Reply #6 on Thu 14 Nov 2002 05:39 PM (UTC)
Message
As an admin myself I feel kinda compelled to comment on this one..... As far as client choices go, MUSH is by far one of the best I've ever seen. Granted, there may be a few shortcomings for the "social butterflies" but as a poweruser app, its nigh untouchable. I use few to no plugins in my admin duties nor do I see a need for a calander application to be built into the client with the insane number of freeware/shareware options available. I will say the easy scalability via plugin is one of the attractive features of MUSH over more traditional clients like zMUD or a "chat conscious" design like Simple. In all honesty, I cant say I see a reasonable need to incorporate a calander directly into a mu* client when there are as many existing calendar programs readily available at little to no cost that can handle more functionality than a scaled down version ever would within a client.

That may just be me though.
Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #7 on Thu 14 Nov 2002 06:35 PM (UTC)
Message
Well, as I said earlier, a calendar (as opposed to the separate windows for chat/page messages feature) may indeed be one of those features that wouldn't be useful för enough people to merit its inclusion.

However, the same can be said for mxp/pueblo on MUSHes. In my experience, 9 out of 10 users never enable it, even when the MUSH supports it.

Personally, I felt a calendar would make sense because I have enough entered into my regular calendar/to-do program that I'd very much like to separate out the MUSH duties from my RL duties and have those easily accessible within the program i use for MUSHing. That, to me, makes as much sense as the built-in notepad: yes, you can use a standalone one, but having it within the client is handy.

Certainly, more people use the notepad than would use the calendar, but otherwise you can justify them in the same way.

Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #8 on Thu 14 Nov 2002 08:06 PM (UTC)

Amended on Thu 14 Nov 2002 08:09 PM (UTC) by Shadowfyr

Message
To throw in my two cents.. I think magnum is right. A built in 'window' class that can be customized is a must. Why? Because everything from you seperate chat window to the calendat can be implimented through a script, which could even be given away by the designer to Nick as one of the 'standard' plugins that come with the client. However, being able to impliment the code needed to support it and being able to diplay the results are two very different things. Because we can't display it, we can't code it. Imho an external COM program is not really an option, since it would require its own installer, some means to make sure it is actually loaded before trying to use it and a mess of other problems that don't exist with something built in. It wouldn't even need to be seperate windows for everything. Using a single window linked to the world you could use tabs to switch from the calender to the chat, etc. So the interface would be like:

Tab.Add "Calendar"
Window.Show

to display it. And a simple layout file for placing stuff like:
Box {
  Name = "Box1"
  Left 0
  Top 0
  Height 20
  Width 20
  Textfield = "1"
}
Box {
  Name = "Box2"
  ...
}

The plugin could update the calendar data fields, etc. without the window even showing by simply setting the Textfield values for each box. Same with handling pictures, input, etc.

Of course as Magnum also stated this could be complicated to do right. It could also add additional overhead to the program. However for functionality purposed, it either needs to be something that comes 'with' the client and is automatically loaded and linked to new worlds or is built into it. A third party, "But it was available last week", option that needs to be created seperately in the script each time it is used (and thus can't be tied to a specific world and 'all' its plugins) is not acceptable imho. And that is the key issue, making sure it does know who it belongs to so it doesn't make things worse instead of better.
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #9 on Thu 14 Nov 2002 08:29 PM (UTC)
Message
Admittedly, I didn't understand much of the previous post as far as the code suggestions went, however ... if chat windows/calendar/etc can be accomplished through scripting that is certainly preferable to not having it at all. So, to that extent I am for extending the scripting capacities.

But I am still concerned that some of these things will be harder to use and less intuitive when done through plugins. And while that may be acceptable for something like a calendar, I think spawned chat windows should be something easily accessible even for a newbie.

But I guess we won't know for sure what can and can't be done for a while. :)

Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #10 on Thu 14 Nov 2002 09:05 PM (UTC)

Amended on Thu 14 Nov 2002 11:23 PM (UTC) by Nick Gammon

Message
Hmm. Ok. To mke it more clear the idea would be this. You have a single window linked to the world that autoloads and a set of tabs like:

|-------------------------------------------------------|
||----------||------||-------------|                    |
|| Calendar || Chat || Other Stuff |                    |
||-----------------------------------------------------||
|| Fred tells you: Hi!                                 ||
|| You tell Fred: Hello!                               ||
||-----------------------------------------------------||
|| Send: tell Fred Havng a nice day?_                  ||
||-----------------------------------------------------||
|-------------------------------------------------------|


You could then window.show or window.hide for all things connected to that world file. The in the case above the
chat bit would be something like:

Chat.frm >
RichTextBox {
  Name = "Chat"
  ...
  Stretch = True
  Text = "[blue]Fred tells you: Hi!
[green]You tell Fred: Hello!"
}
InputBox {
  Name = "SendBox"
  ...
  Sendto = "world"
}


Or in other words you would tell the window to Window.Add "Chat.frm" and then by hiting enter when typing in the send box it
would automatically send the text to the mud, another option would be Sendto = "variable". To add a line grabbed from the
mud you would use Chat.AddLine wildcard(10) or the like. I am not sure how richtext does colorization in the text, so the above
example is a guess, but could be done with something like Chat.AddColourText "blue", "black", wildcard(10) and
Chat.AddColourLine "blue", "black", wildcard(10). This is equivalent to colourtell and colournote. ;)

The point is that it 'could' be done this way and any permanent info that you needed to keep track of stored into a database
or the like within the scripting, but without a window to display the form in... With such a thing, anything becomes possible
within the limits of what objects are supported and external apps become necessary only in cases where the code is too complex
for scripting to handle easilly.
Top
Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #11 on Thu 14 Nov 2002 09:11 PM (UTC)
Message
There are some pretty good points above, and I find myself agreeing with most of them. :)

First, Linda, I agree about the extra windows. This sort of things which isn't easily done in a plugin is the sort of core functionality that I would look at adding.

However one of the reasons a lot of work has gone into plugins recently, and the extra scripting features that can be used by those plugins, is to make the client extensible by lots of people, not just me. In fact this is starting to happen, with my trying to kick the process along by doing quite a few examples myself.

The idea of plugins, which seems to be working, is that rather than trying to teach people how to add new things by laboriously entering triggers, aliases, timers, and editing the script file, they just download a plugin, click on the plugin "add" button, and they are done!

For instance, the example script I did ages ago for a MUSH teleport I recently converted to a plugin, because someone was having trouble doing all the steps manually.

And, today, to demonstrate that I haven't forgotten MUSHes, I redid the "grab" feature that is so old I had to hunt for half-an-hour to find it. This is now in the plugins web page. Try it, and you'll see how easy it is to install. Using grab you can type, for instance:

grab me/describe

The alias "grab" sends the appropriate command to the MUSH, and a trigger awaits the result.

This only took 10 minutes to write once I had found the syntax of the @pemit command, and there must be a heap of similar ones that someone could do for MUSHes.

If you defined in a bit more length what you were hoping from the calendar, perhaps that could be a simple plugin too. :)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #12 on Thu 14 Nov 2002 09:37 PM (UTC)
Message
I'm glad to hear that the separate/spawnable windows (perhaps of a basic sort that can be further extended/mutated via scripting, as was suggested in this thread) is something you could consider adding on. I do think it would be appreciated by a lot of the users. :)

And I do understand the reasons for making the scripting/plugin capabilities as powerful as possible; I've simply been a little concerned of late that it will mean that things that once might have been added as new features won't be added, and then there aren't enough MUSHers into scripting to get them done as plugins. I may be wrong about that, but so far I haven't been able to interest any good MUSH coders in looking into making plugins. :)

As for the calendar ... well, what I had in mind was some kind of combined calender and to-do tool which would allow me to enter short notes about various events and tasks as well as a due date for each. And then ideally there would be a simple list of 'stuff due today' popping up when I open that particular world window. I suppose the list should also be manually retrievable, ideally both per day and in some kind of overview format for x amount of time.

Whether that is possible through a plugin I have no idea. It seems tricky. :)

Oh, yes, the grab plugin does look pretty handy. :)

Top
Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #13 on Thu 14 Nov 2002 10:12 PM (UTC)
Message
Linda, although I was reluctant to add a calendar into MUSHclient I think the general idea has great merit. In fact, I wrote such a system for myself a while ago, which runs here at home, using a database to store the events and a web browser to display them.

However, it has nothing to do with MUSHclient at this stage.

I could probably adapt the general design to work as a MUSHclient plugin. What I currently have is (amongst other things like names and addresses):


  • Fixed events (eg. lunch next Wednesday at 12)
  • Recurring events (eg. backup files every Saturday)
  • To do items - they stay on the list until they are done (eg. change light globe)


When you mention "that particular world" did you have in mind that events would be linked to a world, or did you want something more general that would apply no matter what world was open?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #14 on Thu 14 Nov 2002 10:30 PM (UTC)
Message
That kind of functionality sounds just like what I was thinking of. :)

I am not sure what would be best, actually, as far as whether each world should have its own calendar of events, or if it should be a global thing.

Either would do the job quite well, I think. :)
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

52,309 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home