Keybounce

Since we now have a fix, and since 1.13 has not yet been released, can we please get a quick 1.12.3 so that those of us who play modded can make use of these various (this one, the Redstone dust one, etc.) community contributed fixes without having to wait for another round of "all mod catch-up"?

Arguably, it is very hard to get an L of 100 in real life.

For that matter, it's very hard to get L's below 50 as I understand it also.

Maybe this is the point where Minecraft could add a "black level" – just as bright white is made a little less than bright white, so to a dark black object could be raised up to the monitor's Black level so that dark objects that are supposed to be dark but visible do not disappear completely.

Forgive me for commenting with a lack of full understanding, but as I see the issue, the basic idea is that collision detection only compares the bounding box to walls outside that box.

Would a simple, and better behaving test (solves the child grow-up as well) be to say that the center of the object (and it doesn't have to be exact) cannot cross a wall?

I.e.: If at any time, the bounding box for an entity crosses the bounding box of a wall/fence/etc., and the center does not, then the whole entity is moved so that the bounding boxes do not intersect.

This code check would be placed where new bounding boxes are computed, rather than on save/load.

Benefits: It solves all issues – rotation, save/load errors, growing up.
Potential problems: I don't know how frequently a BB is recalculated; if it's too frequent, this would take too much CPU. Can't recalculation go on a thread?

> Mojang employees are hamstrung by an idiotic Microsoft policy that forbids them to even looking at code we post here

Dang. Then, we need to make sure that anything we post is clearly marked as "This is just psuedo code, and is not intended as an actual solution", right?

Independent of a minecraft upgrade, yes.

Last time I checked, on the mac, Minecraft was using the nightly builds of Lwjgl, rather than staying with a specific, known behavior build.

The effect is the same to the end user – a regression in behavior while playing Minecraft. That it is caused by bad behavior in a library isn't the issue.

Mojang could say "We'll standardize on a working version of the library".
Or, Mojang could weigh in at Lwjgl, and say "Hey, this is breaking programs like us".

Alright, testing with the captive minecraft map, and my captive polar bear exhibit is making all the expected sub-title sounds.

So these can be updated without changing the game version?!?

...

GAAAH. Support nightmare to have two different user-facing programs with the same identify.

OK, why does it work in your setup, but not in my setup?

Ahh, I see – you are saying that since i'm using forge to supply two information mods, that it is forge that is messing things up. Got it.

Here you go
https://youtu.be/Ro2p0AaFoeo?t=15m53s

I was playing captive minecraft 4, and a polar bear shows up when I expanded the world border. See it wandering around, making noise, and no subtitles.

1.10.2 release.

1.10.2? Sure. Give me a moment, and I'll get a URL/timestamp for you

Attached.

Sonic: "SIGSEGV" – segment violation – means that the code did something it was not supposed to do. It did not happen in the java platform, or the java VM. It happened in a library, supplied by twitch, for the purpose of minecraft being able to contact twitch.

Updating java won't help. It's a flaw in the twitch library. It's a user-visible flaw in a Mojang-shipped product. The user's recourse is to complain to Mojang; Mojang's recourse is to complain to twitch.

Updating Java won't do a thing. This is a bug in the twitch library, and it is not the only one (there is a game-killing assert error, that will trigger any time you lose your network connection after connecting to twitch).

The resolution is for Mojang to pass this bug report (and https://bugs.mojang.com/browse/MC-65480) upstream; they are the consumers of a product from twitch, that is broken, and causing issues with Mojang's game.

The problem may not be in Mojang-written code; the problem does exist in a product distributed by Mojang.

Still happened tonight:

[20:03:27] [Sound Library Loader/INFO]: Sound engine started
/Users/buildslave/workspace/release/build/twitchsdk/twitchchat/source/chatsockettransport.cpp:98: failed assertion `(( (err) <= TTV_EC_SUCCESS))'
ERR: Tue Feb 17 20:03:27 2015 - Socket - Error Sending from a socket. Error = 54
ERR: Tue Feb 17 20:03:27 2015 - unknown - Assert "(( (err) <= TTV_EC_SUCCESS))" failed at /Users/buildslave/workspace/release/build/twitchsdk/twitchchat/source/chatsockettransport.cpp:98

Just because the twitch library has an error, it should not crash the game. It should have at least the equivalent of a try/catch. Not an "assert".

Please report this upstream to twitch, so they can give you a better library.

It's my understanding that:
1. There are work-arounds/alternatives for all the things that this bug permits,
2. There are some things that this bug makes impossible,
3. The recommended solution is to make two types of droppers/dispensers/pistons (and probably hoppers, etc), with the two being "strict powered" and "action at a distance powered" (hmm ... quantum-powered?).

Alright, I just had this happen again tonight.

/Users/buildslave/workspace/release/build/twitchsdk/twitchchat/source/chatsockettransport.cpp:98: failed assertion `(( (err) <= TTV_EC_SUCCESS))'
ERR: Thu Jan 1 17:17:31 2015 - Socket - Error Sending from a socket. Error = 60
ERR: Thu Jan 1 17:17:31 2015 - unknown - Assert "(( (err) <= TTV_EC_SUCCESS))" failed at /Users/buildslave/workspace/release/build/twitchsdk/twitchchat/source/chatsockettransport.cpp:98

This is in 1.7.10. And, I have a useful additional piece of information: My network connection basically went dead for more than 30 seconds.

I was playing on a local server on my own machine. So I never lost connection to my minecraft game server.

• HOWEVER, the twitch library lost connection to Twitch, and even though I was not streaming, and not doing anything, the game crashed for an assertation failure, and no game log.

Key points:

1. I have my chat setting set to show me the chat from twitch in-game,
2. My network died.

Twitch's library has a reason, with these settings, to try to contact twitch.com; but it still should not die / kill the game just because the connection goes down.

Again: This is NOT a duplicate of an optifine issue. This is a straight network failure, and the assumption of the twitch libraries that the network will NOT die.

Wasn't there a followup to Grum's post that did in fact show how to rebuild all those things with properly behaving pistons?

More to the point, given all the builds that make use of it, wasn't the "best practice" suggestion to leave the existing blocks as "quasi-pistons", and make a new block "normal-pistons"? Giving both backwards compatibility and forwards reasonableness?

Not only that, but if you had something that would transmit power through an extended piston, then depending on how the timing actually works, it could be a cheap, sequenced activation detector.

In my experience, a massive lag like this in the server only happens when a major garbage collection is needed while using the default "throughput" garbage collector.

When I switched to using CMS collection, those rare, large garbage delays went away.

Maybe CMS needs to become the new recommended default for servers? Even clients benefit from it in my experience.

So ... this may need to be closed anyways, as "resolved".

I was playing around with 1.7.10, and ... low and behold, not only is it not crashing, I was actually able to stream. From 10.7.5.

Twitched complained that my stream quality was only acceptable, not constant bit rate.

But –
1. The crashing is gone.
2. It actually works! It works as well as anything else I've managed to get to work on 10.7.5.

Maybe I need 10.8 to do constant bit rate encoding; in any case, it seems to be stable/functional/no longer crashing.

Again, you are missing the key point.

• Vanilla minecraft crashes in the twitch libraries even when I am not trying to use twitch! *

Do I meet the minimum needed to stream? No.

Should minecraft crash? No.

Should I get a "Your system cannot stream" box if I try to stream? Sure.
Should minecraft crash if I try to stream? No.

Should I get a crash, while not even trying to stream? "Sorry, your system is not up to date, so a crash when not trying to stream is not Mojang's fault"? Is that what you mean by "Invalid"?