Still an issue in the latest 1.18 pre-release
I thought I was going insane. Happens to me on 1.14.4 (java on windows 10) constantly. I noticed that this occurs almost everytime when you hold the key longer but it also happens on very short presses. So I assume the game does something regularly with the key states that doesn't handle altgr correctly. So if it's pressed in this moment leftCtrl gets stuck.
This happens a lot of times when I enter []{} which happens quite often when working with commands and if you then try to correct a typo it usually removes the whole selector or NBT which is quite infuriating to say the least.
Additionally I would like to mention that this occurred on a local superflat world with no lag spikes according to graph and constant 20TPS
Also happens in 1.14.3 I had a hard time figuring out what's going on before I found this report. It's also a diagonal going on here but what I find interesting is that the comparator clock for the hopper dropper works on one side but not the other, possibly due to update order. Manually I found out that by extending the wire by one it changes the behaviour https://www.youtube.com/watch?v=LyFJE-DIMtQ
I mean I only had 2 crashes so far but this seems to happen for all vanilla as well. But as pokechu22 pointed out in the referenced bug it has not the same stacktrace.
[media][media]It's the LWJGL update I guess. Since MC-42171 also got resolved and now behaves like it does everywhere in the system I guess it's not far fetched that it now also supports scroll axis (which I haven't verified but I found old posts complaining that it didn't support it at some point).
In 1.12.2 with LWJGL 2.9.2 you can go to Options -> Controls and scroll or shift-scroll to scroll through the key bindings list.
In 1.13 with LWJGL 3.1.6 build 14 you can only do normal scroll, shift-scroll will not scroll the list. That will ofc translate to the hotbar as well but it's not hotbar exclusive, it affects any scrolling in the game apparently.
Maybe it's just as simple as to alias/bind left/right with up/down respectively?
Well you can add 1.9.2 to the list and I don't really think this is a creative only issue either... I noticed lagspikes when building the roof and the last block just kills it completely (client and server both on quite some hardware)...
@Marcono1234 Well I guess that is because there is no way (without knowing) what is NBT and what is JSON. The reason for that might be that lenient-JSON and NBT look the exact same. I just tested this here in 1.9.2 and it works (you were right though that I have to put the JSON as string with all quotes escaped):
/blockdata -231 72 213 {Text1:"{\"text\":\"hello\",\"color\":\"green\",\"bold\":true}"}
So I just guess it is intended now that you cannot use the shorthand syntax anymore (e.g. Text1: "just text"
)
I still think though that it is not intended that the server basically crashes when the command is wrong.
So in 1.9.2 the crash OP described is (not really) gone BUT. You seriously screwed up JSON in minecraft. This command wants lenient syntax, one doesn't care and the other one again cares.
So yes I can do this (non-lenient):
/blockdata 111 64 -13 {"Text1": "Hello","Text2": "hello", "Text3":"hello", "Text4":"asd"}
And it DOES update the block but then again, JSON screwup: It updates it so that I have a data tag with "Text1" AND just Text1 without quotes. Effectively not changing anything on the sign.
[22:17:40] [Server thread/INFO]: [2called_chaos: Block data updated to: {"Text1":"Hello",x:111,Text4:"{\"text\":\"\"}",y:64,Text3:"{\"text\":\"\"}",z:-13,Text2:"{\"text\":\"\"}",id:"Sign",Text1:"{\"text\":\"\"}"}]
With lenient syntax it still doesn't work:
/blockdata 111 64 -13 {Text1: "Hello",Text2: "hello", Text3:"hello",Text4:"asd"}
Client: "An unknown error occurred while attempting to perform this command"
Server: [EVENT] [22:25:09] [Server thread/WARN]: Couldn't process command: 'blockdata 111 64 -13 {Text1: "Hello", Text2: "hello", Text3:"hello", Text4:"asd"}'
Then if I try to use Text1: {} compound syntax:
/blockdata 111 64 -13 {Text1: {"text": "Hello"}, Text2: {"text": "hellooooo"}, Text3: {"text": "rly"}, Text4: {"text": "cmon"}}
Same thing as OP described (server crash + restart required)
Let's try it one more time with complete non-lenient and text compounds...
/blockdata 111 64 -13 {"Text1": {"text": "Hello"}, "Text2": {"text": "hellooooo"}, "Text3": {"text": "rly"}, "Text4": {"text": "cmon"}}
Same thing as before, no error but double data tags (with and without quotes)...
PS: By the way it doesn't matter if a user does this or a command block but due to all the required quotes you will almost always need a command block due to the ridiculous chat limitation (I get it for messages but allow longer commands or a command input chat thingy :>)
Yep, all my stuff is working again.
My repeater here is facing east, the whole contraption is in the same chunk: https://www.youtube.com/watch?v=d0b7gFBr5vg
I think it's the same as with my short pulser here although the repeater may face in any direction in my case... https://www.youtube.com/watch?v=d0b7gFBr5vg
I think this is the same as with my short pulser here, am I right? https://www.youtube.com/watch?v=d0b7gFBr5vg
Wouldn't it decrease more lag when doing it the other way around since there are usually more leaves in the distance than near you?
Or is the same as with when riding minecarts: You see this line on which rendering appears to change (less accurate)...
Could be but it doesn't work in older versions (maybe just due to the fact that the boats didn't break). Should I post my "discovery" there too (as it is not mentioned and I couldn't find a report of that)? I'm new to this tracker and I don't know what the correct procedure is. Thanks!
I don't think this is a duplicate of MC-2793 at least not entirely. And it is isn't fixed in 14w25b. I've made a short video to show the difference between the "moving into block" and "clipping through block" behaviour... Don't know if I should create a new issue, please let me know...
I can confirm this on latest 14w25b (shot with Power 5 Bow)
I can confirm that either the house detection has changed or the villager breeding is broken somehow...
I have an artificial village with 2 villagers cured from zombie villagers and like 50 "houses" as they worked before. Nothing.
I found a natural village with around 7-10 houses (so a pretty big one)... All but 2 died due to zombie attacks and even though I added more doors... nothing...
Fortunately I can confirm Alex's post. OS X 10.8.5 with german keyboard layout and Minecraft 14w21b: Cmd+Alt+N = ~
Edit: And CMD+^ (the key under my escape key) inputs ^ (it seems that cmd+deadkey is a workaround) http://en.wikipedia.org/wiki/Dead_key
I honestly don't know why the other bug is considered WAI. Any sort of explanation would have been nice.
It essentially makes the grow over time feature useless when using "add", as the result might completely bug out (as pointed out) when multiple things trigger a growth/shrink. The process quite obviously keeps track of "time remaining", why it can't keep track of "delta remaining" too I don't understand.
Setting a border to 16 and adding 1 twice should result in a border of 18 but it doesn't (or it does, depends on timing).
Due to the fact that I can't set the size from a score I have to workaround it by setting it to 1 and recursively add 1 until I match the score (optimized by checking some powers of 2). This combined with the delta loss makes using the timing feature completely useless unfortunately. I can't even do the recursive thing and stack multiple adds in one tick as only the time stacks but not the border size.
I guess that fact illustrates OPs point as well, calling "
worldborder add 1 1"
three times in a function will grow the world border by 1 block in 3 seconds which makes no sense. But it frankly also doesn't make sense if it would result in 1 block in 1 second, the only sensible thing (imho) is that it grows by 3 blocks in 3 seconds, as that would be the thing it would do if you were to omit the "in seconds" part and do it instantly. Or 3 blocks in 1 second, a successive add call just "ends" or finishes all running transitions instantly and queues the new one (that would remove the timing oddities when mixing add calls with positive and negative numbers)If we want to be fancy we would only finish running transitions when we change direction as most use cases I imagine mainly go in one direction at any given phase and those would then benefit from easy to implement smoothness.