Building and removing underground transformer results in different maintenance

[ceeac]

Building an underground transformer below a factory and subsequently removing the transformer results in a monthly maintenance of 6 credits with pak64 and bits_per_month=20. When building the transformer above ground, the maintenance is 0 as expected.

[Dwachs]

Here is a patch. The easiest way for me to solve this was to change the maintenance computation of underground power lines: different to before, now total maintenance is maintenance of powerline object (or transformer) plus that of the powerline tunnel. In order to fix the old implementation (maintenance is that of tunnel only plus that of potential transformer) much more work has to be done: one has to check that powerline tunnel destruction is such that the tunnel object is removed first, then the powerline object. I did not succeed in fixing this :(

[ceeac]

Replacing an underground powerline by the same powerline increases maintenance now; otherwise the patch looks good to me.

[Dwachs]

Fixed the patch, it is now in r9949.

[Mariculous]

May I ask if it was an intetional design decision not to book construction costs, maintenance costs and so on whenever an object joins or leaves the world aka is added to or removed from a tile (which exists in the world)?

I'm asking because I am currently working on a refactoring of way construction/destruction as the current design turned out to be difficult to maintain in extended (duplicate code everywhere, slight changes have to be applied to many locations in the code)
It seems sensible to me to add a virtual join_world/leave_world method to obj_t and call these in grund_t::obj_add/grund_t::obj_remove, but maybe there are reasons against it.

[Dwachs]

I think the handling of construction, maintenance etc at one dedicated place has its merits. The problem is that objects are placed on the map for two reasons: (1) some player builds them (or they are placed during world generation) or (2) when loading a savegame. Both cases update maintenance, only the first requires construction costs.

Most of the mess is due to the special handling of ways on bridges/in tunnels: such ways do not add to maintenance.

[Mariculous]

Yes, I had a few ideas about this and I'm currently evaluating two:
1. Globally disable book_construction_costs functions whenever the world is in save/load state. Or
2. On (de)serialisation bypass the grund_t methods (as far as I've seen this is already the case in many cases anyways) and book maintenance manually (using a virtual obj_t::get_maintanace method for sure, otherwise we will introduce new code dupes.)