Closed giorov closed 2 years ago
mixed repeats of the following errors:
If I disable Bobby but leave Sound Physics in I get this log (much, much cleaner)... latest.log
Well. Bobby seems to make the game think that chunks, which are not loaded yet are "full" (means fully generated and loaded). Without Bobby, there are no SP errors.
Well. Bobby seems to make the game think that chunks, which are not loaded yet are "full" (means fully generated and loaded).
No, no it doesn't. For one, there is no "generated" state on the client, it's either loaded or it isn't. But more importantly, it is loaded (as evident by the fact that the game can render the chunk, you can look at it, and if you can reach it, you could even interact with it). The reason Sound Physics dies is because it assumes that the only way a chunk could ever be loaded on the client is through a packet, which simply isn't true once you consider Bobby (cause that's the whole point).
To spell it out: Chunks loaded via packets use the first constructor, which passes a bunch of dummy values to the second one, and then call the method to fill in the chunk from a packet. Chunks loaded via Bobby use the second constructor, already passing fully valid values. So it doesn't need to load from a packet, and it can't cause there is none.
Without Bobby, there are no SP errors.
Without SP, there are no errors either. That doesn't mean anything. Especially not for compatibility issues.
(just for reference: https://github.com/Johni0702/bobby/issues/65)
Thank you very much! Since it is that easy to fix, I will in an upcoming release. This block caching brings 6x performance improvement, so if you don't mind, you can use a previous version.
I have the same issue, invisible chunks that never load. When I check the minecraft log it has a bunch of errors like
[19:42:50] [Render thread/FATAL]: Error executing task on Client java.lang.NullPointerException: Cannot assign field "xm" because the return value of "com.sonicether.soundphysics.performance.WorldChunkAccess.getNotAirLiquidStorage()" is null
a lot of them.
I thought this was fixed by Vlad ages ago, but as i can confirm it has not been, I will fix it before the next release
@Johni0702 I'm struggling a bit with this.
So from what I've gathered, the client always calls loadFromPacket()
when loading chunks, except for when loading Bobby cached chunks, which come from the client's memory instead of from the server. Since these chunks are not Intitalized with Sound Physics, any time the game tries to load an adjacent chunk from a packet, the Sound Physics code causes it to fail and exit, which causes the chunk not to load properly in more ways than one.
So, the only thing I would need to do to fix it is to find a function that is called when loading both normal and cached chunks, and mixin there instead? Is there something I haven't considered? Is there an assumption that i made and shouldn't have? Is my logic flat out wrong? Or did i somehow manage to make sense of this issue?
Either way, i need some help figuring out how to fix this problem, if no other reason than a lack of confidence and experience. I'm outside my area of expertise here, and I'm struggling to make sense of it all. Any help is greatly appreciated. Thanks!
I don't think there is such a function. You can try adding a variable "initialized" and copying the load-from-packet mixin over for the constructor. You can only mix in at constructor END and TAIL, so uninitiated stuff shouldn't be a problem.
I don't understand everything you're doing in there but if we simply treat it as a black box, then yes, easiest way is to just move all that code into a separate private method and call that from both, the constructor (though only if chunkSections isn't null, cause if it is, then loadFromPacket will definitely be called later) and loadFromPacket.
I don't understand everything you're doing in there but if we simply treat it as a black box, then yes, easiest way is to just move all that code into a separate private method and call that from both, the constructor (though only if chunkSections isn't null, cause if it is, then loadFromPacket will definitely be called later) and loadFromPacket.
After trying to understand how palleted storage works, I just treat it all as a black box. Doesn't decrease performance anyway.
You can try adding a variable "initialized" and copying the load-from-packet mixin over for the constructor.
So moving the mixin to the shared constructor should work, then? Is it really that simple? I will test this later today or tomorrow
@thedocruby No. The whole point of not doing that in the first place because an empty constructor is called when you load from a packet. May work if we overwrite it IMMEDIATELY after or indeed do some checks.
Okay, well can you do this? I am struggling
I made a draft, but have no way of checking it. Pleas fix the material settings so that I can commit it.
Okay, on it
Sorry, i keep hitting "close with comment"
@vlad2305m You're good to go with the drafts, be sure to pull before you push.
This has been fixed in the latest release
When I have this mod and Bobby mod on at the same time, chunks fail to load properly.
Happens most severely online, on Wildercraft for example.
In SP it's more difficult to reproduce.
log from a session online and a session offline.
latest.log
Here are interesting errors/warnings I got in online portion of that logfile: