[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  A Hide Trigger/Alias/Timer Option and Another group level

A Hide Trigger/Alias/Timer Option and Another group level

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


Pages: 1 2  3  

Posted by Karl_Newbie   USA  (23 posts)  [Biography] bio
Date Tue 01 Jun 2004 07:22 AM (UTC)

Amended on Tue 01 Jun 2004 07:25 AM (UTC) by Karl_Newbie

Message
I have multiple characters on my mud, not on at the same time but using the same world file. I know I could make multiple worlds with seperate .mca and .mct files. But
many aliases/triggers need to be shared between characters while others do not. And some aliases and triggers would outright conflict if they were enabled for one character but I am logged in with another. Plus I have some triggers and aliases that might be complex and time consuming to make but only used very, very infrequently.


This leads my trigger and alias setup menu to be extremely cluttered and confusing. I tried sorting some triggers that don't need the option of sequence to different values but bleh that's not a real solution.
I'm sure I could write a startup script that enables and disables the relevent and irrevelent triggers and aliases based on the character I log in with, but that doesn't really solve the clutter issue. (Okay I'm a moron, edited similiar but the wrong triggers and aliases too many times :D )

I use the 'group' option in triggers very frequently. Is there a way to assign a trigger to be included in more than one group? (without having to make a second trigger, trying to reduce clutter here :) )

And that second group name in my case would be character specific. Enabled many triggers in many differnt groups under this 2nd group name umbrella. For example in taxonomy, all groups of mammals and all groups of fish are still grouped in eukaryots. heehe. Eiither a hierarchy or just a second group name.

Second that group name could also be used to 'hide' unneeded triggers and aliases etc. world.hideTrigger, world.hideTriggerGROUP :D
It would be automatically disabled and out of sight (but would still save and load) on the setup menu. Of course there could be a show all option on the setup too.

Just my 2cents, thanks for reading.
[Go to top] top

Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #1 on Tue 01 Jun 2004 07:40 AM (UTC)

Amended on Tue 01 Jun 2004 07:44 AM (UTC) by Flannel

Message
The solution to your problem is plugins. You can take things out of worlds and into plugins easily with the plugin wizard. Make the plugins with triggers for multiple players in their own plugin, a core plugin, or leave them in the world. Then have a plugin for each character.

Actually, wait. Youre still using mca and mct? UPGRADE your mushclient to the XML version. Unless theres some pressing reason not to.

While talking about other solutions, Why exactly do you want only one world for the multiple characters? You can just open new worlds, and preload them from this existing one (it basically copies the world) then delete what isnt needed, etc.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top

Posted by Karl_Newbie   USA  (23 posts)  [Biography] bio
Date Reply #2 on Tue 01 Jun 2004 09:47 AM (UTC)
Message
"Actually, wait. Youre still using mca and mct? UPGRADE your mushclient to the XML version. Unless theres some pressing reason not to."

I am using 3.49. I always save the world as .mcl but I thought the triggers and aliases were saved in the .mct and .mca?
Thats the only option I see here.


"
While talking about other solutions, Why exactly do you want only one world for the multiple characters? You can just open new worlds, and preload them from this existing one (it basically copies the world) then delete what isnt needed, etc."

I understand how to open new worlds, that how I started off from the original character. But I don't want multiple worlds because if I make a new trigger or alias that I want for all the characters, how do I export it easily into the other character's worlds?


I'll take a look at the plugin option. I've only used the .xml files such as chat and calender, never the wizard thanks.
[Go to top] top

Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #3 on Tue 01 Jun 2004 07:23 PM (UTC)
Message
No, we dont use mct or mca anymore. Its all stored in your world file, in XML format. Technically you could include the things you want, directly into the worlds, but plugins would probably be more modular for you with a world file that shares everything.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top

Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #4 on Tue 01 Jun 2004 08:37 PM (UTC)
Message
What I do is make a file with all the triggers/aliases/whatever, for example one for the thief characters, one for the cleric characters, etc, and include each one in the world file. That way, when I change a trigger in the world file, it is changed in all the relevant worlds. Is that what you want to do?

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top

Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Tue 01 Jun 2004 09:29 PM (UTC)
Message
Quote:

I am using 3.49. I always save the world as .mcl but I thought the triggers and aliases were saved in the .mct and .mca?
Thats the only option I see here.


The .mct and .mca files are not *primarily* used to save your triggers and aliases, they are part of your world file. They were originally intended to allow you to export (say) your triggers from one world and import them into another.

However nowadays a simpler way is to simply highlight the ones you want, click the "copy" button, and then go to the other world and click the "paste" button. That copies them via the clipboard.

However as the other posters here have said, plugins are far simpler for this purpose. You can use the plugin wizard to select a batch of triggers, aliases etc. (you can sort by group during this process) and then generate a plugin from them. It is just point-and-click unless you have scripting as well.

Then that plugin can be used in other worlds. In fact by making it a "global plugin", things that you always want can be automatically available in all worlds.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Reply #6 on Tue 01 Jun 2004 10:46 PM (UTC)
Message
In the early days of plugins, I had an Email discussion with Nick, which I ended up posting to the forums. In it, I discuss my philosophy that World files aren't really World files, but rather, Player files. (Or at least, it's best to think of them that way).

