nathanwolf / bukkitplugins Goto Github PK

The last I tried using the damage hooks, they didn't really work.

Once they're working, modify invincible to be functional. Consider other damage-based spells, modify gills to work better, etc.

DataType should try just directly supporting every datatype- maybe SqlLite handles data types it doesn't support (such as Date) gracefully on its own?

Failing that, fix the problems with float, and then move it to DataStore so it can be overridden by other stores, such as MySql, that may support Date or other types directly.

I'd like a spell that summons a magic treasure chest. You can summon it, take items in and out, and then dismiss it to summon later.

I want the ability to import / export data from YAML files, since that is the chosen standard Bukkit file format.

Importing and exporting will be done via the console UI, and will by default use YML files dropped in the Persistence data folder. An import or export can specify a node path to only import a set of nodes.

Wandmin should make use of Persistence to store wands and commands, and Classes for permissions.

Blink should find a place to put you (within range), no matter what. There are still some bugs in the search algorithm that turn up results where you can't actually stand, which makes blink fail and generates the "You can't fit there" message.

Persistence should be modified to throw exception on developer error, instead of logging+continuing.

Many of the things Persistence currently logs should be caught at development time as an exception.

Logs are for admins- let the devs know what's up in the debugger.

The disintegrate spell should be useable as a combat spell.

Implement incremental auto-save using the async features of BukkitScheduler.

This issue depends on the "allow concurrent read" access issue. Not directly, necessarily, but it's not really useful for it to be async until that gets done.

Object fields can be of two types:

1.References
2. Internally owned entities

Right now, only #1 is supported- an entity referenced by another entity must itself be a full-fledged unique entity.

This is good for references, but bad for complex object structures, or objects that "own" other objects.

These need to be handled specially. They would not have a unique entity table, instead they would have only the owner/value join table, and the entity field would exist there.

In other words, each instance of the owned entity would only exist within the context of its owner. The PK for this table would be the same as it would be for the sub-table otherwise: (owner.id, child.id). Therefore, a child can not be found directly- it doesn't have a unique id on its own.

Similarly, a list of owned objects is a special exception- the list data table would contain the child class instance data as well.

Map markers created with "recall" should be restored on server reboot, or at least removed on shutdown.

Create a base class that we'll recommend people base their DAOs on.

It can handle some basic things like equals() and hashcode support.

Flush out Classes, make it functional. Right now, it's just a glorified player tracking system.

Many, many people have asked, some nicely, some rudely, for Permissions support.

I plan on implementing the ability to import YML files, including the Permissions config file, to Classes. This will let admins brings an existing user/group setup over to Classes, and hence to Spells and Wand.

Blinking and constructing through glass should work as expected.

Implement a spell to tp another player to the targeted spot if that player died there recently.

I want to move all in-game text to data.

To facilitate this, create a Message class, which contains a text message and a string id.

These ids could be dotted, such as "persistence.reloadMessage". It may or may not make sense to store them as a tree structure, though- since most likely only the child nodes would have data anyway.

I am also considering a boolean flag in each message, to allow admins to disable any message in the system. A per-user solution for this would be nice, though, too- so maybe that belongs in a separate entity-table.

in reference to my post about using the Persistance singleton in the data objects

If we wanted to insulate the data classes from the actual persistence plugin then perhaps a singleton class like daoHelper that can be brought in?

public class PersistenceDaoHelper{
    getServer()...
    getWorld(worldName)...
    getBlock(worldName,x,y,z)...
    getPlayer(playerName)...
    ...etc?
}

this would be instantiated in Persistence:

private PersistenceDaoHelper persistenceDaoHelper = null;

....
Persistence.onEnable(){
     persistenceDaoHelper = new  PersistenceDaoHelper(server);
.... 
}   

then in the DAO objects:

  private PersistenceDaoHelper daoHelper =   Persistence.getInstance().getDaoHelper();

 public getBlockThatHasBeenPersisted(){
         org.bukkit.Block bukkitBlock = daoHelper.getBlock(persistedWorldName, persistedX, persistedY, persistedZ)
         return bukkitBlock 
   }

