CleverRaven / CleverRaven/Cataclysm-DDA

Replace reliance of random magic add_roof calls with explicit roof placement

Open
#73,149 2 comments 2 reactions 0 assignees View on GitHub
(P5 - Long-term) <Suggestion / Discussion>
Dominant language
C++
Stars
13.1k
Forks
4.6k
Avg merge
2d 1h
Merged PRs (30d)
205

Description

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

The game currently has "terrain" define what their "roofs" should be and relies on add_roofs being called implicitly some time down the line to add roofs that should have been there.
This causes bashed open terrain to magically close again (typically after a save/load cycle). It's also plain illogical to tie the roof on the next Z level tightly to the "terrain" on the current Z level: they should be handled independently.

### Solution you would like.

A long and slow process to gradually separate "roofs" from the terrain below:

Basecamp construction:
- Change basecamp construction code add the roofs specified by the constructed terrain as a temporary measure. Seems to be quite tricky, given that construction is stripped into phases, and you end up at map::set_ter, which isn't a good place to make such changes. Might be better to move directly on to the next step.
- Change basecamp construction code and JSON syntax to allow the definition of construction on other Z levels, which would allow for the explicit specification of roofs.
- Change all basecamp construction JSON definitions that should result in roofs to explicitly specify those roofs.
- Remove the temporary roof addition code from the first step, as it's now redundant.

Player/companion construction:
- Change player/companion construction to explicitly add the roofs specified by the constructed terrain as a temporary measure. Not needed, as it's already present.
- Change player/companion construction code and JSON to allow the specification of the "roof" terrain above the constructed terrain.
- Change all construction that generates roofs to use the explicit format.
- Remove the temporary roof adding code.

map code:
- Once basecamp and player/companion crafting has been modified to always produce roofs when needed (the temporary measures are in place), remove add_roofs (would obviously have to make sure there isn't something else that relies on it. If there is something, deal with it in a similar way to the above).

Once add_roofs has been removed:
- Remove all "roof" definitions from terrain definitions when the temporary roof adding code has been removed from basecamp and construction (as all usages have been converted).
- Define new constructions that only affects the actual tile addressed, i.e. walls without a roof, rooms without a roof, etc.
- Define separate "roof" constructions such that it's possible to construct "roofs" on top of roof less walls, rooms, etc. Note that this should make it possible to create a "roof" in the form of a floor or wall on the next level, allowing for the construction of multiple stories.
- Also note that at this stage it's possible to remove terrain duplicates such as dirt floor with and without a roof. There's only need for a single copy.

### Describe alternatives you have considered.

Digging a deeper hole with interconnected and conflicting code for dealing with terrain and its "roof".

### Additional context

As far as I understand, mapgen is not affected by this mess because it already defines roofs separately from the terrain underneath it.

Contributor guide

Open the contributing guide

Research direction

Start by tracing basecamp construction, player/companion construction, map::set_ter, and the map-level add_roofs calls mentioned in the issue. Review the related construction and terrain JSON definitions, while confirming that mapgen's separate roof handling is unaffected. Done means roof placement is explicit, implicit add_roofs reliance is removed, and the remaining terrain and construction definitions are updated.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, json
Domain
game-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.