Optimally, one would do best to put 'stuff' that is appropriate only for a single character into one "World" file [per player]. Any other 'stuff' that could possibly be shared amongst different players, you put that stuff into Plugin files. The others here have already said that.

Anyway, here's the link to me saying it first, a long time ago. Heh. ;)

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=1607&page=999999

'stuff' = Timers, Triggers, Aliases, Script.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top

Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #7 on Wed 02 Jun 2004 12:54 AM (UTC)
Message
Magnum wrote (a long time ago):
Quote:
The biggest challenge to all of that is the interdependency between the plugins. All of those proposed plugins require certain levels of interdependency on the others. The "monitor" calls the "Spellqueue" when my health drops too low, the "Autobots" only function when they are toggled on, and depend on "Monitor" data, and issue calls to the "SpellQueue", etc. Given the stickiness of making cross-plugin calls, this could require some interesting and
innovative subroutines. Also, because of that interdependency, I pretty much need all 3 to in production at the same time, else I go without a lot of functionality while I develop the next one. It's enough to make me want to just keep them all in the current state they are in... but again, it's not practical if I want to develop ALT characters.


Heh, since we are having flashbacks... I'll bring up another thing in this connection - the EventManager plugin. Here's a snippet from one of my EventManager instances, which allows a plugin to report a certain value changing to any other plugins (IDs - since the world can be called also) and point those other plugins in the direction of that value, so they can use world.GetPluginVariable() on it.


'Register a new event
RegisterEvent "OnVariableChanged"

'Register a plugin to listen for the event, supplying the plugin's ID and the event's name.
'The listening plugin must have a sub with the same name as an event it is listening to and
'this sub must accept exactly 1 argument, otherwise the event will cause an error
RegisterListener "9ba81f81508fb8a03adac921", "OnVariableChanged"


The plugin being called is responsible for knowing how to handle the offered value, and therefore should only retrieve the contents of variables whos names it is familiar with. The event includes the caller's ID and a variable name as a '_' delimited list.

Since all the EventManager needs to know in order to keep the whole setup running are IDs, you can even go so far as to create multiple "instances" for the same IDs, by assinging different names to plugins but keeping their IDs, each slightly modifying the ID's behaviour. If you plan it right, you could even make a plugin to switch alts on the fly by switching ID implementations with a single alias, though that would require that your world file contains ONLY stuff that is 100% guaranteed to be used by all your alts unmodified, meaning - practically nothing, which is about as much as mine does nowadays ;)
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #8 on Wed 02 Jun 2004 02:26 AM (UTC)
Message
Hmm. I don't remember the specific post, but a method using alises within plugins made this more or less redundant. In most cases things like a change to a variable are handled by the function/application in which the change happens. The suggested solution is for you to add something like this to any plugin that needs to be informed of the activities of anther plugin:

