Chunks can be loaded outside player loaded areas using various means. Redstone and hoppers are more commonly known but grass spread, tree growth, leave decay, farming tiles looking for water and most importantly fire spread can also load chunks. Most of them cause no harm and some are vital for general gameplay but in the one instance of fires it causes more problems then the other ones listed.
Nether spawns with random fires on netherrack that permanently stay lit. Fires also cause chunks to load around them 2 blocks out from the centre in a 5x5 area. Basically any fire next to or 1 block from a neighbouring chunk on any y-level cause a chunk to load randomly anywhere between 0 and 3 seconds. This causes no problem when there are few fires as said chunks get removed during auto saves. But the issue is when some configurations of fires daisy chain making them even auto save immune. It even gets worse where if there are to many fires in a single chunk they keep that chunk permanently loaded. By permanently loaded referring to chunks that are outside player loaded areas.
These fire loaded chunks get loaded and stay loaded when the player enters the nether and simply explore the nether. Even though the player travelling in a specific direction force unloads chunks behind the player, the fires cause chunks outside the player loaded area to load, behind or towards the sides of the direction of travel where the player loaded areas never have the chance to force unload. After a time of nether exploration these fire loaded chunks accumulate and cause unneeded strain on the server.
The pictures provided shows a mod by EDDxample which shows loaded chunks outside the player loaded areas (green being the player loaded, red the extra loaded chunks). He even shows this in a 5 min video.
https://www.youtube.com/watch?v=kOIsPONbR8A
One of the pictures even show a chunk that have an unusual amount of fires in it for case of demonstration that never unloads. Even after hours of the player staying outside view distance.
Lastly there is even a picture of a random area in the nether (picture taken from the nether roof for ease of travel) to clearly demonstrate that chunks outside the player loaded area stay loaded.
A simple suggestion is to simply have fires not get ticked in lazy chunks preventing them from loading neighbouring chunks. Code provided by Timothy Miller in a picture as suggestion for the fix.
Attachments
Comments 11
Its worth noting that the line:
worldIn.scheduleUpdate(pos, this, this.tickRate(worldIn) + rand.nextInt(10));
only gets called when the fire is updated. It basically breaks when doFireTick is set to false. It won't ever update itself causing odd effects making the fire never go out. It might be worth placing a secondary update outside the if statement to make sure updates are scheduled even if the if statement isn't run.
Picture of code:
http://i.imgur.com/Ipy9K8r.png
There's no reason to spread fire from nether rack. You could just make extra check BEFORE trying to spread: needs it to. It will also make fire dissapating a bit easier.
There's no reason to spread fire from nether rack
I don't see why that's the case. It doesn't make logical sense for it not to spread (it's the fire that's spreading, not the block under it). And there's a gameplay use for it (even if it's rare): if a nether portal gets blasted out, you can relight it using the existing fires in the nether via fire spread.
IMO the already recommended fix of checking if the area is loaded is better.
In the following video: https://www.youtube.com/watch?v=flXSpm5e5QM&feature=youtu.be&t=1377 I suggested the following solution, and here I will argue why in my opinion it solves the problem in a simple and elegant way
"Let fire schedule these fully random ticks (30-40 ticks apart) only if it is not a permanent fire (on netherrack, magma blocks, or bedrock in the end)"
Why effective - the purpose of random ticks scheduled with fire is so fire spreads much faster than randomTickSpeed allows, It makes sense if you light a tree on fire, but with the nether - doesn't make too much sense - the permanent fire won't go away, and won't spread to netherrack, but it still ticks. Fight a few ghasts, and the entire area around you will start tick like crazy "forevar and evar".
If we allow permanent fires to tick only via global random ticks, they will be limited in number, and happen typically only as random ticks do, within 128 blocks of a player (there are a few exceptions in the code, but that's not that important atm). This way when played with render distance of 10 and above, they should not cause any random chunkloading issues, and even with lower render distances, 3 attempts per tick is not sufficient to cause the entire chunk to tick.
The fire from these fires will still spread, in the same speed it spreads from lava, so lighting a portal through them would still be possible.
And the last point - the change would be minimal to the code. The Fire block already determines if it is permanent before it calls to shedule the tick, so replacing:
worldIn.scheduleUpdate(pos, this, this.tickRate(worldIn) + rand.nextInt(10));to:
if (!flag)
{
worldIn.scheduleUpdate(pos, this, this.tickRate(worldIn) + rand.nextInt(10));
}where flag is defined earlier already as:
Block block = worldIn.getBlockState(pos.down()).getBlock();
boolean flag = block == Blocks.NETHERRACK || block == Blocks.MAGMA;
if (worldIn.provider instanceof WorldProviderEnd && block == Blocks.BEDROCK)
{
flag = true;
}I think this simple change could improve greatly performance of the game especially in the nether, without affecting too much existing game mechanics.
BTW, for these who would want to check how this works, I added an option to the carpet mod in 17w38a release as /temprule calmNetherFires true/false which can be toggled and tested, but anybody who has access to the code or MCP, should be able to easily replicate this solution.
That seems reasonable. My objections about disabling fire spread on netherrack were mainly only if it didn't spread at all; having it spread slower seems valid.
I don't particularly like the way some of it looks but that's something that mojang can figure out (right now it's hardcoded as netherrack/magma/bedrock and ideally that'd be a method in Block(State)). The actual fix seems reasonable.
Does this still happen in 1.14.0? It shouldn't, because of MC-147818.
This report is currently missing crucial information. Please take a look at the other comments to find out what we are looking for.
If you added the required information and a moderator sees your comment, they will reopen and update the report. However, if you think your update to this report has been overlooked or you want to make sure that this report is reopened, you can contact the Mojira staff in Discord or Reddit.
-- I am a bot. This action was performed automagically! Please report any issues in Discord or Reddit
It may be valuable to look into what other blocks could benefit from a "lazy chunk margin" like this. Do sufficiently large farms also cause chunks to perma-load as farm blocks check within 9x9 areas for water?
One concern I have is that since fire blocks run on random ticks, where the fire block itself schedules each next tick, if we just return from updateTick, will the fire never tick again? It may be necessary to schedule another random tick and THEN return. (This still has to be before canPlaceBlockAt, which also checks neighboring blocks and therefore can load neighboring chunks if on a chunk border.)