Unofficial MapTool-1.3.b90beta Plugin Support Mod

[Lee]

I'm sorry for the late reply, but it seems you got it done without further input from me. Good job LA.

[Lord.Ashes]

I'm sorry for the late reply, but it seems you got it done without further input from me. Good job LA.

Well...Yes and No. I managed to figure out how to call a Class instead of the JAR. As I said, it was actually even easier than calling JARs because you just need to specify the directory as opposed to having to specify the actual file (as you have to do with JAR files). However, I would never have thought of doing it without your suggestion...So I am happy to give you some credit

I think there will be one last rev to my MapTool Plugin Mod in the next couple days. Currently the results of Plugins are passed back to either the calling Macro or the Message Panel. However, in the case the Message Panel the result is only local. Thus it is not possible with Rev 3 to do some computations (in the plugin) and then send the results, for example, back to the GM.

In my latest version I have added the ability to re-process plugin results. If the result of a plugin starts with a chat command the result, instead of being displayed only locally, is re-sent to the Message Panel causing the chat command to be re-processed. This means you can, more easily, build plugins for sending messages or command to groups of people or back to the GM. It will also allow the GM to execute commands on clients without the client having to trip a macro. If this seems scary, players don't have to use any plugins that use this function but it will allow such plugins to be made. For example, this can be used to allow the GM to request a list of currently installed plugins from the client. Since activation of plugins can be done any time without having to restart MapTool, if a GM bans some particular plugin (or wants to enforce the use of a particular plugin) then that GM would need to periodically check on the client's plugins to ensure that they did not add some or remove some after the campaign has started. By making use of this re-process, a plugin can be written that lists the installed plugins. It can be tripped by a MessagePanelHandler messages and then the results can use the ToGM chat option. In this way the GM can type the keyword in the Message Panel which will trip the plugin, and the results will be sent back to the GM without the player being involved at all.

This addition, which will come out soon, will be backwards compatible with all Rev3 plugins.

[Lord.Ashes]

Security Considerations:

A wise man once said "With great power comes great responsibility" (please don't sue me for copyright infringement) and this is definitely true for Plugins. There are two facts which can make Plugins potentially dangerous:


1. In MapTool, all macro functions could only affect MapTool. Maybe someone figured out a way to bend some function to unintended effects outside of MapTool but, for the most part, macros could not affect the environment outside MapTool. Plugins, on the other hand, are basically independent applications which have access to the entire Java library and (depending on security settings) your system. For example, while MapTool can delete files as part of its core code, there wasn't a function to do this as part of campaign defined macro functions. A plugin, as seen in my CacheCleaner plugin, does not have this limitation. Although CacheCleaner is written to only delete files in the assetcache directory, it could just as easily delete files anywhere else on the system.

2. In MapTool, except for macros tripped by events like CampaignLoad or onTokenMove, macro functions must be invoked by the client. A GM can, for example, have an initiative macro that he/she can run but if he/she wants each player to roll initiative then he/she must ask the players to each run the macro. This is no longer true with Plugins. Although with Rev3 the result of a MessagePanelHandler plugin can not be passed back to the GM (or other players), other clients can still trip execution of code on other clients. A perfect example of this is the Sound plugin. A single client initiated a audio request but it is distributed to all applicable clients using the Message Panel which ends up tripping execution (of the sound) on other client machines. In Rev4 (coming soon) the result of MessagePanelHanlder plugins will have the option to specify chat commands so that the result can be re-distributed to specific players and/or GM (or make use of any of the other chat commands). This will make this option of plugins even more powerful.


As a result of this the following precautions should be taken. I believe that these precautions are fairly obvious and generally apply to download and use of all software but I will state them in any case:

Use a specific plugin only if you:

1. Trust the source it comes from. If your best buddy pal has made the plugin then it is likely that it is safe to use. If you have downloaded the plugin from the
internet from someone you don't know, then you need to be more careful.

2. Have checked the source code of the plugin to verify that it does not do anything malicious. This is why I include source code with all my MapTool plugins.
Generally you don't really have to fully understand the code to verify it. A quick look at the imports and the code can generally tell you if the plugin is
using any potentially dangerous functions (such as those that give access to system resources, delete files, etc). For example, scanning through my CacheCleaner
plugin one would spot the delete method being used so slightly more detailed study would need to be paid around that part of the code to determine that it is
only deleting stuff in the assetcache directory. On the other hand, a quick scan of my GroupSend plugin would reveal no obvious dangerous code and thus one would
not need to study the code in complete detail to know that it is probably safe to use.

The same applied to the MapTool-1.3.b89.Plugin_Source mod itself. Although I am providing the Mod as a JAR file which is ready to be used "out of the box", I am
also providing the Patch file which shows the differences between the regular vanilla version of MapTool (i.e. an unmodified MapTool-1.3.b89 version) and my
modded version. For those that are extra suspicious, the Patch file can be applied to the vanilla MapTool-1.3.b89 source code to re-create the my mod. In this way
the possibility of me providing a JAR file with extra (malicious) code that was not included in my Patch file can be avoided because a new JAR file would be made
from the Patch file itself.

Hint: If I am willing to post the Source Code in the form of a Patch file, there is a good chance (but not 100% certainty) that at least the Patch code is safe.
With so many members, posting a Source Code Patch which includes malicious code would be very risky because someone would likely identify it. Having said
that I *do* encourage people to get in the habit of checking source code because it is generally a good practice.

[Full Bleed]

A wise man once said "With great power comes great responsibility" (please don't sue me for copyright infringement) and this is definitely true for Plugins. There are two facts which can make Plugins potentially dangerous:

And this, so far as I know, is one of the primary reasons why MT doesn't have an "official" plugin ability.

It comes as no surprise to me that, given the long periods of time between builds and little new functionality, that someone would eventually do what you have just done: Sacrifice security for a convenient way to add additional functionality that subverts the need for new builds/releases.

I'm not sure how I feel about this personally, but this is exactly the sort of "unofficial" release that I worried about when various custom builds started popping up. As is, we have reputable users of MT consistently suggesting that people NOT even use b89 (the "official" release) in favor of the b90 beta.

I have to wonder if it makes sense to get this plugin into the next build so that users can also pull community policed plugins from the same source instead of being forced to "take a chance" with a plugin that might pop up. Otherwise, there is a very large can of worms being opened here.

[wolph42]

basically its a typical risk assesment: what are the chances of... and what would the damage be...

Chances of...
To assess this you'll need to check motivation of the 'wrong do-er' which usually boils down to:
1. fun (can I do it/can it be pulled off/ways to cheat the game/revenge)
2. criminal (usually financial gain)

I think the chances on 2 are very slim. The user group is simply too small and therefore not worth the effort. On the other hand, because its small its also unguarded from the big scanners (e.g. norton)
Chances on 2 are greater and my guess would be in the cheating area. Some player writing a plugin for her group and also installing a backdoor for cheating

damage...
*should* 2 happen then that would either mean a bunch of extra spam-bots or a couple of people with a maxed out credit card. Which would obviously suck, but in a bigger picture is really not any different from other spyware that is constantly bombarding your pc. Still you would not want MT be associated with that.

If 1 happens. Well in case of revenge I guess a PC that won't boot and has some vital files deleted. In the other cases Raising eyebrows as the 5th natural 20 is rolled in the same evening by the same person.

Given this I guess there are two policies you can take:
1. give a good and solid warning possibly even in MT e.g. on start up: 'MT Detected the following Plugins, check those you wish to load, click here to read the risks. Click here to remove the ones you checked'
2. only allow plugins to be loaded/installed through dorponds gate (with that I mean the mt resources in the menu)
3. both 1 & 2.

I'm definately in favour of 1 and this should be implemented asap. 2/3 however brings a liability risk with it. Should it happen that the gatekeeper misses a smart line of code and the 'approved' plugin turns out to be malicious after all then you might be held liable. So you would at least need a disclaimer and come to think of it, even if you choose for only 1, it would still be wise to have a disclaimer

[Lord.Ashes]

A wise man once said "With great power comes great responsibility" (please don't sue me for copyright infringement) and this is definitely true for Plugins. There are two facts which can make Plugins potentially dangerous:

And this, so far as I know, is one of the primary reasons why MT doesn't have an "official" plugin ability.

It comes as no surprise to me that, given the long periods of time between builds and little new functionality, that someone would eventually do what you have just done: Sacrifice security for a convenient way to add additional functionality that subverts the need for new builds/releases.

I'm not sure how I feel about this personally, but this is exactly the sort of "unofficial" release that I worried about when various custom builds started popping up. As is, we have reputable users of MT consistently suggesting that people NOT even use b89 (the "official" release) in favor of the b90 beta.

I have to wonder if it makes sense to get this plugin into the next build so that users can also pull community policed plugins from the same source instead of being forced to "take a chance" with a plugin that might pop up. Otherwise, there is a very large can of worms being opened here.

My intentions were to provide expandability but in a somewhat limited manner. It is true that this plugin method can do a lot more outside MapTool but it has a very rigid interface into MapTools which allows the MapTool version to remain the same regardless if a plugin is installed or not.

The problem with no doing this through a plugin system such as mine is that you get may mods of MapTool running around and then campaign compatibility is shot because one use is using the vanilla version, another has my CacheCleaner mod and another my Sound mod. Sure MapTool is currently small enough to allow a user to have 10 different flavors if he/she wants but I prefer to be able to open one MapTool and be able to run the Campaign file. This is why, in my Plugin Support MapTool, any macros that are requested through the PluginExecute macro command are fully optional. If the user does not have the plugin the request is skipped but will not cause the Campaign file to fail.

In my opinion, if b90 will be the last release then a plugin support would be very valuable because any bugs still left in the MapTools might be fixable by replacing that functionality with a plugin...otherwise users will fix bugs themselves and this will spawn many custom builds that will never make it into an official release (because there won't be any official releases beyond b90 as far as I know).

Keep in mind that plugin support doesn't automatically make your MapTool vulnerable. Your MapTool only becomes vulnerable if you use plugins that you have not verified and that don't come from a trusted source. If a user does not install any plugins then no one can use them (i.e. the client itself or other clients) because they aren't there to be used. Similarly I specifically did not create a method to remotely install plugins so that a user can not use MapTool to download a plugin to other users. So as long a you take a bit of care, it actually isn't a huge security risk (in my opinion). And I definitely think it is worth the gain...but everyone has their own opinion.

My notes on Security were more intended as a awareness but not as a "don't do it". I'll definitely be making use of it with my players...but then again I am writing my own plugins and I wrote the mod so I know I can trust myself

[Lord.Ashes]

basically its a typical risk assesment: what are the chances of... and what would the damage be...

Chances of...
To assess this you'll need to check motivation of the 'wrong do-er' which usually boils down to:
1. fun (can I do it/can it be pulled off/ways to cheat the game/revenge)
2. criminal (usually financial gain)

I think it greatly depends on who you play with. My group tends to be limited to friends that I know which have no interest in stealing from me and/or doing damage to my system if one of them wrote a plugin I'd probably use it without even bothering to check it in detail...but if you sessions include people you don't know well or people that you only know through the internet the the above can be issues.

I think the chances on 2 are very slim. The user group is simply too small and therefore not worth the effort. On the other hand, because its small its also unguarded from the big scanners (e.g. norton). Chances on 2 are greater and my guess would be in the cheating area. Some player writing a plugin for her group and also installing a backdoor for cheating

Off the top of my head I can't really think of how one would use the plugin system to cheat...having said that I am sure someone will find a way...the problem with trying to use it for cheating is the limited interface between MapTool and the Plugin. MapTool can send the plugin MapTool parameters but without modifying the actual MapTool code these parameters are limited to values that you can get through one of the MapTool macro functions. For example, I had to specifically add the passing of MapTool directory to the plugin because a user, using the MapTool macro function, normal does not have access to this and therefore would not have been able to pass this as a parameter. The return from the Plugin is a single string so, again, unless there is a corresponding MapTool cheat macro to actually do something with the result of the plugin then I can't think of a way that the plugin can be used to create a cheat.

The closes I came to a "cheat" would have been in my GroupSend plugin but in that case the plugin wasn't the cheat, the "cheat" was not to use the plugin.

Again...I am not saying that it is impossible...but I haven't though of some devious cheat that could be implemented.

damage...
*should* 2 happen then that would either mean a bunch of extra spam-bots or a couple of people with a maxed out credit card. Which would obviously suck, but in a bigger picture is really not any different from other spyware that is constantly bombarding your pc. Still you would not want MT be associated with that.

Exactly my point. Any software that we download has the risk that the creator added spyware/malware or that someone added the spyware/malware on top of it. As en extreme example, even MapTool could have spyware/malware in it. I seriously doubt it since the Source Code is available and someone would have noticed it but when I modded my MapTool, I didn't check all of the Source Code for any spyware/malware...similarly there are some calls to JAR libraries which could be infected. Please don't misunderstand me, I am not at all saying MapTool has any such things...I have been using for a while and have absolutely no reason to suspect that it does...I am just trying to make a point that anything we download potentially puts us at risk to spyware/malware, so some discretion and care needs to be taken.

If 1 happens. Well in case of revenge I guess a PC that won't boot and has some vital files deleted. In the other cases Raising eyebrows as the 5th natural 20 is rolled in the same evening by the same person.

Keep in mind that the plugins added using my mod are supposed to all be optional plugins not necessary for processing the campaign file. Thus it is unlikely that the plugin would be used to roll dice (because if the client does not have the plugin how would he roll). I guess the plugin could somehow spoof the output back to MapTool to make it look like the player used a campaign provided macro to roll but in reality the user was using a plugin which buffs the rolls. But such things are generally easy to overcome. For example, when the roll macro is used, the macro can send the GM some secret keyword validating the authenticity of the macro use. If the players don't have access to the contents of the macro they won't be able to see the secret keyword and then spoofing such a macro use would be very difficult.

Given this I guess there are two policies you can take:
1. give a good and solid warning possibly even in MT e.g. on start up: 'MT Detected the following Plugins, check those you wish to load, click here to read the risks. Click here to remove the ones you checked'

This could definitely be done but since plugins have to be installed on each client individually and manually I figure the user is well aware of the plugins that he/she is using. So he/she should already be aware of the risks. I am not planning on adding any features that would allow other clients to download plugins remotely to your MapTool client...that would just be screaming for trouble. This way the user is always makes the final decision as to the use of a plugin and, according to the Prime Directive (boy more copyright infringements coming my way) of my MapTool Plugin Support mod, choosing to not use a plugin shall not prevent a campaign file from working.

I am also writing a plugin which allows a user (or possibly only usable by GM) to query the plugins used by all connected clients. In this way the GM can see if the players are using some unknown plugin. Of course if the player is cunning he/she can disguise a cheat plugin as something more mundane.

But I have no problem adding a warning if any plugins are installed.

2. only allow plugins to be loaded/installed through dorponds gate (with that I mean the mt resources in the menu)
3. both 1 & 2.

At this point I am not mapTool savy enough (and probably don't have enough time) to implement a proper MT menu for selecting plugins. The beauty here is that with the Plugin Support a menu for Plugins could be added using a plugin. Plugins start working as soon as they are dropped into the plugins directory without needing to restart MapTool. Plugins stop working as soon as they are removed from the plugins directory. So when MapTool starts up, it could have all the "available" plugins in a directory outside the plugins directory except for the plugin that will provide the menu. When this plugin is tripped it would look at the alternate plugin directory to see what is available and generate the corresponding menu. The selections that are made would me moved (or copied) to the plugins directory to kick them in.

I am not saying this would be the best way to do it but if the Plugin Support made it into b90 but a proper menu did not, then it could be added using a method such as the one described above.

I'm definately in favour of 1 and this should be implemented asap. 2/3 however brings a liability risk with it. Should it happen that the gatekeeper misses a smart line of code and the 'approved' plugin turns out to be malicious after all then you might be held liable. So you would at least need a disclaimer and come to think of it, even if you choose for only 1, it would still be wise to have a disclaimer

So the suggestion is:

1. Warning at the beginning of MapTool, listing the installed plugins, if (and only if) some plugins are installed. I'm thinking an option in config to suppress this if you are constantly using the same plugins and have deemed them safe.

2. Maybe a disclaimer when a "new" plugin is detected saying something to the extent of "a new plugin named 'bob' is detected. Use at your own risk. If you did not install this plugin then do not continue...delete the plugin from your plugin directory immediately". Or maybe even "Press yes to continue with this plugin. Otherwise it will be removed."

Any opinions? I want to keep user safe as much as possible but I also don't want to nag them to death just because they want to use my Sound plugin <grin>

[wolph42]

to prevent lengthy posts I'm gonna limit my reaction to the essence of my last post (and your reply to it): warning on start-up.

Here a simple scenario:
- On the forum a GM invites new players to his game
- Players react and pm/skype/mail the details with the GM
- GM tells players that he makes use of a couple of plug-ins for his game. Even better, to make it easy for the players, he gives them a dropbox link with a maptool zip with everything pre-installed and ready
- players download that maptool zip and install it
- the game commences.

a lighter version would be a dropbox link with only the plug-ins zipped and instructions of where to place them.

Now we could start a discussion that anyone accepting anything from anybody over the internet is a douche, but the simple fact is is that the above is a realistic scenario. And obviously could someone go even further and simply add some malicious code to the MT core and create his own version in the above scenario, not much to do about that, but at least we should try to make this as difficult as possible and at least have a warning system for plug-ins.

Your suggestion for the 'not show warning setting' in preferences, I would limit that one to 'not show warning for plug-ins you have already approved', so you would still get the warning if anything would change.

Another thought I had is using an hash algorithm on the plugins which cross refernces a hash table on the MT server. This way plug-ins that are checked by the Devs can be added to the hash table and when running them in MT they can be checked and set to 'safe' or 'approved by mt Dev team'

[Lee]

I brought it up before on a different thread some months before that there is actually a prescribed architecture for implementing a plugin system. This tries to take care of security considerations, among other things. I didn't bring it up again, even though this early work is basically a devoid of the other parts of the "standard" architecture apart from the class loading feature, since it's an enthusiast's work that: 1. can improve over time, 2. Might take a while to gain traction due to the developer drought.

[Lord.Ashes]

to prevent lengthy posts I'm gonna limit my reaction to the essence of my last post (and your reply to it): warning on start-up.

Here a simple scenario:
- On the forum a GM invites new players to his game
- Players react and pm/skype/mail the details with the GM
- GM tells players that he makes use of a couple of plug-ins for his game. Even better, to make it easy for the players, he gives them a dropbox link with a maptool zip with everything pre-installed and ready
- players download that maptool zip and install it
- the game commences.

a lighter version would be a dropbox link with only the plug-ins zipped and instructions of where to place them.

Now we could start a discussion that anyone accepting anything from anybody over the internet is a douche, but the simple fact is is that the above is a realistic scenario. And obviously could someone go even further and simply add some malicious code to the MT core and create his own version in the above scenario, not much to do about that, but at least we should try to make this as difficult as possible and at least have a warning system for plug-ins.

I agree with what you are saying. It is a realistic scenario and this would be the case where you'd probably want to get the source code instead and compile it yourself. If the plugin uses only standard libraries (which most of my plugins currently do) then its just a matter of typing javac ClassName.java to compile it. Most plugins should be fairly simple and thus fairly simple to find any malicious code.

Your suggestion for the 'not show warning setting' in preferences, I would limit that one to 'not show warning for plug-ins you have already approved', so you would still get the warning if anything would change.

I am happy to add a warning but in my opinion it is somewhat redundant. Since plugins can only be added by the user manually the user will obviously be aware that a plugin was install because he put it there in the first place. Yes, a plugin could activate more plugins (as was reasoned out with the plugin menu plugin) but the user would still have to be aware of the initial plugin (e.g. the plugin menu plugin) so there should not be any surprise. This is why I would like to keep warning to a minimum because the user should already be aware (unless, for example, you are sharing your computer with others). For example, if I write my own plugins I don't want MapTool warning me each time I add one. So I think, if I add the warning, I will make a configuration which allows you to suspend it (with the default being ON).

Another thought I had is using an hash algorithm on the plugins which cross refernces a hash table on the MT server. This way plug-ins that are checked by the Devs can be added to the hash table and when running them in MT they can be checked and set to 'safe' or 'approved by mt Dev team'

This is a good idea but it is an idea that requires action on the part of the core MT team. Since MT-1.3 is coming to the end of its life cycle (i.e. focus is going to switch to MapTool 2.0) it is unlikely that the core team would invest time to do this for MapTool-1.3.b89/b90.

My intention was to put something usable on the table before MapTool-1.3 releases end and, if possible, get it into the official release so that even with no new builds, user can continue to expand MapTool until everyone migrates to MapTool-2.0.

Remember, just because the Plugin Support is there, does not mean that users have to use it. As I mentioned multiple times, the Prime Directive of my Plugin Support is that Campaign files can make calls to plugins (such as CacheCleaner and Sound) but the ability to take part in the campaign must not be impacted by installing or not installing a plugin. This means that when you are playing a campaign with people you don't know, the safest action is not to install any of the GM's plugins. Or install only those plugins that you are fairly sure are safe (i.e. you got them from a trusted source or you have checked the source code).

[Lord.Ashes]

I brought it up before on a different thread some months before that there is actually a prescribed architecture for implementing a plugin system. This tries to take care of security considerations, among other things. I didn't bring it up again, even though this early work is basically a devoid of the other parts of the "standard" architecture apart from the class loading feature, since it's an enthusiast's work that: 1. can improve over time, 2. Might take a while to gain traction due to the developer drought.

My answer to this is probably very similar to last time's answer...

I probably don't have the skill and/or time to implement a proper "standard" plugin architecture. In addition a complete plugin system would probably provide more functionality within MapTool than I am allowing with my Plugin Support. Although this can be an advantage when trying to add new functionality to a application, it defeats the Prime Directive of my Plugin Support system. My Plugin Support is supposed to be only for plugins that are not essential to running the campaign file. Players with and without the plugin should be able to use the same campaign file (even be connected together in the same session) without getting version mismatch errors or losing vital parts of campaign. A campaign that make use of the Sound plugin, for example, will provide a slightly different experience to those using the plugin as to those that are not (i.e. the playing of the sound) but if a player does not have the plugin installed, the Sound plugin cues get ignored and the player without the sound plugin can still take part in the campaign without problems. This is why, I stressed in the Sound plugin documentation, that the Sound plugin must not be used to provide any plot critical information unless it is also provided by text.

Anyway, by limiting the return interface from the plugin back to MapTool to a chat message or a macro return value, my Plugin Support ensures that the plugin can not do anything inside MapTool that MapTool could not already do. In this way, it can almost be guaranteed that a user using a plugin and a user not using a plugin will process a Campaign file the same way. On the other hand a complete plugin system might provide the ability to patch/modify existing MapTool functionality in which case the same campaign file compatibility can not be guaranteed.

So if you can't do anything in MapTool that you could not already do with MapTool what is the point? There are a few reasons for using plugins:

1. You can do more outside MapTool. The CacheCleaner and Sound plugins are perfect examples. CacheCleaner removes old asset files which you can not do from inside MapTool. Sound triggers the playing of sound giving the illusion that your sound is integrated with MapTool but it is actually running outside MapTool.

2. With the re-distributer version (Rev 4) coming soon, you can use plugins to re-distribute messages and/or results to a subset of players. Thus you can make plugins for team communication, chat message distribution based on "rooms", etc.

3. With the re-distributer version (Rev 4) coming soon, the GM can use clients for distributed processing. Instead of having complex macros run only on the GM's workstation, the GM can offload the processing to each client and then have the client provide the results back to the GM.

4. The last case somewhat bends the Prime Directive but plugins can also be used to simplify GM side calculations which might be possible in MapTools but not ideal. This bends the Prime Directive because, obviously, such a plugin would be necessary to the campaign but if such a plugin is only used by the GM it still maintains the Prime Directive for all connected players.

One last note:

Do I think this is a great plugin system? Its not bad but by its own design it is very limited (in what it can add to MapTool). Do I think it is a plugin system that should be used for MapTool 2.0? No. I do think it would be a good idea to have a subset of plugins, for 2.0, which do not modify MapTool core functionality so that they can be used or not used without resulting in MapTool campaign version incompatibility but I agree that my Plugin Support can be greatly improved upon when MapTool goes 2.0.

Having said that, with MapTool-1.3.b90 probably being the last official build of MapTool it is clear that a "standard" architecture plugin system will not be added to MapTool-1.3. So in my opinion (and that is all it is...my opinion), if I have a choice between no plugin system or my limited Plugin Support then I will take my Plugin Support. Players that are afraid to use it can "turn it off" by not putting any plugins into their plugin directory (which should still allow them to play all campaigns) but it would be there for players who want to make use of it.

This is the same philosophy that I have use for my other MapTool mods (most of which have now been re-created as plugins). Consider my Sound Mod and now my Sound Plugin. Do I think it is the best way to implement sound? Probably not. Having a sound resource that you can get from MapTool repositories and drop in similar to a token would probably have been a better implementation but such an implementation is beyond my ability in a quick time frame. So I did it a little differently. It gets the job done and make the functionality (in this case sound) available to user that want to make use of it. If I stuck to trying to implement it properly, as a resource, I probably still would not be finished and others would not have the functionality.

Yes...I confess...when it comes to larger programs such as MapTools that I did not write, I am a hacker programmer. I find a way to accomplish my goal, usually with the least amount of resistance, and get it done. It may not be the nicest solution but it works. If this is not your approach, I apologize but when it comes to a dark cabin, I will always take a flickering candle light if the alternative is to wait 2 months for a electric light (<grin> like the metaphore?).

[Lord.Ashes]

MapTool-1.3.b89.Plugin_Support.R4 is available for download.
Download it from https://www.mediafire.com/folder/29a96e ... Support.R4

See the original post (of this thread) for details. Changes are highlighted in orange.

Hopefully this will be the last mod to the MapTool mod and now we can just focus on using it to make plugins.

Added Features:

- A warning, in the Chat window, when MapTool starts up which indicates which, if any, plugins are installed.

- Reprocessing capabilities which allow Plugin output to be reprocessed by the client so that it can make use of Chat Command.

- JAR file is compiled under Java 6 so that it can be used on Java 6 or Java 7 machines.

A download link to the available Plugins is also provided. Note that the only changes between the R3 versions of the plugins and R4 is that the help function was added.
Each of my plugins can now be called, from MapTool, with the "help" function. This provides a brief description of the functions available in the Plugin and any usage notes.

There are also some new plugins available. All my plugins now support the "help" function. You can use pluginExecute() to call the "help" function on the Plugin and it will return a brief description of the functions available in the plugin and some usage notes (if applicable).

Plugins Plugin = Provides functions for listing currently installed plugins to the client, GM and everyone.
GroupSend Plugin = Provides functions for creating groups and being able to send messages to all members of such groups. Users without the plugin see all messages.
MultiSend Plugin = Provides functions for creating groups and being able to send messages to all members of such groups. Users without the plugin can receive but not Multi send.

[Lord.Ashes]

Notes on Java 6 vs Java 7 with MapTool-1.3.b89.Plugin_Support.R4:

The R4 version is compiled using Java 6. This means the modded MapTool should be able run both on Java 6 and Java 7 machines.

The following chart summarizes compatibility:

Running on a Java 6 machine, MapTool-1.3.b89.Plugin_Support.R4 can be used to run any Java 6 plugin (currently everything except CacheCleaner7).
Running on a Java 6 machine, MapTool-1.3.b89.Plugin_Support.R4 can not be used to run any Java 7 plugin (currently only CacheCleaner7).

Running on a Java 7 machine, MapTool-1.3.b89.Plugin_Support.R4 can be used to run any Java 6 plugin (currently everything except CacheCleaner7).
Running on a Java 7 machine, MapTool-1.3.b89.Plugin_Support.R4 can be used to run any Java 7 plugin (currently only CacheCleaner7).

If you find results contradictory to the above table, please let me know in this thread.

[lmarkus001]

Why are you basing this on b89 and not b90? Since you are creating a fork, I would think you would want the "better" code to fork from.

Also, since you seem to have energy and wherewithal, I might suggest you talk with Azhrei and maybe takeover Maptool build control (as he has clearly lost the time/interest/focus/etc to maintain this tool we love).

[Lord.Ashes]

Why are you basing this on b89 and not b90? Since you are creating a fork, I would think you would want the "better" code to fork from.

Also, since you seem to have energy and wherewithal, I might suggest you talk with Azhrei and maybe takeover Maptool build control (as he has clearly lost the time/interest/focus/etc to maintain this tool we love).

As far as I know b90 is still in beta, no? The RPTools website does not officially have b90 for download. As such I am guessing that most main stream clients still use b89.

I have heard a lot of people discussing b90 but I am not sure where to get the latest build and what stage it is at. I would imagine that it shouldn't be too hard for me to add the same functionality into b90. Most of the mod is addition of functions as opposed to modifying existing ones (so it shouldn't really be dependent on the build unless serious changes have occured between b89 and b90). The patch that I provide (for building my mod yourself if you prefer) wouldn't work (because patches uses the previous version for reference) but doing a manual patching to create a b90 mod wouldn't be too hard.

I was actually suggesting to Azhrei to incorporate my limited Plugin System into the official b90 build so that, if b90 is the last build before going on to 2.0, then it will have a method that users can add on to MapTool without having to create a fork for each new addition.

However, I have not go any response from Azhrei on this subject.