<aliases>
  <alias
   script="HandleEvents"
   match="PluginEvent * *"
   enabled="y"
   omit_from_command_history="y"
   omit_from_log="y"
   omit_from_output="y"
   ignore_case="y"
   keep_evaluating="y"
   sequence="1"
  >
  </alias>
</aliases>

sub HandleEvents(aname, output, wilds)
  Firedfrom = wilds(1)
  if instr(wilds(2),"Partlist") = 1 then
    Params = split(wilds(2),",")
    ...
  end if
  ...
end sub

Then in the sub that fires an event, for instance:

world.execute "PluginEvent" & GetPluginID & "Partlist,Left arm,Right arm,Left leg"

It is up to the plugin designer to figure out what information needs to be sent, how it is sent, how the plugins that recieves it deal with the information, etc., but you are not limited in the same way as CallPlugin for handling the information. You could even make the handler optionally look for multiple wildcards, instead of just two, so each piece of information arrives seperately, no need to split it. It will simply ignore events that don't match that pattern.

In any case, this trick kind of makes a seperate event handler useless. The only real reason for such a handler would be to capture events from programs called from the script, a capability that MS bent over backwards to prevent you from doing from inside of a script. I haven't found a solution to that one yet, short of the lame method of creating another program/dll to sit in between, that 'can' respond and talk to Mushclient. This is really lame in cases like WinAmp, where such a middleman becomes just one more thing that can fail in a process. A process that starts with Mushclient talking to a script, which would talk to your middleman, which talks to a middleman designed to talk to WinAmp, then finally WinAmp itself. lol Heh.. I've got an idea... Lets stick a 6th or 7th application into the works and see if we can crash things even faster. ;)

But seriously, an event manager for external apps would be nice, but you can build one for plugins that is very easy, if not necessarilly standard for every person designing one.
[Go to top] top

Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #9 on Wed 02 Jun 2004 03:07 AM (UTC)
Message
We are actually talking about the same thing, which is this:


<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE muclient >

<muclient>
   <plugin name="EventManager1" author="Keldar" language="vbscript" purpose="Managing custom script events"
     save_state="y" date_written="2004-03-11" requires="3.32" version="1.0" id="fc8161da9a2a5d7f56a03600">
 </plugin>

<aliases>
<alias
	name="register_listener"
	match="fc8161da9a2a5d7f56a03600 reg_listener */*"
	enabled="y"
	sequence="0"
	send_to="12"
><send>call RegisterListener(&quot;%1&quot;, &quot;%2&quot;)</send></alias>
<alias
	name="register_event"
	match="fc8161da9a2a5d7f56a03600 reg_event *"
	enabled="y"
	sequence="0"
	send_to="12"
><send>call RegisterEvent(&quot;%1&quot;)</send></alias>
<alias
	name="dispatch_event"
	match="^fc8161da9a2a5d7f56a03600 dispatch_event (.*?)/(.*?)$"
	enabled="y"
	regexp="y"
	sequence="0"
	send_to="12"
><send>call DispatchEvent(&quot;%1&quot;, &quot;%2&quot;)</send></alias>
</aliases>

