This is not intended to change how current fields work, and instead is a proposal for a similar, but more open-ended mechanic.
Essentially: Have a building refer to other buildings and command them to spawn when the original building spawns, or perhaps on other triggers.
Most simple stage:
Write "Annex[ i ]=Object_name" in the dat of a building. When that building spawns, "Object_name" will try to spawn as close as possible.
This could already be really useful to break up bigger building complexes. Look at the attached factory as an example - it's a static 3*3, consisting of 4 buildings and 3 "warestacks". Now you can't just cut it up as it is right now, but if it was created with a modular structure in mind, you would have gotten 5 1x1 and 2 1*2, which would spawn next to each other and give the factory a consistent look, while still being different each time. Note that this is only partly possible with fields - you cannot have 1*2s, you cannot have rotations, and you cannot make it so "each field spawns once", so you could have duplicates even if only two fields were spawned.
Now this is a factory, and as such it would require a bit more than just spawning in additional buildings. But it would work for curiosities. For examply, you could have a theme-park curiosity which is only a theme-park-gate with a main plaza, that spawns in a bunch of rides. If it would be one building, it would have a rectangular shape, always look the same, and would fail to spawn due to it's size. If it's only the gate, it easily finds a place to spawn, and if the attractions are on different levels it would not really matter. In this case, each attraction could be it's own seperate building, and it would still be fine.
So before, I only said "spawn them in", and did not specify where they are supposed to be spawned. Well, the nearest possible tile, of course - but I'd go a bit further and define a spawn distance for each Annex. "Annex_distance[ i ]=x". Sometimes you don't care if there is a road between a building and it's annex, sometimes you do - simple as that. Personally, I think it would be best if "distance=0" would mean bordering a side, "distance=1" means bordering at least a corner - and then it does not matter if it's a circle, diamond or square. Perhaps square is easiest, and 0 is a special case?`
There should also be a spawn probability "Annex_probability[ i ]=255" would mean 100% always spawning (unless it fails for other circumstances). As such, not all buildings would have the same compartments.
One more advanced thing I'd like to see would be something like "Annex_direction[ i ]=(0-3)" and "Annex_rotation[ i ]=(0-3)" While this might seem like going a bit overboard, this could essentially be used to 'programm' variable layouts. Let's imagine ways in a park. You could start with a straight_way. You could say:
Annex[0]=straight_way
Annex_probability[0]=100
Annex_direction[0]=0
Annex_rotation[0]=0
Annex[1]=curve_way
Annex_probability[1]=50
Annex_direction[1]=0
Annex_rotation[1]=0
Annex[2]=curve_way
Annex_probability[2]=50
Annex_direction[2]=0
Annex_rotation[2]=1
Annex[3]=three_way
Annex_probability[3]=10
Annex_direction[3]=0
Annex_rotation[3]=0
Annex[4]=three_way
Annex_probability[4]=10
Annex_direction[4]=0
Annex_rotation[4]=1
Annex[5]=three_way
Annex_probability[5]=10
Annex_direction[5]=0
Annex_rotation[5]=3
Annex[6]=four_way
Annex_probability[6]=10
Annex_direction[6]=0
Annex_rotation[6]=0
Annex[7]=end_way
Annex_probability[7]=15
Annex_direction[7]=0
Annex_rotation[7]=0
Annex[8]=straight_way
Annex_probability[8]=100
Annex_direction[8]=2
Annex_rotation[8]=0
Annex[9]=curve_way
Annex_probability[9]=50
Annex_direction[9]=2
Annex_rotation[9]=2
Annex[10]=curve_way
Annex_probability[10]=50
Annex_direction[10]=2
Annex_rotation[10]=3
Annex[11]=three_way
Annex_probability[11]=10
Annex_direction[11]=2
Annex_rotation[11]=2
Annex[12]=three_way
Annex_probability[12]=10
Annex_direction[12]=2
Annex_rotation[12]=1
Annex[13]=three_way
Annex_probability[13]=10
Annex_direction[13]=2
Annex_rotation[13]=3
Annex[14]=four_way
Annex_probability[14]=10
Annex_direction[14]=2
Annex_rotation[14]=0
Annex[15]=end_way
Annex_probability[15]=15
Annex_direction[15]=2
Annex_rotation[15]=2
What does this do? It tries to place ways on both ends, but not to the side. The first possibility is a straight way tile - a copy of the one we already have. If that was to be buildt, nothing else could be buildt in this direction. However, it does not end there - that new tile then can have annexes as well - causing a way-grid to be buildt. What's between those ways does not really matter for now, additional Annex-entries could fill it up - with trees for parks, attractions for an amusement park,...
(Note: I falsely use a chance-value instead of a probability value. To lazy to calculate it right now, but the values would be higher each time, the last one being 255 to be buildt in any case if nothing else was)
This is overly complicated any might not always work, especially if there are a lot of hills. But this just serves as an example would could be done, not what should be done. Chain reactions could be useful in other ways as well. For example, thick-forest could be spawned by a forestry, and thick forest could spawn normal forest, normal forest spawns thin forest - and you get a nice forest that thins out the further away it is from the forestry. Or the oposit - closest to the foresty spawn tree stumps, which spawn stump-tree-mixes, which spawn forest.
Another interesting implication: You could have land-attraction or land-factories which spawn townhalls, thus cities. So if the map spawns a castle, it comes with a town next to it, as it should.
Another benefit is that the same factory buildings can be surrounded by different "fields" of stacks-of-goods as the timeline progresses, as with an automobile factory whose "fields" of cars can now remain somewhat consistent with the current-year's citycars.
Quote from: wlindley on August 18, 2017, 12:24:49 PM
Another benefit is that the same factory buildings can be surrounded by different "fields" of stacks-of-goods as the timeline progresses, as with an automobile factory whose "fields" of cars can now remain somewhat consistent with the current-year's citycars.
Especially if combined with this other request, yes: http://forum.simutrans.com/index.php?topic=17304.0
Though in both cases, factories need a lot of extra code for implementation. While for pretty much everything else it would be satisficial if the result were seperate buildings, same as if they were placed/replaced by a player, in the case of factories they need to combine under the same unchanged "factory"-umbrella. Such an umbrella could not be tied to the main building (because of replacement issues), but would be it's own entity which can exist without body (buildings).
Except for a lot of code to be written, this would mean:
- It would be possible to move a factory from one place on the map somewhere else, without having to re-contract everything.
- Instead of multiple factories that do the same thing (eg. oil field and oil platform) you could instead define one oil-factory that does both, depending on location.
- the player-color-system could be reused for factory colors. Each factory comes with two colors at random, all factory buildings follow suit.
- You could not delete a factory by deleting it's buildings, since you would need to destroy the umbrella-entity. Since the player is not allowed to destroy industrial buildings anyway, this is only relevant for the public hand. Plus, it means that if all buildings of a factory get destroyed, you could make it pop up somewhere else automatically.
But this is the kind of thing I'd like to avoid as the main request, since it would make everything terribly complicated, especially since it also needs to be backward compatible. Spawning another Building however should be 'rather' easy in comparison, since it's just triggering a function that already exists.