/setteam <color> now will add an additional spawn point if the team already
exists.
When a player joins a team in a warzone, they will be sent to any one of
their teams spawn points, picked at random.
This change required major modifications to the underlying teams subsystem
in order to support multiple spawn points for the team.
This test task is incompatible with additions to War regarding teams.
This method of preventing players of receiving spawn protection is
currently extremely buggy and there has to be a better way to fix the issue
at hand.
@taoneill please email me if there is any serious reason this task is
needed, otherwise it just deteoriates from the War experience. Numerous
times I have played War, I have been bumped out of a warzone even due to
this. There seems to be no need for it. I can revert this commit if needed.
One possible solution could be disabling all protections for anyone who
returns to their spawn, such as like how loadout switching is prevented
after leaving spawn. Another solution could be preventing multiple teams
from taking a flag while another flag is on the run.
Please leave your ideas in the comments or email me.
Update health references to use double-precision floating point numbers instead
of integers due to minecraft spec change. Update Java to 1.6. Update bukkit
version.
The WorldEdit API is utilized to allow the use of WorldEdit selections
when creating or modifying a warzone. If the current player has a
WorldEdit selection when the /setzone command is used, this selection will
be used for the zone's corners.
War saved a player's state before they were teleported into the warzone.
This causes issues if the lobby is in another world and the server is
using plugins to manage per-world inventories. Essentially, the player is
getting their inventory from world A saved, teleported to warzone in world
B, their state being restored in B, then teleported to A. Per-world
inventory plugins save and restore inventories on every
cross-world-teleport. This causes blank inventories when a player joins a
warzone and the player gets the items from the zone when they leave.
This issue is easily fixed by teleporting players to the warzone's world
before saving their state. This is merely a standardization of state
save/restore order.
permission specific loadouts.
Loadouts can be defined with a permission which can limit who can access
the loadout, in mostly the same manner as I did in the zone-permissions
commits. The permission can be used to only allow say VIP and above to get
a certain loadout (for donation benefits) or to allow the server's lower
ranks a class only (to allow lower ranks to survive faced with the server's
experienced players).
This is controlled by an additional argument to /zonecfg.
Example: /zonecfg loadout:vip:server.ranks.VIP - allow only VIP players
access to the vip loadout.
To remove the permission, re-make the loadout without the permission
parameter.
Example: /zonecfg loadout:vip - remove the permission requirement for the
vip loadout.
To allow a lower rank access to a loadout only, you can use your permission
manager's feature of negating a permission (if supported by the plugin).
Example: /pex group recruit add server.loadout.noob, /pex group builder add
-server.loadout.noob - allow only recruits to have access to a loadout
which requires the permission "server.loadout.noob" (with PermissionsEX).
Adds a team default permission configuration option. Default is
war.player. It is modifiable at the zone level and the team level. In
autoassign zones where there is a mix of teams that some players have
access to and some that they don't, the player will only ever be placed
in a team he can access. You can't /join a team you don't have
permission to join.
When a player joins a warzone for the first time, they will be given a
loadout called "first" instead of the default loadout. After they have died
once, they will receive the default loadout. Players will also be assigned
the "first" loadout every battle if they are on the default loadout when
the battle ends.
I do not know how servers will deal with players who might constantly leave
and rejoin the zone in order to get the loadout back. This could be fixed
with a war change if it becomes necessary (maybe remember the player until
the battle ends). But, as always, if a server does not want to have a
"first" loadout in a warzone, they do not have to create one.
This is mainly for servers such as the Warhub, where most players can make
their own warzones. Inexperienced zone makers may place ender chests in
zones which makes their zone susceptible to smuggling items.
This may also apply for zones which would like to use ender chests for
aesthetics.
Hopefully this change shouldn't be a problem. I cannot think of any way
that an ender chest would be used inside of a warzone.
Backward compatible with 1.4.5-R0.2 and previous. Switched version to
War v1.7.4-PREVIEW. Lobbies and warhubs should line up properly now, at
least. Commands such as '/setzonelobby east' still use the wrong
directions.
Got my head out of my butt and figured how I was casting bytes to ints
all wrong. War map format can support block ids up to 255 now with this
ugly patch. This is just to tide people over until a format switch to
something that will supports custom blocks and items.
Closes gh-530. Weirdly, it seems that some new blocks (e.g. emerald
block) get saved with negative block type ids. For the time being, the
absolute value of the negative type id is used instead. The console spam
should be lessened as well - leading to less crashes. Still gotta find
the reason for the weird block ids, though.
Closes gh-526. Restoring a user's inventory when geting kicked. This
should technically solve an inventory reset problem. I've always found
the kick-prevention pretty hacky, anyway. Hopefully, the accidental
flying in warzones caused by War's teleporting people around has been
fixed upstream by the Bukkit folks since back in the day when this was
an issue.
Closes gh-503. Now letting players just walk through their own spawn
really fast (instead of just getting them stuck blindly), and being a
bit smarter about where I teleport them (i.e. mostly not in walls
anymore). Much less brutal than in v1.7.2.
The inventory reset bug was caused by a concurrency issue, but all this
sychronization added some now unnecessary weight. Hopefully this should
help with the lock ups that have been happenning with v1.7.2.