<script> 
<![CDATA[
option explicit
dim evt_list
set evt_list = CreateObject("Scripting.Dictionary")


'Register a new event
'RegisterEvent "OnPrompt"


'Register a plugin to listen for the event, supplying the plugin's ID and the event's name.
'The listening plugin must have a sub with the same name as an event it is listening to and
'this sub must accept exactly 1 argument, otherwise the event will cause an error
'RegisterListener "9ba81f81508fb8a03adac921", "OnPrompt"

sub RegisterListener (id, evt)
	dim listeners, new_listeners
	if evt_list.Exists(evt) then
		listeners = evt_list.Item(evt)
		if ubound(listeners) > 0 then
			new_listeners = join(listeners, "_")
			new_listeners = new_listeners + "_" + id
			evt_list.Item(evt) = split(new_listeners, "_")
		else
			new_listeners = id
		end if
		evt_list.Item(evt) = split(new_listeners, "_")
	else
		world.Colournote "red", "white", "EventManager plugin: " & evt & " event not registered"
	end if
end sub

sub RegisterEvent(evt_name)
	dim listeners(0)
	if evt_list.Exists(evt_name) then
		exit sub
	end if
	evt_list.Add evt_name, listeners
end sub

sub DispatchEvent(evt, args)
	dim listeners, listener
	if evt_list.Exists(evt) then
		listeners = evt_list.Item(evt)
		for each listener in listeners
			world.Execute listener & ":" & evt & " " & args
		next
	else
		world.Colournote "red", "white", "EventManager plugin: " & evt & " event not registered"
	end if
end sub

]]>        
</script>
</muclient>


I think that the handler is needed for 2 reasons:

1) it provides a central spot for declaring both events and listeners associated with them, thus letting you see the entire infrastructure at a glance;

2) it ensures that the events stay as generic as possible - it's really simple to get carried away with calling between plugins and end up in the same situation of not knowing which plugins need each other to work, and event handler introduces a middle layer that mediates between the plugins and hides them from each other, keeping them independent at least at the most basic level.

There's no need to mess with 3 plugins that depend on some other plugin, just because that latter plugin needs to be changed - you can just change the plugin and replace the old version when done, since EventManager enforces a protocol for firing and capturing events that you can't go around without rendering your plugin incompatible with the rest of the system. And passing IDs in event arguments is also essential, since it ensures that no plugin needs to know about any other installed plugins and at the same time can expose itself for whoever would be interested in noticing it, as in the example from the previous post, where a plugin notifies any listeners about one of its variables changing, while listeners don't have a clue about that plugin's existance and don't care if it suddenly disappears and is replaced by something completely different, even with a different ID, as long as it exposes a variable with the expected name.
[Go to top] top

Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Reply #10 on Wed 02 Jun 2004 04:58 AM (UTC)
Message
Hmm. What I've actually done is simply duplicate the information tracking in each plugin, generally with the exact same triggers & script within two or more plugins. Although this may not seem efficient, it is more user friendly, since other people using your plugin(s) don't need to worry about interdependency. I don't do this often anyway. Generally, just the health\mana tracking.

Now, I still may have one plugin make a call to another plugin's routine, but for that I simply use "CallPlugin". If the target plugin is not installed, then the call silently fails, and it's no biggie for the user. I guess that's because of the nature of my plugins.

One example of this, is my "Statline" plugin. Almost all of my other plugins will make a call to my "Statline" plugin to display information on the status line. However, if "Statline" isn't installed, then I guess the user doesn't care for that feature. No catastrophic failures, which is nice. :)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #11 on Thu 03 Jun 2004 12:35 AM (UTC)
Message
Well Ked.. I admit that as a plugin yours could act as a middleman for all other plugins. One built into Mushclient would add an extra layer of complexity though that is quite silly, especially since mine works well enough, though imho I forgot that you at minimum need the plugin firing an event to also capture them, if for no other reason than to make sure at least one alias matches and the text isn't sent to the mud.

A better implimentation would be a special callback/Mushclient command:

sub OnPluginHandleEvent (ID, Type, Data)
...
end sub

Boolean = FireEvent(Type, Data)

If true, something responded to it. Their is no need to register anything in this case. Mushclient should know which plugin fired the event and thus what ID to send the plugin. "Type" would be a string like 'changed', 'attacked', etc. Basically a short description of what is happening. Data would be a joined array or single string containing what ever data the plugin needs to recieve.