this way it becomes SUPER easy to turn persistable data objects back into their org.bukkit counterparts.

in the example above, of course it's possible to create a new block and return that, but then its not THE block referenced by the game world. I'll make the class if you think this is worth a go-ahead and you want to add it to Persistence. I think it would be a great usability feature.

PS and FYI gonna go have a life. will be offline until tonight. :)

Blocks that are automatically added to a block list during an undo action (to protect attached items such as torches, for instance) need to be specially marked.

When a spell like transmute requests an undo list, it shouldn't get these blocks.

Right now, transmute has some strange behavior because of this- though I now have a lovely glass-filled crater because of it.

Lists of primitive types are supported, lists of objects need to be supported as well.

Spells should make use of Persistence for:

• All in-game text
• All material lists
• All configuration info
• All other data

Spells should make use of Classes for permissions.

I want to modify "frost" to damage living entities, for use a combat spell.

I also want to implement an "encase" spell, which would recursively surround a structure in another structure.

I could see two variants by default - "crystallize", encases a structure in glass, and "freeze", encases a structure in ice.

It would be cool to be able to target living entities as well, and trap them.

If login and logout, your familiar will be dead.

It would be nice if familiars returned on login, even after a server reboot.

For that matter, it'd be nice if they followed you around.

Phase 2 data migration will cover cases that Persistence can't handle in a completely automatic way. The idea is to put the onus on the dev to create migration scripts, which Persistence can manage and auto-apply for admins.

Persistence will maintain a special MigrationStep global entity for this, which tracks each migration script that's been applied.

Admins will drop a script in the Persistence folder with the server shut down (during a plugin upgrade). On startup, Persistence will execute this script, mark it as having been completed. and then move the physical file to a separate "completed" folder.

There needs to be some way to uniquely identify migration scripts- this gets complex, since they need to be globally unique, across all plugins and all changes. We made need to have Persistence auto-generate a template or something.

The actual id could either be the filename, or embedded in a comment on the first line of the script.

It would be handy, though generally I just persist a list and map it in onLoad().

It should be easy to implement, though- functionally no different than an owned object.

Currently, Wandmin only works with "legacy" commands that use onPlayerCommand.

It should continue to work with these, but also add support for the YML-based commands.

Especially since I imagine I will be, reluctantly, converting Spells over to use them, and Wandmin needs to be able to support Spells.

Persistence needs to use a read lock and a write lock to make access thread safe.

