Brianna Schuman
- mhungry
- mhungry
- Europe/Stockholm
- Yes
- No
MC-152707
2018-06-02_21.34.23.png
I just started up a 1.14.1 server, and we are setting up our spawn area to be a protected area. We can easily prevent most mobs by typical lighting, walls, etc. An Illager Patrol has decided to have a consistent respawn point near the center of our manually set spawn chunks (consistent as in they regularly spawn there every few in game days). The respawn point for the Illagers is definitely over 200 blocks from the nearest village and mansion. We are running vanilla, and don't have any obvious way to protect against these raids (besides using commands to give us iron golems), which are inside of our protected block zone (We currently have all of spawn protected so people can't randomly mess up the server ticks, etc).
This is a VERY serious issue, as this is where new players spawn into the world, and are the least protected. We desperately need a way to stop these raids from forming. There is currently no in-game vanilla method to stop this from happening either via builds or by server op command. We are early in the server set up time frame, and this is seriously hampering our ability to move forward.
I just started up a 1.14.1 server, and we are setting up our spawn area to be a protected area. We can easily prevent most mobs by typical lighting, walls, etc. An Illager Patrol has decided to have a consistent respawn point near the center of our manually set spawn chunks (consistent as in they regularly spawn there every few in game days). The respawn point for the Illagers is definitely over 200 blocks from the nearest village and mansion. We are running vanilla, and don't have any obvious way to protect against these raids (besides using commands to give us iron golems), which are inside of our protected block zone (We currently have all of spawn protected so people can't randomly mess up the server ticks, etc).
This is a VERY serious issue, as this is where new players spawn into the world, and are the least protected. We desperately need a way to stop these raids from forming. There is currently no in-game vanilla method to stop this from happening either via builds or by server op command. We are early in the server set up time frame, and this is seriously hampering our ability to move forward.
I've included a map showing our designated spawn chunks (17x17) and their relationship to the nearest village and woodland mansion.
Brianna Schuman Might not necessarily be about the nametagging in that case, but would be good to know.
As I currently can't do that myself, could you test if this happens also with any mob riding? Villager would be an adequate test entity, as it's also similarly large.
If you test with nametagged hostiles, could you please also check their persistence-tag before going out of range? Just to make sure, nametag/item holding works as it should.
Could you please also have your launcher log open and ready, in case anything would appear in there?
Richard Could you please also check the persistence-tag on your zoo mobs, before going out of range? Just to make sure.
This bug seriously messes with the look of a base I'm starting building. There's a glowstone below every glass block in the paths in this image. It's hard to visually tell if I've mob proofed an area properly. I've tried manually updating the bad chunks with the block/destroy forced update method, and sometimes it works for a little while, but eventually it reverts. This happens under optifine as well.
This needs fixing very badly.
Still in 1.12.2
I encountered this bug bigtime when I started setting up my storage system in a multifloor building. Basically, I have a building with a 7 floor deep bunker all the way down to bedrock underground. The three bottom floors are all storage, with the top two being for bulk storage (414 chests each floor in a 6 tall by 69 wide U shape) and the bottom being an individual chest sorted storage system (allowing multiple items per chest; total of 324 chests in a 6 high u-shape arrangement). All floors are seperated by a glass floor with lighting in it for a depth effect. Visually and practically speaking, Item frames with item visuals in them are the prettiest and most practical labeling system. After putting item frames on just one bulk level though (69 frames), I was finding that the frames w/ contents were dropping my FPS massively (from about 150 to 40), even from ground level outside the building. I've thought about switching to signs only on it, but it gets pretty ugly when trying to label the bottom individual chest sorter system, and it takes a lot longer in the bulk storage system to find what I'm looking for.
Item Frames are quite a unique item in terms of what they do and how they display. I just wish there was a way to make them less laggy. They're a great asset, but the amount of lag they produce makes them impractical to actually use in situations like this where they would be excellent to use otherwise. There's got to be some way to lower their lag. I'd give up Item Rotation, for example, if it meant they lagged out less.
Notes on the impact of this bug on play-ability:
Mycelium is only found in Mushroom biomes which are extremely rare. These are the only biomes in which hostile mobs do not spawn and Mooshrooms do. This combination makes them HIGHLY desirable to build in. Grass and vegetation colors are particularly vibrant in this biome, further enhancing their desirability. Mycelium, however, is not very desirable to look at. However, it is a clear, visual cue about the biome that makes it unique. Previously, clearing swaths of the biome of Mycelium with water was a very significant amount of work that yielded great rewards when done well. This tactic has been used previously by several well known Minecraft YouTubers who used it to great effect. Without this option, the only alternative methods for clearing the mycelium are extremely slow, manually doing it block by block, This significantly decreases the usefulness of the biome for base building and terraforming. Effectively, without a widespread, simpler solution such as the previous water mechanic, this biome is more likely to be skipped over and become useless outside of Mooshroom gathering.
The functionality of pistons becoming transparent when open and opaque on retraction is CRITICAL to many machines that have been built and have worked in MC for many years now. To break that functionality would be a major problem. One of the major users of this feature has been large scale iron farms (Iron Phoenix, Iron CASSter, etc). Since the default state of pistons is closed/opaque, it's a lot simpler to design large redstone circuits that extend pistons into an open/transparent state than it is to design default on redstone that retracts pistons one at a time, especially when we're talking about potentially 96+ pistons. There are many other machines that rely on this same functionality of letting light in vs not, and the same mechanics apply.
Confirmed on my home server (MC 1.14 and 1.13.2 running via mineos in a jail under FreeNAS). Idle difference is about 1% on 1.13.2 vs about 14% on 1.14. It's hard to capture in the CPU data, but visually at least, a single chunk /fill destroy command with about 20 blocks of height (16x16 chunk 20 blocks high, crossing subchunks 2 blocks above, 2 below; ~ 46 ~ to ~15 65 ~15) definitely appears to peg the 1.14 server much harder than the 1.13.2 server ever did. It's VERY noticeable. I've added an image of my results on my (antique?) Q6600 FreeNAS server box. I will note that 80%ish CPU time use with Java is effectively CPU pegged because of FreeNAS doing other normal things on the server.
I think I'm spotting 2 disparate but connected issues emerging as I puzzle my way through the frame drop issues. After letting the world load and cool off for a few minutes, I picked two spots on the server's spawn area base that are about 6 chunks apart. I let the area sit for 2-3 minutes after getting to it. Changing chunk render distance had minimal effect on frame rate.
Area 1- Next to a large base storage building with lots of chests, signs, etc.
A- facing the building:
FPS: 46 avg
E:12/195
Total CPU % use avg: 35% (25% for JavaW)
Total GPU% use avg: 29%
B- Facing cleared area. Large 8x8 map on ground using item frames, towards regular spawned land
FPS: 132 avg
E: 144/193
Total CPU % use avg: 35% (25% for JavaW)
Total GPU% use avg: 37%
Area 2 (6 chunks away; out of chest render range, map entities in between)
A- facing the building:
FPS: 105 avg
E:153/168
Total CPU % use avg: 39% (29% for JavaW)
Total GPU% use avg: 37%
B- facing unaltered natural spawned land
FPS: 170 avg
E: 4/188
Total CPU % use avg: 35% (25% for JavaW)
Total GPU% use avg: 40%
Conclusions derived from these simple tests:
1) Something is artificially capping Minecraft from fully using the CPU AND GPU to the full extent possible. At no point was any single CPU core every running over 50%, and at no point did my GPU% ever go over 38%. I have PLENTY of overhead available that's going unused for some reason.
During void world block tests I did (below in point 2), I tested the same actions in 1.14.4 and 1.15.1 on a local world. In 1.14.4 I hit 75% GPU/50% CPU use with a 20x20x20 chest group. For 1.15.1, I never passed the 40% GPU/35% CPU boundaries I experienced above. This reinforces again that something is capping out calls to the CPU and GPU, despite there being horsepower remaining.
2) Blocks that have previously been known to affect framerates (chests, signs, etc) are performing even worse. I ran a separate test in a void world of dumping 4000 chests and another of 4000 wall signs into the world, and the frame rates of both were worse. Signs in particular were giving me a framerate 33% of that in 1.14.4. The overall point being, some blocks seem to be affecting framerates very differently than in 1.14.4, and that is also contributing.
Machine info: i5-2500k/16GB/1050ti 4GB playing on an in home Vanilla MP server running Vanilla 1.15.1, server max render distance 12.
1.15.2 Server/client. Disappears when in a mine cart, removing the mine cart with it. Running Gnembon's iron farm, with a roof covering the entire thing, Zombie helmeted, named, and carrying an item. Zombie will despawn when I go out of range, consistently, every time.
There certainly has been FPS loss due to increased entity use. such as mob pathing improvements, etc. This is particularly noticeable with villagers, chests, signs, etc. This appears to potentially be a distinct issue as it does not explain what some of us are seeing as a deeper base issue: why the game appears to cap out around 30% CPU use and 40% GPU usage. This is especially noticeable on lower end systems (e.g. i5-2500k/1050Ti) where it becomes super clear that lots of processing power is being left unused and frame rates suffer for it, for no obvious reason.
It may be that this issue needs to be bifurcated into two problems:
I agree there is still something going on that should be dealt with on idle. 1.13.2 ran at 1% use idle (see my 1.13.2 v 1.14.x graph above). 1.15.2 on my i5-2500k home server runs at 6.5% average on idle. That scales with the 14% idle I saw on my Q6600 on 1.14.4, and it scales with Michiel's percentages on that CPU. SOMETHING in the server is doing work that shouldn't need to be when the server is idle and no players are on; nothing is being updated or tracked. The server should easily be able to settle to <1% at idle within a few minutes of no connections like EVERY other process on my server does (and I have several that can easily become CPU hogs). The increase is substantial enough to consume more CPU power over time than 1.13.2 and previous ever did. It doesn't seem like much, but a constant low load like that can cause a processor to bounce up in it's power draw.
In the charts I posted when I was using my older Q6600 (MC server CPU test), you'll also notice that EVERYTHING scaled up with the increase in idle use on the server side. Even starting the server now uses much more CPU than 1.13.2 did. Simple tasks do as well. All of this seems to point to a potential bug somewhere that may be calling a routine too often/unnecessarily, etc. I just spun up a 1.13.2 server to check on the same i5-2500k CPU, and yup, it falls to 1% avg. If I manually watch it, it sits at near 0% most of the time with an occasional bounce to 6.5%. My guess/theory is that since 1.14, the thread is perhaps no longer putting itself to sleep all the time, or is checking/running a routine constantly without regard to it being in a no player state when it could put itself to sleep/stop doing The Thing. Probably a flag somewhere not set or removed.
With no players on, the server does not load and tick the spawn chunks by default. For what reason would the spawn chunks continue to tick with no players on unless you deliberately set it to? E.G. I have an iron farm (and usually do) in my spawn chunks, and it certainly does not run when no players are online, nor do any other things in spawn. There are certainly reasons on MP servers to force it to do so (e.g. using /forceload), but by default, entities don't process, redstone doesn't work, etc. That's the point. NOTHING should be or is active to be tracked/ticked. Nothing needs to be. There is no work that needs to be done with no players on. The world is effectively frozen until a player comes online. The server therefore shouldn't have anything to track, so there is nothing for it to do, ergo, it's wasting CPU cycles and power doing whatever it's doing.
Per the official Wiki:
Idle timeout
Each dimension has its own "idle timeout." Without a player or forceloaded chunks in the overworld, this timeout eventually expires. When the timeout expires, some behaviors such as entity processing stop for spawn chunks and the rest of the dimension. The timeout can be reset by frequently sending entities through a portal.
Once the spawn chunks hit idle timeout when all players leave, the world is idle. Nothing is supposed to be happening. So, why the extra CPU cycles? I suggest that somewhere in the code the idle flag is possibly not setting the thread to allow it to sleep, some other worker thread is busy doing useless tasks because it's hasn't been told it's ok to stop, or there is a bug that's continually calling code more than necessary underlying everything. I don't know, I don't have the code, but it's behavior that's unnecessary, and therefore a bug.