Bukkit

Hi great plugin, just saw your posting guidelines and though I'd better split the ticket
Feature request below

Limit glass break area. The could be either a radius from the break point or some sort of random chance that the break will spread. Either way this would mean that jumping through large glass windows and skylights will leave some glass in the corners like in a real window breaking. Using a random chance to break glass breaks would be different each time, always leaving a broken glass structure rather than nothing. It would mean breaks were limited to a small area but the area is not always the same.

I see the random block breaking go something like this, although no doubt this is vastly over simplifying it.
Firstly break a 9 blocks around the break point This will allow anything to travel through regardless of the random breaking , players boats minecarts etc

Then we look at adjacent blocks the further the break travels the lower the chance to break the adjacent block.
Before breaking an adjacent block we will also check how many blocks are adjacent to it. The more blocks around it the lower its chance to break. This means if you build a glass cube and shoot one corner its likely to blow off a chunk at the corner but leave most of the cube. If you build a 1 block wide glass bridge and shoot the middle it is very likely the whole bridge will collapse.

You could make the chance the break will spread configurable up to 100%. 100% will behave like it does now, 1% will make very small breaks, 99% will make very big breaks.

Am I making sense here

Are you aware of config option to limit the number of blocks that are broken? or is this a suggestion to replace that?

The MaxBlocksBroken field is the simplest way to take care of this. Tho, it isn't really situationaly aware. MaxBlocks is simply going to count up to a certain point, then stop breaking. So, small windows always break but bigger ones don't. The random chance aspect would make it act only slightly differently. It's the same basic idea, just a bit more organic.

Firstly No I was not aware of the max blocks broken. I swear I looked at the config file, somehow I missed it. It will do most of what I need for now.

I still think the random thing should be added though, it would make glass breaking more organic, weaker structures would have larger breaks strong structures would have small breaks

@bigmommulgrew: Go

By weaker and stronger, do you mean based on the amount of blocks or the type of block?

Because for the type, you can already set the limit per type.

By stronger I mean: A block is strong when it has a lot of other blocks connected to it A block is weak when it has few other blocks connected to it.

Here are a few examples This is a 1 block wide glass bridge. Each block, except the ends is connected to two other blocks. If I built this in real life it would be very weak and would break completely at the smallest tap. Using the idea of breaking blocks on a random chance this should have a high chance to break completely

This is a 2 by 2 glass bridge Each block is connected to 3 other blocks. If built in real life it would be stronger than the first bridge. Each block in this bridge should have a slightly lower chance to break

This is a 3x3 glass bridge Each corner block is connected to 4 other blocks The side and top blocks are connected to 5 blocks The centre blocks are connected to 6 blocks If I actually built this it would be very stong and would be likely to remain largely intact even if it was damaged. Using the random chance idea this bridge would have a low chance to break completely.

Here is an example of an anchor point. By anchor point I mean any point where glass meets another surface. In my example it is where my glass bridge meets the stone. It could also be the feet of a glass statue for example. On this bridge each block is only connected to two other blocks. However working from right to left the next block is connected to 3 blocks, 1 either side and 1 below. Since this is connected to more blocks it would have a lower chance to break. The next block is connected to 5 blocks, 2 glass at the sides, 1 glass the side of the bridge, 1 stone the opposite side of the bridge, 1 stone below. Since it is connected to lots of blocks it would have a low chance to break.

If we determine a blocks strength by how many blocks it is connected to, and then give weaker blocks a higher chance to break we will get the effect that thin/frail glass constructs will break easily and completely. Chunky glass constructs will only break partially.

Bear in mind though that blocks hit directly should always have a 100% chance to break Is this making sense yet?

@bigmommulgrew: Go

Okay, awesome :)

I actually like this a lot, but here are a couple issues I foresee.

1) When you're dealing with chance like that, there's always a chance that a block is left out floating on its own, which might be difficult for me to catch (tho possible)

2) Difficult to configure, tho, this plugin is arguably already difficult to configure, from the viewpoint of most users who are incapable or otherwise unwilling to do 2 seconds of research before directly asking me a question (lol)

3) Adding more calculations for each block will increase the load this plugin deals to the server. I'm not sure how different it would be, but depending on how many blocks are connected, i might be running the code a couple hundred times a second, so that's something to consider.

Also, I would think the old system should remain in place. The two would work together fine, and the max blocks broken could be set higher and used as an actual cap.

Would you only count blocks of the same type, or any block?

1) When you're dealing with chance like that, there's always a chance that a block is left out floating on its own, which might be difficult for me to catch (tho possible)

