Kyle Koder
Assigned
Reported
Comments
Update: after replacing the spider eye layer with a custom version, I've come to the conclusion that the fire render issue is due (as one may expect) to an issue with the lightmap settings upon leaving the spider eye layer rendering method. I've fixed this in my mod by simply saving the lightmap texture coordinates to method-local variables, doing the render, and then setting them back to what they were, instead of attempting to recalculate them as is done "currently", "currently" being 1.12.2 in my case.
Edit: My solutions for spiders and endermen can be found below, but they also include a non-optimal workaround for team glow color (MC-84404). The relevant part for this issue is strictly the lightmap-related code (what has been removed, changed, and added for lightmap-related functions):
...
Update: after replacing the spider eye layer with a custom version, I've come to the conclusion that the team-colored glow is rendering just fine...however an additional white glow layer is being rendered on top of it during the spider eye layer render. I've partially worked around this in my mod, however the part of the glow near the spider's eyes is still white (while the rest is normal). This is good enough for me, but for vanilla, this would be best solved by not drawing the glow while rendering "bright layers" such as spider eyes.
Edit: My temporary solutions for spiders and endermen can be found in the links below, but as I said earlier, it's probably better to fix this by instead not drawing the glow during these render layers:
...
I was able to fix this for spiders in a forge 1.12 mod by using reflection to remove the spider eye render layer from the spider renderer's render layer list. Doing so also fixed MC-84404.
I was able to fix this for spiders in a forge 1.12 mod by using reflection to remove the spider eye render layer from the spider renderer's render layer list. Doing so also fixed MC-69696.
In my case, the area remains glitched after a client reload (f3+a) and/or a server reload (leaving area and returning and/or logging out and logging back in. I don't think I did an f3+a in the video I posted, but I did test it just now. The video covers most of the other points.
I haven't done any thorough testing on underground areas yet, but I'm betting they are still 16x16x16 block areas.
I'm surprised I'm the first to mention this for 1.9 stable release...but then again, I hadn't been playing MC for a while and wasn't there for the snapshots mentioned, so maybe it's not as bad now as it was before, but our server (running 1.9 stable) still has this issue.
I recently made snocrash's pigman grinder, and if I go up and activate it, the following WILL happen:
1. Lag will increase noticeably for all connected players
2. The pigmen will start jittering as they move (due to server taking many seconds to process all the pigmens' AI)
3. The server will crash
These happen consistently, every time.
We've noticed lag at other times as well, but the above example is the single most extreme case, and proves there is still a major issue with the AI (and yes, the pathfinding does seem most likely, as others have mentioned, since the pigmen in the grinder can't actually reach you and it will push the pathfinding algorithm to its limit, whatever that limit is).
Steven mentioned a sudden jump in memory usage. This in combination with other evidence makes me think it's probably an issue with method recursion. This is just the most common culprit for similar situations I've seen before. In many cases, each level of recursion must retain any temporary variables / data structures / objects / etc it has created until (at least slightly after) the final recursion returns, so if you're not careful, it will easily use up all resources available to it almost instantly (unless there is some kind of delay in the method...or a few other exceptions).
I'm guessing one reason they're not just moving back to the old algorithm is because some of the new features rely on the new one...?
TLDR This still seems to be occurring in 1.9 stable release SMP vanilla; can any confirm?
Confirmed for 1.9 villagers; I had villagers disappearing in a safe fake village too small for zombie sieges, and assumed they were entering walls and suffocating, so I replaced my solid block walls with half-slabs hoping to fix it. Well, looks like I was right, because now I have a villager stuck inside the half-slab wall in the corner.
This is probably how it's happening:
1. The villager (or other mob) pushes its hitbox into the wall (this is observable in "empty corners" or corners with empty diagonals; a mob can push or attack you if you stand in the corner)
2. When the chunk is unloaded or loaded (can't see results in between an unload and a load without looking at raw save data), the villager is considered "inside" the block, and as we all know, you can move around and/or stay inside a block once you're inside it...
As for the specifics, that's for the devs to look through the code for, since it could be any number of things, like...
...the chunk saving between an entity's movement and it's movement correction if the game uses that type of system, which would effectively remove the part where "the wall pushes back" (most likely of my guesses)
...a rounding error during save/load, particularly if different variable types are used
...any number of other floating point physics engine glitches.
In either case, some workarounds that should help would be...
...after finding whether the glitch occurs during unload or load, add a bit of code that pushes entities into the CENTER of an adjacent air block (only during the chunk load/unload, where the glitch is occurring). There would have to be air blocks (and other non-physical blocks) directly adjacent that fit the hitbox as well as a steppable block below them.
...simply add some (very reasonable!) behavior to the AI...like...
if (suffocating in wall) then {try to move out of wall}
...which would make a lot of sense even if we didn't have this glitch, AND would help with the glitch (though they would still take some damage, and could still die with repeated glitching...and if they're stuck in a corner like mine, they still wouldn't be able to escape anyway)
Ah, I see. Glad your bug is fixed! And yeah...that sounds even more annoying than the one I mentioned lol...
Sorry to bug you by posting here. The issue may have been marked as "resolved," but the comments didn't reflect that, so I assumed it was "resolved" and not RESOLVED...if you know what I mean.
My apologies...each edit was after more tests were done, and I assumed a post edit would not send mail (personally I don't think it should; only new posts...that's one of the reasons to have an edit button). I'll avoid it from now on as best I can. This system doesn't seem to have mail or pm capabilities (unless I'm just not seeing them), or I would've sent you a mail instead of posting this.
Since I'm posting this apology anyway, I'll include a link to a video that proves this lighting glitch is affecting 16x16x16 areas, not full height chunks - https://youtu.be/f-1ql9vngag
And I almost forgot to test with a fixed 16x16x16 ABOVE a glitched 16x16x16, shown in the picture attached. If you look at the picture AFTER watching the video it makes sense. Also...I thought that "attach files" would include them in this post...sorry again...
SIDE RANT
More importantly, I'd say that edits sending mails should be changed at the very least; it discourages people from doing further testing and posting their findings. I realize for some, or even MOST issues, the entirety of the information can be posted in one go after all testing is done, but I think it's reasonable to say that this issue is not one of those, since it's been around for many years even after Jeb specifically targeted and attempted to fix it. If you want some real tests that show actual useful information, the system should not have something in place that discourages the posting of such information, even if it was found shortly after a previous post was made (I know this is not your fault and that you just have to deal with it as part of your moderator job FV...my condolences). I may even go so far as to say that if you don't like it...unsubscribe! (Again, I'm assuming mods cannot unsubscribe, so sorry about that; just meant for those who can.)
Also, a mail system should be added, so that you don't get UNRELATED SIDE RANTS LIKE THESE in the threads, taking up space!
Lastly, I didn't even notice that preview button until you said it existed...plenty of horizontal space down there for it to actually say "preview" but guessing that's atlassian's fault (but thanks for bitbucket, atlassian...very useful).
...and when you attach a file, it has you put in some description text, but neither the file nor the description text link to each other anywhere...? That will result in some extremely confusing posts. That's no good.
END SIDE RANT
Sorry one last time FV...just angry at the system, not the mods.
The single block with the dark bottom face is showing the glitch in the 16x16x16 block area directly BELOW it. You can also see the one fixed 16x16x16 as the light section on the vertical 1x1 tower.
This is a very broadly discussed topic, so hopefully these things were already considered, but...
...were the villagers in a completely lit and inaccessible area? (wooden doors should be treated as open doors, and one-block high openings are not safe, even adjacent to a wooden door to "block" it, as kid zombies can still go through)
...were there enough villagers for a zombie siege to occur? If so, zombies can spawn INSIDE well-lit areas, including inside houses, and will in most cases the resulting zombie villagers despawn before you return to the village, leaving it empty (unless they fail to kill the golem, which happens sometimes, but they usually get all the villagers).
Of course, neither of these should kill them off if the village chunk itself is unloaded. As for whether a zombie siege can occur beyond the 128 block despawn distance, I'm not sure.
This sounds more like a legitimate zombie siege; yes, there should be zombie villagers after a siege, but they are then hostile mobs, witch can start despawning randomly if no player is within 32 blocks, and should despawn instantly if no player is within 128 blocks. If this were the invisible entity glitch, the villagers would still technically be there, so you would at least see doors opening and closing during day and hear villagers getting killed by zombies (if applicable) during night.
This is pretty broadly discussed in many forums, but...there's something (unofficially) called a zombie siege that can happen, where masses of zombies can spawn IN villages, even if they're walled off and fully lit. This is the most common cause of a mass disappearance, especially if the village had golems (golems have the same population requirement as zombie sieges, if I remember correctly, so if there was a golem, you could have a siege and vice-versa).
THAT SAID...there have also been legitimate cases of villagers "disappearing"...probably without getting killed as they can still be seen on other programs such as MCEdit AND still count toward the number of villagers (I had a village where this was happening and the village later acquired a golem with only 6 villagers present). This is not the glitch where entities don't render, as reloading the chunks / leaving and coming back / restarting the game don't fix it.
I have a feeling in your case, it's just a siege, but if not, you might want to add some more info about what the village was like when it happened.
Edit: According to the wiki, the requirement for a zombie siege is 20 villagers, not 10...my mistake there. Still something to consider though.
Confirmed for 1.9 stable
A few deductions I've made (Jeb probably already considered these, but just in case)...
1. Because mobs can spawn in the dark spots (Marcus mentioned, I confirmed), even on SMP, it seems to be server-side (in SMP).
2. Block light levels are updated on triggers (not periodically), which leaves a lot of possiblilities, but...
3. Marcus also mentioned some are sky light levels, which are updated over time as the day/night cycle continues, which means the light level update is either not running for certain air blocks or that it is giving a false result consistently until related data is updated.
4. Both cases rely on the same data, so that's one chokepoint for finding the issue, though it can branch out again from there to anything that is altering (or SHOULD be altering) the block data.
5. To narrow that down a bit more, the PHYSICS of the blocks in the areas are perfectly fine. That is to say...the issue is not that there is a phantom solid block, etc. The issue probably lies in the state of a more specific data set than the one that keeps track of which blocks are where.
There are so many ways of doing things beyond this point that I can't make any further deductions without seeing the source, and I don't really feel like trying to go through obfuscated decompiled code to find something this complex lol (I really don't feel like looking at obfuscated code at all, and haven't...so far). Not sure if any of that helps, but maybe someone can expand on it or correct anything I may have wrong.
Lastly, a couple very broad areas that could affect many systems including the light levels...
...skipped or cut-off frames, ie frames belonging to a cyclic executive or similar task sheduling system (if the relied-on data was supposed to be updated there...but this is not likely, as the sky light levels would have to be skipped consistently if they stay there through the entire day cycle, which I have not confirmed....do you know if they do, Marcus?)
...data synchronization
These are both broad categories that could affect any number of things in a game, and may or may not have anything to do with the issue.
Edit: A few more bits that may or may not be helpful:
1. Sometimes the block renders as black when the (glitched) light level is 0 and the sky light level is high, even though it is supposed to use the higher value, and sometimes it renders the sky light level.
2. Placing a solid block on the dark face of a glitched block seems to extend the glitch to the same face of the new block. I extended one on side face and it extended until 2128, a chunk boundary but not a region boundary (80 blocks or 5 chunks from the nearest chunk boundary at 2048...interestingly, this was at a height of 80, which matches the block distance from the region boundary, but...that's probably not related...?)
3. Noticed edges of a glitched areas were at a chunk boundaries (in their found state, not after adding blocks as mentioned in #2), but not necessarily in a single chunk (some extend through multiple chunks). There are some exceptions though...I think I noticed an organic shape in one area...
4. Glitched areas don't seem to extend to region boundaries (at least in their found state), though they COULD have an effect if the area would normally extend beyond them...this would have to be tested at a region boundary though, and finding a dark spot on a region boundary is no simple task.
5. Watched affected areas as they loaded on an SMP server; they all seem to have boundaries matching edges areas that are loaded at a time. I'm not saying "chunks" because one of them is directly ABOVE unaffected blocks (flat vertical wall, glitched on side face), and visibly loaded AFTER the lower portion of the wall. Are chunks no longer full height, or do chunks load in sections from bottom up? If they're not explicitly being loaded in vertical sections, are they loading partially due to multiple chunk loading threads, or possibly packet transmission sections (would assume full chunks for each packet, but...)?
6. Added block adjacent to a glitched area, was fixed, relogged, broken. Removed block, fixed, relogged, broken. Added block JUST inside glitched area (glitched top, added to top face), still glitched, relogged, FIXED (interesting...). Same behavior for 1 block further inside (moving horizontally, placing on top face which is glitched). Same behavior for 1 block above as well, so probably any within area...HOWEVER it only seems to fix the glitched area for a certain distance, maybe the distance the "fixing block" would alter other blocks' light levels...?
...this is getting long and turning into a debugger's ramble. I think I should stop here.
In MinecraftServer.class, in the updateTimeLightAndEntities() method, if allow-nether is set to false, it completely skips the world tick of every single dimension type except overworld. This includes modded dimension types, of course (which is how I ended up here), but also obviously the end as well.
The setting's name is a far cry from what it actually does. If no change to functionality is wanted, it could at least be renamed to "allow-other-dimensions" or something.
Code analysis done in 1.12.2