Overloaded from Scute - Make all triggers process server-side first
A partial rebuild is in order due to the nature of trigger chains.
If a player has Kor Celebrant (+1 Life when a creature or token enters the battlefield) and mutated Auspicious Starrix Scute its all too easy to start a cascade of triggers. The scute clone alone isnt the issue, its that on each clone it triggers Kor separately, causing timeouts to be used (should never happen when triggers are resolving!) but it starts bugging out; it lost count of the cloning, stopped triggering Kor (no life gain where there should have been) and ultimately the client had to be restarted. I was able to resume, but future Scute cloning did not trigger Kor. (The on board counts of the clones were also off. It started reducing the number of real clones, replacing them with new ones, not simply adding, even though they were really there, just hidden.)
There needs to be a fundamental change on how triggers are processed. They need to resolve ALL triggers at once unless theres an opportunity for a player to play an instant/sorcery. It should also be done server side because my 3090, AMD 5700 couldnt handle it. Once evaluated server side, the client should have an option to animate the triggers, OR to disable them.
Secondary triggers cannot interrupt a large trigger series, ie. 100+ Scute because it causes timeouts to be used and locks up the client.
It became apparent when my client crashed that the unfinished triggers never processed (when I restarted and resumed the same game). Had they been processed async server side then synced with both players it would have been a non-issue.
The backend server needs to handle gameplay effect not just to ensure triggers work, but to avoid cheating. If the server accepts game state from a client, then a client could potentially send a false game-state. If this worked like a remote desktop - processing done server side, visuals processed client-side (if the user does not disable them) that would be a non-issue.