Christopher Durham
- cad97
- cad97
- America/New_York
- Yes
- No
MC-33915
Smooth sandstone appears in an item frame sidwaysinvalid
When you get into a bed facing from the foot towards the head (i.e. when getting in you turn around), you end up looking at chunks that are not rendered.
Relates to
MC-63070- when viewing chunks outside the normal frustum either by their method (F5, high FOV) or this one (bed) they won't render. Fixing one should fix the other.Steps to easily reproduce
1. Build a wall
2. Stand on one side of the wall, facing away
3. Put down a bed in front of you
4. Get in the bed
5. See un-rendered chunks
When you get into a bed facing from the foot towards the head (i.e. when getting in you turn around), you end up looking at chunks that are not rendered.
Relates to
MC-63070- when viewing chunks outside the normal frustum either by their method (F5, high FOV) or this one (bed) they won't render. Fixing one should fix the other.Steps to easily reproduce
1. Build a wall
2. Stand on one side of the wall, facing away, inside a different chunk
3. Put down a bed in front of you
4. Get in the bed
5. See un-rendered chunks
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.
http://youtu.be/c24XFa6n6Lw
(Uploading currently)
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
[Imgur](http://i.imgur.com/FCtKXJj.gifv)
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.
http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
[Imgur](http://i.imgur.com/FCtKXJj.gifv)
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.
http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.
http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail
{powered=false}, Powered Rail == minecraft:golden_rail {powered=true}, {this is a block state})
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.
This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
minecraft:golden_rail replaces it's boolean {powered} with a four bit integer {power} from 0-9.
A {power} of 0 is unpowered, like the old {powered=false}, and a
{power} between 1 and 9 acts like the old {powered=true}.
When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's {power}to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
{powered}
If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a> 0, it takes the highest adjacent
{power} and sets it's own {power}to the adjacent
{power} - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
Possible feature creep by change:
Since block state is tied to the rendering system, brightness level of golden rail's glow depending on {power}.
{power}
Redstone signal strength into golden rail determines how far the power propagates.
Different speed boost depending on.
Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail
{powered=false}, Powered Rail == minecraft:golden_rail {powered=true}, {this is a block state})
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.
This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
minecraft:golden_rail replaces it's boolean {powered} with a four bit integer {power} from 0-9.
A {power} of 0 is unpowered, like the old {powered=false}, and a
{power} between 1 and 9 acts like the old {powered=true}.
When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's {power}to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
{powered}
If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a> 0, it takes the highest adjacent
{power} and sets it's own {power}to the adjacent
{power} - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
Possible feature creep by change:
Since block state is tied to the rendering system, brightness level of golden rail's glow depending on {power}.
{power}
Redstone signal strength into golden rail determines how far the power propagates.
Different speed boost depending on.
Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail <powered=false>, Powered Rail == minecraft:golden_rail <powered=true>, <this is a block state>)
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
minecraft:golden_rail replaces it's boolean <powered> with a four bit integer <power> from 0-9.
A <power> of 0 is unpowered, like the old <powered=false>, and a <power> between 1 and 9 acts like the old <powered=true>.
When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's <power> to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a <powered> > 0, it takes the highest adjacent <power> and sets it's own <power> to the adjacent <power> - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.Possible feature creep by change:
{power}
Since block state is tied to the rendering system, brightness level of golden rail's glow depending on.
Redstone signal strength into golden rail determines how far the power propagates.
Different speed boost depending on <power>.Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail <powered=false>, Powered Rail == minecraft:golden_rail <powered=true>, <this is a block state>)
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
minecraft:golden_rail replaces it's boolean <powered> with a four bit integer <power> from 0-9.
A <power> of 0 is unpowered, like the old <powered=false>, and a <power> between 1 and 9 acts like the old <powered=true>.
When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's <power> to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a <powered> > 0, it takes the highest adjacent <power> and sets it's own <power> to the adjacent <power> - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.Possible feature creep by change:
{power}
Since block state is tied to the rendering system, brightness level of golden rail's glow depending on.
Redstone signal strength into golden rail determines how far the power propagates.
Different speed boost depending on <power>.Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
1. Create a line of powered rail
2. Place down a redstone torch to power it
3. Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
4. Note no rail gets power until manually updatedCase B:
1. Create a flat line of powered rail
2. Place redstone torches all along the side
3. From one side, destroy all the torches but the last one in order
4. Note no rail gets depoweredPossible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail <powered=false>, Powered Rail == minecraft:golden_rail <powered=true>, <this is a block state>)
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
minecraft:golden_rail replaces it's boolean <powered> with a four bit integer <power> from 0-9.
A <power> of 0 is unpowered, like the old <powered=false>, and a <power> between 1 and 9 acts like the old <powered=true>.
When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's <power> to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a <powered> > 0, it takes the highest adjacent <power> and sets it's own <power> to the adjacent <power> - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.Possible feature creep by change:
Since block state is tied to the rendering system, brightness level of golden rail's glow depending on <power>.
Redstone signal strength into golden rail determines how far the power propagates.
Different speed boost depending on <power>.Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
- Create a line of powered rail
- Place down a redstone torch to power it
- Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
- Note no rail gets power until manually updated
Case B:
- Create a flat line of powered rail
- Place redstone torches all along the side
- From one side, destroy all the torches but the last one in order
- Note no rail gets depowered
Possible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail <powered=false>, Powered Rail == minecraft:golden_rail <powered=true>, <this is a block state>)
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
minecraft:golden_rail replaces it's boolean <powered> with a four bit integer <power> from 0-9.
A <power> of 0 is unpowered, like the old <powered=false>, and a <power> between 1 and 9 acts like the old <powered=true>.
When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's <power> to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a <powered> > 0, it takes the highest adjacent <power> and sets it's own <power> to the adjacent <power> - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.Possible feature creep by change:
Since block state is tied to the rendering system, brightness level of golden rail's glow depending on <power>.
Redstone signal strength into golden rail determines how far the power propagates.
Different speed boost depending on <power>.Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
- Create a line of powered rail
- Place down a redstone torch to power it
- Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
- Note no rail gets power until manually updated
Case B:
- Create a flat line of powered rail
- Place redstone torches all along the side
- From one side, destroy all the torches but the last one in order
- Note no rail gets depowered
Possible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
. More/Less speed depending on power?
. Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
. More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail <powered=false>, Powered Rail == minecraft:golden_rail <powered=true>, <this is a block state>)
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
*minecraft:golden_rail replaces it's boolean <powered> with a four bit integer <power> from 0-9.
*A <power> of 0 is unpowered, like the old <powered=false>, and a <power> between 1 and 9 acts like the old <powered=true>.
*When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's <power> to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
*If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a <powered> > 0, it takes the highest adjacent <power> and sets it's own <power> to the adjacent <power> - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.Possible feature creep by change:
*Since block state is tied to the rendering system, brightness level of golden rail's glow depending on <power>.
*Redstone signal strength into golden rail determines how far the power propagates.
*Different speed boost depending on <power>.Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
- Create a line of powered rail
- Place down a redstone torch to power it
- Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
- Note no rail gets power until manually updated
Case B:
- Create a flat line of powered rail
- Place redstone torches all along the side
- From one side, destroy all the torches but the last one in order
- Note no rail gets depowered
Possible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
- More/Less speed depending on power?
- Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
- More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail <powered=false>, Powered Rail == minecraft:golden_rail <powered=true>, <this is a block state>)
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
*minecraft:golden_rail replaces it's boolean <powered> with a four bit integer <power> from 0-9.
*A <power> of 0 is unpowered, like the old <powered=false>, and a <power> between 1 and 9 acts like the old <powered=true>.
*When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's <power> to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
*If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a <powered> > 0, it takes the highest adjacent <power> and sets it's own <power> to the adjacent <power> - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.Possible feature creep by change:
*Since block state is tied to the rendering system, brightness level of golden rail's glow depending on <power>.
*Redstone signal strength into golden rail determines how far the power propagates.
*Different speed boost depending on <power>.Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
- Create a line of powered rail
- Place down a redstone torch to power it
- Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
- Note no rail gets power until manually updated
Case B:
- Create a flat line of powered rail
- Place redstone torches all along the side
- From one side, destroy all the torches but the last one in order
- Note no rail gets depowered
Possible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
- More/Less speed depending on power?
- Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
- More balance for possible return of faster minecarts?
New overview for clarity:
------------------------------(Terminology used: Golden Rail == minecraft:golden_rail <powered=false>, Powered Rail == minecraft:golden_rail <powered=true>, <this is a block state>)
Powered rails do not update properly when being powered. Because they store their power value in a boolean (yes/no), when a powered rail that is powered through the conductivity of golden rails receives power from a redstone power source, the power does not continue to propagate down the line. As long as any specific golden rail does not receive an update, it cannot change state.
Abuses:
The first case in the gif above is the most obvious case: if you power a powered rail, then the other rails do not update until receiving an outside update. This can be used for minecart stations, as in Sancarn's Evolution of a Minecart Station series. This case is just annoying and can be useful when playing with BUD creations.
It is possible to power an infinitely long line of golden rail with only one power source. To replicate, simply make a line of golden rail and then power each one with a redstone torch, then remove the torches from one side, leaving the last one. The rail remains powered. This case could be considered an exploit of game mechanics. It is possible to set this up using only two torches, but this setup is easier to understand.This is more likely a implementation flaw than a bug, but deserves to be documented.
Suggested change:
- minecraft:golden_rail replaces it's boolean <powered> with a four bit integer <power> from 0-9.
- A <power> of 0 is unpowered, like the old <powered=false>, and a <power> between 1 and 9 acts like the old <powered=true>.
- When minecraft:golden_rail receives a redstone update, it first checks to see it is receiving a redstone signal, like normal, and if so, sets it's <power> to 9. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
- If there are no direct redstone signals for the block, the block then checks for adjacent minecraft:golden_rail. If it finds one with a <powered> > 0, it takes the highest adjacent <power> and sets it's own <power> to the adjacent <power> - 1. It then propagates a redstone update to all adjacent blocks, as would a piece of redstone updating it's power level.
Possible feature creep by change:
- Since block state is tied to the rendering system, brightness level of golden rail's glow depending on <power>.
- Redstone signal strength into golden rail determines how far the power propagates.
- Different speed boost depending on <power>.
Old overview:
(Is there any way to collapse this?)
------------------------------
This is one of the stranger bugs I have encountered, and hard to explain with text. For clarity, I have created a video.http://youtu.be/c24XFa6n6Lw
(Sorry for awkwardness - I've only recorded a couple videos so far)Content of the Video:
---------------------------Powered Rails in minecraft only store their power as a boolean (yes/no), unlike redstone.
Because of this, it is possible to trick a powered rail into thinking it is powered when it should not be, or vice versa.
Normally, power in powered rails travels eight blocks away from the source. If you place a source down along this length (where it does not provide a redstone update to the unpowered rails), no unpowered rails update to the powered state. If you create a line of completely powered track and destroy the power sources in a way that no rail that should no longer be powered receives a redstone update, no rail depowers.
Steps to reproduce:
Case A:
- Create a line of powered rail
- Place down a redstone torch to power it
- Place down another redstone torch on the powered bit that does not provide a redstone update to the unpowered rail
- Note no rail gets power until manually updated
Case B:
- Create a flat line of powered rail
- Place redstone torches all along the side
- From one side, destroy all the torches but the last one in order
- Note no rail gets depowered
Possible solution:
Have powered rail store power in the same way redstone does, rather than just a boolean.
Possible featurecreep enabled by above solution:
- More/Less speed depending on power?
- Redstone level put into rail effects how many powered rail are powered? (redstone's power: value converts linearly to powered rail's power: value)
- More balance for possible return of faster minecarts?
Powered Rail "power level"is notstoredPowered Rail "power level" does not propagate properly
Would like to clarify that it seems ANY particles are drawn behind any translucent render in-game, e.g. water, nether portal, clouds. Most distracting with eating particles, as most obvious there. Ruins the depth of the game. Seems to be a simple layering bug, but seeing as it has existed for so long and not been fixed, it must be more complicated than that.
I have a possible brute force fix for the problem pointed out by Markku: When a village exists, don't unload parts of it, only all of it. AKA treat a village as one big chunk for loading/unloading purposes. May cause lag issues esp. with overly large villages, but this is just a brute fix.
I actually just updated my drivers (using an override so that it would let me) and now I get this crash, but I didn't before... so I think that this may be a problem with the newest drivers...? The easy workaround is just minimize on the level select screen. Seeing as this is a problem with the Intel graphics driver there probably isn't much Mojang can do to fix it and the way that graphics drivers update you almost never update because there are specialized versions for each machine (and as soon as the company makes a new machine they stop validating new drivers for the old machine).
[Even though it's resolved maybe a mod could change it to say it effects 1.6.2 as this doesn't show up in a search as it doesn't effect the current version (and also maybe because it is closed..)]
Was this fixed by the recent structure fix (or in parallel) (1.6.4)? I remember a Mojanster saying that the only difference between 1.6.2 and 1.6.4 was the structure bug and one concerning villages... I'd like someone to actively test to see if this bug was fixed or addressed in any way, but I don't have the skill set or computer to do so myself.
Invalid, sorry. It turns out that item frames keep the rotation state even when you take out an item so every time I put the smooth sandstone back it would be rotated.
duplicates
MC-63070MC-63070is the first of THREE possible hits for the search "chunk 3rd person"With some bugs it is hard to find that it has been reported before, but for something as simple as that, PLEASE search before posting the bug to the tracker. Chances are someone has posted the bug before with the size of the minecraft fanbase.
It seems that the game will always cull the chunks behind the player's head - these would not normally be seen. 3rd person mode kind of screws with that though.
Also, you could go through the effort to type a description, even if you are just repeating what is told in the pictures. Yes, "pictures tell a thousand words" but sometimes it is better to have some direct explanation.
Added example image made by the reproduce steps
This effect can also be caused by sleeping in a bed. I created a separate ticket for it here -
MC-63185- because they are separate issues but likely with the same cause.Works properly in survival.
(Therefor it's not a dupe.)
The banner is likely not getting removed because the creative idea is you don't lose the item when you use it.
However, this is not the way leather armor works - when washing dyed leather armor in creative you don't keep the dyed version, so this is likely still unintended behavior. (Just not a dupe.)
The fact that renamed items didn't increase in cost to repair was a bug, which was fixed.
Duplicate of
MC-63070Any time you place a wall banner (i.e. on a side hitbox rather than a top hitbox) it doesn't check for collisions before placing the banner.
Have you done it? Now that the video is up you can see me demonstrate. The thing is that the rails DON"T depower, even when more than 20 blocks away from any power source
This is fixed in the current version, when
MC-63070was fixedYes, it still affects 1.8.1. Until they change how the rail powering is figured to use the blockstate data tag, I expect this will stay. I'm currently writing a clearer report now that I've played with this for a while.
Sorry for not updating this issue. One other thing that I would like to say, however, is that this can be used creatively as well, as in the case of this minecart station by Sancarn, where he also describes this activity: https://www.youtube.com/watch?v=iD_h2bBFc1U
I would agree, however, that this may be classified less as a bug but as more of a possible design flaw, and may end up staying for the same reason the piston BUD did. It would still be nice for official confirmation of Works As Intended or even just Won't Fix, so I am making my better explanation now.
(Also, that was way too much text.)
EDIT: Update complete.
@Lucas Ignacio Morrison Osorio
>.< derp >.<
Yes, it does.
Please provide the error message.
I can reproduce this in 1.10.2.
Note that extra hearts from the Health Boost effect persists over a relog, but extra health from AttributeModifiers does not.