NoXray is loading unloaded chunks causing performance issues

[bloodmc]

http://i.imgur.com/R0PTba0.png

[thomas15v]

Yeah, the problem is that I need to know the block next to the chunk. I am using the SpongeAPI to read the block next to it. This was one of the first problems I had to tackle since chunks can only obfuscate when they are being send to a player, and not on load.

I don't really know another solution to this, unless I can just read the chunk without actually loading it.

https://github.com/thomas15v/NoXray/blob/5e5f0835835185757273532c56b12e7f87da029d/src/main/java/com/thomas15v/noxray/api/NetworkBlockContainer.java#L133

[bloodmc]

@thomas15v hop on spongedev on irc.esper.net

[bloodmc]

As discussed, obfuscate any ores at chunk borders then handle them when the surrounding chunks load and update if necessary. This avoids doing 2x the work as the player cannot reach the ores at edges without loading surrounding chunks.

[thomas15v]

Adding IRC conversation as reference for later:

<thomas15v> blood_ I am here
<blood_> so
<blood_> The way it should be working is the server adds a chunk to the PlayerChunkMap, loads it, populates then and only then it should be constructing a SPacketChunkData to send to the player. However, it seems you are checking "surrounding chunks" for some reason? A player should never receive a chunk unless it loads on the server side first so I don't see why you would check this.
<blood_> basically you are loading chunks outside of a player's view distance
<thomas15v> I know
<blood_> why?
<thomas15v> If you have an piece of ore, on the chunk border
<thomas15v> I need to know if the block next to that ore, is air or not
<thomas15v> It could even go this extream as an entire wall of ore on a chunkborder, I can't simply ignore it
<blood_> what if the chunk wasnt populated?
<blood_> how would you know
<thomas15v> Ehm
* Spottedleaf (~Spottedle@d108-180-66-178.bchsia.telus.net) has joined
<thomas15v> Idk actually lol
<thomas15v> It just happends to work kinda fine, I suppose sponge generates the chunk if it isn't in their
<blood_> so why do you need to know if the block next to the ore is AIR?
<blood_> some xray logic?
<thomas15v> Yep
<blood_> why not just prevent ores from generating at borders?
<blood_> or raise the server view distance
<blood_> and have players be 1 less
<thomas15v> Because than I have to alter the ore generation
<thomas15v> I want to keep it as simple as possible
<blood_> loading chunks is just a bad idea
<blood_> but let me look
<thomas15v> I could skip the obfuscation of that area and update it later
<thomas15v> but if you have a smarter xray mod
<thomas15v> it could prevent ore updates and bypass it
<blood_> so why not do this
<blood_> just obfuscate it and update it once the chunk loads?
<blood_> because when they reach that point, the chunk would have loaded
<blood_> then you can simply update it if you were wrong
<blood_> or do nothing if it was supposed to be blocked
<thomas15v> That could work
<thomas15v> Altrough it adds some extra complexity
<blood_> it is better than loading a ton of chunks
<thomas15v> Indeed
<blood_> just to check a single block
<blood_> any of those cases, block by default
<thomas15v> I do think they unload themself eventually
<blood_> then update accordingly
<blood_> because the player will never be able to reach those borders without the surrounding chunks loading
<blood_> this also covers chunks not populated
<blood_> and make sure you account for worldborders
<blood_> well it wont matter actually
<blood_> they cant get through that anyway
<blood_> but yea i think that is a better solution
<thomas15v> I kinda still thought the getBlock function worked like the bukkit version 
<blood_> what are you trying to do?
<blood_> with getBlock
<blood_> just get the state?
<thomas15v> Yep
<thomas15v> But I thought it wouldn't load the chunk
<thomas15v> because bukkit also doesn't do that
<thomas15v> It just reads
<blood_> reading is just worse
<blood_> read it when it loads
<blood_> or you will do 2x the work every single time
<blood_> for no reason at all
<blood_> let the chunk load naturally then handle it then
<thomas15v> Ye I will just hide it, and update if I know for sure it can be visible
<blood_> yes that is best
<blood_> also the chunkprovider has its own method for checking if a chunk is loaded
<blood_> sec
<blood_> https://gist.github.com/bloodmc/a9cbfb896dba18694d87befc0cb5f9e2
<blood_> use that when you are unsure
<blood_> because if you access a chunk that is queued for unload, you essentially stop it from unloading
<blood_> i should add a method in API for this
<blood_> but for now just use that
<thomas15v> Alright
<blood_> if that returns null, it isnt loaded
<blood_> if it returns a chunk, make sure it isnt marked for unload
<blood_> chunk has an unload flag
<blood_> any other issues you have?
<thomas15v> Not really, except barely having time to code on it xD.

[heartsemma]

You're forgetting something. If a player does not have the surrounded chunk loaded, the player cannot possibly be looking at the chunk from that direction. So you don't need to check if there's a block or not on that side. It wouldn't matter anyway. The player isn't there and they can't see from that direction.

Don't obfuscate until the chunk behind it is loaded; check whether or not there are blocks surrounding it inside the loaded chunk. If there are blocks surrounding it in the loaded part, the player can't see it. After all, the player is in the center of your image there.

[thomas15v]

Yeah we already have a solution for this, like described above. I remember having a semi-working solution already. I try to code on this plugin tonight.

(it's hard to get back to coding after an entire day of coding at work :( )

[Mohron]

This also cause World Generation lag:

>  [19:56:42] [Server thread/WARN] [FML]: NoXray loaded a new chunk (40, 30  Dimension: 0) duri
ng chunk population, causing cascading worldgen lag. Please report this to the mod's issue trac
ker. This log can be disabled in the Forge config.
>  [19:56:42] [Server thread/WARN] [FML]: NoXray loaded a new chunk (40, 32  Dimension: 0) duri
ng chunk population, causing cascading worldgen lag. Please report this to the mod's issue trac
ker. This log can be disabled in the Forge config.