And by default have them locked! and unlock by command, by zone, and even by layer type.
Why?
Because there is no "undo" and layer edits are extremely volatile.
To speed testing by granting use of admin commands to testing team but avoid accidental layer edits (its happened enough times to where it is a problem - no amount of training or explicit instruction has managed to avoid this even with expert users)
One caveat, I suspect the client is editing its local layer and sending data to the server and not relying on a response to render/persist the changes made.
So not only kicking back an error on SetLayer command but perhaps sending back the static layer data for the cells/Area updated. (I think this strategy was used for the out-of-bounds layer edits too)
And by default have them locked! and unlock by command, by zone, and even by layer type.
Why? Because there is no "undo" and layer edits are extremely volatile. To speed testing by granting use of admin commands to testing team but avoid accidental layer edits (its happened enough times to where it is a problem - no amount of training or explicit instruction has managed to avoid this even with expert users)
One caveat, I suspect the client is editing its local layer and sending data to the server and not relying on a response to render/persist the changes made.
So not only kicking back an error on SetLayer command but perhaps sending back the static layer data for the cells/Area updated. (I think this strategy was used for the out-of-bounds layer edits too)