Warning of item warning for blueprints used for player construction

[PatrikLundell]

Is your feature request related to a problem? Please describe.

The introduction of checks and warnings for items that are located on terrain modified by blueprints is causing problems with base camp blueprints, and possibly player assigned blueprints as well.

Solution you would like.

What I envision is the modification of the camp construction logic such that it can do the check and tell the player to move items away from there if any items are found when the order is given. Ideally the code should somehow display WHERE this area is, as the current logic doesn't tell the player.

Since the logic sends companions off on construction and finalizes the construction later, the finalization step should perform the check again (things may appear within the area for multiple reasons, such as animal droppings, item dropped on neighboring tiles but placed on blueprint tiles due to tile overflowing, and weirdo "sorting" bugs where items are dropped where they shouldn't (camp supply zones might possibly be targets for that/those bugs). If a conflict is encountered, the player should be given the option to back out (keeping the mission as a finalized one), or go ahead anyway and destroy the conflicting items. The latter is necessary to have as an option as there are "item" plants that cannot be interacted with until they're mature. Ideally, the code would be able to identify "items" that cannot be removed by the player and go ahead without the prompt of such items are the only obstructions.

I've never used player blueprints, but would expect a similar solution might work.

Describe alternatives you have considered.

Shoddy application of the newly created flags to every camp blueprint, resulting in unsatisfactory results regardless of which flag you select.

Additional context

Note that the current destroy/keep flags in the blueprints don't cut it. If destroy is applied the players will have items "randomly disappear" when expanding camps onto tiles they can only guess are going to be targeted by each individual construction order. If keep is applied it's a partial lie, as it seems walls destroy items anyway, based on a test a day or two ago (with a blueprint without either flag (i.e. a current blueprint), where I was told to report it, so there was no way to back out anyway).

Another concern is whether the functionality actually works as desired. I suspect it only works when the "rows" directive is given, and thus won't apply to "line", "point", or "square".

The feature request asks for a "check this construction" level function that can be called from the code managing the construction. It can be noted that the solution also asks for a "show me the footprint of the this construction" functionality that can be called from a bulletin board or conversation (so the interaction UI would have to be suppressed and the game viewport shifted to the target location (as the construction might target a remote corner of an expansion, which might be out of the view of the player's screen viewport(although it should still be withing the reality bubble))).

[haveric]

Ideally the code should somehow display WHERE this area is, as the current logic doesn't tell the player.

To extend on this: we already have zone construction actions that can show what something will look like in the location when it is built and I would assume the logic could be copied over to do the same here when first selecting the upgrade. After the upgrade is selected, the options then become:

1. Create actual work zones and have npcs work them. (which would require significant re-work to how basecamps function currently) . This would already handle the checks via the construction requirements, but that can run into issues with large amounts of construction.
2. Create a new fake zone that would at least be visible to the player so they can identify where work is being done. This would still need the extra checks for items in the way as you suggested.
3. Maybe something in-between the two?

[PatrikLundell]

I find number 1 to be attractive, but I have no idea how the zone construction functionality works. Does it cause the companion to disappear into limbo until the job is finished like the faction camp one does, and, if so, how do you get the companion back (the faction camp has you explicitly return the companion by interacting with the bulletin board)? If not, how is the removal of the construction site from the reality bubble handled?

[haveric]

Does it cause the companion to disappear into limbo until the job is finished

No, it happens in real time, which could mean you could get rid of the weird limbo state that currently happens. You could also assist in the building or have other NPCs jump in mid-progress. There'd need to be some way to handle camp food for this, although the current handling of food is already not great.

If not, how is the removal of the construction site from the reality bubble handled?

I haven't tested this, but that is a great thing to check for.

The other thing I will warn though is that zone activities are currently somewhat buggy and can get stuck in long loops when npcs can't find their tools or run out of light, which would need to be fixed to have this work perfectly. (https://github.com/CleverRaven/Cataclysm-DDA/issues/54920 and https://github.com/CleverRaven/Cataclysm-DDA/issues/52283)

Other thoughts if moving to zones:

• Current construction zones don't require each npc to have different tools, so there might be a need to "claim" tools for each.
• Some constructions might need to be split up so that you build the floor/ground first before building the wall as I have no idea what happens if you attempt to do both at the same time.
• There would need to be a new way to handle completion/status tracking of the in-progress work.

[PatrikLundell]

Yes, it sounds like the zone construction needs to mature before it can be used.

It makes sense, though for each companion to have the tools needed for the current job at hand, and the way I've dealt with that for vehicle deconstruction is to manually give them the tools needed, but that set is less diverse than the one needed for arbitrary construction.

I believe zone construction will have to be matured to figure out a valid construction order, or we'll get a horribly large chain of constructions where you first build the walls, and then a set of circles of floor/ceiling. There's also a need for the construction rules to change to allow you to construct real world constructions such as the one used by the livestock expansions, where you have a row of pillars supporting a roof extending out from the stable. The current rules demand that each ceiling is supported by two neighboring tiles, which means the pillars can be at most two tiles from the stable (i.e. a single tile gap).

If logic to check for items pre construction is made available, the same logic can probably be used to come up with a check for completion logic. Initially that could be a bulletin board action, while eventually that could be part of scanning of the camp, possibly triggered by bulletin board access (scanning would allow camps to detect not only the completion of construction jobs, but also the presence (and removal) of other resources not part of the camp construction blueprints, such as extra smoking racks, constructed appliances, etc..

[haveric]

Yes, it sounds like the zone construction needs to mature before it can be used.

I do agree that it needs to mature, but this might be the perfect opportunity to help it mature and then we don't end up creating duplicate functionality that works slightly differently just for basecamps.

zone construction will have to be matured to figure out a valid construction order

I could see this working in one of two ways:

• Create separate "work orders" for each step
• Each tile gets a chain of constructions that once one gets completed, the next starts. Maybe even entire groups get chained together so you could have a full building get built from one work order without anything breaking or needing to start a new work order. Once for example the floor gets built, it moves on to creating furniture/walls/pillars and finally the roof, potentially even grouping up chunks that we know would have support before moving onto the next. Doing this automatically would be awesome, but probably more effort than it's worth as a first pass.

If logic to check for items pre construction is made available, the same logic can probably be used to come up with a check for completion logic.

Zone construction already handles this. If there are items moved onto the tile mid-construction, it will kick them off onto an adjacent tile when it completes.

[PatrikLundell]

Remember that the blueprint logic is mainly used for map generation, so any additional requirements will have to be compatible with that function. While I want to construct my base camp from a single material, I think it's a perfectly valid strategy to build different sections from different materials to make the most of the materials you have available, so the breaking up of construction into many steps make sense from that perspective. Also, you may have different priorities regarding the order you want to build your camp in depending on other resources you have available. I haven't used the beds, for instance, because a luxury RV is a nice place to live in, with access to basic crafting as well.

You don't want a strict construction order unless the logic can handle a horde of companions working on the same tile. I'd rather have the construction order logic work the other way, i.e. a tile becomes available for construction once its prerequisites for support have been satisfied (and furniture becomes available for construction only when the floor/ceiling has been constructed).

The last comment misses the mark (but it's useful info nevertheless). What I meant with completion logic is the logic the bulletin board would need to determine that the construction recipe has been finished, and thus that the tokens defined by the recipes can be updated, allowing for dependent construction recipes to be made available.

One weird thing with the current construction logic is that floor and ceiling is a single terrain tile that somehow generates a roof tile above it, rather than the ceiling belonging to the upper Z level. It's probably something that won't be remade into something sensible anytime soon. Otherwise, the normal construction order is to build the roof first and the floor afterwards (apart from a potential slab to support all of it) as you don't want (acid) rain to destroy your nice new wooden floor.

[haveric]

I think we're on pretty much the same page overall on what we'd like to see here and there will definitely be some hiccups that will need to be figured out along the way, but I think the general idea of using the zone construction logic would make the experience better.

There's probably enough info here between us that this could be broken down into each step and there could be some more focused discussion/investigation of each one and turn this into workable chunks. With that said, this is obviously a much larger task than the initial request and maybe it still makes sense to just focus on that piece first while investigating how it could be improved.

[Maleclypse]

So are you all suggesting a flag like "MOVE_ITEMS_UNDER_TERRAIN" that moves it to the unsorted loot zone in a basecamp since that zone is a mandatory for faction camps?

[PatrikLundell]

I like Maleclypse's idea, although I don't think that approached had been suggested by someone else.

Unless things have changed recently, the two mandatory zones are the food distribution zone and the base supplies zone, but not any unsorted loot one.

I like the idea of a MOVE_ITEMS_UNDER_TERRAIN flag, but there are issues with the implementation:

• Some "items" do not make sense to move (the container "items" containing potential seeds for some growing plants). They could be destroyed, though, if there's some way to identify them.
• Where should the items be moved? The player doesn't know where the construction will be made, and thus doesn't know where zones can be placed safely, and player made construction can be placed anywhere, possibly covering any base/expansion blueprint placed zones. However, it may be possible for the code to define a temporary unsorted zone if the player hasn't provided one or it can't be used (full, or fully or partially covered by the blueprint area) based on what's currently constructed. You'll still get corner cases, though (such as when the complete area gets covered by walls, which is absolutely stupid in our current situation, but wouldn't necessarily be if you start to dig underground).

One possible approach or fallback might be akin to what I guess the player construction zone does (haven't looked at the code), i.e. push things to neighboring reachable tiles, searching for such a tile further and further away as required, limited by the reality bubble. That would be annoying when things get moved into existing stockpiles, under vehicles, or onto tiles that will be targeted by future constructions.

After that rambling, I think I'd like to see the following attempts, in order:

1. Move to existing, player defined, unsorted loot zone(s) when possible (defined and not full).
2. Push things onto neighboring reachable tiles, out to the limit of the reality bubble.
3. If possible, drop onto reachable tiles modified by the blueprint (such as the floor of a room constructed).
4. Destruction of objects that can't be placed anywhere, possibly with a warning that allows the player to back out and move things themselves.