I'm running a modified Etho Blaze spawner with a big area around it and I'm having the same issue. The spawner will spawn though however very rarily. The cause is the gazillion blazes roaming all free around the nether now it seems.
Random blaze spawning should be removed asap as it is completly breaking the nether as is.
Post patch, this is the most serious issue I think. I used to love hunting for Blazes, and now they're everywhere! I'm guessing you updated the code for their spawn routine when you edited the witches and Wither skeletons? Well it's screwed!
After spending the last 6 Hours or so messing around with shift registers I can confirm that any 1 tick per bit transfer will be corrupted, 2 ticks per bit and higher (tested with 2,3,4) reliably transfers the first 12 bits after which corruption is guaranteed (tested with 4,8,16,32 bit shift registers) The 12th bit causes a redstone 'lock' which rectifies after a seemingly random amount of further bits, don't know if this will help.
For people like me who find that difficult to decipher, can you explain in game terms what that means for us redstone builders? If you were using mob farms, pistons or hoppers for example how does it affect the gameplay?
For people like me who find that difficult to decipher, can you explain in game terms what that means for us redstone builders? If you were using mob farms, pistons or hoppers for example how does it affect the gameplay?
A shift register is what enables serial data, multiple bits of information passing down 1 line (as opposed to paralell, each bit having it's own line). This relys very heavily on timing as each bit takes up x ticks. most clocking circuits also produce serial data though generaly in a much more predictable 101010 stream but still at x ticks per bit. So basically on a clocking circuit you can rely on the first 12 bits (6 clock cycles) to get through after which who knows what combination of bits you will get. Or put even more simply (so house mate can understand) any flashing redstone wire will flash on/off 6 times before locking for a random duration.
I'm not sure that explanation helps those that aren't in computer programming circles... let me see if I can paraphrase a bit less technically...
So basically you need to know what a shift register is... or as sometimes called, a sequencer...
Basically, imagine a redstone device that has a certain number of (ordered) outputs (the number of outputs isn't important, so for this example, we'll use 10).
Now, you can save a specific sequence to these outputs (hence where the order is important), in our example, we'll use:
(ON)
(OFF)
(OFF)
(ON)
(ON)
(OFF)
(ON)
(OFF)
(ON)
(OFF)
Now we can 'shift' this sequence in one direction or another (since this is usually written horizontally when looking at computer binary, it became called a left shift or a right shift), in this case, since I have these outputs listed vertically, we can shift this list either up or down.
Optionally, especially with sequencers as opposed to shift registers, there would sometimes be a need for a loopback shift of the last and first bit so that the patter would continue to stream in a continuous loop.
Such that shifting the above pattern down, with loopback, would yield:
(OFF) {was #10}
(ON) {was #1}
(OFF) {was #2}
(OFF) {was #3}
(ON) {was #4}
(ON) {was #5}
(OFF) {was #6}
(ON) {was #7}
(OFF) {was #8}
(ON) {was #9}
This allows for the execution of certain things at different intervals (it is also pretty good to use for multiplying or dividing by 2 in binary calculations)
Didn't see this posted and made an account just for it. After the most recent update there is EXTREME input lag, to the point that it is game breaking. Takes over half a second between controller input and in-game turning to occur. Didn't test if it affected anything else because I was too frustrated by the sluggish controls.
The piston does not feed the piston down, making it a Bud Switch.
How it works in version 1.6.4 pc as you will see in the image and no console version ...
Greetings!
OldDNOn is exactly right. Let me help clarify....
In the image posted, s/he is showing how pistons should be working: a piston should be able to draw power if the block above it is receiving power (even if that block is an air-block). However in TU20 this is only the case if the block above a piston is receiving Strong (primary) power, such as feeding the top block with a repeater.
The image shows the top block/ top piston being powered by Weak (secondary) power. This should still power the bottom piston, but instead what is happening is the bottom piston won't activate until it receives an update. Hence, it becomes a BUD switch.
In the image posted, s/he is showing how pistons should be working: a piston should be able to draw power if the block above it is receiving power (even if that block is an air-block). However in TU20 this is only the case if the block above a piston is receiving Strong (primary) power, such as feeding the top block with a repeater. The image shows the top block/ top piston being powered by Weak (secondary) power. This should still power the bottom piston, but instead what is happening is the bottom piston won't activate until it receives an update. Hence, it becomes a BUD switch.
I am experiencing this bug as well, but also an interesting variation of it involving torches which should, in theory, directly power the redstone below and thus also the pistons directly below. The top line demonstrates the bug as deskepticon described it, the middle two lines demonstrates my variation of it, and the bottom line shows that the bug is not chunk related(if I understand the concept of chunks correctly then 5 or 6 pistons should be retracted)
I can confirm the same problem. It isn't the space, the lighting, etc., as others have suggested. I used the same farm style (either Mumbo's or someone else's...they're very similar). I push the mobs out of the 8 block range that would prevent additional spawner mobs from appearing, and until TU20, could get dozens into a crusher. When I first came to the spawner, after running a good distance from my portal, about a dozen appeared in the spawner, and then it completely stopped. killing the first dozen didn't help...no further spawns occurred.
From messing around with it, it does appear to be an issue with the number of mobs present on the map affecting the spawn rate of the spawner. As I ran to it, mobs had yet to spawn up to the mob count limit, so it spawned a dozen. But after a minute, the outside mobs reached the mob limit and stopped the spawner.
Spawners should never be limited to the mob cap limit...instead, the spawner should essentially remove other outside mobs up to the mob cap if that's needed to control lag issues.
On TU19, there was a change that actually allowed about twice as many mobs to spawn off the spawner, and as pocassium said, it was working beautifully. It would get visually choppy from so many mobs, but let me reach level 30 effectively. (I'm okay with the graphics lag...the 360 is old hardware!)
I imagine some purists would argue that you shouldn't use farms to get xp, but the joy of minecraft is building such machines so you can go build something else with the newly enchanted armor and tools. I hope 4J would agree and tweak the spawner back to the way it was.
The problem though with the previous spawning was if you left it too long without killing those mobs the framerate would drop to almost 0 and the game would crash.
Rollback Post to RevisionRollBack
Twitter - @4JSteve
Currently Playing - League of Legends (EUW), Tales of Vesperia (PS4) and Kingdom Hearts 2 (PS4)
Feel free to add me on Steam, PSN and XboxLive, Make sure and leave a message saying you are from the forums
Controls bug: It's no longer possible to interact with interactive items such as doors and trapdoors when crouched (introduced horse update). Note that this behaviour is not consistent, sometimes you can open a fencegate when crouched for instance and at other times you cant. Best way to replicate is to try and trade with a villager when crouched, it doesnt work (this may be intentional to allow for naming of villagers I just realised). It seems very inconsistent.
This is the correct behavior - If you have an item in your hand while crouched you won't be able to interact with Doors/trapdoors.
If you have no item in your hand they will work correctly.
This matches 1.6.4 behavior.
Rollback Post to RevisionRollBack
Twitter - @4JSteve
Currently Playing - League of Legends (EUW), Tales of Vesperia (PS4) and Kingdom Hearts 2 (PS4)
Feel free to add me on Steam, PSN and XboxLive, Make sure and leave a message saying you are from the forums
Twitter - @4JSteve
Currently Playing - League of Legends (EUW), Tales of Vesperia (PS4) and Kingdom Hearts 2 (PS4)
Feel free to add me on Steam, PSN and XboxLive, Make sure and leave a message saying you are from the forums
I'm not sure that explanation helps those that aren't in computer programming circles... let me see if I can paraphrase a bit less technically...
So basically you need to know what a shift register is... or as sometimes called, a sequencer...
Basically, imagine a redstone device that has a certain number of (ordered) outputs (the number of outputs isn't important, so for this example, we'll use 10).
Now, you can save a specific sequence to these outputs (hence where the order is important), in our example, we'll use:
(ON)
(OFF)
(OFF)
(ON)
(ON)
(OFF)
(ON)
(OFF)
(ON)
(OFF)
Now we can 'shift' this sequence in one direction or another (since this is usually written horizontally when looking at computer binary, it became called a left shift or a right shift), in this case, since I have these outputs listed vertically, we can shift this list either up or down.
Optionally, especially with sequencers as opposed to shift registers, there would sometimes be a need for a loopback shift of the last and first bit so that the patter would continue to stream in a continuous loop.
Such that shifting the above pattern down, with loopback, would yield:
(OFF) {was #10}
(ON) {was #1}
(OFF) {was #2}
(OFF) {was #3}
(ON) {was #4}
(ON) {was #5}
(OFF) {was #6}
(ON) {was #7}
(OFF) {was #8}
(ON) {was #9}
This allows for the execution of certain things at different intervals (it is also pretty good to use for multiplying or dividing by 2 in binary calculations)
In the image posted, s/he is showing how pistons should be working: a piston should be able to draw power if the block above it is receiving power (even if that block is an air-block). However in TU20 this is only the case if the block above a piston is receiving Strong (primary) power, such as feeding the top block with a repeater.
The image shows the top block/ top piston being powered by Weak (secondary) power. This should still power the bottom piston, but instead what is happening is the bottom piston won't activate until it receives an update. Hence, it becomes a BUD switch.
[quote=cyko_01;/members/cyko_01;/forums/minecraft-xbox-360-edition/mcx360-recent-upcoming-updates/2337446-mcxbla-official-known-bugs-list-tu20?comment=75]
I am experiencing this bug as well, but also an interesting variation of it involving torches which should, in theory, directly power the redstone below and thus also the pistons directly below. The top line demonstrates the bug as deskepticon described it, the middle two lines demonstrates my variation of it, and the bottom line shows that the bug is not chunk related(if I understand the concept of chunks correctly then 5 or 6 pistons should be retracted)
Thank you everyone for the explanations. I really appreciate it.
So, as of right now, what's the limit of the redstone -> piston power?
As in, the redstone power signal gets weaker for each block it travels over via redstone dust unless a repeater is used as we are all of course aware. At what point along that line of weakening redstone does it stop powering secondary pistons, or other devices attached to them?
Not only does it help me understand this in more detail to help with builds, it may help in bugfixing too
Many thanks everyone for your patience.
If possible could you provide any relevant screenshots/Youtube videos of the setup.
I would love to, but I have reservations with starting a Facebook account. Perhaps allowing screenshots to be saved to the Xbox HD. . . *wink wink, nudge nudge*
But the image posted by OldDNOn a few posts up shows perfectly what the issue with pistons is. (To be fair there are actually several issues with pistons, some of which I have had trouble pinpointing exactly what might be causing them. But for the time being will concentrate on this one particular issue.)
Using OldDNOn's image as a reference: On the 360 half of the screen, the row of bottom pistons are not extended, but they should be. Those pistons, however ARE receiving power, but they won't update naturally. They will extend if they receive an additional update, such as placing a block next to them. Essentially, they have been BUD'ed.
I have found that the BUD'ing only occurs if the top piston(s) are powered using Weak, or Secondary, power... such as being powered through a "transmitter" block (as shown in the image). If the top piston receives Strong (Primary / Direct) power, such as having a repeater or line of dust pointing directly at it, then the bottom piston will update correctly.
PS - For the sake of transparency and to help the community better troubleshoot piston-related issues, I think we need to know the reason why piston timing was changed in TU14, since that is where many of the issues originate.
Thank You.
As of now, I havn't found any correlation to redstone "strength" having an effect on the issue, but it is an interesting concept and I will do some tests when I'm able. As far as I can tell, the issue occurs only when the "type" of power is used (Primary v. Secondary / Strong v. Weak, etc. -- however you prefer to word it).
1. Redstone blocks will activate pistons not touching it if they are below it.
2. After an unknown event, a player on multiscreen will have hud, and inve`tory and creative and pause menu invisible, as in, the screen will be blank but you could exit the game, if you knew the way through the menu
3. Witches potions still arent textured correctly.
4. Also the creative option should be like a host privilege so at least the host can switch from creative to survival at will, and will obviously disable achievements
5. When saving and exiting a world when riding a horse reloading it will make you appear to be off, but imobile until you press the dismount button.
6. Invisible mobs, not invincible, i can hear them but, if its a pigmen, then you just recieve damge from seemingly nothing, from everywhere.
1. Redstone blocks will activate pistons not touching it if they are below it.
If I'm understanding what you mean by this, then it's not a bug. It's the way pistons function. However, if you read some of the posts on page 4 of this thread you will see that there is a bug in which pistons are NOT activating when they should be (under certain conditions).
EDIT
Question: You mean you you have a RS block with an air block below it and then a piston, right? Or to put it another way, a piston and RS block with one block of empty space inbetween?
If this is the case, then Yes!, the piston should activate.
Stay fluffy~
Stay fluffy~
Post patch, this is the most serious issue I think. I used to love hunting for Blazes, and now they're everywhere! I'm guessing you updated the code for their spawn routine when you edited the witches and Wither skeletons? Well it's screwed!
For people like me who find that difficult to decipher, can you explain in game terms what that means for us redstone builders? If you were using mob farms, pistons or hoppers for example how does it affect the gameplay?
but
Tamed Horses still despawn in old worlds..
it doesnt have any problem once you created a new world.
its kinda frustrating that you need to create a new world just to take advantage of the horse features.
please fix this too..
(PS VITA Ver)
I'm not sure that explanation helps those that aren't in computer programming circles... let me see if I can paraphrase a bit less technically...
So basically you need to know what a shift register is... or as sometimes called, a sequencer...
Basically, imagine a redstone device that has a certain number of (ordered) outputs (the number of outputs isn't important, so for this example, we'll use 10).
Now, you can save a specific sequence to these outputs (hence where the order is important), in our example, we'll use:
Optionally, especially with sequencers as opposed to shift registers, there would sometimes be a need for a loopback shift of the last and first bit so that the patter would continue to stream in a continuous loop.
Such that shifting the above pattern down, with loopback, would yield:
OldDNOn is exactly right. Let me help clarify....
In the image posted, s/he is showing how pistons should be working: a piston should be able to draw power if the block above it is receiving power (even if that block is an air-block). However in TU20 this is only the case if the block above a piston is receiving Strong (primary) power, such as feeding the top block with a repeater.
The image shows the top block/ top piston being powered by Weak (secondary) power. This should still power the bottom piston, but instead what is happening is the bottom piston won't activate until it receives an update. Hence, it becomes a BUD switch.
I am experiencing this bug as well, but also an interesting variation of it involving torches which should, in theory, directly power the redstone below and thus also the pistons directly below. The top line demonstrates the bug as deskepticon described it, the middle two lines demonstrates my variation of it, and the bottom line shows that the bug is not chunk related(if I understand the concept of chunks correctly then 5 or 6 pistons should be retracted)
The problem though with the previous spawning was if you left it too long without killing those mobs the framerate would drop to almost 0 and the game would crash.
Twitter - @4JSteve
Currently Playing - League of Legends (EUW), Tales of Vesperia (PS4) and Kingdom Hearts 2 (PS4)
Feel free to add me on Steam, PSN and XboxLive, Make sure and leave a message saying you are from the forums
This is the correct behavior - If you have an item in your hand while crouched you won't be able to interact with Doors/trapdoors.
If you have no item in your hand they will work correctly.
This matches 1.6.4 behavior.
Twitter - @4JSteve
Currently Playing - League of Legends (EUW), Tales of Vesperia (PS4) and Kingdom Hearts 2 (PS4)
Feel free to add me on Steam, PSN and XboxLive, Make sure and leave a message saying you are from the forums
If possible could you provide any relevant screenshots/Youtube videos of the setup.
Twitter - @4JSteve
Currently Playing - League of Legends (EUW), Tales of Vesperia (PS4) and Kingdom Hearts 2 (PS4)
Feel free to add me on Steam, PSN and XboxLive, Make sure and leave a message saying you are from the forums
Thank you everyone for the explanations. I really appreciate it.
So, as of right now, what's the limit of the redstone -> piston power?
As in, the redstone power signal gets weaker for each block it travels over via redstone dust unless a repeater is used as we are all of course aware. At what point along that line of weakening redstone does it stop powering secondary pistons, or other devices attached to them?
Not only does it help me understand this in more detail to help with builds, it may help in bugfixing too
Many thanks everyone for your patience.
I would love to, but I have reservations with starting a Facebook account. Perhaps allowing screenshots to be saved to the Xbox HD. . . *wink wink, nudge nudge*
But the image posted by OldDNOn a few posts up shows perfectly what the issue with pistons is. (To be fair there are actually several issues with pistons, some of which I have had trouble pinpointing exactly what might be causing them. But for the time being will concentrate on this one particular issue.)
Using OldDNOn's image as a reference: On the 360 half of the screen, the row of bottom pistons are not extended, but they should be. Those pistons, however ARE receiving power, but they won't update naturally. They will extend if they receive an additional update, such as placing a block next to them. Essentially, they have been BUD'ed.
I have found that the BUD'ing only occurs if the top piston(s) are powered using Weak, or Secondary, power... such as being powered through a "transmitter" block (as shown in the image). If the top piston receives Strong (Primary / Direct) power, such as having a repeater or line of dust pointing directly at it, then the bottom piston will update correctly.
PS - For the sake of transparency and to help the community better troubleshoot piston-related issues, I think we need to know the reason why piston timing was changed in TU14, since that is where many of the issues originate.
Thank You.
As of now, I havn't found any correlation to redstone "strength" having an effect on the issue, but it is an interesting concept and I will do some tests when I'm able. As far as I can tell, the issue occurs only when the "type" of power is used (Primary v. Secondary / Strong v. Weak, etc. -- however you prefer to word it).
2. After an unknown event, a player on multiscreen will have hud, and inve`tory and creative and pause menu invisible, as in, the screen will be blank but you could exit the game, if you knew the way through the menu
3. Witches potions still arent textured correctly.
4. Also the creative option should be like a host privilege so at least the host can switch from creative to survival at will, and will obviously disable achievements
5. When saving and exiting a world when riding a horse reloading it will make you appear to be off, but imobile until you press the dismount button.
6. Invisible mobs, not invincible, i can hear them but, if its a pigmen, then you just recieve damge from seemingly nothing, from everywhere.
If I'm understanding what you mean by this, then it's not a bug. It's the way pistons function. However, if you read some of the posts on page 4 of this thread you will see that there is a bug in which pistons are NOT activating when they should be (under certain conditions).
EDIT
Question: You mean you you have a RS block with an air block below it and then a piston, right? Or to put it another way, a piston and RS block with one block of empty space inbetween?
If this is the case, then Yes!, the piston should activate.