Note: I, with notable probability, will make myself the missing Lua API, but hardly will enhance the client editing interface.
Common note for all API sub-tickets: each call to a separate editing function requires sending packets to clients. It looks like the packets won't be glued together by the net buffer, so, if you add 10 buildings to a city and rename it, you send 11 packets. That is less effective than client editor mechanism that gets a single special edit packet, changes its fields and sends it back, then update happens once for one object. What can be done:
a) We make classes for editing packets, append to each game class server API :edit() method that loads one into Lua memory, then we edit it and use :apply(X_Edit_Obj modified). Obvious pluses: easy to make, one edit object can be applied to several cities etc. Minuses: the API is inopaque and more visible edit methods must be done separately.
b) Make it possible to freeze dispatching info to clients from Lua code, force to unfreeze back when a callback ends. But developing single methods (and coding some other stuff) is mandatory, cloning needs a special mechanism, and a ruleset author easily forgets to use freezing before overwriting the whole map.
I currently incline to (a) but maybe some parts of (b) may be also done if it proves easy enough.
This (along with other related tickets) is currenty targeted to S3_1-d3f. There has been no progress in many months, and even if there was, we've already been postponing even active S3_1-d3f tickets to S3_2-d3f, when the changes have been deemed too big/risky compared to how critical it is to get that change to 3.1.
Correct me if I'm wrong, but there's no regression in S3_1 compared to 3.0 that this work would fix. Nor is this crucial for completing some other S3_1 development. Is there some other good reason to keep this blocking S3_1-d3f? At the moment I would be inclined to postpone all these tickets to 3.2.
Well, actually, there is not that much work, and some unit editing is already done... but I am not sure I'll do anything here in a predictable time. Probably we should postpone it.
Client editing mode and Lua edit methods work basically in the same moments. So we have a code to edit the game but part of it has one interface and another part has another interface, and not all possibilities are represented in both ways. Maybe some code under packet processing and Lua API is unnecessary doubled.