Any number of threads may read at one time (do I need to switch to concurrent hashmaps for this to be safe? I don't think so...), but only one thread may write at a time, and no thread may read while another is writing.

Over-simplified, but I think that should cover it.

This also implies refactoring all of my plugins to use the Bukkit command system properly.

I think this should be a separate Gameplay feature from the core Persistence MaterialData functionality.

Support the "auto" modifier on the Persist annotation, to create an autoincrement value.

This is really only valid for ints, and then maybe only for ids (not sure), but for now I'll let the db sort that out.

A variant of fill that automatically fills with air would be great.

Also, look into why fill is not using the selected material by default.

Phase 1 data migration needs to happen right away- I need it for NetherGate, and I think WinSock needs it for ProtectedDoors, too.

Phase 1 will handle adding new columns to a field. Removing fields should already be "safe", though the new migration code will clean up any removed columns from the data table.

I plan to save a backup table for each migration, just in case.

When binding to a persisted class, Persistence should check up the class hierarchy for other persisted classes.

From there, they can just be handled like invisible contained objects.

This is a catch-all for some short-term work:

• Fix using an object as another object's id- seems to be broken. I have some test code now, so that will help a lot!
• Allow adding or retrieving persisted classed programmatically.
• Allow for adding persisted fields programmatically. This could be used in conjunction with the above to persist a third-party or otherwise unmodifiable class. It could also be used to extend an existing persisted class (though eventually I will traverse up the class hierarchy automatically, looking for persisted parent classes)
• Allow for read-only attributes, such as the id field of BlockVector. This is "read-only" from Persistences' perspective.

I'm going to create a plugin to mimik the original single-player Nether/gate experience as closely as possible.

Admins will create "Nether" areas underground, which can be use as portal hubs for the surrounding area, using a distance ratio formula similar to the orignal Nether.

Other than creating a Nether area, there will be no console commands, no signs required, and no UI of any other kind- just like the original Nether.

I'm hoping this will be a reasonably easy task thanks to Persistence, and it will be my first real time using Persistence in a plugin. So I'm hoping a lot will come out of it.

For now, I'll just this one issue for NetherGate- once it's mature enough to be functional, I can add additional bug and feature tickets as needed.

Wand should make use of Persistence for settings and text. It should make use of Classes for permissions.

It should manage material/spell bindings, instead of letting Spells do that.

Some sort of fire spell, mainly for combat.

This might be really, really dangerous- so it needs some thought.

First, decide whether or not this is a good idea.

I think would it be handy, perhaps necessary- if you want to essentially extend an existing data structure, such as storing some data per player. You could just make a new data structure with String id of playerId, but it would be more referentially consistent to have an id of Player (or User, whatever I have to make the player DAO named....)

In the end, the data is the same- a text id of playerId, so it's really just semantics. I think I'd like to support it, though.

Normal Cast; Directional Glass shield, lasts 60 seconds, but can be destroyed.
Shift Cast / Stealth Cast; Full Glass shield, lasts 30 and unable to move (Or you can move with the shield, like the magic carpet. Either one would be cool :P)

I want to port the undo ("rewind") system from Spells over to Gameplay.

I have a few features I want to add, and some performance improvements to make- mainly giving each BlockList a BoundingBox.

Otherwise, for starters at least, I'm basically just moving the system over wholesale.

I want to explore the idea of having a "spell inventory" that you Wand could switch to.

It would contain one icon (material) for each spell you know. You could swap back and forth between you item inventory and spell inventories.

You would not be able to move non-spell items into your spell inventory.

Set up a lightweight mob manager in Gameplay, using the code from the familiar spell and NetherGate's Nuke.

This is probably temporary, until a Bukkit system is in place.

But, honestly, I'm hoping that goes for all of the Gameplay plugin features!

I had originally intended for messages and commands to be one giant namespace, relying on plugins to use some sort of dotted notation for the ids, or something.

This now seems like a terrible idea, so instead each plugin is going to have its own store for messages and commands. In order to do this, I'm going to create a Plugin data type that has a list of messages and commands.

However, this requires internal/owned object support, since each message/command is no longer a unique entity- the are always contained in a Plugin entity.

Persistence currently throws some exceptions when it can't find the SQLLite drivers.

This root issue (a Bukkit problem) is preventing the following:

The "absorb" spell won't correctly absorb material variants (colored wool, etc)
The "mine" spell won't mine lapiz lazuli
The "paint" spell and other material selection spells won't properly apply material variants.

I want materials (and material variants) to be full-fledged entities.

Since I can't use Material, the classname will probably be MaterialData, but the entity will be "material".

It will have a materialId, a default data value, and a list of variants.

This table will be auto-populated if empty, using the Material constants and some hard-coded logic about the material variants (since I'm not aware of that being available in the API anywhere at present).

There needs to be a nice list of blocks that look silly with snow on them.

Should the disintegrate spell (and others?) have a config option to pass through any block listed? In my experiences, it feels weird when trying to destroy blocks that are "behind" blocks like rails, torches, and flowers, since they don't seem to be in the way. The problem with this is that the spell obviously wouldn't be able to work on those blocks at all...

The targeting system should be modified to somehow find line-of-sight living entities.

I'm not sure I can dig around in Permissions directly, and importing the config YML file is a more flexible approach, anyway.

I would import and merge in groups, players, player->group assignments, and permission assignments.

I would not import permission nodes themselves- I would bind to the ones already present in Classes.