WCT doesn't open after reconnect
Nintai opened this issue ยท 17 comments
So i got a server running together with 3 friends and we are using WCT 0.1.32 in FTB Beyond 1.10.0-1.10.2
For the second time now, after i logged in i couldnt open the WCT. Sometimes u could see the window open for a split second, but it never stays. The only way i found to fix it is by placing the security terminal again and linking the terminal once again.
Well, does it work with the wireless terminal? We had some rare reports but nothing that could be reproduced.
You're sure it's not a power/channel thing?
I am unable to reproduce as well. I don't have the time to dedicate to this for situations where I would need to let a server run for a couple of hours. When I stop/restart servers with AE2/WCT I simply do not experience this. It seems to me that this has to be something related to chunk loading, user error, or mod interaction. I wish I could get a log specifically referencing either AE2 or WCT.
I can confirm this is happening to me as well, but this was after being on a server for a couple hours. This only started occurring once I left the range of my wireless thing. I had also had a time where I was crafting using the grid (Was trying to clear the config for ender io filter) and I shift clicked and it kicked me out of the gui and never let me reopen it.
ok..i'll load that exact pack up and try my best to reproduce...anything in log files on client or server about it?
Sorry i'm not playing beyond, I am playing Age of Engineering latest version also, after a weird crash (Not sure what caused it but it wasn't WCT) it fixed the WCT and I could access it. But for the original one I had when crafting the ender io filter, it has yet to work...
hmmm..yeah that wouldn't affect anything AE2 related (including addons)..i'll just have to try and reproduce myself...thank you for the report tho
Ok this is strange, after closing the game and then relaunching it and joining the same server. The wct I crashed with no longer works anymore. I am really confused.
Edit: This is really strange... I restarted the pack once again, and it works again... I am not sure what to make of this...
Forge currently has some bug(s?), which can cause data loss due to being not threadsafe, while pretending it. There are claims it might been fixed, but currently I would not trust it. It is way too complex to decide some small change suddenly turns a non threadsafe environment into a threadsafe one. It might not even be a single change, but simply the combination of sacrificing data integrity for performance in multiple areas. One feature potentially related to it goes back to 1.7.10 and the first reports of TE dataloss for AE2 did pop up a few weeks/months later.
Of course this case here might be unrelated, but if we cannot trust Forge to ensure data integrity, then it is pretty pointless trying to indentify something else...
Ah, thanks. This is what I was referring to. While reading over many issues in many repos from many mods, there is definitely something wrong since 1.7.10. TE data loss happens even in environments with only Forge+Mekanism or Forge+Thermal Expansion (I am only noting this because of recent reports claiming that only AE2/AL have this happening). There are a couple PRs that try to address this, but like you said, it is hard to believe this will indefinitely fix these issues. They seem to be more band-aids than an overall solution.
So, what I'm wondering is if this happens with only WCT, or with the AE2 Wireless Terminal as well. If @dmb1881 could make a normal AE2 Wirless Terminal, link it, and just store it somewhere until it happens with WCT, then do a check to see if the normal terminal is affected, it would help shed a least a little light on this, and in my opinion, confirm TE corruption rather than a bug in the ItemStack (which I believe to be highly unlikely).
Yeah. There are so many small and large issues. Ranging from corrupting a whole chunk to probably single TEs. E.g. when TEs are loaded by a hopper or so, it will see an validate() -> invalidate() -> validate() call. Should forge now also add threaded chunk saved and minecraft decides to throw away invalidate TEs...
But that happens, if you randomly backport bukkit changes for the sake of performance and just reverse engineer the code by guessing the contracts. Which somewhat works until it blows up.
I want to assume that itemstack corruption is unlikely. At least compared to chunk corruption. But I won't trust Forge at all currently. It might be enough for the player.dat to be loaded before the world/chunk with security terminal is loaded. Thus the key might still be undefined, but is then cached in the itemstack. (That is just a huge guess)
There is so much which can go wrong. E.g. Forge also accumulates TE instances, if no player is inside the dimension and all then tick once the moment a player joins. Which can lead to the watchdog killing the server. Or probably just skipping some ticks, which then results in something like the previous load player data before terminal.
What just comes to my mind is the share tag for itemstacks. Because we have some issues with it. When moving items between ME and the player, we only use the vanilla/forge helpers for it. Which will only synchronise the sharetag. But some baglike items (botania flower bag) seem to use the clientside data not the server side. Should this somehow get transfered back to the server, it might purge the nbt tag of the affected itemstack.