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".

Ok.

The new Mac-specific launcher does not open too low.
However, it has enough issues that it is unusable for me.

And, the generic launcher for use on Linux and other systems is the same (older Mac) launcher that reuses a window and does not re-position it after resizing it.

OH COME ON MOJANG!

"It looks like you've used a newer launcher than this one! If you go back to using this one, we will need to reset your configuration."

And the choice is "I'm sure. Reset my settings."

All of my profiles, gone? All of my forge install settings, gone???

WHAT THE ACTUAL FRACK? (Frack, as in, pumping water into the ground like a James Bond villain to make earthquakes and get rich)

Ok, there are three launchers available on Minecraft.net.

"minecraft.jar" turns out to be the same v5 bootsrap.
"minecraft_legacy.dmg" contains the same Minecraft.app that I have.

minecraft.dmg contains ... wow. The background image looks like it came from an old, legacy macintosh OS. Classic looking.

WOW. The old launcher weighs in at 507 KB. The new one weighs in at 336 MB. ... Chromium framework, and the x-64 jre. Jre I can understand – they want to make sure you are using J8 now, but why Chromium?

... Ok, first, this new "welcome" page looks like a badly designed web page 🙂. Second, those new solid color building blocks in the 1.12 snapshots don't look like colored wool or colored clay (the white is actually white, without the wool stains, or the clay pink tint.)

... OH GOD NO THOSE ARE HORRIBLE SETTINGS! The new launcher is actually specifying CMS garbage collection by default with only 128 MB of "new" memory. CMS wants a LOT more than that to be happy, and that's before the BlockPos object churn.

UGH, this is bug-report worthy. If I click on the sample skins (alex or steve), I get a file browser, looking for alex.png or steve.png, pointing to the contents directory of the app bundle. Not the skin.

Actually trying to select a profile from the list? It's harder to work with that list; you can't use the keyboard to find something; it's not alphabetical; it's not sorted by date used, or minecraft version, or anything I can decipher; you can't use the up/down arrow to scroll through it (mouse only),

Ok, next big bug. The program output window: Cannot scroll. The scrollbar is locked in the middle of the output. Two-finger swipe does not scroll, click-and-drag on the scroll button does not scroll, click in the scroll bar itself does not scroll.

All in all? I'll go back to the legacy launcher, this new one was not designed by people who actually use it.

The launcher I have is 1.6.73-j, bootstrap v5.

The startup behavior is that a window is opened to log the startup and self update. That window is centered. This is (presumably) bootstrap v5.

Then, the main launcher itself starts up. It takes the existing window, and resizes (bigger), without moving/recentering.

2.0.805/806? I do not have that one.

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?