Implement a new ``type`` for plants / Expand furniture functionality for plants

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

When reading and responding to #75708 I realized I never actually wrote down my thoughts on plants anywhere, I have just been rambling on discord for the past 2 years. I am not able to implement absolutely anything here, but at least writing this down means that some poor C++ capable fool might fall into my trap and implement this.

The long story short is - we really have a painfully poor system for plants as it stands. It is currently split into:

Terrain plants - which are harvestable and can regrow after some (I believe static) amount of time so they can be harvestable again - have all the flaws associated with terrain and the harvestable/harvested versions need to be separate terrains, meaning each of those needs to be specified in the JSON twice - this is nonideal on the code side, and actively problematic on the tileset side as it means each of those needs 8 sprites to have full coverage across all the seasons
Furniture plants - which are harvestable and then they're just fucking gone - this is mostly fine, albeit barebones - they don't exactly have many issues (other than just the system being crude) other than not supporting transformation through harvest to my knowledge
Crops - which are furniture under the hood but have a plethora of hardcoded interactions and carry the data primarily from the seed item

All of those have something the others don't have, and neither is even close to perfect. The terrain approach is a massive JSON churn and a pain in the ass from the tileset side, the furniture can't regrow, and neither of those can have growth stages like the crops do.

Solution you would like.

Either expand the functionality of type: furniture or implement a new type: plant to handle this. Have the chosen type be able to track growth stages as well as harvest results/yield, and ideally temperature tracking, so that plants can automatically stop growing/producing their harvest when temperature goes below a certain threshold (this is why the new type approach is handy - having ALL furniture track temperature I believe would slow the game down to a crawl). This would, ideally, allow us to unify crops, furniture, and terrain in the same functionality and allow more plants to be planted.

What I am saying is have the growth timers as well as harvestable/harvested distinction be handled in the metadata of a single JSON object, instead of requiring multiple to function, and be able to be placed on different terrain while doing so.

If chosing the new type option, this would also require the terrain/furniture migration to be expanded to support this type.

Describe alternatives you have considered.

This poses a lot of performance concerns. This change would mean that not only do all affected plants track upgrade timers like #75708 proposed, but they also track temperature. How much that'd slow the game down I cannot predict, but given that in most cases plants are pretty common I would say the impact would be nonzero, and if anything I presume this would be the main dealbreaker on this idea.

Additional context

It would also be nice to have support for plants growing on other plants, such as shelf fungi on trees, but realistically that's just wishful thinking and I cannot think of a use case for this that isn't cosmetic.

And if anyone in the comments points out I just called fungi a plant I will lose my mind

I'm not sure the tile burden would lighten that much from a unified approach, as you'd still need different sprites for harvested/unharvested, and I think some trees can be harvested of different things in different seasons. That said, a single thingie is better than having it split.

I still think we need a new layer for constructions and vegetation combined. Note that this would mean having either a plant or grass on a tile rather than both (which I don't really consider a downside) and won't be able to have a tree and a plant on the same tile (which I consider to be an improvement). Planters would still require special handling of some kind (make planters "constructions" and separate plants and constructions in separate layers as well (with constructions always being below the vegetation)?).

I don't think temperature tracking is viable as long as we use reality bubbles, wildly swinging temperatures, and dynamic loading of overmap tiles. Any kind of temperature tracking would have to back evaluate the temperature changes on the tile during the time since it was last loaded (and if you can do that you can probably make fires behave in a reasonable manner too). I don't know where you'd get past temperatures (or rainfall, sunshine, hail, etc.) for a tile from. You'd get weird results with neighboring overmap tiles being at different development stages because of the times they happened to be loaded/generated at, with ugly artificial tile borders. For these reasons I'd stick with growth timers and season based evaluation, possibly with some kind of special handling for indoors growing (but, again, temperature tracking will be an issue, so it shouldn't be the first prioirty).

If you don't want to be called out for fungii /= plants, try to use mistletoe (is it present in the area?), kudzo, or vines as examples (although I don't think the game would benefit from it and the resulting code required to deal with the removal of the supporting plant, etc.). From a game perspective, non mobile fungii should be considered "plants", together with non mobile other dimensional"plants". Non mobile fungaloid associated stuff should also be "plants" in a game data context. In fact, I'd consider sponges and mussels to be "plants" from a game perspective (immobile living stuff growing).

In fact, I'd consider sponges and mussels to be "plants" from a game perspective (immobile living stuff growing).

Yeah I had the same opinion. I did talk with NetSys in the past about implementing mussel clusters as harvestable plant-like terrain, and I intended to add sea urchins and the such near the ocean shore once that becomes more available. I'd say that for most purposes they'd be identical from the code side.

I don't think temperature tracking is viable as long as we use reality bubbles, wildly swinging temperatures, and dynamic loading of overmap tiles. Any kind of temperature tracking would have to back evaluate the temperature changes on the tile during the time since it was last loaded (and if you can do that you can probably make fires behave in a reasonable manner too)

I'm afraid you're probably right about that. The alternative is have produce/growing timers halt per-season instead, which is similar to what we do now and probably just about good enough to be a replacement. Given how rain is rarer than portal storms, I'd say we can abstract from simulating climate at least until we've got climate sorted out in the first place.

I'm not sure the tile burden would lighten that much from a unified approach, as you'd still need different sprites for harvested/unharvested, and I think some trees can be harvested of different things in different seasons.

For tilesets it might be a marginal improvement in not needing to draw the terrain underneath the plant in question, but for JSON it would halve the line count and make working with terrain more manageable. I recently tried playing around with EoCs that interact with specific terrain, and for every harvestable tree that EoC had to be accounted twice.

Sea urchins move, so you might find them in a spot at some times but not others. I'd rather treat them either as collective animals (so you'd see a sea urchin cluster, or something like that, which can be harvested) or foraged snails (i.e. something you can find while foraging, and foraging shallow water presumably wouldn't be completely different (miserably wet and cold, or course, but still not entirely different)). Also note that you might consider trap logic for these (and lobsters).

Sea urchins move, so you might find them in a spot at some times but not others. I'd rather treat them either as collective animals (so you'd see a sea urchin cluster, or something like that, which can be harvested) or foraged snails (i.e. something you can find while foraging, and foraging shallow water presumably wouldn't be completely different (miserably wet and cold, or course, but still not entirely different)). Also note that you might consider trap logic for these (and lobsters).

They do move, but I am still not confident it's worth having them be monsters due to that, given how much overhead this would require and make them track more things, slowing the game down more. Perhaps a harvestable item is the best approach, but it would prevent me from making a sea urchin tank in an utopian future where we can actually use fish tanks.

In general, though, I'm gonna test out this approach with echinoderms in a mod first and see how that works there. I'm in no rush to implement them in vanilla until that ocean starting scenario PR goes through.

CleverRaven / Cataclysm-DDA