this is a pretty low priority request, but personally i would like the ability to merge two buildings.
My main reason, sometimes i might forget something on a building and i add the few slabs after i already finished it.
So i would like the ability to make these blocks a part of the building so i can make a “completed” blueprint.
@sdee
Part of my ideal stonehearth would allow me…
To be able to build two buildings, complete the first and then decide to later place the second combining it to a wall on the first and connect it using that shared wall and merge that into a single building where I can then adjust that wall and update the new building save.
So build it as I go instead of build the entire thing with every room. I would rather add each room as needed to an already existing ever expanding house indefinitely.
Just so i understand ! in basic, what you want is the ability to put a building back in to planning mode and the ability to merge buildings?(assming that stuff like walls could still be removed) Since i cant really argue against that!
yes but not only that. I want to be able to create a completely separate blueprint that I can plop down adjacent to a wall on whatever I built first.
Well umm not sure i follow? Cant you do that already ?
Like that ?
or more like you want to be able to place a blueprint on a blueprint ? You can already place blueprints next to already built stuff, since thats what i did here.
While you can place blueprints and new buildings connected to existing ones, there’s some potential gameplay problems in how the game currently segregates them. For example, if you building one building with a flat roof, and build a second building directly on top of it, then demolish the first - what happens to the top structure? As far as I can tell currently, the game will leave the top structure floating. There are many other potential cases where this could arise - slab or stair additions to existing structures, for example.
Combining structures should definitely be possible so we don’t have these sorts of accidents… but if we make it mandatory or automatic, then one runs the risk of demolishing an entire city when you remove one connected part.
well if the would be combined, they should only act as one building. So both buildings would be destroyed ?
not sure what you mean by making it mandatory or automatic…i was thinking more like select a build click combine button , select other building and confirm ?
(also if you build really large stuff you learn to turn off auto save >.< so you wont lose a city 
reminds me i need to make a post about autosave )
sorry maybe my wording was a bit confusing when I said “adjacent to a wall” what I really meant was sharing that same wall and becoming an extension of the building by adding a new room, or sets of rooms, to a building along that shared wall but not by drawing a room from scratch- from a blueprint you made previously. completely different.
Similar to what psyduck is saying, I’d like to go back and edit/add to a build later on. Especially for large structures.
here is my super awesome explanation drawing
a way to revert to old template designs rather than deleting single objects at a time would be nice regardless if this becomes a thing or not as an option rather than deleting the entire building or saving the new version of the building as a new template or updating an existing template. your hearthlings could “restore” the building to the original template design. in fact this would be nice for each wall and section of floor in separated rooms- not just outer walls. this would give the player a lot more control over the history or lifetime of a section of the build.
Long Post Warning: may not be relevant to most people. Just some wild exploration of possiblities. Please SKIP if it gets too hard to read.
My feel is that the system described above is too complex and probably not feasible for implementation. (I can only speak from a general design/programming point of view though. Radiant programmers/designers may like the challenge?) For one thing, any form of history is messy. Not only storing, maintaining consistency etc. And the use case does not apply to all users. It will make those players whose use cases fits happy, but do not solve the problem in general.
(messy part begins)
TL;DR at the end.
Disclaimer: some concepts are probably already similar to what is being implemented atm. I am just approaching it anew and any similarities will be coincidental. And most of this is just adhoc thoughts which is not organized at all. I.e. may be totally not feasible or have major flaws. (so feel free to attack 
)
But if I were to do it, I may want to approach it using clear conceptualization of what is the design, space and actual built building.
Firstly, I would separate the concepts of design (intended state of spaces) vs physical (real state of spaces).
E.g. A design is constrcted by changing physical block spaces covered by the design to match what is specified in the design. e.g. design specifies a stone block and physical space has nothing? hearthling should build a stone block there. If design specifies open space but physical space is a terrain block? it means hearthlings needs to dig it. If design specifies a space to be “any”? hearthlings should leave that physical space in whatever state it was in.
It is not necessary, however, to have a design after the physical space has been built once. e.g. after building a design, I could just delete the design. The physical space is still left behind, but there is now no direct way to change the design (since it is abandoned). But similar to current system, we can “generate” a design from what is in a physical space. e.g. by defining a space extent over all or even just a part of a physical building, we can generate the design for that.
(The current game probably start with separate concepts of design and physical space as well, but when the building is “finished”, the two seems to be merged into one, which is why it make some actions, like say removing/changing a selected part of the finished building impossible?)
Further examples:
The main action associated with a design is simply “construct”.
This just means “changing all the physical space covered by the design to match what is specified in the design”. Construction is considered “finished” when there are no unmatched space left.
This generic construction process is actually interruptible. E.g. I can start the construction of a design, then stop it halfway (not just “pause”. totally stop and abandon ALL in-progress transient construction states), change the design or manually change what is physical, then later on start construction again. The processing part will actually make no difference between whether this is a new building or continuing an existing one, and can just compute the “difference” between the design and what is physical there and figure out a way to make the rest of the physical space match the design. (it may actually make building construction more robust? lol… implementation-dependent… )
When “editing” an existing building, we are really editing the underlying design, then “construct” it.
When “removing” a building, it is just replacing the design with a empty one then “construct” it (and auto-abandon the design when it is finished).
Just to recall: changing the design is just one way of changing an existing building. There can be more direct actions/commands which changes the physical space directly without changing the design.
Next comes the management of designs and their spaces. Let us use the example from @genboom above, where we want to build 2 templates (let’s call them template 1 and template 2 as well) with an overlaping walls of 1 block in thickness. I may have the following different requirements:
First attempt:
I want the final thing constructed to:
Build the design according to both templates, but with template 1 taking precedece : i.e. if template 1 and 2 both overlap same block space, template 1 wins.
similar to above, but with template 2 taking precedence.
With the concepts from above, both are possible, and just controlled by the order of “construction”. in the first case, we construct template 2 first, then template 1. Since template 1 is constructed later, it will change the parts of the shared wall already built by template 2 to match template 1. And in the second case, just reversed the order.
But I am not happy: that I actually had to build parts of the shared wall using first template then re-built by the second template. How do I just build the shared wall once?
Second attempt:
I’ll create a merged template (which is NOT reversible, though the effects can be… will describe later.). By merging the overlapping templates 1 and 2 into a new template 3 (must specify precedence similar to construction order though), we now have a new single template that spans the combined space of template 1 and 2, and where the “shared” wall was, there is only one specified state for each block space left, there will no longer be cases of build first, changed later for each block space.
But what if I want to “revert”, say back to just template 1? template 3 is created in a non reversible manner. But the process which it is created can be reverted manually. Let’s say I want to remove the design in template 2 and just keep template 1. This is what I can do :
What this will do is: it will change those spaces defined only by template 2 to empty space, while preserving those that are in template 1. And as a bonus, if any shared space was built according to template 2 which is different from template 1, it will be re-constructed to make it match again.
Think wrote too much lol… and not too well organized as a first unplanned draft.
TL;DR:
Reinterpret “construction” simply as changing physical space to match a design, which exists independently from the physical building even after being built once.
Designs can overlap in space. The one that is constructed later will decide the final state of the shared spce, by default.
Designs can be merged. Shared space will end up with the state of one of the designs according to options/preference/priority in merging.
A design can be generated from physical space by defining the extent of the space. (this can be used to easily “break down” a previously atomic design)
“Changing” a building can involve a ad-hoc change by changing the physical space directly, or a change in plan by editing the underlying design then “constructing” it again.
All manners of grouping, management, overlapping etc are specified over the designs rather than physical space, and can be changed simply by putting a different design with different space extent over the same physical space. removal of existing designs over same space is entirely optional.
Again I think I may have caused a misunderstanding.
I am not saying save every single iteration of a design in a history of additions and subtractions. I am saying simply save the blueprint the building is based on and the current state of the build. Thats it, keep it simple.
I am also not saying place any blueprint within a section of a building and build over that building with the new blueprint. I am saying a blueprint could only be added by combining it to a wall that is shared between the “active building” and the template. This shared wall must not have a floor attached to it on the side you are adding the blueprint and you would still require enough space for the blueprint to be built in the area while being attached to that wall.
The difference in my idea of separating walls and floors to have different states of memory is that you would not be locked into changing the entire build between the “active building” and the blueprint state but you could make the changes with specificity by only selecting a small section of the build relevant to the area.
Now what this means is that new rooms will exist as part of a separate entity that are not saved as a blueprint yet. So you have template 1 which is built, template 2 which is a blueprint and template 3 which is the combination of those two but also the “active building”. That is- any small changes made are kept separated in memory so that the game knows the things that have been added since the combination of template 1 and template 2 in each section respectively.
To make this even more highly organized I think it would be simple to separate each room into sections of floor and wall and designate things as being part of and attached to these two basic things required in a room as everything in the room is dependent on the state of those two things. This means that each wall that is based on a template and then is changed in the “active building” can have a total of four states of memory- the template 1 AND template 2 AND shared wall forming template 3 AND “active building” while the floor would only ever have template 1 OR template 2 AND the “active building”. I see this as a simply keeping a list of object numbers in a set of coordinates on each section of a length of wall or floor. Sure slabs can mess things up but you can very loosely define a floor and wall and still make this work. This would make the blocks have associations in memory just as they do visually and structurally.
This means that unless you extend or shorten a wall section or room, it will still recognize it as being part of template 1 or template 2. However, if you do shorten or lengthen this wall it is now the “active building”. If you change the shared wall that combines template 1 and 2 you break the connection of template 3 and now this section of the building is the “active building” and can still return to any of the three templates.
even better super awesome explanation drawing
To me this is the most logical way to handle the data, it also happens to come with the benefit of being extremely useful. If things are designated separately like this in memory you could then easily select one of these sections and export it as a new template and you suddenly have a library of any wall design or floor plan you could imagine. Then you could select a template of this section of wall or floor to add to an existing building and build with that instead of drawing a blueprint from scratch. This would give you a catalogue of designs to choose from that can be shared using the current template format but designated by “floor” or “wall” with attached decorations to each respectively. Then you could filter each design by dimension, number of doors and windows, and decorations relevant to your search, adjust it sightly to fit your asthetic and repaint it as you see fit.
White squares would be pillars or “anchor points” for defining the building. A wall or floor can be added, removed or combined or cut into sections, forming a new section where the data between those two “anchor points” change and a new template can be formed, represented by combining colors.
The “active building” represents data that has not been saved as a template. The ideal scenario is that I would be able to select any color of floor or wall that is in the “active building” state and restore it to the previous state of the stored template.
So the data of a room is dependent on the “anchor points” that define the wall and that wall defines the floor. By checking the data between those two points you can know if the wall or floor has changed. Adding more anchor points adds more walls and more checks but you don’t need to know the state of every block, only the blocks along these points. No matter how long the wall section is you will either connect by adding a new “anchor point” or connect to an existing one.
This makes me realize you only really need to know the “anchor points” to generate a random building.
If this was a 3D building it would be 1168 blocks with just the floors and walls (assuming 6 blocks tall, with the floor in the ground, and excluding roof design) and it can be defined by 24 “anchor points” and 30 connections between those points in 2D.
This also means that the AI could then prioritize the “anchor points” with the most connections, from bottom to top, as being the core foundation of the building and build those connections first before building a second floor or walls to help the structure support itself if physics ever becomes a thing. If you simply create another floor plan and overlay it for a second floor, you would only need to look at the “anchor points” and their vertical alignment with the floors below it to estimate the amount of deviation between them to know how well it holds its weight.
Great discussion so far. I like the idea in concept, but the implementation concerns me. I don’t want this to happen automatically - some type of prompt or button push should be necessary.
Here’s my concern. Let’s say I want to make a row of houses (think New York City townhouses). I want them to touch, but I want each house to be a unique entity. That way, if I want to upgrade house number 2 (between house 1 & 3) I can do so without destroying all 5.
One way this might be solved is by checking if walls overlap or touch. If you use the same wall for 2 buildings, they should prompt you to merge. If you put two walls right next to each other, they shouldn’t neccessarily merge.
Definitely.
The idea is that each block would have to know what state it is in and give it a menu if you click on it according to its association of wall or floor and template or no template.
Yes!
Click to select your blueprint, rotate the building and move your mouse to place it to a wall that will snap it to that wall and prompt you to edit that wall while in the building mode. You can add an option in the menu to default to template 1 or template 2 or a blank wall with all features removed that you can edit at another time- the problem is that this could create rooms with no exit so I don’t see it as a great option. Either way its less work than creating an entirely new design every time you play the game.
This game is about blocks in a finite space, but as the game expands and buildings get larger this organization becomes more useful. If a massive city is the long term plan for Stonehearth, or you plan to build within the 1:1 scale, like in Minecraft, this would be incredibly useful.
not that i dont like the idea. But i have to say that’s overkill compared to what i wanted.
And i still have a hard time seeing the implementation…at least im glad i dont have to attempt programming that 
If i could add one block to an existing building i would be happy really! But of course i would like the ability to just combine 2 blueprints, rest of it i really feel i can plan around enough for it to not really be an major issue to me anyways.
and i cant help to think… If i could put a building back in to full planning mode, I could remove the walls as i see fit after i combined the buildings? might be a bit more work for the player, but seems way more simple to me and would archive the same deal?
I think when it comes to organizing data there is no such thing as overkill. Plus, you have to think what Stonehearth will be in 5 years, not what it is right now. All the demands of new features that are not even in the game yet.
As it is right now, the game does seem to have some logic, though its hard to tell how organized it is, for separating chunks of a building into sections by different blocks. What my suggestion will do is give logic, that is tied to the structure of the building, to how those chunks are separated and organized as a set of data. The game already does this to some degree, it just doesn’t seem to do it very well.
Think maybe thats what i am doing thinking a few years ahead…this is a game that sucks up +10 gigs of memory on something i would call consider a fairly small build. And the game start doing weird bugs with lots of CPU tasks already
and thats with only 50 people lets says that number might become 200…of course optimization is gonna fight that problem …
but i am worried about using more resources on something that can be fixed with simplicity and 2 mins of work ingame.
And i find that a better option than slowdowns and what not.
This may help you visualize what I struggle to explain in my posts above.
some suggestions @Chris for Building Overhaul
Would suggest you make your own post then since i surely don’t support any of your ideas…they are insanely
overcomplicated for something that should be incredible simple.
