Use the Info.lua file (being newly standardized) to store plugin information and (multi-)command bindings

Currently each call to the DB to load an area produces a new instance of the area object table; it is then rather difficult to track these for multiple players and update when needed (removal, locking). It'd be much better to make an "area cache" that would return the same object for the same area. Updates would then mean just modifying a single object instance.

The code for DB access and storage should be split into a separate file and class. Once split, it would be possible to switch between multiple DB backends (SQLite, MySQL, ...)

Some servers might want to block WorldEdit usage outside the galleries; since only the Gallery plugin knows about galleries, it's logical that it should be the one responsible for that.

Add a configuration option that specifies whether WorldEdit is allowed outside the galleries.

Add a CI check using the CuberitePluginChecker project.

This will allow players to reset their area to the original state. Only useful if the area comes from a schematic template.

You can place snow on other people's claims. Not the block, just regular snow. It sends the "You are not allowed to build here" message but still places the snow. You can not go over 1 block height while placing the snow. This glitch only works if there is already one blanket of snow on the ground.

If the gallery has the Biome attribute set, all the chunks in that gallery should generate with that specific biome.

Each area should remember the last time it was changed, for statistics, as well as future export purposes.

Some galleries may need setting proper biome in order to become useful. If there's a desert-themed gallery and it's assigned the Plains biome by default, then it rains there, which feels weird.

This would benefit players with newer clients - they could for example list areas and teleport to them simply by clicking the names in the list.

This should provide better experience. Consider: "/gal goto fountain" vs "/gal goto Village 1453".
Names should be at least world-unique; questionable if globally unique.

Players that have been allowed using /gallery allow should be able to use WorldEdit functions in that area.

Add a /gallery select command that selects the entire buildable area and sends this selection to the WorldEdit plugin.

When exporting the template using '/gal template', the blocks' metadata is lost. The exported schematic contains metas all zero.
This may be a MCServer bug, but needs to be investigated first

Each area should remember the number of placed and broken blocks, to provide statistics.

Command syntax:
gallery maintenance CheckIndices <AdminPlayerName>

This command should walk each gallery and for each area from the first index to the end index check that the area is either claimed or in the RemovedAreas table. Areas that are not found in either should be marked as claimed by the admin player, given as a parameter to the command.

So that the players may look at the gallery before claiming an area.

Add a command to let players allow other friends to build in their areas.

When using the goto command, the players should be teleported to Area.MinX + Gallery.TeleportOffsetX, Area.MinZ + Gallery.TeleportOffsetZ; the Y coord might be settable, too.

Users may decide to abandon an area, make it possible for them to specify this, with other users possibly adopting the abandoned area later.

Although theoretically possible, reusing abandoned areas for new area claims is a bad idea, because that would effectively destroy the area's contents, which may already be something valuable.

When there are many areas, the list becomes chaotic

The auto-teleport after claiming an area seemed like a good idea, but in reality it feels kinda weird. It would make sense to allow users to be able to turn it on or off by themselves. The state should be persisted to the DB. Use a syntax for the command that assumes further similar settings will be made available soon(ish).

Workflow:
1, Issue command /gal set teleport-on-claim false
2, The teleport is switched off for this player
3, Issue command /gal set teleport-on-claim true
4, The teleport is switched on for this player

The WorldEdit plugin currently knows nothing about the galleries, so it allows players with WE rights edit any area.
The basic requirement would be to disable WorldEdit for entire galleries. If it is possible / reasonable, per-player allowed regions would be better.

When using the /gal reset command, the area's contents should get backed up to a file before being erased. Just in case.

Subcommands for which the player doesn't have permission shouldn't be listed in the subcommand help

Since a multi-word name is assigned to each gallery by default, the goto command should recognize them

When templating, right-clicking a block under a torch while holding a placeable block results in selecting {-1, -1}. That is because the client sends BLOCK_FACE_NONE coords, since the placement is invalid in such a place. Either don't select such coords, or use line block tracer to calculate the real coords.

A feature minor to normal server admins, but crucial to using Gallery for MCServer's own generator-template management, is to allow RCON usage and especially allow "downloading" individual areas through RCON.
The idea is that the plugin would register a console command that would handle the queries, return the metadata (possibly in a Lua / JSON format), and one special command would make it output a .schematic file for the specified area as the command output.

When multiple worlds are set up in Cuberite, the Gallery's generator hooks are fired for all such worlds, generating gallery-areas in worlds where they don't belong.

