vdvman1

Whelp, this maths is beyond my understanding. It seems to be using a process called single value decomposition on the upper left 3x3 submatrix, which is what extracts the left rotation, scale, and right rotation, and it extracts the translation separately from the original 4x4 matrix.

Unfortunately I don't understand how the process works, so I can't really check to see if there are any errors in the implementation. I'll leave it to Mojang to figure out why the decomposition isn't working correctly

This form definitely can represent shears/skews, here's a generic example:

Exactly why it is breaking during the decomposition, I am not sure. I am currently doing some analysis of the code to try to understand how the decomposition works to see if I can find the cause

That doesn't resolve the problem at all. The issue here is that when you teleport `@s` to another dimension it causes `@s` to no longer point at the correct entity, being able to get the dimension from NBT would not do anything here, and setting from NBT will almost certainly result in desyncs between client and server

What is actually happening is that the game sees it as two characters, because it is, and so it is texturing the emoji and the modifier separately This is not a bug, as it is still useful to be able to texture the modifier and the emoji separately.

Minecraft currently supports displaying a single code point (often called a "character" colloquially), made of single UTF-16 code units or double UTF-16 code units (surrogate pairs) that will be displayed as a single glyph (the actual image that is displayed)

Minecraft does not support combining multiple code points into a single glyph, referred to as ligatures. Since the game does not support ligatures it is not possible to include emoji with the different skin tones, or other unicode modifiers such as accents on arbitrary characters

I would suspect that this will be marked as invalid as it is really a feature request for support for ligatures

The bug is not that it renders with a space, it is actually that it is treating the emoji and the modifier as two separate characters rather than having the skin tone modifier actually modify the character before it

If the same emoji without a skin tone modifier or with a different skin tone modifier were used then it would still render the left half of that emoji character

That is not a bug, commands are only capable of returning values of type int, which is a limitation hardcoded into brigadier. 

This use case is part of why `data modify` was added, which is capable of copying between two NBT locations without going via brigadier, allowing the data to remain unchanged

That's not the problem with the bug. The problem is that dx=0 results in a 1 block volume being checked, and dx=-1 results in a 2 block volume in the opposite direction being checked. This means there is no way to directly check for volumes smaller than 1 block volume

That's only because the `tag` tag of items is different to most NBT, it is stored as actual NBT in memory, whereas other things such as `Pos` and `Motion` are not, they are stored in a different internal format

Dinnerbone has previously explained why they can't, and won't do that. TLDR; modifying NBT actually involves destroying and recreating the entity/block, and doing so for players would kick them from the server

It is actually possible to select a smaller region by combining a few parts of `execute` to get the intersection of two volumes:

execute as @a[dx=0] positioned ~-0.5 ~-0.5 ~-0.5 if entity @s[dx=0] run ...

This will select entities that are in a 0.5x0.5x0.5 volume

But of course, it isn't always possible to do this trick depending on what you are doing, we shouldn't need this workaround, but we do

I'd like to have this as an option, intentionally copying by reference, but I don't think it should be the default. Having copy by reference by default is unintuitive IMO, having a change to the original causing a change in the copy is unexpected

Can confirm for 18w10d

Using lwjgl 2.8.4 the bug does not exist! Turns out it is a bug with 2.8.5

@MrHeat: Nope, using vanilla, started in single and later opened to LAN, before opening shift would get cancelled by the mouse and after opening it would still happen for me, but my friend who joined and was using a Toshiba was working fine

I have now discovered the reason this isn't working! The problem is that any mouse interaction cancels any keyboard input!

Edit: It appears to work fine on Toshiba, but not on Lenovo

Please get this fixed! I started playing mc 1.5 and I almost straight away noticed the lack of shift-click.

Edit: I discovered that any interaction (except moving) when holding shift will often cancel the shift

Another thing to note is that the mod Mystcraft is also affected by this, this means i cannot switch between ages much, which is really annoying as my resources are in the overworld but i am doing work in an age. Please fix this memory leak Mojang!