Morilibus
- morilibus
- morilibus
- Europe/Stockholm
- Yes
- No
4 issues
Key
Summary
Status
Reporter
Assignee
Created
MC-11457Efficiency V + Haste II does not break stone slabs as quickly as full blocks and stairs
Works As Intended
MC-11457MorilibusMC-11457
Pretty sure that is intended. They are supposed to explode if the derail at 'speed'
I experienced a similar crash. Threw an enderpearl and game crashed when it hit. Game would continually crash when trying to re-open world. Was able to load world in mcedit and move the player to a different location. Then was able to load world, have not re-experience this crash. And I enderpearl a lot.
Attached crash report "Enderpearl Crash.txt"
Still happening in 13w06a
Reproduced in 13w06a in creative by having a furnace being supplied with coal from a hopper and manually putting iron in. Furnace was facing north. Attached screenshot and crash report. Does not happen all the time, I kept breaking and replacing furnace and putting in iron till it happened then forced a crash.
Noticed this on a SMP server. Was breeding cows in a fairly large pen, and cows were pushing each other into the walls(2 high stone brick blocks) and suffocating. There was plenty of room in the pen for the cows to go, but they tend to cluster around the sides. And if you have baby cows they will clump together around the closest adult cow, in which they typically force the adult against the wall and it dies.
confirmed not fixed in 13w07a
Could we add to this what Dico is talking about? How we can't send 1-tick pulses through torches anymore either(from what I can tell), might be related to this. Or should that be it's own separate bug?
Present in 13w09a
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.
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.
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.
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
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.
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.
Still in 13w19a, but also allows duplication of the contents of a donkey/mule's chest.
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
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.
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.
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,
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.
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.
http://youtu.be/ouum9Z9GlpY
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.
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.
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.
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.
Searched again for just 'slime' in case it effected all slime types and found the following
MC-49577Please mark as duplicate.
Witnessed in a mob farm where only tiny Magma's used to be able to spawn. See Screenshot.
Still an issue in 14w10c
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.