At least no one from WS is chiming in.
Yep, see the same thing. Hard to say if it’s cause the people dressed much better than me in Europe have all gone to sleep or if it’s related, but it is very specifically around that time eh?
1 Like
If it’s a routing issue between the US and Europe, as the evidence above seems to point to, there’s probably not much Wonderstruck can do here—the problem likely lies on the ISP or backbone side
It’s crappy WS shouldn’t have to do anything, as a small-ish company.
Luckily the guys at AWS are crazy responsive. Worked with them before. If WS calls up and says “hey! WT_ is this?” they will get some help. Then AWS could strongarm the ISP.
Also a little worried that the “netcode” as you will may not handle minor packet loss though.
1 Like
minor packet loss is handled, as long as your latency is not very close to 500ms a few dropped packets will not cause rubber banding. I can’t call 75% packet loss “minor packet loss” though, and packet loss that high will just not be playable yes.
2 Likes
75% over tcp is terrible, agreed. Even 3% will shut your window size to unusable.
Earlier today when dropping a few packets here and there, that’s was what was causing the rubber-banding though. I think it’s because even losing one packet is causing ~360 or so ms of extra delay due to the RTT to Europe.
Probably 2 separate issues.
- We can’t connect now cause it’s really bad
- Rubber-banding.
Is there any reason why the client isn’t allowed to be more than 400 ms out of sync with the server? Well I guess it’s not my place to ask, and does distract from issue number 1. It’s something I do wonder about though, given the global scale.
1 Like
if you were getting really bad packet loss it may have dropped back to using tcp/websocket to send inputs, and then yes any packet loss would cause issues (it would show in the game log when this occurs, something about dropping udp and falling back to websocket)
but in the general case as I described earlier, inputs go over UDP and the client sends N last frames worth of inputs over UDP each prediction frame (every 62.5ms), and they have to get to, and be processed by, the server within 500ms of being sent for our max-allowed latency, that means that if your latency is say 300ms, then a single dropped packet would not cause a rubber band, because even if the UDP message is dropped, the next frame the client will send another UDP message that contains the previously dropped data as well so that the total time on the previous frames input getting to the server will be about 360ms (not 900ms like a normal tcp dropped packet) and still able to be used by the server.
the 500ms limit (realistically, about 400ms user-latency) feeds directly into how “responsive” creatures can be in their movements, as all attacks have to be projected ahead of time for client prediction to be able to work, so with 500ms limit, creatures project their attacks to the clients 1 second in advance, and if the limit was lets say, raised to 2000ms, creatures would start having to project their attacks 4 seconds in advance and they’d start to feel much too sluggish.
2 Likes
Yes I started having issues yesterday, it gets worse in places with any portals. I am in NA East, but i traveled to all but Aus servers and had the same issues… my wife is having issues with this today as well
Ah I see. That makes sense, I’ve seen this strategy (and an alternative NAK based approach) for UDP protocols in the past.
Any thoughts on just allowing the client to let us walk around and letting things catch up slowly on the server when the packets arrive? I think that’s how other games prevent rubber banding.
Also… is it worth having me look through my logs for more info? If so tell me where they are and I’ll be happy to provide the infos.
1 Like
Eu servers are still consistently unplayable most days starting shortly after or around 0130 UTC. Connection is fine, fine, fine, and then boom your character begins a grand-mal seizure lasting several hours.
Location: Central Virginia, USA, Comcast user