It's been a looonnng time since I last touched vanilla minecraft, being sucked into modded minecraft and all kinds of other games. Having started playing vanilla 1.8 with a couple friends, I found myself wondering if this still worked. Seeing as a quick search of the forums yielded no results, I figured I'd test it myself and post back here. Thus, what follows is the results of my experimentation.
I had some trouble with the now much more fragile boats (which had been my go-to entity for this glitch), and minecarts didn't want to work either. My test setup wound up looking like this:
It's not meant to be pretty, all this is designed to do is:
Bounce the arrow to keep it from despawning
Create a detectable event when/if the collision box on the iron bars changes
Reset the arrow when/if that happens.
How the glitch used to work, I could shoot an arrow at the bars off to the side as shown above, and, as the arrows I just shot are newer than the one on the piston (oversimplification, but this is in effect how it works), the collision box of the bars they are in would become, in effect, the definitive collision box for iron bars overall. This would have the effect of the arrow on the piston falling through the iron bars (due to its careful positioning), hitting the slime block, and bouncing up, triggering the tripwire.
What actually happened was not at all what I had expected: there seems to be a discrepancy between the internal server and client as to whether this glitch works or not. The arrow will fall through the bars for a few ticks client side before the server corrects its position.
What this means: It's impossible to be sure without further testing, but it seems this glitch has been fixed, intentionally or otherwise. It could be that it still works with some of the other blocks that exhibited this behavior (and that bars and panes were fixed as part of getting colored panes), but I will have to test that later.
EDIT: I can confirm this does in fact still work with piston heads!!!
Rumors abound about a hermit amassing an army far to the east...
Villager Army
HP: 2000
Armor: 500
Attacks:
Charge! (infinite ammo): Sacrifice 15% hp to deal 50% current hp of damage
Mine (infinite ammo): Sacrifice 5% hp to restore armor to 25% of hp and fully restore mp, cannot act next turn
Powers:
Build (1mp/1max): increases building health by 10% current hp, takes 3 turns.
Buffs:
Self-sufficient: restore 5% hp each turn
Debuffs:
Combat Sense: cannot tell the difference between the pointy and dull ends of a sword. Damage -25%
Building Expertise: equally proficient with all building materials. Aesthetics -90%
Perfect Planning: I accidentally left my infinite villager spawner running... Lag +5ms
On their way via minecart from 4km out (nether distance). ETA: 5 rounds.
I'm a little confused what you mean by pre-allocating modules. Do you mean figuring out what will be in the next chunk by "placing" modules there?
Yeah, by that I meant letting the modules "claim" an area in a non-generated chunk, and actually generating them later, with the rest of the chunk. (So basically, as far as the module-placer is concerned, those modules are already there, but the terrain generator would still need to generate them later)
Hmm... If I were developing this mod, I would make three changes to your module format/generation.
1: I can't help thinking that generating multi-chunk buildings from the center would be a nightmare. I would go about it from the corners, but that would require rotating the module to fit (which would probably be a needed feature anyways)
2: I would make connection types case-insensitive strings, and allow a module to explicitly define supported types for each side. The default types (0-2) would translate to "wall", "hall", and "room" or similar. This would allow modules that are parts of larger buildings to define special connection types, like "tower-courtyard" or "garden-fence", and would make it easier to cross chunk borders without pre-generating modules.
EDIT: on second thought, this isn't a good way to get around pre-allocating modules, but I think it's a good way to describe different connections, like "3x4_hall" and "avenue", and good for connecting random modules within larger structures.
3: A couple changes to linking: make an option to _attempt_ to place a certain module where specified, but if it fails, just act as though it never tried to link, or optionally, default to a different module (note that this should take rarity or similar into account). Also, allow linking to a folder (randomly picks modules in the folder until one fits), and, if possible, wildcards. For example:
try link 1 0 0 aqueduct.txt 95% default aqueduct_end.txt
link 0 1 0 tower_parts\*
Also I'm a little concerned about the rarity system. If I understand correctly, if one module is particularly rare or hard to place, the next item in the list will be that much more common.
Do note that, while I have a little experience with minecraft modding, I have never once taken a sideways glance at the generation code, and have never worked with anything similar. So it's completely possible that these suggestions are all horrible. I'm just trying to help where I can with a great project
Just had an idea: what if we can switch this glitch around?
Can we somehow make a system that makes the player subject to the glitched hitboxes, instead of an arrow, minecart, or boat?
For example, can I make a system that will, at the push of a button, make me fall through the piston-base floor in my house?
Again, can someone explain this to a redstone level 0 beginner?
The fact that you know there's levels means you're at least level 1 :tongue.gif:
Basically, at any given time, every glass pane in the world has the same bounding box. Same with pistons, iron bars, and stairs. The bounding box is only changed when something collides* with these blocks, like an arrow, mob, a player's feet, a dropped item, etc. (*this is not entirely accurate, there are some other odd conditions)
So what happens is when that bounding box changes for, for example, every glass pane in the world, any arrow/boat/item will fall through what it should actually collide with, if it weren't for this... glitch. We then detect the fact that the piston is no longer lifting the item using pressure plates.
So, in short, the bounding box change changes every block of that type, and "older" entities will not re-calculate the box, thus falling through the wooden pressure plates, making the redstone turn off.
---
Also, there is a way to effectively have more channels. We could use multiple signals as an ID for each receiver, and use one of the other block types (possibly stairs) to act as an "in use" or "connected" bit. :smile.gif: (in fact, with only 2 signals, there can be 225 receivers per world :smile.gif:)
EDIT: as for uses:
Player 1: hey look a stronghold! but somebody has already been here. :/
*Player 2 dials in his stronghold base receiver, connected to tons of TNT*
Player 1 blew up.
Player 1: o_O
of course that's an extreme example. more practically, it could be used to enable/disable traps, spawners, lighting, all kinds of things that you might not want to be (or can't be) anywhere near. just wire up tons of these receivers bound to different addresses and take some iron bars/glass panes with you wherever you go :smile.gif:
alternatively, you could simply set up a transmitter in a storage room with a hole in the ceiling. dial a code and one of your many automatic farms gets redirected to that hole. operate your whole base from the storage room :biggrin.gif:
Well, to stop someone from leaving the entire map, you could hook an armageddon block up to a rapid pulsar, just far enough away that the chunk loads only when the player leaves the map.
It'll be effective regardless of flight (since chunk loading isn't affected by the Y coordinate), and creative won't help either (player can't even see it before it goes off).
Unfortunately, this is much more difficult to get to work for protecting individual map segments...
Just a thought: arrows can collide with invisible stairs, and boats, in turn, can collide with arrows.
Although this is not technically free-floating, from a distance both the stairs and arrows are invisible, giving the appearance of (painfully slow) flight. :smile.gif:
Do note that I haven't tested this, and that the positioning of the arrows may prove quite tricky.
Soo.. Which part of that is random? I haven't studied chaos theory etc. but last time I checked, if you don't know how to predict it, doesn't make it random. You just don't know the algorithm. As far as I've thought, "random" would require breaking the laws of physic... in pieces, since if it exists, it can be calculated at some point. To make something random, something would have to appear from somewhere for no reason (and why would something move for no reason?), and from that comment of yours it only seems that the particles aren't really random since they, according to you, do things when they intersect which could be predictable if we knew where those vibrations are and where they're going.
Ok, so if nothing is random, I propose we redefine random.
If you can predict where the stock market goes next you'll make bajillions!
Unfortunately, the problem here is that you would probably need a computer the size of a small universe to accurately predict it. But then, the simple act of observing it would, by necessity, interfere. For instance, would the you in this pocket universe have a pocket universe?
0
I had some trouble with the now much more fragile boats (which had been my go-to entity for this glitch), and minecarts didn't want to work either. My test setup wound up looking like this:
It's not meant to be pretty, all this is designed to do is:
How the glitch used to work, I could shoot an arrow at the bars off to the side as shown above, and, as the arrows I just shot are newer than the one on the piston (oversimplification, but this is in effect how it works), the collision box of the bars they are in would become, in effect, the definitive collision box for iron bars overall. This would have the effect of the arrow on the piston falling through the iron bars (due to its careful positioning), hitting the slime block, and bouncing up, triggering the tripwire.
What actually happened was not at all what I had expected: there seems to be a discrepancy between the internal server and client as to whether this glitch works or not. The arrow will fall through the bars for a few ticks client side before the server corrects its position.
What this means: It's impossible to be sure without further testing, but it seems this glitch has been fixed, intentionally or otherwise. It could be that it still works with some of the other blocks that exhibited this behavior (and that bars and panes were fixed as part of getting colored panes), but I will have to test that later.
EDIT: I can confirm this does in fact still work with piston heads!!!
0
Owwww... (Switches proxies)
Speaking of which... (Hacks the proxy the hacker is connected to, to try and get the ip of the next proxy :P)
Rail Gun 3/?
0
Ill also try to hack the server's router/firewall.
0
Also I start building a rail gun (equally capable of piercing bedrock as soggy newspapers, geothermal powered) 1/?
0
Villager Army: 2/15
0
Villager Army
HP: 2000
Armor: 500
Attacks:
Charge! (infinite ammo): Sacrifice 15% hp to deal 50% current hp of damage
Mine (infinite ammo): Sacrifice 5% hp to restore armor to 25% of hp and fully restore mp, cannot act next turn
Powers:
Build (1mp/1max): increases building health by 10% current hp, takes 3 turns.
Buffs:
Self-sufficient: restore 5% hp each turn
Debuffs:
Combat Sense: cannot tell the difference between the pointy and dull ends of a sword. Damage -25%
Building Expertise: equally proficient with all building materials. Aesthetics -90%
Perfect Planning: I accidentally left my infinite villager spawner running... Lag +5ms
On their way via minecart from 4km out (nether distance). ETA: 5 rounds.
1/5
0
Yeah, by that I meant letting the modules "claim" an area in a non-generated chunk, and actually generating them later, with the rest of the chunk. (So basically, as far as the module-placer is concerned, those modules are already there, but the terrain generator would still need to generate them later)
0
1: I can't help thinking that generating multi-chunk buildings from the center would be a nightmare. I would go about it from the corners, but that would require rotating the module to fit (which would probably be a needed feature anyways)
2: I would make connection types case-insensitive strings, and allow a module to explicitly define supported types for each side. The default types (0-2) would translate to "wall", "hall", and "room" or similar. This would allow modules that are parts of larger buildings to define special connection types, like "tower-courtyard" or "garden-fence", and would make it easier to cross chunk borders without pre-generating modules.
EDIT: on second thought, this isn't a good way to get around pre-allocating modules, but I think it's a good way to describe different connections, like "3x4_hall" and "avenue", and good for connecting random modules within larger structures.
3: A couple changes to linking: make an option to _attempt_ to place a certain module where specified, but if it fails, just act as though it never tried to link, or optionally, default to a different module (note that this should take rarity or similar into account). Also, allow linking to a folder (randomly picks modules in the folder until one fits), and, if possible, wildcards. For example:
try link 1 0 0 aqueduct.txt 95% default aqueduct_end.txt
link 0 1 0 tower_parts\*
Also I'm a little concerned about the rarity system. If I understand correctly, if one module is particularly rare or hard to place, the next item in the list will be that much more common.
Do note that, while I have a little experience with minecraft modding, I have never once taken a sideways glance at the generation code, and have never worked with anything similar. So it's completely possible that these suggestions are all horrible. I'm just trying to help where I can with a great project
0
Can we somehow make a system that makes the player subject to the glitched hitboxes, instead of an arrow, minecart, or boat?
For example, can I make a system that will, at the push of a button, make me fall through the piston-base floor in my house?
0
Yes, assuming:
1: "X" is a wireless receiver/transmitter
2: the receiver is in a loaded chunk
yep. no wire at all, except from the receiver to the trap door :smile.gif:
0
The fact that you know there's levels means you're at least level 1 :tongue.gif:
Basically, at any given time, every glass pane in the world has the same bounding box. Same with pistons, iron bars, and stairs. The bounding box is only changed when something collides* with these blocks, like an arrow, mob, a player's feet, a dropped item, etc. (*this is not entirely accurate, there are some other odd conditions)
So what happens is when that bounding box changes for, for example, every glass pane in the world, any arrow/boat/item will fall through what it should actually collide with, if it weren't for this... glitch. We then detect the fact that the piston is no longer lifting the item using pressure plates.
So, in short, the bounding box change changes every block of that type, and "older" entities will not re-calculate the box, thus falling through the wooden pressure plates, making the redstone turn off.
---
Also, there is a way to effectively have more channels. We could use multiple signals as an ID for each receiver, and use one of the other block types (possibly stairs) to act as an "in use" or "connected" bit. :smile.gif: (in fact, with only 2 signals, there can be 225 receivers per world :smile.gif:)
EDIT: as for uses:
Player 1: hey look a stronghold! but somebody has already been here. :/
*Player 2 dials in his stronghold base receiver, connected to tons of TNT*
Player 1 blew up.
Player 1: o_O
of course that's an extreme example. more practically, it could be used to enable/disable traps, spawners, lighting, all kinds of things that you might not want to be (or can't be) anywhere near. just wire up tons of these receivers bound to different addresses and take some iron bars/glass panes with you wherever you go :smile.gif:
alternatively, you could simply set up a transmitter in a storage room with a hole in the ceiling. dial a code and one of your many automatic farms gets redirected to that hole. operate your whole base from the storage room :biggrin.gif:
0
It'll be effective regardless of flight (since chunk loading isn't affected by the Y coordinate), and creative won't help either (player can't even see it before it goes off).
Unfortunately, this is much more difficult to get to work for protecting individual map segments...
0
2. Have you played on the server for more then 4 days? : today is the 4th
3. How old are you? : 18
0
Although this is not technically free-floating, from a distance both the stairs and arrows are invisible, giving the appearance of (painfully slow) flight. :smile.gif:
Do note that I haven't tested this, and that the positioning of the arrows may prove quite tricky.
0
Ok, so if nothing is random, I propose we redefine random.
Unfortunately, the problem here is that you would probably need a computer the size of a small universe to accurately predict it. But then, the simple act of observing it would, by necessity, interfere. For instance, would the you in this pocket universe have a pocket universe?