Add an option to the config that specifies whether players are allowed to build outside the galleries. An admin-level permission should be used as an override that can be granted to players.

Most commands and actions require that the user is the owner of the area. However, admins should be allowed some control, too. For example, admins should be able to name users' areas, or modify their contents. Power-users may be allowed to use "goto" to any area, not only their owned.

Either change /gallery visit, add a param or make a completely new command, so that the recently added areas can be checked out.

Admins should be allowed to "revoke" areas, mainly meant for dealing with trolls claiming and then not using areas. Such a revoked area should be made available for new claims.

Let players decide they are buddies, so they automatically share all their areas, can build on one another's areas, allow or deny friends etc.

Q.: Do we make the buddy relation symmetrical, or not?
Symmetrical is more "brotherly", but requires acceptance from the other player (otherwise anyone could buddy an admin). Single-direction ("I trust him, so I give him my areas") would be easier to implement.

If an explosion tries to occur in a place that is covered by a gallery, the plugin should abort it in order to avoid griefing by tnt cannons

Have two worlds on the server, one of them has Galleries defined in it. The player is in the other world (the default world). Whenever the player places a block, an error is output to the console:

[13:55:36] LUA: Plugins/Gallery/Gallery.lua:320: attempt to index field '?' (a nil value)
[13:55:36] Stack trace:
[13:55:36]   Plugins/Gallery/Gallery.lua(320): GetPlayerAreas
[13:55:36]   Plugins/Gallery/Gallery.lua(532): FindPlayerAreaByCoords
[13:55:36]   Plugins/Gallery/HookHandlers.lua(62): (no name)
[13:55:36] Stack trace end

The plugin should cooperate with the world generator - if a chunk is being generated that is intersecting a gallery, the chunk should receive the gallery template.

It would be nice to be able to leave a message for players, associated with a specific area of theirs - for example "Fix the missing corner" etc. Such messages should be stored until the player connects, then displayed to them using a somewhat interactive menu, allowing the player to replay the message, delete it, go to the associated area etc. The messages should be announced when the player connects, so that they get a notification.

When changing a username, a player can no longer use the land registered under the previous username. I think identification should be UUID-based. Player UUIDs never change (Or do they?), but usernames may change.

The areas that have been approved should be locked even for their original authors, to prevent malicious authors to grief MCS's generator by building stuff that gets approved and then destroying the built area.

To help battle abuse, the plugin should allow players to claim only a limited number of areas. Once they hit the limit, they will not be allowed to claim new areas. Admins can enlarge the limit for individual players.
Questions:

• global limit, or per-gallery limit?
• total limit, or time-based limit (5 areas per hour) ?
• default limit dependent on user's group (how? what with multiple groups?)

Can we detect if the player has modified an area "enough" to consider it a unique area? That way, normal happy users won't ever reach the limit, because once they build something, it is excluded from their limit, yet it would still eliminate malicious abusers trying to claim too many areas.

It should list newly claimed areas and last edits in areas.

Use the syntax /gal my <filterpattern> and /gal my @<playername> <filterpattern>, so that player can view only areas they're interested in. Use Lua pattern matching.

Add a command to display the players with the most claimed areas and the most claimed areas approved by admins.

Add a new claiming method that would claim a new area and copy contents of another area into it. Only areas in the same gallery may be forked.

Some commands have multiple forms available, and even the admin overrides, so it would be good to have a help system that would list all the available forms for the user.
The idea is to define an array of help items, each containing the permission needed, the params and the action performed; then provide a /gal help command that would process these and output the proper help to the user.

Claiming only works if the area is in a chunk that is currently loaded. If the chunk is not loaded, the area template schematic will not be written to it. This needs to be solved properly. Not sure if there is a way to solve this completely in the current API, though.

Admins are quite unlikely to have a .schematic file laying around that they'd want to use as a template for the areas. Rather, they are likely to build an area themselves and then use it as the template. The plugin should provide an easy method for doing this.
Workflow:

1. The admin builds the area template
2. They issue a /gal template FileName command
3. The plugin instructs them what to do next - left-click and right-click opposite corners of the area
4. The admin left-clicks and right-clicks the opposite corners of the template
5. The plugin saves the template into the "FileName.schematic" file. Both clicked corners are included in the area.

The command will print information on the area that the player is standing on.

For regular players, only their areas can be info-ed. For admins, any area can be info-ed, possibly showing more information.