Closed inklit closed 7 years ago
Yeah I noticed this while implementing the random modifier, figuring out if the block should be visible is one of the major performance issues I am having. It takes about 530ms of tick time for new chunks, and fast travel can bring a server on its knees in no time.
Wich technically means that I already have addressed this issue, but implemented it very poorly.
I see, maybe you can ask some Sponge developers for some insight on performance. @bloodmc comes to mind since he does a lot of optimizations in Sponge but maybe there is a better person to ask.
Fixed in 82fab2095222325a75a7e05de405add74eba6ac9
Sweet. Just a note: You should use a profiler such as WarmRoast or YourKit (you can get a free license by emailing them about your open source project)
I am using VisualVM, and it is working fine enough for me :smile:.
Also this is fixed for the next release. So not a hotpatch.
Sweet, any ETA? I'd like to test it as soon as possible on my server. Not sure of the branch you are committing to is ready for testing.
Well I have a jar that works, but the modifier is hardcoded to randomized. https://drive.google.com/open?id=0B4cT1XPmcnpKeG85dVJzNEhQSk0
I'll test it out later, thanks!
Blocks that have a smaller hitbox (or transparent) will hide ores directly behind them until a player breaks the block.
Go into a mine shaft to see this issue in it's prime. Ores behind fences, that players should be able to see, are masked by stone.
I can think of two solutions to this: Check for abnormal hitboxes or transparency and consider them air. Only start hiding ores 3 blocks away from air instead of 1 block away from air.
The best solution is the first one, but either of them will solve the issues that players have been experiencing on my server.