Hello, Alot of the "hub" servers out there have different worlds, when you enter a portal you come to example a faction server, when another portal takes you to hungergames. How is this possible to have different plugins for each world?
iChrille, http://forums.bukkit.org/threads/per-world-plugin-disabler.154421/ it is not possible unless those plugins have multiworld support
Try hosting multiple servers and using BungeeCord. Per-world plugins is not possible, and any plugin that claims to do it is dangerous and very hacky.
theoretically I could just cancel any command from a specific plugin if the world isn't the right one, couldn't i? And Bungee Cord can be found on the Spigot forums.
And make sure that events aren't passed on to the plugins, disabling help pages. Good luck with such features
I know you can do this with GroupManager. You will have multiple folders for each world on your server in the group manager folder. Just edit the groups.yml for each world to give players, in one world, perms for factions, and in another, perms for other stuff.
Plugins which claim to offer a per-world solution are using very hacky methods to do so, they cause major issues and should never be used.
Firstly due to the way bukkit works, hacky changes is the only way to achieve this. I figured this out because I know how bukkit works, and I am very active and OP in the WorldEdit, WorldGuard, CraftBook and CommandBook support channel, in which people come for help with those plugins and others. People always have issues when they have a plugin that hackily stops plugins working in certain worlds.
Define these "hacky" methods please. If checking for disabled worlds from a configuration file and not executing one or more conditions if a condition was meant to be executed in a disabled world is hacky, then how would anyone disable certain functions from executing in worlds you don't want said functions to apply to.
If a plugin itself implements it's own version of a multiworld system, that is fine. It's when another plugin steps in and takes the matter into its own hands for other plugins that it becomes troublesome. Plugins that do that modify the way bukkit processes commands, events, and even modifies portions of the bukkit API to stop other worlds being seen as existent to certain plugins. Not only does this make giant assumptions about the way every plugin works, but it also causes issues with the bukkit API not doing what it is supposed to do. And with the way the event system works, overriding what plugins receive what events becomes incredibly troublesome.
Ok, now I see. Personally I have never heard of such cases so I can't speculate on it, but out of your description it sounds like a quite unnecessary procedure lol.
It would be best for Bukkit to either implement their own multiworld plugin system, or each plugin to do it themselves. A while ago I devised a good system for bukkit to do so, using a system similar to permission nodes. It'd work as a per-world system of defining plugin nodes, but not only that, it'd allow you to disable certain features of plugins entirely.. Without the need of having it in the plugins configuration. For example, using plugin nodes.. You could enable CraftBook gates in a world like this: world: - craftbook.gates CraftBook would check with bukkit if the plugin node is enabled, and would then enable the feature for that world.
Why so complicated? Every common permissions plugin can do per-world-permissions. So you can't disable plugins for specific worlds, but you can easily disallow players to use them and block their effects. Which basicly does the same as disabling the plugin for this world. No "hacky" methods needed.