PSN:
Junokaii (although I'd recommend not adding me because I'm on literally like... once every month or two)
Member Details
You're mining a block of obsidian with a normal pick axe (no enchantments etc).. it takes a decent time to break it. The cracking is starting to take up the whole block and it's almost broken WHEN...... Your friend accidentally bumps into you and the block is Instantly repaired and you have to start the process over.
My proposal is... Instead of having blocks "unmine" instantly... have them gradually go back to it's normal state in a sort of "reverse" of what it does when you are actually breaking it. So you slowly start seeing the block go back to it's normal state in a fashion of how it looks like when you are actually trying to break it.
This would be especially useful because.. say your friend does bump into you.. or accidentally gets in your way so you hit him instead of the block.. you could have a sort of... "opening" to continue back where you were instead of having to start breaking the block over entirely because it's gradually going back to it's original state.
I can see the argument of how this is unnecessary. But.. I also see this as being useful.
ummm... you apparently have annoying friends who have a habit of either getting in your way or bumping you around when you are trying to mine.
At least my friends only get between me and my target as I'm shooting them in the back with an arrow...sometimes I think they'll never learn... don't step directly between an archer and his target AS he is in the process of firing his bow.
Seriously though, I can see a few downsides to this, but some upsides as well in that you could have multiple people working on the same block to mine it in half the time (which can be useful in the case of obsidian).
All in all, I don't have a problem with this suggestion, the trade-off seems to be overall fair. (ie. Zombies would have an easier time breaking doors on hard mode because the door doesn't immediately reset itself).
ummm... you apparently have annoying friends who have a habit of either getting in your way or bumping you around when you are trying to mine.
At least my friends only get between me and my target as I'm shooting them in the back with an arrow...sometimes I think they'll never learn... don't step directly between an archer and his target AS he is in the process of firing his bow.
Seriously though, I can see a few downsides to this, but some upsides as well in that you could have multiple people working on the same block to mine it in half the time (which can be useful in the case of obsidian).
All in all, I don't have a problem with this suggestion, the trade-off seems to be overall fair. (ie. Zombies would have an easier time breaking doors on hard mode because the door doesn't immediately reset itself).
Funny............
Well I was just using the friend in the way as an example... there's tonnes of ways to have things make it so that you end up not getting the block.
I'd be okay with the zombie thing to be honest..
Since I use gates instead of doors... Unless they learn how to aim down and break something I'm pretty much safe. Next step should I need it.. Just a piston door with stone etc.
Even though there isn't anything wrong with your suggestion it seems a bit pointless to me. Its only on a rare occasion that someone I'm playing with gets in my way and it doesn't take long to break any block provided you have the right tool of course(obviously obsidian is an exception).
Even the simplest block to break, can take away a lot of time over a long period of time. Might save a measly 2 seconds.. but over 30 blocks that's one miniute of extra time going towards things that matter.
I do see why it is also pointless, but it could also be things like... your finger slips or something and you accidentally aim at something else.
Changing the way blocks behave just to shave off a minute isn't very practical in my eyes.
Actually... I'm warming up to the idea... in fact, it could be like a slider bar in the options. Far Left, blocks restore instantly as they do now in the game, while far Right, blocks don't repair at all until replaced, and remain in what ever damaged state they were last left in, somewhere in the middle adjusts how quickly they recover over time.
Having blocks just remain damaged and not repairing at all would be interesting to have on multiplayer PvP siege maps.
The problem is this would break ALOT of how MC works, including block updates and require quite an overhaul to the way the 'server' code works. I kind of like the idea but to implement it would be no easy feat, and could break alot of the internals to how MC works.
The problem is this would break ALOT of how MC works, including block updates and require quite an overhaul to the way the 'server' code works. I kind of like the idea but to implement it would be no easy feat, and could break alot of the internals to how MC works.
After looking over some of the Java code from the PC version, technically from a programming stance it seems doable... but I have to agree that practically, it could cause a lot more block-updates happening at once which could strain the RAM and processor of the 360 if the system has to perform a lot of regular block updates to track damage on a higher volume of blocks, and render cracked graphics appropriately.
PSN:
Junokaii (although I'd recommend not adding me because I'm on literally like... once every month or two)
Member Details
Hmm.. slider thing... sounds interesting.
Because.. yeah I know it's a game... But... Would you really be able to go to someone's house and hit it with an axe, or something etc and then just look away for 0.00001 seconds and have it look like it was just refinished? Lol.
But at the same time.. yeah it doesn't overly matter. Even it was slow repairing... Taking 10+ seconds for each block to fully repair, depending on the damaged state it's in before it was mined.
Thats not really the problem Junokaii. The problem is that as you are mining something its really only being mined on 'your end' at the client level, when the block breaks it sends this to the server. Although as you mine it does send that you are mining that block to the server as well, but it doesn't actually register any work being done at the server level per say.
In order for this to work first we would need to move the 'break state' to the server level, and also all work has to be moved to the server level, state would need to be able to reverse itself should work stop, which would then cause block update for each state that occured, which could break alot of things.
I don't think its doable without putting alot of strain on the server, though i could see alot of uses for it in the future, such as explosions actually damaging blocks as well, ect
Thats not really the problem Junokaii. The problem is that as you are mining something its really only being mined on 'your end' at the client level, when the block breaks it sends this to the server. Although as you mine it does send that you are mining that block to the server as well, but it doesn't actually register any work being done at the server level per say.
In order for this to work first we would need to move the 'break state' to the server level, and also all work has to be moved to the server level, state would need to be able to reverse itself should work stop, which would then cause block update for each state that occured, which could break alot of things.
I don't think its doable without putting alot of strain on the server, though i could see alot of uses for it in the future, such as explosions actually damaging blocks as well, ect
To add to this...
The Block Class (a data/method element within the program) already tracks damage done to it as a block is being 'mined', this is handled on the server side and is used to determine which cracked transparent graphic overlay it places on the sides of those blocks. When a user stops mining after a period the block resets to it's undamaged state. As I stated above, I don't think that there would be too much of a programming challenge to basically reverse the Damage over Time sequence for the block instead of just arbitrarily resetting it, but there is a memory and processing strain that would be added to the server for handing this for each block it has to track for repair purposes.
Players quite like mining obsidian and the method of stopping the lava flow underneath which leaves you with a lot of safe blocks, this change would make mining this particular block much easier. (This will not be most peoples main concern with this idea but it is a concern of mine.)
I don't see how... obsidian still mines at the same rate if you don't get bumped, or stop mining the block for some reason.
People like mining and the risk that comes with it. If you make it easier then it takes the fun out of it. Here are some sub points that back this point up:
If your last pick unfortunately breaks whilst mining a valuable ore someone else wouldn't have to do a lot to break it
If there is lava behind a damaged block and you accidentally hit it just once there could be bad consequences. Although this adds a higher risk level it is inconsistent to how people mine now therefore it would frustrate a lot of people.
It would make the transition from wood pick to stone pic and stone pic to iron pic a lot easier.
This never happens... tool breakage only happens after the block breaks, if the block doesn't break then the tool doesn't incur damage.
No more than if there is lava behind a block and you hit it once, as it is designed right now. Cracked blocks don't allow anything past them any more while mining than if this were in place. In fact wooden signs will stop lava flow without bad thing happening.
It would make the transition between tools pointless... the one that successfully breaks the block is the one that incurs the damage to it for use. (see #1)
It would be a nice feature but it would be too much for the 360 to handle. Actually I don't think minecraft itself could handle this feature. TNT explosions could probably crash a game very easily this way.
i like the idea. it sounds very practical. i think it should vary block to block though. higher the block health slower it reverts and vice versa. or maybe even by block type too.
i like the idea. it sounds very practical. i think it should vary block to block though. higher the block health slower it reverts and vice versa. or maybe even by block type too.
Well.. My intention was to have... Basically the rate it breaks.. is the rate it 'repairs itself', per block of breakage.
Or for the sake of challenge.. The ones that are harder to break are the ones that repair faster.
For example... Obsidian takes longer to mine than Stone. But have the Obsidian repair itself faster because it's harder to break.
But generally speaking... I like hte idea of it just.. repairing itself the same speed it breaks.
But generally speaking... I like hte idea of it just.. repairing itself the same speed it breaks.
Actually... you'd want it to repair at a set rate of damage over time per block type... breaking at the same speed it breaks would mean that the game would have to track how fast damage was applied to the block from that tool (or explosion) that did the damage. You'd end up with things damaged by explosions or by an enchanted diamond pickax with efficiency IV, would repair (almost) immediately, while the same block types damaged by fists would be extremely slow in repairing.
I think that if the damage recovery was at a standard rate over time, you would get the effect that you are looking for, ie. where wood repairs much faster than obsidian (because wood can take less damage before breaking than obsidian can).
But still there is the memory management concern of something like a massive TNT blast doing damage to multiple blocks at once, causing a huge amount of block updates over time that need to be managed... something like this could cause excessive lag for a long time, and could potentially crash the game.
Having to track how fast damage accumulated over time would be much more complex from a memory management perspective and would make game lag/crashing that much more likely when handled on a larger scale... and I don't think it would have quite the effect you are really looking for.
Actually... I'm warming up to the idea... in fact, it could be like a slider bar in the options. Far Left, blocks restore instantly as they do now in the game, while far Right, blocks don't repair at all until replaced, and remain in what ever damaged state they were last left in, somewhere in the middle adjusts how quickly they recover over time.
Having blocks just remain damaged and not repairing at all would be interesting to have on multiplayer PvP siege maps.
Having this option, could make another thread I made called "Hammers", virtually useless. This could pretty much make my suggestion there all with a slider bar in this option for your "far right" idea.
Because my suggestion with the hammer, was to create all kinds of "cracked blocks" to give things a more, "rugged" look, and have the ability to have things look more rundown and ancient. With your option, I wouldn't ever need my idea. I could have all kinds of differently cracked blocks, in many different pattern way easier.
Because each block has different levels of "broken-ness" depending how long you keep breaking it for, I could make things look real interesting. Only downfall to that vs my idea, is the hammer would make it permanent. While this COULD be permanent, it would have to have the slider on the right, all the time, forever for that world whereas the hammer you wouldn't have to.
Actually... you'd want it to repair at a set rate of damage over time per block type... breaking at the same speed it breaks would mean that the game would have to track how fast damage was applied to the block from that tool (or explosion) that did the damage. You'd end up with things damaged by explosions or by an enchanted diamond pickax with efficiency IV, would repair (almost) immediately, while the same block types damaged by fists would be extremely slow in repairing.
I think that if the damage recovery was at a standard rate over time, you would get the effect that you are looking for, ie. where wood repairs much faster than obsidian (because wood can take less damage before breaking than obsidian can).
But still there is the memory management concern of something like a massive TNT blast doing damage to multiple blocks at once, causing a huge amount of block updates over time that need to be managed... something like this could cause excessive lag for a long time, and could potentially crash the game.
Having to track how fast damage accumulated over time would be much more complex from a memory management perspective and would make game lag/crashing that much more likely when handled on a larger scale... and I don't think it would have quite the effect you are really looking for.
Yeah... Now that you mention that yeah. Perhaps a standard issue would be better. But would your idea of a standard be the same for each block? Or like in my suggestion where it does the same as the block has in itself? ie Wood vs Obsidian like you mentioned?
Having this option, could make another thread I made called "Hammers", virtually useless. This could pretty much make my suggestion there all with a slider bar in this option for your "far right" idea.
Because my suggestion with the hammer, was to create all kinds of "cracked blocks" to give things a more, "rugged" look, and have the ability to have things look more rundown and ancient. With your option, I wouldn't ever need my idea. I could have all kinds of differently cracked blocks, in many different pattern way easier.
Because each block has different levels of "broken-ness" depending how long you keep breaking it for, I could make things look real interesting. Only downfall to that vs my idea, is the hammer would make it permanent. While this COULD be permanent, it would have to have the slider on the right, all the time, forever for that world whereas the hammer you wouldn't have to.
If this adjustable rate of block repair was implemented, then that makes your hammer idea easier to implement into the game, because the core code to alter block repair rates would already be in place.
Yeah... Now that you mention that yeah. Perhaps a standard issue would be better. But would your idea of a standard be the same for each block? Or like in my suggestion where it does the same as the block has in itself? ie Wood vs Obsidian like you mentioned?
Each block has a specific 'Hardness' that must be overcome to break it. It takes the standard diamond pickaxe 9.4 seconds to break obsidian, and one tenth that time (0.95 seconds) to break anything with a hardness of 5.
Hypothetically, if you set the slide bar to a slow recover setting, it could take 1 second per point of hardness damage done to the block to fully recover... so if you have 2 blocks each damaged down to 1 hardness, one Obsidian (50), and 1 Wood (2), it would take the Wood block only 1 second to fully recover, while it would take 49 seconds for the Obsidian to fully recover. This would be using a standard recovery rate for each block based on the number of Hardness points of damage that block had incurred.
If this adjustable rate of block repair was implemented, then that makes your hammer idea easier to implement into the game, because the core code to alter block repair rates would already be in place.
Each block has a specific 'Hardness' that must be overcome to break it. It takes the standard diamond pickaxe 9.4 seconds to break obsidian, and one tenth that time (0.95 seconds) to break anything with a hardness of 5.
Hypothetically, if you set the slide bar to a slow recover setting, it could take 1 second per point of hardness damage done to the block to fully recover... so if you have 2 blocks each damaged down to 1 hardness, one Obsidian (50), and 1 Wood (2), it would take the Wood block only 1 second to fully recover, while it would take 49 seconds for the Obsidian to fully recover. This would be using a standard recovery rate for each block based on the number of Hardness points of damage that block had incurred.
49 seconds huh?? I didn't think that it would be that kind of opening to continue where you left off that's hilarious. You could go empty your inventory in an empty chest and have enough time to come back to the block lol.
Perhaps that could... be adjusted for the sake of the suggestion? Maybe have a maximum of 6-10 seconds and a minimum of 2?
49 seconds huh?? I didn't think that it would be that kind of opening to continue where you left off that's hilarious. You could go empty your inventory in an empty chest and have enough time to come back to the block lol.
Perhaps that could... be adjusted for the sake of the suggestion? Maybe have a maximum of 6-10 seconds and a minimum of 2?
You could use fractional exponentials to create a sliding scale to bring the timing more n alignment with each other... but then you would want to store that recovery rate, alternatively, you could divide the durability by the block hardness to decrease the time of recovery for the harder to mine blocks. there are a number of ways where it could be handled to bring them into closer recovery alignment, including assigning a different recovery rate to each block type.
The point is, is that you would want a standard rate of block recovery, not something that changes depending on how fast you mine it (since that is variable and based on how it takes damage and what tools are used).
My proposal is... Instead of having blocks "unmine" instantly... have them gradually go back to it's normal state in a sort of "reverse" of what it does when you are actually breaking it. So you slowly start seeing the block go back to it's normal state in a fashion of how it looks like when you are actually trying to break it.
This would be especially useful because.. say your friend does bump into you.. or accidentally gets in your way so you hit him instead of the block.. you could have a sort of... "opening" to continue back where you were instead of having to start breaking the block over entirely because it's gradually going back to it's original state.
I can see the argument of how this is unnecessary. But.. I also see this as being useful.
Thoughts?
ummm... you apparently have annoying friends who have a habit of either getting in your way or bumping you around when you are trying to mine.
At least my friends only get between me and my target as I'm shooting them in the back with an arrow...sometimes I think they'll never learn... don't step directly between an archer and his target AS he is in the process of firing his bow.
Seriously though, I can see a few downsides to this, but some upsides as well in that you could have multiple people working on the same block to mine it in half the time (which can be useful in the case of obsidian).
All in all, I don't have a problem with this suggestion, the trade-off seems to be overall fair. (ie. Zombies would have an easier time breaking doors on hard mode because the door doesn't immediately reset itself).
Funny............
Well I was just using the friend in the way as an example... there's tonnes of ways to have things make it so that you end up not getting the block.
I'd be okay with the zombie thing to be honest..
Since I use gates instead of doors... Unless they learn how to aim down and break something I'm pretty much safe. Next step should I need it.. Just a piston door with stone etc.
Even the simplest block to break, can take away a lot of time over a long period of time. Might save a measly 2 seconds.. but over 30 blocks that's one miniute of extra time going towards things that matter.
I do see why it is also pointless, but it could also be things like... your finger slips or something and you accidentally aim at something else.
Actually... I'm warming up to the idea... in fact, it could be like a slider bar in the options. Far Left, blocks restore instantly as they do now in the game, while far Right, blocks don't repair at all until replaced, and remain in what ever damaged state they were last left in, somewhere in the middle adjusts how quickly they recover over time.
Having blocks just remain damaged and not repairing at all would be interesting to have on multiplayer PvP siege maps.
After looking over some of the Java code from the PC version, technically from a programming stance it seems doable... but I have to agree that practically, it could cause a lot more block-updates happening at once which could strain the RAM and processor of the 360 if the system has to perform a lot of regular block updates to track damage on a higher volume of blocks, and render cracked graphics appropriately.
Because.. yeah I know it's a game... But... Would you really be able to go to someone's house and hit it with an axe, or something etc and then just look away for 0.00001 seconds and have it look like it was just refinished? Lol.
But at the same time.. yeah it doesn't overly matter. Even it was slow repairing... Taking 10+ seconds for each block to fully repair, depending on the damaged state it's in before it was mined.
In order for this to work first we would need to move the 'break state' to the server level, and also all work has to be moved to the server level, state would need to be able to reverse itself should work stop, which would then cause block update for each state that occured, which could break alot of things.
I don't think its doable without putting alot of strain on the server, though i could see alot of uses for it in the future, such as explosions actually damaging blocks as well, ect
To add to this...
The Block Class (a data/method element within the program) already tracks damage done to it as a block is being 'mined', this is handled on the server side and is used to determine which cracked transparent graphic overlay it places on the sides of those blocks. When a user stops mining after a period the block resets to it's undamaged state. As I stated above, I don't think that there would be too much of a programming challenge to basically reverse the Damage over Time sequence for the block instead of just arbitrarily resetting it, but there is a memory and processing strain that would be added to the server for handing this for each block it has to track for repair purposes.
I don't see how this would really make the game that much tougher... You'll have to elaborate.
None... wait 2 minutes and the damage will repair itself (unless the host turned repairing off entirely for some reason)
I don't see how... obsidian still mines at the same rate if you don't get bumped, or stop mining the block for some reason.
I just came up with the idea. how it works is pointless to me
Well.. My intention was to have... Basically the rate it breaks.. is the rate it 'repairs itself', per block of breakage.
Or for the sake of challenge.. The ones that are harder to break are the ones that repair faster.
For example... Obsidian takes longer to mine than Stone. But have the Obsidian repair itself faster because it's harder to break.
But generally speaking... I like hte idea of it just.. repairing itself the same speed it breaks.
Actually... you'd want it to repair at a set rate of damage over time per block type... breaking at the same speed it breaks would mean that the game would have to track how fast damage was applied to the block from that tool (or explosion) that did the damage. You'd end up with things damaged by explosions or by an enchanted diamond pickax with efficiency IV, would repair (almost) immediately, while the same block types damaged by fists would be extremely slow in repairing.
I think that if the damage recovery was at a standard rate over time, you would get the effect that you are looking for, ie. where wood repairs much faster than obsidian (because wood can take less damage before breaking than obsidian can).
But still there is the memory management concern of something like a massive TNT blast doing damage to multiple blocks at once, causing a huge amount of block updates over time that need to be managed... something like this could cause excessive lag for a long time, and could potentially crash the game.
Having to track how fast damage accumulated over time would be much more complex from a memory management perspective and would make game lag/crashing that much more likely when handled on a larger scale... and I don't think it would have quite the effect you are really looking for.
Having this option, could make another thread I made called "Hammers", virtually useless. This could pretty much make my suggestion there all with a slider bar in this option for your "far right" idea.
Because my suggestion with the hammer, was to create all kinds of "cracked blocks" to give things a more, "rugged" look, and have the ability to have things look more rundown and ancient. With your option, I wouldn't ever need my idea. I could have all kinds of differently cracked blocks, in many different pattern way easier.
Because each block has different levels of "broken-ness" depending how long you keep breaking it for, I could make things look real interesting. Only downfall to that vs my idea, is the hammer would make it permanent. While this COULD be permanent, it would have to have the slider on the right, all the time, forever for that world whereas the hammer you wouldn't have to.
Yeah... Now that you mention that yeah. Perhaps a standard issue would be better. But would your idea of a standard be the same for each block? Or like in my suggestion where it does the same as the block has in itself? ie Wood vs Obsidian like you mentioned?
If this adjustable rate of block repair was implemented, then that makes your hammer idea easier to implement into the game, because the core code to alter block repair rates would already be in place.
The best way to understand it is to look at the chart on this page for digging: http://minecraft.gamepedia.com/Digging
Each block has a specific 'Hardness' that must be overcome to break it. It takes the standard diamond pickaxe 9.4 seconds to break obsidian, and one tenth that time (0.95 seconds) to break anything with a hardness of 5.
Hypothetically, if you set the slide bar to a slow recover setting, it could take 1 second per point of hardness damage done to the block to fully recover... so if you have 2 blocks each damaged down to 1 hardness, one Obsidian (50), and 1 Wood (2), it would take the Wood block only 1 second to fully recover, while it would take 49 seconds for the Obsidian to fully recover. This would be using a standard recovery rate for each block based on the number of Hardness points of damage that block had incurred.
49 seconds huh?? I didn't think that it would be that kind of opening to continue where you left off that's hilarious. You could go empty your inventory in an empty chest and have enough time to come back to the block lol.
Perhaps that could... be adjusted for the sake of the suggestion? Maybe have a maximum of 6-10 seconds and a minimum of 2?
You could use fractional exponentials to create a sliding scale to bring the timing more n alignment with each other... but then you would want to store that recovery rate, alternatively, you could divide the durability by the block hardness to decrease the time of recovery for the harder to mine blocks. there are a number of ways where it could be handled to bring them into closer recovery alignment, including assigning a different recovery rate to each block type.
The point is, is that you would want a standard rate of block recovery, not something that changes depending on how fast you mine it (since that is variable and based on how it takes damage and what tools are used).