GDFireFrog

Sorry we made you worry :) The patch had been ready for a bit but we had some last minute server issues stopping us from publishing.

There was an issue related to those stairs that should be fixed in any new games started in a few minutes.

Sorry, it should be fixed now.

Bit of an update on our UI issues for the sake of transparency. It's really frustrating not to be able to help people with issues, but specially people with crashes. Normally if there's a crash going on that can be reproduced then it's maximum priority and nothing else is worked on until that's fixed, but this is assuming it's in our control to do so.

Crash when loading maps/leaving games

There is a crash on Gameface happening around the time a game starts or ends. Gameface is the HTML engine we use for rendering the menu interface, made by Coherent. It happens more consistently for some users for w/e reason we haven't been able to surmise and it's most likely the crash you are experiencing. Supposedly they fixed this crash about a month ago but their update with that crash fix introduced a severe performance regression that slows the game too much, and this regression has been present in the 5 new versions released since, so we've been waiting until they f...

Should be done for next version, yes, but not sure about 8 hours :) sometimes testing/last-minute fixes extend very late into the morning. (Also going to link to this previous comment by me here again about the team and attribution: https://www.reddit.com/r/Diabotical/comments/jdchvw/patch_notes_version_020380_october_17_2020/g9dceii/ )

If you are still getting some freezes you must be incredibly laggy. We'll increase the threshold again when we've had the change to normalize extreme warping and test it for a while, but for now it's probably already too generous. But also: do you know why your connection to our servers is so bad? If you DM me I can tell you how to do a trace to the servers you are playing in and we may a routing issue that we can fix.

Are you in a very low spec PC that struggles seriously when spawning? We have some optimizations for that coming soon that may make that go away if that's the case. For now I have added a grace period of 2 seconds to the start of each life, that should get you over the bump and not enter the 5-second recovery wait period. I've also added the same at the start of every round and game just in case.

I've pushed this to servers, the fix should be available for new games in 10 minutes.

Sorry about that, we are adding a lagometer today and that will allow you to see the peaks that were causing the issue (hopefully with the latest threshold increase you are not getting frozen anymore anyway). Nonetheless, the threshold was already set quite high and I'm guessing you, like may others, have pretty substantial hiccups in your connection for you to be freezing that much, even with the old threshold. I was testing the game yesterday with a few people who were having freezes and they were quite warpy and just they didn't realize it. But this is on us for not adding the lagometer with data that people can see for themselves before introducing this option.

But if your opponents still were still finding you playable, it wasn't our intention to address your level of warping in this way. The freezing should just be for half-dead connections, there's an intermediary level of warping between the point that we remove reconciliation and the point where we freeze people th...

(Don't like to comment on this sort of thing but I know the kind of thing you are talking about, and although I've been in that situation, that's truly not the case in this team. Specifically two other guys who are shy and don't like to be named work with me every single day, very long hours, even though I've told them repeatedly that I can manage some days by myself.)

Before you give up, there are plenty of things we can do to make this better. You are probably just getting very intense isolated spikes periodically. Not enough to make you think you are lagging or annoy your opponents but enough to trigger the detection. If you don't mind DM'ing me on Discord I'm happy to take a look at your transit and see if it's possible to safely filter out your particular phenomena. We can always roll out something experimental in your region's servers, too, if we come up with something that doesn't feel completely safe. But in general let me be clear that we are not happy with how the feature works currently, and we will be prioritizing this because we really dislike regressions.

(For the record we really do care about all regions, and in fact allowing SEA and Oceania people to play with each other is one of the reasons why I'm trying really hard to make this work with a rather high amount of reconciliation.)

I pinged your network from one of our Rotterdam servers and the latency looks about right, at least in this direction. What server are you getting high ping on and what ping? If you DM on Discord we can look into it. So far when it comes to the servers hosted with i3D they have been able to address any routing issue we bring to them, we just need a trace to identify it.

The detection part is in fact quite conservative, it doesn't trigger unless there's a massive spike, the kind that would cause annoyance. There is a particular edge-case (there could be others) with people who have mostly perfect connections but they get an intense lag every so often. This kind of issue is actually common, may happen due to some faulty equipment along your route to the server, so we will consider some potential solutions to make this less annoying while not annoying others.

For now we have reduced the time that you are frozen after this event.

We've added it to the controls screen.

We are aware of this and we'll be doing something about it at some point.

Well, we have always had extrapolation, technically, or the game would be very warpy, just not in the normal sense that people mean when they say something like "this game's netcode has extrapolation."

There're two different kinds of extrapolation here, let's name them "reconstructive extrapolation" and "predictive extrapolation". With reconstructive extrapolation you are only extrapolating in response to discontinuities in communication in order to no have to stop the player in the air for an instant like many old games. Here you are just trying to fill in a gap before new data arrives. This extrapolation is not speculative as long as network conditions are OK. Then there's predictive extrapolation where you are speculating even ahead for gameplay purposes. This is the kind that is most susceptible to what's called rubber banding though hopefully we can keep this to a minimum when we implement it.

There's a very simple fix to apply here that doesn't involve rethinking much of the netcode. Players who are lagging in that way should simply lose some or all backwards reconciliation privileges. We'll test this and try to find out some sensible thresholds for when to trigger this condition and how long to maintain it after a lag episode and put it in the next version later today (0.20.380). We will add some kind of on-screen notification so that the lagging players are notified of this state and they understand why their rockets are going through things now.

This is just a fix for this lagging scenario (and it should have been pretty obvious that we needed to prioritize this earlier, sorry). There are other general improvements coming soon that will improve the situation with projectiles+high ping. (Our focus so far has been to make sure people can hit on the server-side netcode, now we need to make sure some people can't hit). The following things will also address the s...

Nobody who is able to reproduce the issue has come forward yet. The person who reached to us initially stopped being responsive. This issue is probably not up to us, it's likely in one of our 3rd party dependencies, which is why we need to pinpoint it. If you have the issue, or anybody who reads this and have the issue wants to help us fix it, feel free to DM me on Discord, I'll send something for analysis and we would be able to locate where the issue is.

Yes, getting reports of this, we are investigating. A user from reddit who reached us is running some tests to locate the issue and we are waiting for results back. It may expedite a resolution if you wanna DM me on Discord and also run some tests.

We have some UI-related stutters left that we know about. We replaced Gameface with a custom HUD engine for most of our hud elements because the performance wasn't good enough to preserve a smooth experience, but there's a few things that we are still using this product for, for some reason or another (kill feed, crosshair, chat, announcer text messages and other stuff I may be forgetting now). Even though these are very simple elements sometimes Gameface will block for excessive amount of times when updating the view with these elements. Your 1-2 second stalls are very severe, but I'm not surprised these stalls manifest magnified in some systems for some reason or another, the spawn timing matches up with this since the Gameface view is active at around that time. Hopefully sometime soon we should have an update mentioning getting rid of some stutters related to UI rendering, which will mean we have completely gotten rid of those remnants of Gameface usage completely during gamepl...

Just to clarify, there's actually no theoretical barrier to solving this in modern compensating netcodes. We are testing a few things and I'm sure we'll be able to make this specific problem go away, it may just require a few patches worth of tweaking at first. There are some issues that are matters of trade-off and unfortunately can't be solved to everybody's satisfaction, but this isn't one of those. Just so you see it's not really an unsurmountable problem, consider the following simple blunt solution that could be in the cards: "if a player is lagging a lot, opponents gain full client-side prediction against said player". Any game could implement that.