Keybounce
- keybounce
- keybounce
- America/Los_Angeles
- Yes
- No
MC-2523
MCL-2743
Bug report, 152, minecart tracks.
When placing tracks north/south: Normal tracks line up with each other pretty much as-expected. Trying to place tracks adjacent to each other – for example, 6 lines of tracks in 6 spaces – "works" if you place every other one first. Until you get to the ends. The ends will insist on turning to connect. This is all proper behavior.
The bug: Attempting to place powered rails, which won't turn, works on the first "every other" spacing. As soon as you place the missing powered rails, even though they are connected north/south to other tracks, they will turn to all face east/west to touch each other.
When placing tracks east/west: Normal tracks sometimes line up with each other, and sometimes run north/south. Placing powered rails at the end will work, if
the rails face the right way. That is not guaranteed.Video shows all these issues: http://youtu.be/dnBLSwBGyqk
Note: Neither direction lines up as-expected. Both directions show different errors. Lining tracks north/south results in powered rails ignoring their existing connections. Lining tracks east/west results in both normal and powered tracks arbitrarily going north/south for no apparent reason.
Bug report, 152, north/south powered rail minecart tracks.
When placing tracks north/south: Normal tracks line up with each other pretty much as-expected. Trying to place tracks adjacent to each other – for example, 6 lines of tracks in 6 spaces – "works" if you place every other one first. Until you get to the ends. The ends will insist on turning to connect. This is all proper behavior.
The bug: Attempting to place powered rails, which won't turn, works on the first "every other" spacing. As soon as you place the missing powered rails, even though they are connected north/south to other tracks, they will turn to all face east/west to touch each other.
When placing tracks east/west: Normal tracks sometimes line up with each other, and sometimes run north/south. Placing powered rails at the end will work, if the rails face the right way. That is not guaranteed.Determined to be an optifine issue, not a minecraft issue.Video shows all these issues: http://youtu.be/dnBLSwBGyqk
Note: Neither direction lines up as-expected. Both directions show different errors. Lining tracks north/south results in powered rails ignoring their existing connections. Lining tracks east/west results in both normal and powered tracks arbitrarily going north/south for no apparent reason.
Repeated travel back and forth between the overworld and the nether results in increasing memory allocated to tenured space.
I used these java flags: -XX:+PrintTenuringDistribution -XX:+PrintCommandLineFlags -XX:+PrintHeapAtGC -XX:+PrintGCDetails -Xloggc:GC.log -XX:+PrintGCDateStamps
and a "tail -F GC.log"
Start by loading up the overworld, and traveling around a little. Then, make a nether portal, and go back-and-forth.
The travel around the overworld let the memory get to an initial baseline.
Repeated travel into the nether keeps raising the tenured space.
- UPDATE: See additional information below. Actual bug is: Structures do not regenerate correctly when chunks are regenerated. Null pointer error actually happened on a world that originally had forge, and was re-loaded into vanilla; and did not happen on a world that was a re-creation in pure vanilla.
—
Well, it crashed in startup.
What I did: I am trying to track down the source of "ghost towns", generating with no people, no chest in the smithy.
I have managed to reproduce this with forge, only – no mods. So now I needed to see if this happened in vanilla.
I found a town. Quit the game. Deleted the region files, so that the world would be regenerated when I logged back in.
What I expected to happen was...:
The world would be created, either with a village, with people (in which case the problem is with forge), or without people (in which case the problem is with vanilla).What actually happened was...:
Null pointer.Steps to Reproduce:
1. New world.
2. Find a village.
3. Quit game.
4. Delete all the .mca files in the region folder.
5. Restart.
The internal trackpad on my mac is basically dead/unusable. I have a trackpad app on my tablet, and a server app on the computer that talks to the tablet app to provide an effective trackpad.
If I am in a gui – anytime that the normal OS mouse pointer would show – then the virtual trackpad words fine.
I can two-finger scroll to change the selected item, no problem.
But I can no longer aim left/right. This was working about a month or two ago.
I can confirm that this behavior exists in 1.11.2.
I do not know if it ever worked correctly in 1.11.2.
It did "used to work" in 1.10.2, and does not anymore.EDIT: In case this is a Lwjgl issue, see also: http://forum.lwjgl.org/index.php?topic=6477.0
Keybounce: You are right that garbage collections can produce something similar, but at least on our server this is not the case here.
We already use a different garbage collector (G1 in our case) and have tested this a lot. The garbage collections are done in half a tick (25ms) and not often enough to cause this kind of behavior. The CPU choke is a result of a combination of code changes that were made.
One possible way to at least prevent it from getting worse:
Instead of saying "a 16x16x16 mini chunk with no blocks is not stored", add in "a 16x16x16 mini chunks with no blocks and skylight 15 full sun exposure in all blocks is not stored.
You could, it would just be surprisingly well lit.
Except, occasionally, when the lighting gets rechecked and suddenly goes dark.
(Where's the opposite bug of areas being artificially dark when loaded?)
As reported http://www.minecraftforum.net/topic/1541173-java-memory-and-minecraft/#entry18994172 and http://www.minecraftforum.net/topic/1541173-java-memory-and-minecraft/#entry19026273 mob spawns will be reduced if the view distance is reduced.
According to the wiki, the number of valid chunks is tossed into a formula to determine mob caps; my first curiosity is whether or not view distance affects the number of chunks used in that formula.
Sorry. Was in 145; will recheck 147, but not expecting any difference.
Ahh – someone else has tested this for me
> I used normal superflat as the base string but added those 20 empty blocks and another layer of ground on top for the ceiling, so the ceiling was certainly more than whole chunk. That is why I asked for the very specifics. Sometimes even something as "irrelevant" as an offset of one block in height can affect the results.
The problem is the height factor. You need an empty 16 tall minichunk.
Normal superflat has values for 1 through 4. You would therefore need 17 through 32 to be empty. This means you need your roof at 33 or higher.
I haven't seen any mention of this in the release notes for the snapshots, and I do not have an easy way to test this right now. (BTW: I love that 5 torch dual-loop!). Is this still active, or has it been fixed yet?
Still present in 13w10b.
Still present in 1.5 pre-release.
http://youtu.be/aR2Kz2N05SM
Not using any of the F9-F12 features (spaces/dashboard/etc).
I missed that comment about the new launcher; not sure when I'll get to it. Thank you.
Block update detectors are useful for people who want block update detectors.
Properly working pistons are useful for people who want properly working pistons.
If you have broken pistons that act as buds, then people who need proper pistons are out of luck and have no work-around.
If you need a bud, and pistons don't do buds, then you have options. Perhaps not compact.
If you need both compact buds, and proper pistons, then you have to break the broken pistons and add in a proper bud block.
The claim "it will break builds" is not acceptable. Piston timings changed, breaking systems. Redstone torch accuracy broke from 125 single player to 125 multiplayer and everything since, breaking systems and actually giving some timing loops zero chance of working properly. (Bug number ... 2523, https://mojang.atlassian.net/browse/MC-2523).
The point is this: We've (our server) had "buds" from what should have been simple piston builds that DID NOT WANT BUD BEHAVIOR!
It has interfered with some relatively simple designs.
If there is a good reason for this – if there is something that you want to do with pistons that cannot be done without this – then please indicate what it is.
"Block Update Detector" is not a good reason. That should be a new block, perhaps using nether quartz.
Please explain what you mean, "just use a half slab". I do not understand your comment.
I know people are saying that you can use halfslabs or stairs to isolate pistons to get the "proper" behavior.
I'd like to actually SEE a working system, with 4 pistons in a 2x2 vertical grid, each one activateable independently from the others.
And, as I say that, I realize that a trivial solution is to power the bottom two "normally", and the top two from "above". So make that a 2 wide x3 tall grid – how do you get the middle ones to work without issues?
I'd like to thank Mojang for officially confirming that this is intended and will not be changed.
Meanwhile: Anyone got a good way to make a tall, two-wide set of pistons work without this? We've run into this issue on other builds by accident, and while small builds can be adjusted, I don't see how to do it on bigger stuff.
Tee hee. Yes, "Won't Remove", or "Promoted to official feature", sound like better resolutions than "Works as intended".
Either way, it won't change.
@Daniel: Thank you for a 152 fix. Is it compatible with Forge? (something to ask anytime there's base class overwrites now-a-days.) If not, can you make a forge compatible?
We've got a few forge mods on our system that we (ebxl, mystcraft, etc) just can't let go of.
It sounds like it is fixed in vanilla 162, so it's just a case of 152 backdating until everything is updated for 1.6.3.
PLEASE.
Thank you for explaining – and showing with simple pictures – exactly what's going on.
PLEASE, Mojang, this and 2025 – please make these, and similar issues, the focus of your next patch level. Yes, I'm asking for 1.7 to be the raid release (raid = bug spray)
Rare or not, lets put this into perspective.
When I first tried using pens of sheeps of different colors, I found it impossible – my early videos include pictures of animals jumping up 2.5 blocks off the ground trying to jump over fences – and constant leaks every time I restarted the server. I gave up and just cheated the colored wool in as a bug work-around.
Somewhere around 1.4.5, I think, the leaks reduced greatly – enough that my strategy changed to "kill the escapees, and just breed new babies" – keeping 3 in each pen (as the escape rate went up when it was 4 in a pen – fence length 4 around a 2x2 open area). That mostly worked – occasionally I was down to 1 in a pen, and trying to lure someone back in as a replacement was ... just not working
. (It was basically built in the first place as two people, me luring sheep, and my friend putting fences up around us.)
Fixed, in survival? I had a 151 test world with a giant pen, filled with cow babies. Over time, most grew up, and leaked. It's currently got 5, I think, and it's something like 6 by 9 in size. And everything beyond those few have leaked. Yes, they leaked as adults over repeated starts/stops (chunks were very close to spawn, so as I understand it, they never unload.)
If the basic issues – mobs thinking that they are at their corner instead of their center, floating point precision issues, and collision issues – are still un-adressed, then the basic bug is still there, and it still is an issue in survival for even a basic farm.
I agree that they are always loaded, currently.
I agree that this is how minecraft works, currently.
"Works as intended"? It seems more like a side-affect of "Designed for single player, multiplayer added later" than "Designed to always keep stuff in memory even if not used".
"Won't fix" as a resolution I can understand.
"As intended" I think is the wrong resolution.
"How it has worked since we started doing multiplayer" I can agree with.
That doesn't make it "as intended" – that makes it potentially a bug.
And actually, I just realized another issue, perhaps more serious:
For an SSD drive, minecraft is constantly re-writing files for no reason. That will kill an SSD drive over time.
<blockquote>I personally think that Mojang should take Mumbo Jumbo's suggestion (http://www.youtube.com/watch?v=QYe_xe7SNKY) about splitting the piston. Change the name of the original piston to something like piston (BUD) </blockquote>
YES!
Keep the old block, with a changed name. Add in a new, better, fixed block.
It's like the old "wooden slab" that was kept, and different from the new, current, wood slabs.
I want a properly working piston/sticky piston. Period.
If it takes having both "older, compatible blocks" as well as "newer, better blocks", so be it.
We have – still, today, fully functional – stone slabs that happen to look like wood, but fireproof and using picks.
So a quick comment/question on that pushOutOfBlocks: Right now there is a "push upwards if fully encased" behavior, that can be used for rapid vertical (up) item movement, as a counter to "hopper down" elevators.
Does your version maintain that? What would happen to something that was fully inside a solid wall with yours?
@Tavis: Can't you make the lower row piston, block, repeater, wire – giving you two rows of wire, with a block separating them?
In either case, treating redstone as "Always has an update range of 2" – such that the upper repeater, and the lower piston are distance 2, so the lower piston will just work – does make sense.
In fact, as I look at that, why use a repeater there at all? Why not redstone dust normally?
If a redstone dust is powered, and the rule is "redstone dust powers anything in range 2", then the lower piston is powered. And, that fits the "repeaters act as signal isolators, and only power the blocks right in front of them" behavior, which would not power the lower piston.
In other words, what seems to be "reasonable, expected" behavior is that using dust instead of a repeater would power both (as well as the one above them if there was a third), and a repeater would only power the one.
(I am not a redstone expert; I've had too much "fun" with torch bugs and repeaters not working right in loops.)
BUDS are fundamentally a way of detecting "The neighbor block has been updated".
There is a way for blocks, in the code, to notify their neighbors that they have changed. Minecraft, at its heart, is a cellular automata.
Any time a state change is not accurately propagated – even in the case of "which way does water flow from here" – it is possible for the "current state of the world" to be strange. And if a block, upon being notified, makes a change from the inconsistent state into the consistent one, then there is something to detect.
Do you think Etho's old "Boat Bud" should not exist?
Can you see any way to prevent it from happening?
In general, if I have a water source that wants to go either to an immediate fall in one direction, or has to go a longer distance in another direction, even if that direction's length is controlled by a piston, then it is possible for the water source to not notice a "change" that has range 2. And if you teach it to look at range 2, I can set up a bud at range 3. Etc. I see no cheap solution to that.
===
There are only two choices:
1. Buds should not exist. Liquid blocks, whenever they get a random tick, should make at least some attempt to detect changed environment around them. Etc. (Actually, any block that has an action dependent on the environment. Not just liquids)
2. Buds should exist, in some form. Then, the question is only "how big" and "how slow". Etho's boat bud is both big and slow. A single block detector can exist – the existing comparator is almost a bud already (and I just saw a video showing that it can detect changes in tile entity data – a data update detector.)
If you want to use #1 (no buds at all), then a perfect examination of the environment is probably not possible because of time. You can either say "Regardless of CPU power, each block we want to check the environment will sample one or two random blocks in range each update tick", or you can say "Each block that that is environment sensitive will add itself to a current recheck list; each time through the main game loop, some blocks on that recheck list will make some attempts to recheck, and the total amount of rechecks made will depend on CPU power, such that more powerful machines will see a world become more consistent faster", with the length of that list being a trigger for removing older blocks from the list (and possibly a block being smart enough to say "I have now checked everything around me, remove me from the list even if there is spare CPU").
The first of those two choices – regardless of CPU power, each environment sensitive block makes one or two random checks each time it gets a random update tick – is probably the better, more consistent one.
And if you want to use #2 – buds should exist in some form – then there is no reason not to have a single block bud. Either an omnidirectional bud (any change in any neighbor sends a notice to 5 other sides), or a redstone-torch like "single direction in, fixed outputs". I personally would prefer to be an omni-buds-man.
===
Entirely separate from the question "Should there be buds?" is the question, "Should this piston behavior continue?".
Should pistons be changed? We've had a major change to piston timings already. So we already have precedent for changing things.
Should old redstone behavior be changed? We already have seen timings of redstone torches, and the behavior of torch and repeater loops destroyed from 125 singleplayer to anything later (bug #2523, that actually kills much of what I was going to use redstone for in my world. https://mojang.atlassian.net/browse/MC-2523). We've seen really long insta-wire loops that propagated through unloaded chunks in one tick in single player turn into loss-of-sync, multiple tick signals.
And yes, insta-wire can be used as a denial of service attack on a server. Arbitrary inst-computations have been demonstrated as a proof of concept (both instant nand and instant nor gates). But there are no "gamerule" settings – or server.property settings, or anything – for a server to indicate how much instawire / redstone torch updates / etc they are willing to put up with in a tick, and the default settings are too low for doing anything interesting.
===
Bottom line: Mojang has repeatedly broken builds in the past. I think we, the community, have gotten used to, almost expecting this to continue. To now turn around and say "It's broken, but won't be fixed" makes very little sense. And if you are going to say "Promoted to official feature", then consider just how little sense it really makes – I could not describe it accurately if I had to, other than to say: "Generally speaking, a piston can be 'powered' if either the block above it would power a piston, or if while extended, the extended arm is powered and then power removed from the base". I think that's accurate.
And if it's not, how would you describe it such that others can understand it, and be accurate?
Still in 152.
I have not yet tested in 16x.
I could not force a crash log by f3+c for 10 seconds. Not even after 20 seconds.
But I did play around with it some more, to make sure it would repeat.
When the
Har, spoke too soon. As soon as I went back to the game, and got out of the F3 screen, then it crashed
.
When the east/west tracks appear to face the wrong way, it is rendering – just changing the view distance to force the game to redraw makes it look right.
I cannot find the "attach file" button.
However, it is relatively short (more stuff – important – below the crash):
If it is just rendering – note that I am actually playing single player this time, I normally play on servers – then the immediate "to check" is optifine. I'll disable the forge stuff as well – it's primarily for NEI, but also for dynamic lights (handheld torches), and lloverlay (displays the light levels on the ground – turned off in that video).
And, retesting with optifine removed – the east/west tracks are now showing up properly. And, they clearly place down – and draw – north/south, and then turn and redraw east/west.
But the north/south powered rails that decide to change facing, break their existing connections, and go east/west – that is still happening.
Confirmed in 1.5.2
PLEASE, I'm actually trying to make use of minecarts in 152, just as you intended. We need a 153 redstone supplemental update for this, pistons, torch timings, etc.
I have an idea, moving forward, for how to distinguish the two pistons.
The new, "properly functioning" piston has the same recipe we now have – three wood on top, stone edges, iron and redstone in the middle.
The old, "oddly diagonally powered" piston gets a new recipe – the redstone dust is moved from position #8 (bottom middle) to position #1 (top diagonal corner). The wood block goes where the redstone was.
Does that make sense? As much sense as the behavior of the old piston. But it seems that two different piston blocks is the only workable solution that makes everyone happy.
> This behavior is highly useful.
The problem is: Proper behavior is also highly useful.
It is apparently easier to mimic the bugged useful behavior with a proper piston than to mimic the proper useful behavior with a bugged piston.
The whole issue can be solved by having both kinds of pistons.
Either form, by itself, will make some things easier and some things harder.
But what is currently there is inconsistent, and confusing.
Backport this to the 1.4/1.5 worldgen as well.
In other words, since nether fortress/strongholds got messed up in the new version, give those of us that have not yet upgraded the ability to preserve our worlds as we move forward.
I would hate to upgrade to 1.6.4, only to find that the game now thinks that all my fortresses and strongholds are in different locations.
So, not only do we need a converter program (so we don't have to visit every chunk), we need to be able to tell it "This world had 1.5 generation" or "this world had 1.6 generation".
Or worse – do the 1.6 strongholds actually "move" depending on whether you went to the nether before finding them?
The problem is that strongholds are "structure-specific" in being the target of eyes of ender.
Does the bug affect the locations of strongholds, or only the contents of strongholds? In other words, do the eyes of ender still work correctly? Is it possible for the error to result in old strongholds no longer targeted and new ones wanting to be generated?
Making a village zombie-proof is "easy". We came across the answer by accident.
1. Make sure that there are dark spots in, around, and outside the "village". Zombies will spawn there.
2. Make sure that zombies cannot get to the villagers; fences / glass / iron gates / elevated platforms do wonders here.
"Village" is defined by a large square around where the doors are, not where the doors are or where the villagers can walk.
We stumbled across this by accident when making a "research lab" over a frozen lake, with part of the "village" elevated over ground. Lots of things spawned under the walkways, around the walkways, outside the buildings, etc, but nothing inside the iron-gate walled elevated pathways.
Only thing that could get in were spiders.
NB: The first step in fixing sieges: Get the inside of the rooms "safe" from zombies. Seriously, the houses have dark spots. No wonder there are so few people in the villages – they were sieged before time 0.
(doesn't explain the low reproduction rates of natural villages
I agree.
Villages are currently badly designed, expected to be wiped out, have dark spots inside their "safe" houses; villagers will walk outside as soon as the sun comes up while zombies are still out there; etc.
The current design of villages needs to be improved.
The current "houses without doors" needs to be fixed on generation.
The whole "you need 8 (9?) doors before any survivors will breed, but you probably won't get that many in any village" means that a village is never expected to survive.
The whole "harder difficulty == village more likely to be wiped out" implies that a village is supposed to be something to be an aid for players, but the whole trading system is broken for that.
Yes, I think that villages should, by default, be big enough that they expect to survive a siege and repopulate; that sieges should generally be rare; that villagers should stay indoors until the monsters are gone; that the houses and churches should be safe. That's not what happens.
So both sieges AND villages are broken.
I have been under the impression (from reading the wiki and other things) that a village is defined by a villager near a door; once villagers sense a door, then a village is recognized by the game. If multiple villages have overlapping bounding boxes, then they can be combined into one bigger village. The size of the village's "box" depends on (number of doors? number of villagers? not sure which), but has a different height versus villager breeding / population cap, which allows for "split-level" villager farms.
Beyond that, the wiki article has changed since I last looked at it. Last time I checked it, it said that zombie sieges would attempt to start at the edge of the village, and only switch to spawning inside the village if it could not find darkness at the village edge. My memory of the article was that it said that zombies would spawn in dark places first, lit places or slabs as a last resort.
Equally, the need for a large village is news to me – I thought smaller villages would get smaller sieges (and it was probably just normal zombie spawns then.)
> Why can't 1.7 just keep a copy of the old (1.6) algorithm around and use it when newly-loaded anvil regions don't have 1.7 structure information?
We could just as easily ask, "why not keep a copy of the old biome generation around, and use that to decide which biome to assign to a block?". The answer is, as we have seen, that it is much better to keep that tracked in the map. It permits people to make custom maps, with custom biome information.
Moving forward, this will permit people to make custom maps with custom structure setups.
Imagine if everything were done this way:
There are still a few questions to ask:
1. Why was the obfuscation table changed? Instead of 95% of mods working unchanged, everything had to be adjusted.
2. Why not release a 1.5.3? This does affect all nether structures made up until now; you'll either have to regenerate your nether from scratch or have things off. (Given how big our nether got before 1.5 and quartz, this looks like the best option for our server – keep the hub and toss everything else.)
3. Why not have a patch program auto-load all existing chunks? We've seen converter programs in minecraft before – see .mca/.mcr
4. And as you mentioned, why not have 1.7, when it loads a world and sees no structure information, just assume it's 1.6 and stamp out the 1.6 structure information? That has the same affect as a patch program loading the world / a converter moving from .mca to .mcr, while still letting custom map makers make maps customized. Note that if this were done, doing it on a region by region basis is a BAD idea – do the whole map the first time it's loaded and found to be missing. The map should be in a single consistent state at all times.
Requiring manually visiting every spot? I can guarantee that people will miss spots. This has to be a ... brilliant idea, for some concept of brilliant that I don't quite understand.
Me: > And as you mentioned, why not have 1.7, when it loads a world and sees no structure information, just assume it's 1.6 and stamp out the 1.6 structure information?
Th3F4114n0n3: > Basically why we don't have the 1.6 algorithim with the 1.7 algorithim has a very easy set of answers answer. ...
On the assumption that you were responding to me, I think you missed the point of what I was saying.
When the map save format changed, moving from .mcr (region format) to .mca (anvil format), the game would detect the old format, and stamp out new data, all at once.
There is no reason this same behavior cannot be placed into 1.7, even now – load up the existing world, stamp 1.6 structure information into the whole thing, and save that all out.
Equally, there's no reason not to have a 1.5.3 that only does this with 1.5.2 level data, for people who have not updated yet. Remember, 1.6 did change the nether fortresses, at least (all I know of).
> So you have 1.6 algorthim running when you open an old world, then as you start loading new chunks and they use the 1.7. While it sounds easy, at what point does the 1.6 stop running? How many lines of code would be needed to make this transition happen seamlessly? The answer, a crap ton.
No, you don't run both at the same time. You transition. The map is always in one consistent state, either the pre-structure or the post-structure.
> At the same time if you've loaded 50 structures, do you actually visit all 50 structures on a regular basis? Can you deal with missing some that aren't important?
Have you ever run into an empty village? Only to count, and find that it's about 120 blocks from your base? And realize that as you're moving around the area just outside your base, this village has come into and out of focus at night?
And with a little thought, realize: zombies loaded into memory will move around, see a villager, and chase. Even if only for 30 seconds, every time you leave the range and come back, it gets another 30 seconds.
(It actually had two surviving villagers, but it had buildings that clearly indicated other villagers had been alive at some point. Distance 120 is approximate, I could go back and actually check.)
Finding structures that don't work – whether villages ruined by the crime of being too far from you to be seen behind the hills but close enough to you to be killed by zombies, or swamp huts where nothing will ever spawn, or having no witch spawning zones at all within 3000 blocks of your base, or trying to find a new nether fortress only to find a bunch of nether brick that just sits there and does nothing but pigmen and ghasts, ...
Heck, just imagine if your ender pearls lead you to the middle of nothing because you never loaded the stronghold chunks because you didn't know where they were.
Now, is that all?
Here's a question I don't know the answer to: If you walk near a chunk, such that the chunk is loaded, but nothing in that chunk changes – it never gets dirty or altered – then does the chunk get saved back out, or not? If only modified chunks actually get written, then what? Yes, I know that a monster being generated, or moving in the chunk, will "modify" it, and I know that the likelyhood of the optimization being valuable is low, so it might not be done – but if the game does attempt to track dirty chunks and not write clean ones out, then are you sure you got all of them saved/marked?
OK, so a bit of misunderstanding here.
I'm not complaining about the decimated village. I know that's part of how things work. I know that if it had gone longer, it would have been completely wiped.
Point is, imagine going to some other structure you find, and find that it doesn't work – because you did not know about it until after you went to a 1.7 game engine.
Second, I mixed up ender pearls and "Eye of Ender". Eyes of ender are supposed to be the tool you use to find strongholds – what if their location changes and you never knew to visit their old location? Imagine this sort of thing happening to any structure.
The point is: "Players must visit the structure for it to work" is a bad idea.
> I'm not understanding tis sentence. It soulds like your saying on world start it would determine whats new and whats old and stamp them out to be set as structures. The problem is that the chunks aren't loaded for it to scan eveything on start up. You could theoretically have it load all discovered chunks at once but then you'd lag all to hell, if not crash on the lower end machines.
Nope. This was exactly what was done – and still done, as I understand it – when you load a region format world into an anvil format engine. It loads and converts the whole world.
> They aren't going to go back to 1.5 and make a 1.5.3 to accomidate people who haven't update since then. Its just not feasable for them to as they're resourses are in current releases. they gave a reasonable option for 85% of people wanting to bring there old world over by having people load the chunks they want brought over.
No. You mis-understood the issue here.
100% of all nether fortresses generated prior to 1.6 are ruined by 1.6!
Many people have nethers that are dominated by 1.5 generation; relatively few nethers are dominated by 1.6 generation.
If you had a 153 that could stamp out structure information, then all you have to do is load your world in 153 once; then, you have proper 153 structure definition in the nether, and 164 will work correctly with you pre-16 nether.
Nether fortresses were what, 142? So all the 14x and 15x fortresses would be fixed by a really simple update, and forward compatible.
As for keeping the old world generation algorithm: Last time I checked, you could use the 1.1 world gen, or the 123 world gen. Adding in the 1.7 world gen only means that the game has three of them instead of two of them.
Yes, you have to manually adjust flags to get the old gen – there is no GUI setting for it – but maintaining multiple world gens can be done, there is an internal API to select flat, standard, large; that can be extended to permit ATG, or BWG, or BOP; the same system permits unlisted but still present older versions.
Mixing two different systems is not being mentioned here.
Mixing two different systems will happen – but in the sense of "All your old chunks are 1.6, all your new chunks are 1.7" – and we've seen that happen before when jungles were added. Mixing the output of these two systems is not a problem.
And no one is talking about mixing both as live code at the same time.
>I, as redstoner, I don't want this "BUG" (not in my opinion a bug) to be removed. All systems will break with BUD-switches
You don't understand.
I'm not asking / wanting the behavior of piston block 33:0 or sticky piston block 29:0 (I hope I have those numbers correct – odd that they are not adjacent numbers) to change. I don't think anyone else contributing to this thread is asking for existing behavior to change.
I want them relabeled to something like "Quasi Piston", or "Quasi Sticky piston".
I want the crafting recipe for them changed, with the redstone in an odd place, to indicate that they can get power from an odd place.
I want new pistons added – either new blocks or new meta data – that behave sanely.
I fully agree with Mojang that "Fixing this would break too many things". Never mind that the timing changes to pistons in 1.5 broke things, and as far as I can tell, ruined dependability (if a piston is guaranteed to make its state change in 1.5 redstone ticks, then you know exactly what the status will be at 1 redstone tick, and at 2 redstone ticks. If the piston is guaranteed to make its state change in 2 redstone ticks, then is it at the beginning of that tick before anything else happens, somewhere in the middle, at the end, how does it interact with other things happening, etc.)
Mojang has a history of "We will break things".
I'm not asking for "Break things".
"Works as intended" is not a valid resolution.
"Will not fix" is.
"Unexpected, but now desired" is.
"Will fix without breaking things" is.
The current system makes little to no sense, causes all sorts of problematic work-arounds, and yet still has uses.
I really cannot believe "This was the goal from day one" ("working as intended") is accurate.
Say something like "We want this current, strange system", "Fixing it is more hassle then we think it is worth", "Yea, it needs to be fixed, but it's a very low priority for us", "We'd like to fix it, but we don't see an easy way to fix it", or something else.
What? What does "setblock" have to do with pistons?
Yes, this is still an issue in the current version, with the current launcher, or the current multiplayer server, or the current single player game.
Seriously Dinnerbones, you said this is indended? Can you please explain why you consider this a desirable or intended feature? Yes, you can load command blocks and redstone near spawn and they will always work – how many of us actually use that? Can you at least give us server control of the loaded radius as a compromise?
New launcher (1.6.2) now used, and ... the behavior is changed. Not fixed. Bugged differently.
Opening a new ticket.
While the issue with ctrl-drop versus command-drop is a duplicate of the other tickets, the issue with the command key being "stuck" is not.
> When starting up, I normally find the "command" key stuck – the first time I try to use it, it does not work. Additionally, any time I use command-tab to switch to another app, and then back, it is stuck again.
That issue is not referenced, that I saw, in any of the other reports.
It affects me because I normally find it when I attempt to drop something and it won't behave, or if I'm trying in chat, and I try to backspace to fix a typo only to find that I've wiped out almost everything that I've typed.
Near as I can tell after playing with this for 2+ weeks now, Minecraft never sees the key_up on command in some cases – including command-tab out of minecraft. Even command-tabbing back into minecraft will generally not see the key_up.
That it starts misbehaved ... still confuses me. I'm not sure if command-tab is the only source of lost key_up notices.
As I read this, I realize: I have never made a map in the nether. Never even thought of it.
Is a java byte an unsigned 0-255 integer? That's what I think of when I think of a byte; when I think "char" I think of -128 to +127.
If this is an unsigned, 0 to 255 integer, then what happens if you make a map in -1 / the nether?
The problem is, that if you say "maps are not supported in mods/mod dimensions", then you are fundamentally saying that a key point of the game will just not work in other dimensions.
That's like saying that a coal block can be placed in the overworld, or the nether, or the end, but any mod dimension where coal blocks won't stay on the ground, well, that's a mod, so that doesn't count. Or worse, you can only place coal blocks in dimensions 0 to 255, and not in the nether.
The cast to a byte does nothing to improve vanilla, and artificially hurts mods to the point that maps have to be re-implemented in order for worlds with a negative dimension number, or a dimension number above 255, to work.
The claim that any object in vanilla can be made to fail in mods, and that it's not a bug in vanilla, is just not a reasonable claim.
And why would you claim that the nether cannot be mapped? You could have the maps render the "sea level" – the first air block in a column stops the map, so you see what happens at the bottom point in the map. Or, you could have the "sans roof" – the highest air block stops the map. Right now, you have the "highest non-air" block – what makes one better than the other?
Between being unable to even represent the nether, arbitrarily failing in any mod-added negative dimension after establishing that negative numbered dimensions are valid, and arbitrarily failing in any high-numbered mod dimension, all for no reason, and requiring a mod framework to re-implement the object from scratch? All for one line of code change?
I call that a bug to fix.
Alright; should it be in the "Discussions" section, in the "suggestions" section, in the "Redstone discussions" section, or somewhere else?
And if you do make an official forum-thread followup, please post a link here from there, and there from here.
http://www.reddit.com/r/minecraftsuggestions/comments/1qyz4d/change_to_piston_quasiconnectivity_mc108/
Reddit minecraft suggestions.
The exact result, in 164, is that memory consumption goes up, and keeps going up. Every time you change dimensions, there is a full GC, but the amount used does not go down.
In 1.7.4, this is fixed – repeated testing shows no change in memory usage, even after exploring a large amount of the nether.
So, yea, already been corrected (ABC).
Whoops, yes. Still present in 164.
Will retest in 174 "real soon now"
So I did some playing around.
First: Re-creating the world, brand-new, in vanilla (so the test is in a copy of the world that has never seen forge): No null pointer.
HOWEVER: The village on re-creation is a ghost town. No people. Additionally, no chest in the smithy.
Try again with 174: World loads just fine. Same issue.
Delete region file: Surprise! There is now a stained clay mesa hills biome there. And, in the middle of the stained clay, desert village buildings, sometimes dozens of blocks down in the hill. Not on the surface, deep in the ground. Where the buildings were before.
No people. No chest in the smithy.
Look around for a 174 village. Find one. People, smithy, chest in the smithy.
Quit, delete region files, restart.
Newly rebuilt town. Farm land starts dry, hydrates. No people. All the animals around – sheep, horses, etc – are there. Just no people, no chest in smithy.
Quit, delete region files, * and delete the two village data structure tracking files *
Restart. Village is there. People are there. Chest is there.
===
So the initial problem – null pointer on server startup – seems to be because of something left over from forge. No clue what. It goes away on a world that never saw forge.
However, when a structure, such as a village, is re-created from the data in the structure files, it does not rebuild "supplemental" stuff such as people, or chests. I am curious to see what would happen in a rebuilt pyramid (treasure chests? TNT?), or temple (chests? arrow dispensers?), or mineshaft (any of the wood support beams? Any of the minecarts with chests?), etc.
In other words, only part of the information is stored in the structure files, and only that is used to rebuild.
===
At first guess, it is entities that are not being saved/restored. This is understandable – entities such as villagers can wander. But tile entities, such as chests, don't. And, just as horses/sheep are recreated with the landscape, so too villagers should be recreated with the village landscape.
So, there is more information about the structure at generation, than is saved in the structure files.
And when it finds structure file information, it only uses that, and ignores/does not actually regenerate the whole place.
Wonder if this means that the blaze spawners in the nether fortresses would go poof as well?
Actually, it has.
I have repeatedly re-created the same world/seed in 1.1 through 125, using the trick of specifying generator version – http://www.minecraftforum.net/topic/1003941-howto-use-a-11-seed-in-12w03a-or-later/ – and I've had no issues with trees being changed in that range. So seeing this be very non-deterministic in 174 is a shock.
Additionally, I am saying that the layout of sand and dirt on the ocean floor is not consistent/deterministic. The vast majority of the time, yes, but it is still possible to get sharp boundary lines.
I know that chunk generation has two phases. Roughly, phase one is 100% deterministic and relies on no other chunks, and includes height (technically noise) and caves/ravines. Phase two is the decorations, including ores, trees and buildings, that can rely on other chunks existing (an ore deposit or tree can extend into adjacent chunks), and this phase can be changed by having different mods loaded, making different use of the RNG.
But when the game is not changed – and I'm talking about two tests of vanilla 174 with the same seed at spawn being different here – those decorations should still be identical.
I agree with "works as programmed"
I disagree with "works as intended".
There have been, in the past, bugs that have resulted in chunks being regenerated because of errors. I believe the code still has checks for invalid data and forceably regenerating the chunks when that happens.
My point is, when a chunk is being regenerated, then all the information should be regenerated.
There are two potential ways that this can be done:
1. On chunk generation, ignore anything about that chunk already in the structure files; write out any new data about structures generated afterwards. This is arguably the proper way – as seen when a 164 village was "restored" into a 174 landscape, the structures are made based on how the ground is made, and when the ground changes, the old structure data should be replaced with new ones.
2. If structure information is to override new generation, then the structure information needs to be complete enough for a full duplication.
Right now, the structure information is not complete, and so the chunks do not generate completely when structure data overrides chunk generation.
Since the result is inconsistent chunks / inconsistent generation, while working as-programmed, it does not seem to be as-intended. Not when the result is that the old system behaved better than the new system.
With regard to the question, in single player, are loaded chunks and render distance tied together:
I can't answer for short or tiny. But for far, for 164, you can be more than 8 chunks away, expect items dropped on the ground to be in unloaded chunks, and safe ... and be wrong.
Back in 125 single player, render distance could be far, and only blocks within normal render range would tick.
[quote]how should i interpret "resolved" and "Works As Intended" ???[/quote]
The answer is both simple and complex. It comes from ... Grum?, I think; it's basically saying that Mojang, at that time, had no plans to change the behavior.
Why it is "Works as intended" instead of "Wont fix" remains a mystery known only to Mojang.
"Works as intended" means that it was always the case that Mojang intended for these strange, active-but-unpowered devices. That it was always intended for something that was otherwise a good state-based cellular automata system to suddenly be broken and behave strange.
"Won't fix" means that while the behavior was not intended, it is more desirable to leave it as-is than to fix it.
This whole issue – and please tell me, are there any other "resolved" issues still being debated – could be resolved by either changing it to "won't fix", or by adding new pistons that behave properly in addition to the current funky ones.
The other thing to consider is that Grum (I believe) has said that the current focus is on refactoring and cleaning up the current code mess that is Minecraft. It is entirely possible, if not probable, that the existing code would make it hard to clean this up, and implement cleanly.
If that is the case, then we should ... encourage the cleanup of the redstone codebase, so that trying to maintain the existing behavior winds up looking like a mess in the code; that alone might be enough to convince talented, observant programmers to implement a clean alternative in time for 2.1. (we already had 2.0, but it had even more redstone bugs.)
I am requesting this to be re-opened. I can confirm that it appears to still happen in the current version (tested in a superflat world).
The issue is a "bug of omission". There used to be no code at all to generate a floor when carving over air. Code was added to force a floor when carving tunnels over air. The issue is forcing floors when carving a staircase over air.
done; http://www.reddit.com/r/minecraftsuggestions/comments/27nq2z/mineshaft_staircases_and_start_rooms_should_force/ if anyone reading this wants to upvote it.
Unlikely to be the same, but might point to something similar.
I looked, and their list of classes does not include the repeater. Maybe what is being seen has the same issue as that.
To clarify: There is an attachment that shows a loop of just redstone torches; that is easy to show the timing error, and is almost certainly the issue that they found (that random block updates interfere with time sensitive scheduled updates – I agree that the call for a scheduled update should not be the same as the call for a random update). But what I originally found this in, and showed in the video I linked, had repeaters and was not just going into timing error, but steady state – including an "impossible" to get to but stable once obtained state.
Hmm, need to retest in 1.7.10 ...
Ok, tested in 1.7.9.
Actually rebuilt both circuits in a new world.
The pure torch loop fails fairly quickly. The torch and repeater loop takes longer to fail, but still fails.
Oh. My video in the original post showed my original circuit – a little more complicated. Basically, an R/S Nor latch, with 3 repeaters at length 4 – two on one side of the circuit, and one on the other side. A "doorbell" button that fed into the circuit, and noteblocks (plus a redstone torch) as outputs.
Gave a nice, "stable" doorbell while playing single player. It actually worked properly in 125 single player. That was the last time that complicated redstone circuits worked without timing issues – heck, instant wire worked across unloaded chunks.
That it worked in 125 single player, and broke in 125 multiplayer, is why I suspect that random block updates is not the only issue, even if it fixed other issues. 125 single player would still have had random updates and scheduled updates.
Actually, there is something else.
If the issue was that a torch getting a random update would turn on and stay on, then I would probably be seeing a different failure pattern.
The "fail" state is always the impossible state. The circuit should exist in either the "off" state, or the "loop" state – the "on, stable" state should never happen.
The "fail" state is always the "on, stable" state – it never fails into the off state. If I'm understanding what you said about the torches getting random updates and going bad, them 1 out of three failures should be into the off state.
My computer is in the shop right now so I can't test. Should be back by monday.
(Motherboard failure under warranty)
AAarrrggh.
I cannot find that test world! I have checked every save I can find.
I am getting the same crash, while just going through the options menus on 1.7.10, before even starting up the game.
Mac OS 10.7.5
Java 1.7.0_65
EDIT: Just to make sure you understand, I can duplicate this in vanilla, unmodified 1.7.10. Most recently happening was while letting it test the various twitch servers.
That it doesn't meet the requirements for twitch does not mean that it should crash.
Keep in mind: It is not crashing because I try to stream and the twitch libraries need a newer OS. It is crashing even when I don't use twitch.
Again, you are missing the key point.
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"?
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.
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.
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.
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?
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.
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.
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?).
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.
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.
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.
1.10.2? Sure. Give me a moment, and I'll get a URL/timestamp for you
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.
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.
So these can be updated without changing the game version?!?
...
GAAAH. Support nightmare to have two different user-facing programs with the same identify.
Alright, testing with the captive minecraft map, and my captive polar bear exhibit is making all the expected sub-title sounds.
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.
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.
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.
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.
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".
> 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?
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?
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.
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"?