mojira.dev

Happ MacDonald

Assigned

No issues.

Reported

MC-144681 Minecarts stopping, derailing, or turning around at every simple corner Duplicate MC-94375 Right (non-destructive) click sometimes registers no action, sometimes a rapid succession of right clicks, sometimes even a left-click (destructive!) Invalid MC-93167 Some textures (Easy to confirm with Netherack in the Nether) jump and change rotation as you move closer or farther from them Fixed MC-90811 Nether portals not always allowing you to step out, sending you back instead Duplicate MC-63070 Chunks do not render behind the player in F5. Perhaps culling should calculate from camera POV instead of presuming head position. Fixed MC-63020 Some chunks are not rendered in first person from some angles in certain situations (incorrect frustum culling) Fixed MC-54119 Can place/take water/lava/lily pads outside world border and inside spawn protection Fixed MC-51030 Endermite, phantom, silverfish and baby turtle sinking and suffocating in soul sand Fixed MC-12269 Various Particles glitchy movement Fixed

Comments

Yay, I wonder if that's a sign that someone is now tackling the issue. πŸ™‚

If they are, I'd recommend keeping in mind how this issue relates with MC-63070 (same problem except when camera position and player's head don't coincide) and with Field of View.

The algorithm to decide which faces to cull as "out of view" ought to take FOV into account on one hand, and the position of the camera instead of the position of the center of the player's head on the other.

In circumstances where re-calculating what gets culled is expensive enough that potential wild swings of the camera become problematic, one could alternately calculate what ought to be culled from the entire filled sphere centered on the player's head with a radius of the camera's maximal distance from that point.

</armchair-quarterback-advice>

OK, I can confirm this is fixed as of 1.14.3PR2. πŸ™‚

As of 19w08b (NOT happening in 19w08a!) absolutely all minecarts at absolutely all corners (flat, no walls nearby, no other tracks or minecarts anywhere nearby) get stuck, derail, or bounce at absolutely every corner.

Β 

I tried to post a seperate bug about that but Jira just dumps me here instead, so I'll comment about it here. 😞

Alright, while I didn't have that problem myself I've loaded the file in 1.13-pre5 and let it do it's conversion magic, and I've updated the description to have a link to the newly updated save file: https://drive.google.com/file/d/10MjcYT6X667OTNczi7ax2pw8e-qxl0qk/view?usp=sharing

Let's see if this one works better for you.Β Thanks, Steven. πŸ™‚

18w22a, While it is more difficult to dump a liquid past world border than it is to scoop it up, I have now confirmed that it can still be done when you try enough.

Plus a very curious side effect, when you make your bucket false-empty in this fashion, you can now use the false-empty bucket to scoop up liquid on the inside of the world border and create a new kind of "dead air".

Previously, if you scooped liquid inside the world border with false-bucket, client would render the liquid as scooped for only about one tick before server rejects client's interpretation and liquid re-appears.

Previously you could also scoop liquid outside of the world border, there would be no block update, and if you expanded the world border you could go into the standing hole in the liquid. It would act as a sort of "dead air", the client thinks there's no liquid there while the server does, client allows you to swim only where it thinks the liquid is, no bubble meter comes up when you submerse your head in the dead air, but after a time you do start to lose health as the server thinks there is liquid there.

Now, with dead air (which can now be created without having to first move the world border outwards) the new effect is that the bubble meter DOES appear, even though client still does not allow you to swim through the dead air.

Β 

All interesting stuff, but understandably all much harder to reach now that something blocks picking past the worldborder on ~97% of attempts.

As of 18w19b I can confirm that bug is at least more difficult to trigger. Not every right click of bucket will scoop up a liquid, though spam clicking or clicking at just the right angle facing a liquid can still do it. And I have not yet successfully been able to dump a liquid past world boundary.

So from a user-facing perspective (custom survival maps that use a tight worldborder) I would rate this bug as "much less annoying" now at least. πŸ™‚

OK, I can report that this is resolved as of 18w19b. πŸ‘

I would just do the thing to mark "resolved" myself, but I don't see where in the interface I do that. :o

@Judith Milgram
Well, the problem listed here (fixed by changing your VBO settings, as it happens) is limited to purely visual glitching.. seeing chunks appear or cycle in flashes either far away or even all around you, but the errors have no physicality. If you were playing blindfolded for example, you wouldn't even know there is a problem. All hit-detection and physical movement and block interaction or placement is unaffected.

It sounds like you are describing "big stone blocks popping up" that you can walk up to and interact with? If the erroneous blocks are actually present, you can't walk through them and you can mine them etc, then your bug is quite different from the one that we are discussing. :o

I just learned (and confirmed) something interesting.

The client-side mod Optifine (at the very least OptiFine 1.11 HD U B1) not only absolutely fixes this bug, but also it's cousin MC-63070 to boot.

I have not yet tested older versions of Optiifine to see how long it's been fixed there, but I was lead to try this out due to a new chunk loading / culling finding that I've made.

Vanilla minecraft as of 1.11 makes some very very strange decisions about which nearby chunks in clear line of site it will keep unloaded for no well determined reasons. After trying out the latest optifine I noticed that while this problem may not be 100% solved, the odd choices are at least pushed quite a lot farther away from the camera.

@Torabi
> Bugs are not all equally easy to fix. Some are just a single edit on a single line, other require ripping out and replacing code spread across the entire codebase.

Perhaps so, but this bug we are chatting in is a single-line fix, according to @Marcono1234 who has done a decompile and described the problem in this comment.

OK, IIUC that means that comment + updating affected list emits two emails instead of one (which might be what FVbico was concerned about) but to people only paying attention to ordering tickets by most-recently-updated there won't be any appreciable difference.

I guess what I'm really after is insight into what the coders view as priority. I've been reporter for 6 (real, non-duplicate) issues. One was next to impossible to reproduce and only happened on one in a zillion computers but got resolved in two snapshots. The other 5 are globally reproducible, easy to reproduce and at least as annoying to experience as the one that got fixed yet go unresolved for years. 😞

Does it bump when I test a half a dozen listed issues on each snapshot release and add results to the listed versions field too? Because after a hundred snapshots or so it starts to feel like so many forms filed into a round bin.

Reasons to fix this ancient bug:

Making foggy particle systems look professional enough to spend any time looking at. Some time down the road you might want "freezing fog" as a game element, wouldn't that be tits?

Also, this bug most likely tells us that you've got two coordinate systems in the client which have glitched origin points relative to one another. One responsible for spawning each particle and a completely different one responsible for evolving the particles after they leave their spawn points.

Reasons to fix THIS ancient bug:

Primarily just because it reveals some very strange design issues with the NPC hitbox system that are liable to find other ways of making your life miserable if you only let them. ;P

Reminder of why this ancient bug is important to try to fix.

Primarily, it can be used to cheat. Sort of a poor-person's X-ray mod to peek into hidden caves and dungeons or to spy on other players from a hidden vantage point. Also it ruins my ability to take certain kinds of screenshots.

Also/also, it ruins YOUR ability, as a game developer to do very many different kinds of cinematic elements.

Suggestion: if it is (potentially) too computationally expensive to re-calculate culling from a flighty, mouse-driven camera location then alternately consider calculating culling from the entire sphere representing the potential positions of the camera? that won't have to recalculate unless/until the player moves either, and by roughly the same delta.

Plus, you could have a fix for most of MC-63020 if you swap out point eye position for a ~1m^3 sphere around eye position for free. πŸ˜ƒ

Reminder of why this bug would be good to fix, out of all of the ancient bugs:

It's sufficiently visually distracting to see parts of the world disappear that it even mars the videos of popular youtubers
It can frighten players to see sudden changes to large areas of the screen in the periphery of their vision. Making use of that form of jumpscare on purpose is fine β€” such as the specter of the elder guardian β€” but in cases like this it has no connection to the story narrative and does not train players to interact with the game in any sense.

Thank you Suncat. :3

Do you happen to know if waving my arms about in the comments will help bring attention to ancient bugs which ought to be either easy to fix, or like this one good canaries for solid client/server synchronization in general? πŸ˜ƒ

Thank you for that inspection, Marcono. I have added a link to your comment into the description as you've requested.
Does anybody know if comments or descriptions in mojira support BBcode or similar, so that I can label links instead of just spilling out complex looking URLs? ;3