City mergers

[neroden]

Neroden,

thank you for your feedback. It seems that a full system as I had originally described might be a bit much for a computer to handle with reasonable performance. Perhaps, however, the idea of using route fragments can survive in a simplified form: as now, we could just calculate city to city routes, and use the existing non-routefinding method to guess the speed of intra-city routes. The inter-city routes, however, could use route fragments in the same manner as I described in the original outlining of the application of this concept; the inter-city routes would be stored, and, whenever a pathfinding algorithm steps on a tile with a route to the same destination, it would stop looking and just append the remainder of the route to the end of the route found so far. Any thoughts on that method? In particular, is there any good use to which the information as to teh amount of traffic using any particular route could be put...?

As to city mergers; traffic under the new model is an interesting one. It might be possible to detect whether one city is contained within another for the purposes of traffic (check whether a town hall's city road is contained within the confines of another city, although that might require iterating through the whole city list for each town hall road), but the mergers idea is an interesting one all the same. The other thing with cities in Experimental is electrification - it might be tricky and unintuitive to have to have a separate substation in a city entirely contained in another city. Are you volunteering to code it...?

I could probably code city mergers -- it seems relatively straightforward actually.  It'll take me a while to decipher the city code though.  Here are my design thoughts:
1 - merger is only triggered when the 'larger city' tries to expand its city limits.  If it then contains a smaller city entirely (compare city limit boxes, I was thinking), the merger triggers.  Alternatively, it could trigger when it surrounded a town hall -- this would require that the larger city then expand its city limits to contain the full city limits of both original cities.
2 - If someone tries to build a smaller city entirely inside a larger city, this should simply be refused, or better, replaced with an "enlarge city" order.  There might be some trouble hooking this into the initial city generation code.
3 - Any open windows for the smaller city, the one going away, are forcibly closed.
3 - The smaller city is then systematically "destroyed" -- each of its buildings and monuments is transferred to the ownership of the larger city, each of the industries in it is transferred to the larger city, each of the road tiles (if they're tracked) is transferred to the larger city, each industry which gets workers from it is disconnected from it and connected to the larger city, it's removed from all databases listing cities, et cetera.
4 - The population and related numbers of the larger city are increased (if this hasn't already happened as a side effect) by the former population (etc) of the smaller city.
5 - The townhall is demolished and replaced with an appropriate monument ("Former Town Hall" I suppose) -- this is the only bit I'm really unsure how to code.
6 - The city objects, now disconnected from all databases, are garbage collected.  The graphs and historic data for the former city are simply thrown away.  If there is any leftover non-updated reference visible to the user, it is pointed to an "invalid city" response.

Stations would retain their "historic" names.

Mod note: Split topics from the "new feature - performance issue" thread for clarity.

[sdog]

what happens to player owned houses? are they already becoming unrelated to their cities when bought?

[jamespetts]

Neroden,

thank you for your thoughts on city mergers. One or two comments. Firstly, you forgot about substations: in Simutrans-Experimental, substations are associated with cities, too, so these would have to be transferred to the new city if they are in the original, surrounded city. Secondly, with cleaning the databases, you'd have to go through all the other cities and delete all the private car routes to that city in the hashtables for the new system described in this thread. If I code a different system again to overcome the performance issue, it would have to fit in with that new system.

Secondly, instead of destroying the old data, ought some thought not be given to merging them instead (i.e., adding them together)? A player would need to know the combined population growth, etc., rather than losing all knowledge of the smaller city.

Thirdly, do we need to demolish/replace the town hall - can't we instead just add a flag to town halls called "deprecated" and cause them to give different behaviour when clicked on? That way, pakset authors would not all have to code lots of new buildings with the same graphics as "former town halls". We might then consider - optionally - adding a parameter for pakset authors to specify alternative graphics for a town hall taken over in such a way, perhaps by having signs outside indicating that it is now a museum or aquarium.

Finally, SDog's point will need considering, too.

Thank you for all the feedback!

[sdog]

As a replacement for the townhall having just another dat file for the same building graphics seems to be the more consistent and less complicated approach.

while this reduces the compatibility with non-experimental pak sets a little, it can be fixed easily. Just set set a flag in simuconf.tab to disable merge by default, the pakset tab has to override it.
If the flag is set and no appropriate building is found, just leave the space of the townhall empty.

A further step would be to have instead of a flag only a string with the objects that replace the townhalls, if they have the same numbering scheme, they will be built as replacement for the corresponding townhall.

Is there already a flag in the dat files of attractions to prevent them from being built by cities and city builder? If not the obsolenscence date could be set to prevent it.


ps.: james, split this into a new thread perhaps?

[jamespetts]

One other thing that needs considering with this: what if one town is created inside another? Are they merged from the outset? And what about the town halls in those cases?

[neroden]

Everybody, thanks for the thoughts.  I'm not going to get around to implementing this this month (lots of stuff going on in my life), but certainly the more detailed the outline the easier this will be to implement.

[skreyola]

Thirdly, do we need to demolish/replace the town hall - can't we instead just add a flag to town halls called "deprecated" and cause them to give different behaviour when clicked on? That way, pakset authors would not all have to code lots of new buildings with the same graphics as "former town halls". We might then consider - optionally - adding a parameter for

Isn't there a citybuilding/attraction already that's a historic town hall? I seem to remember running across it in SimuTranslator.