Chisels & Bits - For Fabric

Chisels & Bits - For Fabric

2M Downloads

Client-server desync when committing BitAccess changes via API

Phylogeny opened this issue ยท 14 comments

commented

I've noticed this for some time (in multiple MC versions), but since my computer isn't the best, and since no one ever complained, I just ignored it. But with SF3 inclusion, I decided to look into it. To make things easier, rather than dealing with EBM, I made a test mod with only relevant code in it (for MC 1.11 & 1.10.2): https://github.com/Phylogeny/ApiTest/releases (the test tool is added to the C&B creative tab).

Not only does the desync require a block update to fix, but after a while, all newly create blocks stop rendering. When that happens, relogging causes all blocks to stop rendering after an update (even in newly created worlds), and can only be fixed by restarting the client. I've used the test mod in 1.11 and 1.10.2, and it occurs in both (and for multiple Forge versions). All this is demonstrated in this video:

https://www.youtube.com/watch?v=5cO9ZJ5RwcI

I just don't know how much of this is due to my computer, the API, the way I'm using the API, or my code in general. I'm hoping you'll notice something I'm doing wrong in the test mod, so I can make the appropriate changes in EBM.

commented

I wonder if there is a missing render update trigger in there somewhere, or something else is going on, I did a cursory glance over the code, I didn't see anything wrong with it.

So I'll go ahead and assume theirs some sort of bug in C&B related to it. I'll try and make some time to look into it tomorrow,

commented

When this builds could you give it a try?

https://dvs1.progwml6.com/jenkins/job/Chisels-and-Bits/71/

I think that it should fix the issue, the API wasn't calling into the Dynamic Renderer to update, I'm surprised its gone on this long, especially since your mod can create such complicated blocks.

Let me know if you are still experiencing any issues after that.

commented

Yeah, if it weren't for my laziness/denial about this I would have had the sense to bring it up ages ago.

So, I would break this up into 3 parts:

  1. The desync that require a block update to fix (including failing to render entire block faces)
  2. The flash of total transparency that occurs when converting a block into a chiseled block.
  3. The disappearance of most blocks in all worlds after enough blocks have been chiseled, requiring a client restart.

This build fixes [1]. It's does not affect [2] and [3], but I'm guessing they have to do with memory settings, since on SF3 (even without this fix, since it's 1.10.2) the flash is shorter in duration for [2], and [3] never happens even when an enormous amount of blocks are chiseled.

It's weird that [3] persists across worlds and requires a client restart, but perhaps it's unavoidable. Perhaps [2] is also unavoidable, but avoiding such things is the goal of running the code on the client then the server in the first place.

Anyway, if there's nothing to be done about [2] and [3], then I'll definitely consider this issue resolved (I'll still verify it works for 1.10.2 when that build is released, but there's no reason to think this fix won't work for it as well).

commented

[2] is the switch between renderers, the blink of transparency is while the blocks are being rendered and after they have been removed from the static renderer. Since C&B's renderer is async the frames between rendering and the removal of the blocks from the static renderer appear transparent.

I might look into it again however, but I don't have time tonight, your debug tool reproduces it much more exaggeratedly then my usual testing.

[3] I'm not sure about, I chiseled and chisled for some time not getting any sign of the bug. What video card you are you using, most usefully how much V-Ram does it have.

Also are you using VBO in your video settings? I'm probobly going to have to look into that further, trying to figure out a way to reproduce it on my end, or at least puzzle out what might be the cause.

At this point I can only think that it might be a V-Ram Leak, but i'm not sure, I'm fairly certain that they are cleaned up, but perhaps there is a bug.

PS: Your correct, that the fix applies equally to 1.10 and 1.11

commented

Yes, I am using VBOs. As for the graphics card... yeah, I should probably get one of those. I just have basic integrated graphics ("Intel HD Graphics 4000").

commented

Alright, I'll try and reproduce tomorrow, hopefully what I have will reproduce the issue, I honestly don't know how it compares, but its integrated intel, so probobly not far off.

commented

Sounds good.

commented

[3] After some research appears to be some sort of terrible GC Race condition.

Could you give https://dl.dropboxusercontent.com/u/9117298/cb/anti-builds/chiselsandbits-13.X.jar a try, I haven't been able to reproduce it with this build, thought I must admit I've had trouble reproducing it reliably.

commented

Yeah, thats the plan.

commented

Yes, that build fixes [3]. Very nice! Also, it would be great if these fixes could be bundled with the upcoming 1.10.2 build that will have the key binding API fix.

commented

I just tested the changes you made in 73efa32. Excellent! It works perfectly on my end.

All three parts of this issue are now completely fixed.

commented

Good to hear, I had forgot to ask about that, it seemed to fix it readily on my testes however so I guess I figured it would work well enough on other machines.

commented

If you could also verify https://dl.dropboxusercontent.com/u/9117298/cb/anti-builds/chiselsandbits-12.X.jar fixes all the issues, as well as has no issues API wise on 1.10.2

commented

Alright; I've tested the API fix and all components of this issue on 1.11 and 1.10.2 for EBM and for the test mod in the dev environment, from the vanilla launcher, and in SF3 from the curse launcher.

It all works perfectly in every case.