The region now contains two location references per region point for
the bounding boxes where p1, p2, l1 and l2 remain the same (min/max),
but also additional locations for the player's actual location, such
that e.g. moving back and re-setting a point has the more intuitive
behavior of expanding regardless of the optimized points.
This also (hopefully) finally fixes the previous issues with the setup
process *knock on wood*.
Previously, the set() method would overwrite coordinates completely
without min/max'ing the values to preserve the invariant that p1 is
the lowest point and p2 the highest.
This commit consists of two components:
- Restarts are no longer required after setting up the first arena
- Regions no longer auto-expand
The restart requirement is fixed by preventing the ArenaMaster from
actually creating an Arena object and assigning it to the selected
arena upon generating the default arena node in the config-file. The
problem was that the selected arena was set to this initial Arena
object, but another Arena object was created afterwards, which due
to the equals() method of ArenaImpl overwrote the previously created
Arena object in the arenas-list, but didn't change the reference in
the selected arena. In other words; two identical Arena objects were
created, but used in different places (arena list vs. selected arena).
The auto-expansion is removed by simply never auto-expanding regions
upon setting the arena warp or spawnpoints. Instead, setting these
warps throws an error, if p1 and p2 have not yet been set, or if the
location is outside the region.
- All the core abilities have been moved into the project folders
such that they no longer require any extraction. As such, all
servers should have the abilities already installed and ready
to use, regardless of setup-retardation.
- An attempt at fixing the "invisible bosses" issue; a call to
removeBoss was replaced with getBoss - hopefully this fixes
all the issues.
Using a node setup similar to that of the classes-section, it is
now possible to make complex Upgrade Waves that update weapons
and armor on-the-fly. This also means 'permissions' upgrades.
Since ConfigurationSerializable, there's no need to manually serialize
items anymore, and thus we let Bukkit serialize player inventories for
when players join arenas.
However, the "repairables" in the soft-restore mechanism still use the
now obsolete SerializableItem and SerializableInventory classes, and
should perhaps be rewritten.
Note that for 1.0, it may still be necessary to write a custom means
of serializing items, since we don't know if a given implementation
supports native serialization (however it should be possible to rely
on Bukkit's in the Bukkit-specific classes).
