Registry (For discussion only)

Ok, here is my idea for a way to handle BlockMaterials, ItemMaterials, EntityMaterials etc.

Atm only BlockMaterials is done, and I didn't create any abstract classes or interfaces really.

Most code is in api/material, api/material/block and engine/registry

The plugin running the game will create a registry and pass the kind of registry it want's to use (yaml etc) to it. It will than initialize the registry which will normally load it if the registry is already on file and if it is a server.

Loading the registry means that the mapping ID = MaterialName is done, nothing more, after that the materials need to be added still.

Base / Fallback material can only be used from the plugin holding the registry, custom material can come from other plugins.

you can remove a custom blockMaterial in which case we will fallback to an older version or to the base material.

Client handshake will handle this with a specific packet which will send over the registry to the client, after that the client will need to start adding the blockMaterials.

I guess implementing server-client-handshake will require some rework in the init and check init part, we should only init the registry if the yamlregistry for example is already transmitted.

Feedback?????
This also needs the name be changed to the other method… Thanks.

On 22.06.2014, at 12:19, Wolf480pl <notifications@github.com> wrote:

> In src/main/java/com/flowpowered/api/material/BaseMaterial.java:
> 
> > +	}
> > +
> > +	/**
> > +	 * Creates a material with a reserved id
> > +	 *
> > +	 * @param name of the material
> > +	 * @param id   to reserve
> > +	 */
> > +	protected BaseMaterial(String name, int id) {
> > +		this.displayName = name;
> > +		this.name = name.replace(' ', '_');
> > +		this.id = MaterialRegistry.register(this, id);
> > +	}
> > +
> > +	public final int getId() {
> > +		return this.id;
> ... and this.
> 
> —
> Reply to this email directly or view it on GitHub.
>