Ticket #42501

Align Lua and client editing functions

Open Date: 2021-06-10 02:44 Last Update: 2021-08-03 00:13

5 - Medium
5 - Medium


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.

Ticket History (3/4 Histories)

2021-06-10 02:44 Updated by: ihnatus
  • New Ticket "Align Lua and client editing functions" created
2021-07-31 02:56 Updated by: ihnatus

Added sub-tickets #42681 #42682 #42683 #42684. Also, may be considered depending on #42502.

Editing scenario strings by Lua may be considered not useful so no ticket for it here. Maybe we should also have a function to set game year that is not in mentioned tickets.

2021-07-31 07:32 Updated by: ihnatus

Note: I, with notable probability, will make myself the missing Lua API, but hardly will enhance the client editing interface.

2021-08-03 00:13 Updated by: ihnatus

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.

Attachment File List

No attachments


You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login