While I was making my first level cluster for this game, I’ve found several bugs of all shapes and sizes. Some of these no one mentioned before, while others are issues that were declared fixed in the past.
Anyway, let’s begin.
Some nodes appear to remain on the board even after being deleted. However, this is not actually the case: you can place other nodes on the deleted one (making for some weird 10-point star-like formations), and the deleted node disappears upon testing. Mostly a cosmetic bug.
On random occasions, the created system refuses to save, even if I get the pop-up saying that it did save. I had to remake some systems 5 times before it managed to save the system.
I’ve recently started getting the “error saving solution” message (the first one, a.k.a. declared duration doesn’t match simulated duration), mentioned a month ago in this thread. For now, this error has only appeared on a single public system (this one), but it can still be a pretty serious problem.
Will post here if I find more of these issues.
EDIT: Now I have the plain old “solution is invalid” error message as well. Sad face.
I’m able to duplicate the issue you’re seeing with “Some shifty fun.” If I had to guess, I’d say we either have an issue with precision timing in splitter loops or some edge case where a packet encounters a node that’s recovering nearly simultaneously.
We’ll look into this, hopefully with the help of some extra instrumentation. It may take a week or two to track down. In the meantime, complex systems like that one might not be reliably functional.
@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.
