Witnessed in a mob farm where only tiny Magma's used to be able to spawn. See Screenshot.
Still an issue in 14w10c
Searched again for just 'slime' in case it effected all slime types and found the following MC-49577
Please mark as duplicate.
Can confirm.
Seems to be not restricted to pressure plates or enderman, but hostile mob spawning in general. I tried in overworld w/ pressure plates with a control platform without and didn't see any spawns on the non control platform. Then tried in end as well with other items such as rails and grass with the same result.
It looks like it's rounding up for the negatives and rounding down for the positives.
Jar_ I'm not sure you understood what the OP was reporting. Or perhaps I did not.
But if you compare the positive and negative pictures, you'll notice that the block value for x is 1 less then the decimal coordinate shown above it. Contrary to the positive.
Take that Negative x Picture. Shows the player in the 0 block on the x at 0.699 yet the block shows a value of 1, contrary to displaying a 0 as it does for the positive integer.
Could see this being confusing for map makers that may use the wrong/incorrect value shown in the block location on the f3 debug screen.
I too can confirm that this is happening, I've experienced it with multiple flatworld presets. This is not related to the bug that this has been set as a duplicate of. That must have been an oversight, please re-open this bug. Thanks.
The 31014 bug is full of different hunger problems. The video provided shows that if you jump in 1.7 while sprinting. It uses about 4x as much food as in 1.6. Is that "works as intended? Did they give us a sprint key for us to never use for fear of starvation? Or maybe a decimal place was off when they rewrote some of the code? I feel like this bug is being swept in with other hunger complaints regarding the use of hunger to heal.
Is losing hunger when standing still - "works as intended" as people have been experiencing that.
or all these problems being combined and overlooked as complaints on an "intended" hunger mechanic.
Can we specifically look at the problem shown in the video to ensure we are talking about the same problem. And if this is an intended change from 1.6 to 1.7 it would be nice for to be listed in the change log.
stamping 'works as intended' without further explanation about what is specifically intended makes it feel like trying to use the bug tracker is a waste of our time and we don't get the sensation that these bugs are being addressed.
Could this be re-opened? Or was there supposed to be a change from 1.6 to 1.7 in food consumption?
I've done some more testing, Did a test of just running in 1.6.4 and the same in 1.7.2 and hunger drained the same.
Did a test to see how many jumps straight up and down it took to deplete 1 hunger icon, and it was the same in both 1.6.4 and 1.7.2.
However when Sprinting and jumping hunger depletes extremely fast. Much faster than in 1.6.4.
Here is a video showing side by side comparison of just running and running while jumping with 1.6.4 on the Left, and 1.7.2 on the Right.
If this is work as intended, then the intent is not a very good one 🙂
I do believe this should be a bug, or at least something has changed since 1.6 to 1.7. Experiencing this in both SP SMP, most noticeable when sprint jumping. I did a basic test of sprint jumping and every 5th jump I lost half a hunger nugget. This test was also done at full health, Compared to ~17 jumps in 1.6.4. I also I don't think it's related to the fairly new mechanic of using the first two hunger to regen health(which was present in 1.6 I believe, indicated again that something else has changed here).
I don't think it's limited to sprint jumping, but it is more noticeable when doing so as it typical uses a lot more hunger anyways.
Any news on the status of this bug?
Still marked as fixed, yet existing fortresses still don't all spawn the mobs correctly depending on the variance of the existing fortress and it's phantom counterpart and if there is an overlap.
As this bug is about whether nether fortress mobs will spawn in existing fortresses, and they do not (unless the generations of the fortresses overlap) I feel that this should be re-opened or marked as "won't fix" if it's not fixable.
Thank You,
Or is it? Been playing on the 1.6.2 PR and been doing some testing. Went to our wither platforms on the server I play on, and if that fortress is generated post 13w18a it generates 7 blocks lower than that actual generated fortress(which was generated in 1.4.6 I believe). I am still seeing only pigman spawning on the top two platforms, and getting blaze and skeeltons only on the bottom two floors(which are in range of the phantom fortress 7 blocks lower.
I also loaded up a old test world in which I have mcedtited out all netherrack around a fortress to get the spawns in the fortress up. I have several test platforms there in which I am only getting pigman and ghasts spawning on. And I do believe ghasts aren't supposed to spawn in fortresses.
I would be interested in what exactly the fix was? As it would appear to be functioning the exact same in 1.6.2 as in 1.6.1
Or perhaps it's fixed from now on? so if any new nether generation changes occur it won't effect the fortresses generated post 13w18a? But fortresses prior to that will still be broken?
As of right now I would claim that this bug is still present in the 1.6.2 Pre-Release.
Can we get this updated to still be an issue in the 1.6 PR?
If this is fixable or not should be answered by the mojang staff.
It would be a shame if every time there are terrain changes that location specific mobs such as the wither skeleton and witches have the potential to stop functioning.
I've run into this bug in my SP world as well as a SMP server I play on. If it is not fixable, it would be good to find that out as our wither skeleton farming platforms on the server will need to be relocated, but no point doing all that work if it does end up getting fixed and we'd have to adjust it again.
Witnessed this on Multiplayer server. New fortress would have generated 7 blocks lower then the existing already generated fortress. As such wither skeletons and blaze or only able to spawn in lower areas of the existing fortress where the spawnable locations of the 'phantom' fortress overlaps with where the current one is. Still present in 13w25a/b/c
Still in 13w19a, but also allows duplication of the contents of a donkey/mule's chest.
That is intended, Powering a hopper only prevents that hopper from pulling and placing items. The lower hopper is not powered, so it can still pull items from the inventory above it regardless of it being another hopper, powered or otherwise.
New test build provide further increase in FPS and feels a lot smoother when moving and looking around as well. Still not matching 1.4.7 but getting close. Still getting choppiness in very heavy redstone areas even though fps are reporting 60+
Great work.
With the test build 13w12~ I get a reported frame rate between 30 - 100 fps (with both min and max smooth lighting)in a fairly heavy redstone area of my survival world. However when moving around and looking around it feels like I have ~5 FPS even though it is still reporting 30+
In a fresh Test world, with a rapid redstone clock going I did 5 tests, and recorded the footage.(http://youtu.be/WgR_qJpVSD4). The test involved waiting till the world fully loaded so there were no chunk updates at start of test, then starting up the clock, flying around and looking around to note how smooth it felt. I tested in 1.47, 1.5 with min and max smooth lighting settings, and this test build 13w12~ in both min and max.
In 1.4.7 I get ~150FPS and it feels smooth moving and looking around.
In 1.5 Smooth Lighting Minimum I get ~40 FPS and it feels very choppy moving and looking around
In 1.5 Smooth Lighting Maximum I get the same results as with Minimum
In 13w12~ Smooth Lighting Minimum I get ~90 FPS and it feels a little bit choppy moving and looking around.
In 13w12~ Smooth Lighting Maximum I get the same results as with Minimum.
Overall I'd say it is a vast improvement over 1.5, however not as good as it was in 1.4.7. Still don't see a difference between min and max settings and It still feels like the reported FPS doesn't relate to how smooth the game actually feels, and that there are possibly duplicate frames giving that choppy feeling even though the game reports a decent frame rate.
Specs of PC used for Test:
Windows 7 64-bit
i5-2500K 3.30GHz
8.00 GB Ram
Nvidia GT 220
[EDIT]Added Link
Depends how the items are being introduced to that hopper, for example, another hopper pointing at that hopper could still place items into a powered hoppers inventory. Perhaps provide a screenshot of the setup you are using so the mod can try and reproduce it.
Here is an example of a setup that will give you the same results as etho in 1.5. Only removing one item from the hopper with each pass of the minecart.
There were changes made to the hopper timings in 13w10a, which could be why you are unable to reproduce his results from a previous snapshot.
Can confirm, newly placed beacon in an existing world(not loaded in any snapshot between 14w21b-14w29b) will not accept the effects chosen or take payment. Beacon still produces a beam. Other beacons that were set before still work.
Can reproduce in a new world too.