This still needs some cleanup, but works well.
I'd like some users to test (and comment here) on the following
commands:
mvm set pvp true/false (can't test this by myself)
Everything else looks good. All tests pass. Think this one (due to the
active properties) fixes#322
- Add Time as a settable (but not stored) function proptery.
- Add Function properties (They're called tempStringConfigProperties until I make them more generic. deal with it :P)
- Remove the globalgamemode setting, since it's already covered with the new perms.
When I move TempStringConfigProperty to a seperate superclass (ActiveConfigProperty) we won't have the issue of things getting set anymore, as ActiveConfigProperties will change an active setting (gamemode for example) **when** they're set, not after some cleanup function gets run. Hell. Yes.
Off to bed... I promised this commit to someone which is why it's a lil' sloppy. Sorry :( Will fix tomorrow!
- Add the MVPortal Adjust Listener (lowest)
- Change the PlayerListener to (High)
Remember that the priories are really just order, so if PlayerListener
was set to lowest, and cancelled the event, no one else would see it.
These changes are required for the fix that i'm finishing up for NPs
and SPs
Closes#355, Closes#149, Closes#349
This adds a new config var: firstspawnoverride that defaults to true.
You should disable this if you don't want mv to do your spawning (if
you have Spout, a warning will print and it will be disabled
automatically. The firstspawn feature will NOT work with spout at this
time.) When the spout bug is fixed, someone should open an issue. I
will not be monitoring this :)
I've added a separate namespace:
mv.bypass.gamemode.[*|X]
where X is a world name.
If a player has the * one, they ignore game mode changes GLOBALLY.
This perm defaults to FALSE, meaning OPS will NOT get it by default.
