@hamuka, I think we’ve fixed (or at least drastically improved!) this issue. There were two major problems in our code:
- The way we were tracking node recovery resulted in a discrepancy of 50ms between when the client thought nodes should recover and when the server thought nodes should recover. This resulted in the server deciding that a packet was stopped by a node when the client thought it should pass through. We made the method of recovery tracking properly identical on client and server.
- There’s a rate limiter on how often a splitter node will split in a certain orientation, to avoid unbounded packet multiplication. Since an earlier timing fix, the server has had this limit at 200ms and the client has had it at 0.2ms. The client’s cooldown has been increased to 200ms.
Change #2 has a slight chance of making some old solutions not work and a tiny chance of rendering unsolvable previously-working systems that depended on splitter spam. I don’t see any existing systems that should be a problem, but let us know if you run into that.
And let us know if you get more invalid solutions or unmatched durations. We’ve added some instrumentation that will make it much easier for us to diagnose those in the future.