Disconnecting and reconnecting shows black queue screen but you are actually still playing

[themoonisacheese]

Disconnecting and reconnecting shows black queue screen but you are actually still playing

[themoonisacheese]

yep, I'm aware. this is also why you need to join the proxy before the end of the queue. basically, when you first join a server normally, it sends you information about chunks near you. when you die/ teleport / respawn, the server sends this information again, in case you re-appear somewhere you haven't visited yet. when using this proxy, the server sends the information, and if your client is not there to record it it won't send it again. I had an idea to make the proxy just play back whatever the server sent before you joined, but that ended up being a problem because it was basically DoSing the client.

if you're near your bed when you discornnect/reconnect, you can indeed /kill to spawn correctly, but that's not necessarly common.

i'm not closing this in case someone would want to open the same issue, but tagging as wontfix for the moment.

[sijanec]

wait a minute, if the issue is by not getting chunks to the client, would pressing A while holding F3 reload the chunks?

If the proxy server relays all packets to 2b2t, chunks would reload.

I am currently still in queue so I will check this in 20 minutes, but it sounds as a useful fix.

If the "reload chunks" packet is not relayed by your proxy, it would be useful to add this feature, because of gaming with laggy network connections, such as mobile data, cause connection drops every so often. The connection drops and unexpected disconnections would be eliminated whilst in queue, but they would still be fatal in case of an in-game drop.

If it is possible to fix this issue, an antiafk packet sending by the proxy server would be really useful, because it would mean a non-stop connection.

[themoonisacheese]

pretty sure it doesn't work, i think I tried it before.

[sijanec]

because the proxy does not relay the reload chunks packet, i guess.

Edit: nevermind, every packet is relayed...

[themoonisacheese]

yeah, it's just that the server doesn't care??? it's pretty wierd, maybe it's just 2b2t that ignore those reload packets.

[themoonisacheese]

after some investigation, i'm pretty sure F3+A reloads chunks from client memory, so there's no packet that even goes out. for instance, I read a conversation on hypixel's forum in which the user was describing people spamming it to see through blocks before they were re-rendered. If a packet was sent, hypixel would have been the first to ban those users.

I will investigate to see whether there is a mechanism in place to trigger a chunk reload, maybe it is a separate packet from respawning, or maybe sending respawn packets can trigger them without actually being dead, i don't know.

EDIT: i'll look into: https://wiki.vg/Protocol#Client_Status, which apparently is used to connect and respawn. maybe the server sends chunk info when that happens regardless of if you're dead? we'll see.

if not, the only thing left is to actually store packets in the proxy memory, and while this is doable for chunks (it gets wierd really quickly as soon as you move from where you started), you get a bunch of issues once you start thinking about players and entities, who have to be spawned then moved, problems with inventory, etc...

for now, killing yourself is still the easiest way to reload chunks properly.

[sijanec]

Yup,

I asked the folksat #mcdevs and they told me that there is no "reload chunks" packet.

[Beaness]

I solved this issue on a project of me by adding recorded chunks to a list and when you join again it loops through the list and re send the packets.
EDIT: This is not a fix. You should listen for block updates, unloading etc.

[sijanec]

@SiebeDW SiebeDW: yeah, that's exactly what I did but I haven't yet committed to my fork. I have looked into your fork but I haven't been able to find where have you implemented that

[confusinguser]

I had an idea to make the proxy just play back whatever the server sent before you joined, but that ended up being a problem because it was basically DoSing the client.
@themoonisacheese

How was it DoSing the client? If you filter out the encryption, compression, etc. packets will it work then? I've made it partially on my fork of this but i have not tried it on the main world only in the queue and it seems to work

[sijanec]

Because he sent all packets, chat, particles, everything in 0 time.

I made a system that stores all chunk packets (only map data) in an array and when it detects /2b2w chunks, it sends them back to the client. Appearently I'm a noob and my message receiver function crashed the server when it received a chat, so I completley stoppled playing on 2b2t.

Hehe, I will try again, maybe sometime, but it worked with a web interface button. Just the chat function fu(ked it up, so I just quit.

So: storing all map packets (even when the proxyclient is online), wait for chat packet with /2b2w chunks, resend all map packets. You still won't get mobs, but you can just walk 8 chunks and get fresh chunks...

[confusinguser]

Wouldn't it be possible to store the latest position for every entityID and only send the newest packet so you get the right packet.

Also just sending advancement and recpie packet when the proxyClient connects is possible.

[themoonisacheese]

entities are updated relatively to their latest position. this means that you would have to keep a running total of their position to have their absolute position when the client connects. not completely impossible, but you can imagine it's not the current main development objective.

[themoonisacheese]

@sijanec is your code available publicly on your fork? i could try to see what's wrong and fix it.

[sijanec]

yes, please do.

[Rattlyy]

Mh, i think that you can fix it by requesting chunks again to the server

[confusinguser]

How do you do that? (F3 + A doesn't send packets if that's how)

[sijanec]

see my fork, but chat receiving system crashes the app. you can fix it and pull.

…

On Fri, 18 Oct 2019, 19:57 confusinguser, ***@***.***> wrote: How do you do that? (F3 + A doesn't send packets if that's how) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28?email_source=notifications&email_token=AKFM2EVHCFQHJNOQ7IGOOJTQPH2IDA5CNFSM4I2E5FZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBVKZZQ#issuecomment-543861990>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFM2ESQJMIKW73V326R6ZLQPH2IDANCNFSM4I2E5FZA> .

[qubard]

my project mcidle fixes all the issues described here

[sijanec]

Thanks, will give it a try! V V pon., 11. maj 2020 ob 05:13 je oseba cub <[email protected]> napisala:

…

my project mcidle <https://github.com/qubard/mcidle-python> fixes all the issues described here — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFM2ERV3UGT7RXTLVYBLBTRQ5UOZANCNFSM4I2E5FZA> .

[themoonisacheese]

While i don't really appreciate the advertising going on here, i have to concede that this project is largely dead and you're offering an alternative.
for anyone else reading this and considering using mcidle, please remember to use the same safety precautions as you would for any other program that asks you for your password, including 2b2w.

[MrGeorgen]

while reconnecting is not completely fixed, the new problems are better described in #148