michael-zinn/slimeit

Minecraft Bukkit plugin that consolidates some redundant gameplay elements into one.

slimeit's Issues

How to extend bukkit?

This is more of a Java question than a Bukkit question.

Languages like Ruby allow mixins and other cool features, so extending Bukkit could look like this:

Block block; // a default bukkit block

if(block.isStickyPiston() && block.isExtended()) {
block.getExtension().setSticky(false);
block.setSticky(false);
}

Or something similiar like this. However, it's not possible to do this in Java.

Option 1:
A utility e.g.
BukkitPlus bp = new BukkitPlus();

if(bp.isStickyPiston(block) && bp.isExtended(block)) {
bp.setSticky(bp.getExtension(block), false);
bp.setSticky(block, false);
}
However, this is somewhat ugly.

Option 2:
Putting another layer on top of bukkit that covers bukkit completely. This would be pretty to use, but probably overkill, because it would mean duplicating the entire API.

So what should we do here? Please discuss!

Protection support

IS

The plugin doesn't integrate with any other plugins. This issue isn't tested well yet, but it's probably possible to steal slime from WorldGuard protected areas and smear them on the walls of players you hate :)

SHOULD

I guess the whole slime thing should be seen as constructing, so it should be grouped in the same permissions category as placing or destroying blocks? Feel free to discuss this, I'm pretty much clueless about protection plugins.

Discussion: Scope of this plugin

There are many other simplifications to be done, e.g. these:

• Item frames should drop their content on the first punch and fall off the wall on the second punch
• It should be possible to put torches into pumpkins by rightclicking the dark face and punching them out of the pumpkin
• The BetterFurnaces plugin implements this concept for furnaces. How to deal with this best?

As I see it, there are several options:

• Write one big monolythic plugin
• Write a plugin that can take configuration files (tricky?)
• Write several plugins

I guess it's best to write several plugins that share a common library. That common library would contain both the bukkit simplifications (like getting a piston's base from its head) and some common "This block has something on its side that can be punched off" functionality (instead of limiting it to slime like it is right now it should be in a generic way i.e. a glowing pumpkin has a torch in its face that can be punched off and a cracked stone brick has a crack that can be punched off but drops nothing). Now that I think of it, it might be possible to really write one single PunchCrafting plugin that allows separate configuration files for slime, cracks and pumpkins... that would even allow users to implement funky ideas like punching coal off smooth stones and sticking them to other stones all by themselves!

Project Management + Github

I'm a github newbie, so please forgive me if the current setup of the project isn't optimal yet. If you want to contribute to this problem, but encounter any problems that I can fix, please add them to the comments!

What can I do to make contributing to this project easier for you?

[BLOG]

Abusing the github issue system to create a mini blog!

Support for Creative Mode

IS

• Breaking a slimey object in creative mode drops a slime ball and destroys the block at the same time.
• Applying slime uses one slime ball
• trying to scratch a block breaks it

SHOULD

• First punch should remove the slime without dropping it
• First punch should scratch the block (if it's the right tool, otherwise break it)

Examples

• Hit a slimey cobblestone and it turns into a regular cobblestone. Hit it again and it disappears.
• Hit the slimey side of a sticky piston and it turns into a regular piston. Hit the regular piston and it disappears
• Hit the non-slimey side of a sticky piston and make it disappear immediately.

Define a block interaction markup language

How blocks and items interact should be defined in config files. Bukkit uses YAML, other options are YAST and JSON (please add other nice markup languages to the comments).

The difficult question is what to model. But lets discuss the (conflicting) requirements first:

• Easy to understand and modify for moderately competent people
• little to no redundancy
• makes it difficult to make errors
• Offers a simple way to handle rotations (i.e. so that it's not necessary to define every pumpkin interaction 4 times because there are 4 ways to orient a pumpkin)

There are several things that could be modelled, here are some ideas (these are somewhat mutually exclusive):

blocks define what can be done with them and what happens.

• Simple and robust (behaviour should always be well defined, even if it could lead to confusing behaviours)
• Redundant, all block transitions need to be specified in both directions.

Items define what they do

• Easy to understand, since most people will probably look at this from the point of view of an item.
• Less redundancy, a slimeball would define which blocks it can turn into which other blocks and that this is a reversible transaction
• Complicated if an object has multiple uses
• Can lead to conflicts if multiple items define reversible transitions that lead to the same block

Actions (e.g. the torch offers the "attachTorch" action and the pumpkin defines what it will turn into when the attachTorch action gets applied to it.

• Robust
• Confusing

It might be best to do a combination of the two. For example, slime balls and torches are passive objects, so they could be defined from the perspective of the block they attach to:
mossycobblestone {
is=cobblestone
sides=slimeball
}
jackolantern {
is=pumpkin
front=torch
}
This is enough to define that you can attach slime to a cobblestone or a torch to the front of a pumpkin. Things like pickaxedamage could be a special thing, like this:
crackedstonebrick {
is=stonebrick
sides=PICKAXEDAMAGE
}
And the plugin code specifies what this special PICKAXEDAMAGE thing is.

Also, the block definitions themselves should be in a config file, e.g. (values made up):

pumpkin {
id = 86
data {
0 = { front = 2 }
1 = { front = 3 }
2 = { front = 0 }
3 = { front = 1 }
}
}

// Inheritance might be overkill here, though.
jackolanternt < pumpkin {
id = 91
}

stonebrick {
id = 98
data = 0
}
crackedstonebrick {
id = 98
data = 1
}
mossystonebrick {
id = 98
data = 2
}

This makes it very easy to adapt the plugin to new versions of minecraft.

Please contribute your ideas in the comments.

Handle silk touch

Silk touch interaction wasn't even tested yet.

But what's the best solution for silk touch? Should it drop the combined block or separate blocks?

• Silk touch doesn't drop things like "Block with redstone dust on top" or "Cobblestone with Vine attached to it". So maybe these items should decompose, making slime behave like a completely separate object?
• Getting special blocks with silk touch is pretty cool, so maybe it would be disappointing if you couldn't get these special blocks with silk touch? What's the harm anyway?

I need help

Hey. I really love this plugin. I want to use it on my server. But I cant find a download for a .jar file. Could you please send me a link for it?

Random Ideas (Notepad)

You have a cool idea? Write a comment!

Support for Logging

It would be nice if it worked with logging tools like HawkEye and LogBlock.

Add awesome explosion handling

It would be nice if mild explosion damage could blast the slime off a block without destroying the block. E.g. clean that dirty fortress by detonating TNT in it to wipe the slime off the walls.

Not sure about this: Give explosions a small chance to turn a stone brick into a cracked stone brick?

Add basic explosion handling

IS

Explosions aren't covered add all yet. So if a creeper or TNT explodes near a sticky piston or any slimey object the item drops as a slimey item instead of splitting into its components

SHOULD

Explosions destroying slimey objects should break them the same way a player does. E.g. blasting an extended sticky piston should drop a retracted regular piston at the position of the piston base and a slime ball at the position of the extended sticky piston head.