I almost didnt post the request because of issues like this. I'm a programmer so although I dont know java I do have an idea of the issues involved and I didnt want to be requesting something that would be masses of work. I am however very willing to help test it, or any other addons decide to put in, one of my servers is only for testing anyway and the other is still being developed.

2) Difficult to configure, tho, this plugin is arguably already difficult to configure, from the viewpoint of most users who are incapable or otherwise unwilling to do 2 seconds of research before directly asking me a question (lol)

Yeah I hate it when people dont read the help files :) I dont think yours is particularly complex though. I've seen simpler plugins but my server currently has 35 with a queue of 65 more to go so this is nothing by comparison. I think you would benefit from a basic installation turorial, I couldnt see one. Just to explain the most important settings. I dont see random breaking adding many extra variables to the config file. Maybe RandomBreakChance: 90 #Base chance of random breaks before block strength and other calculations, lower numbers would make smaller random breaks EnableRandomBreaks: true # Use random breaking or the old method, I'm sure you can come up with a lot more you could add to fine tune it but surely thwy would be the only necessary ones.

3) Adding more calculations for each block will increase the load this plugin deals to the server. I'm not sure how different it would be, but depending on how many blocks are connected, i might be running the code a couple hundred times a second, so that's something to consider.

Yes I did think of this, I think Random breaking should be optional, with a comment in the config file saying something along the lines of "Warning, turning this on requires a high spec CPU or a low MaxBlocksBroken limit, but it doe make glass breaking more awsome"

Also, I would think the old system should remain in place. The two would work together fine, and the max blocks broken could be set higher and used as an actual cap.

Definately, as above. We dont want the kids running a server on their burnt out pile of junk in their bedroom to not be able to use EpicGlass any more.

Would you only count blocks of the same type, or any block?

Firstly I think any block connected to a block should count as adding strength to it. Going back to my example, if you build a glass bridge with an iron anchor point you wouldnt expect it to be weaker than one with a glass anchor point.

Secondly (even more CPU load coming) it may be a good idea to take into account a connected blocks type as well. So that blocks that would naturally make a bad anchor point would be more likely to break. For example build a bridge from a sand anchor point and it will be very likely to break. Build it from Obsidian and it will be less likely to break.

@Malikk65: Go

The points you bring up about server load all make sense, but I really like the idea the OP brought up. What about a super simplified version of this feature request such as:

In the config, have an option for the radius of a break. Default would be -1 and act as the plugin does now, but you could set it to 3 and it would make a 6x6 square or something. Then a huge window would just have a neat hole instead of the whole thing blowing out.

EDIT: So sorry, got super excited about this plugin and posted after only watching the videos and before reading the config, lol. I see there is a maxblocksbroken which works exactly like this. Anyway, thanks for the plugin! If you could limit server load the randomized situation with variances on strength based on thickness would be sweet.

I was just reading over these, and the issue of a floating block could be solved by an if statement if (the block breaks) check all the blocks touching it(would only need to be the 6 touching surface, not corners), if (any of those blocks(block B) has 0 blocks touching it) 100% chance to break the block(or if it would do this calculation before he block is broken, i don't know the code, a check to see if it is only touching one block)

For the config it would just require a minimum radius and a maximum radius, and the percentage would stagger from there, so distance x has 100-(x-min)*(100/(max-min+1)) percent chance of breaking. so say minimum radius is 3, and maxium radius is 6. and you are at a distance of 4 100-(4-3)*(100/(6-3+1)) = 100-1*100/4 = 75. likewise 5 would have 50%, 6 25%, and 7 would have 0% This would only add one variable to config, and if you wanted it to run like it currently does, make the two equal. To avoid a division by zero error, this would have to only run when max>min, so an if statement first.

You could probably add in an if statement, to check if the max radius is large enough(or could have a simple boolean in the config) and if ti is, add in a counter, so that the break only runs after a couple iterations. Would hardly be noticeable, but would make the load way easier on the server.

The having different anchors providing different anchor strength, could require a lot of checking, but you could limit the checking into an if statement to divide it in half based of the ID number, then do that again one or two times, making it 1/4+2 checks, or 1/8+3 checks, respectively, for worst case scenario

@joodoc: Go

The isolated block would be difficult to catch because it might only be isolated AFTER I've run through all of the blocks once. It would require me to check all of the blocks a second time to see if it has 0 blocks touching, effectively doubling the load on the server for one break.

Idk, tho, I'll be putting a bit of thought into all of this. The main concern I have tho is making sure the plugin still runs as smoothly and as optimally as possible. I would really like massive scale breaks to still go relatively smoothly.

I'll experiment around with some of these ideas.