Add functionality for doodads to influence multiple terrains #19
Description
The majority of modern DH maps use multiple terrains.
Make it possible for doodads to influence multiple terrains. We also need all the supporting operators and UI to facilitate this, as well as converting existing functions to go from 1 to N.
I think it makes sense to have the terrain_info object itself just contain a list of doodads that can influence it. This way, we offload the order-of-operations "sorting" onto that list (sorting is now done visually, and per-terrain).
A comprehensive audit of all the doodad-related operators needs to be done to ensure that no operators or systems still use the old system.
Migration could happen automatically. We could potentially just leave the old terrain_info_object link inside the doodad object and then zero it out when it's saved again.
Keep a running list here of operators that need special consideration:
Freezing
Freezing should probably be done as an all-or-nothing deal and it should be frozen into as many terrains as are necessary. When it's frozen then, it should probably not be allowed to be added to other terrains because of the need to immediately evaluate, then freeze the doodad.
Baking
Baking is similar to freezing, but we should allow the user to do it selectively, per terrain since there's no downsides.
Paint Layers
Paint Layers are currently intimately tied to the terrain itself. Typically, multiple terrains should have the exact same layers (or at least similar ones). Internally, we are tracking the ID of the terrain's paint layer on the doodad's paint layer. This is a 1:1 relationship which needs to be a 1:N relationship.
We probably need to create "linked" paint layers for terrain infos first so that different "physical" paint layers can share the same "logical" paint layer that can be referenced (by internal ID). This would allow paint & deco layers to work across multiple terrains without needing to upend a huge amount of existing code.
Some of the the nodes themselves need to reference attributes (Field) or vertex groups (Paint) that are stored on the terrain object itself. We can probably again used shared IDs here, and just do the book-keeping to ensure terrains have the necessary attributes.