The point here is that there is absolutely no reason in either my design or something built into Mushclient "must" register which plugins need to recieve it. Mushclient can call every plugin with a OnPluginConnect in it, there is nothing preventing it from automatically calling a OnPluginHandleEvent function the same way. I admit that is would definitely make things more consistant, where my idea works exactly the same way, but requires everyone to use the same aliases or it won't work at all.

In fact.. On thing I have wondered for a long time is if you can take an object from another program, like say the script, and register it with your own internal event manager in a second program. This would kill two birds with one stone. Plugins would automatically have their FireEvent calls responded to, but objects that fire events, but VBScript and the like currently can't recieve, could be responded to as though they where registered to Mushclient, instead of the script itself.

In effect, the same OnPluginEvent could handle both script generated events needed for interplugin communications, but also events from objects that are normally unable to get the script to respond. The only drawback is that such objects "would" need to have CaptureEvents(<object>) and Release(<object>) commands, since you would need to make Mushclient aware of them. I need to look around again and see if I can find out if this is possible. However, I suspect it may be, I am just not sure if it is as simple as I hope...
[Go to top] top

Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #12 on Thu 03 Jun 2004 01:34 AM (UTC)
Message
Quote:


A better implimentation would be a special callback/Mushclient command:


sub OnPluginHandleEvent (ID, Type, Data)
...
end sub

Boolean = FireEvent(Type, Data)


If true, something responded to it.


How do you know it handled it in this case? Perhaps a better method would be:


Function OnPluginHandleEvent (ID, Type, Data)

  if ' I handled this event
    OnPluginHandleEvent = vbTrue
  else
    OnPluginHandleEvent = vbFalse
  end if

end Function

Boolean = FireEvent(Type, Data)


That way the OnPluginHandleEvent function can indicate if it was interested in this particular event. By returning false (which would be the default) MUSHclient can assume that the plugin didn't handle it, and call another plugin's OnPluginHandleEvent until it gets a true return.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #13 on Thu 03 Jun 2004 03:54 AM (UTC)
Message
Quote:
That way the OnPluginHandleEvent function can indicate if it was interested in this particular event. By returning false (which would be the default) MUSHclient can assume that the plugin didn't handle it, and call another plugin's OnPluginHandleEvent until it gets a true return.


Do I sense an implication that as soon as a plugin handles the event, that event's propagation is stopped? If so then it wouldn't be very consistent with the idea of events.
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #14 on Thu 03 Jun 2004 05:38 AM (UTC)
Message
Yes. Events don't care if they are recieved and are never responded to unless by the responding function firing another event. I was thinking of it as a case of if any single plugin's event manager was successfully called, it might be useful to know if something actually responded. This is actually sort of stupid, since the only time it would happen is if you had a plugin that actually recieved the event, in which case it is true, even if not handled. As for your suggestion Nick, that is even worse, since one plugin could respond to the event and set it true, then the next plugin could decide that it didn't like that event and return a 'false' value. You would have no idea if it was caught or not. Better to just make such a system work like normal events and only fire the event, and leave it up to the plugins to tell the event sender, 'Heh, I heard you!" in some way. For instance a standard 'event' that plugins may want to respond to would be:

sub OnPluginHandleEvent (ID, Type, Data)
  select case Type
    case "GetID"
      World.FireEvent("ID", PluginID)
  end select
end sub

And the plugin generating the event would do:

sub OnPluginHandleEvent (ID, Type, Data)
  select case Type
    case "GetID"
      World.FireEvent("ID", PluginID)
    case "ID"
      setvariable "Plugin_Count", getvariable("Plugin_Count") + 1
  end select
end sub

sub CountPlugins
  setvariable "Plugin_Count",0
  World.FireEvent("GetID", "")
end sub

Of course you can do this another easier way, but the point is that you have no idea how many, if any, event managers will respond, so the boolean idea was really dumb of me. Can't always be right. ;) lol
[Go to top] 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.


87,744 views.

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

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

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]