I have little interest in making an incompatible change like that.
The original reasoning was user friendliness:
When you configure breakfast garden harvesting in the GUI (settings harvestGardenHardcore and harvestGardenSoftcore), you specify the type of crop you want. Many of those crops require multiple days of growth to achieve. Rather than requiring the user to know, for each garden type, how many days each prize will take to achieve, they pick the desired prize from a dropdown and let KoLmafia decide when to pick.
When we added get_campground(), we continued with that: it contains the item (with count) that you will get if you harvest right now. You will sometimes get multiple kinds of item: the ice and beer gardens, for example. A wrinkle is the Skulldozer, which is a fight, not an item. We denote that as "skeleton (-1)".
When grass seeds came out, there was another wrinkle. You can have from 1-7 patches of tall grass, or, on day 8, one very tall grass. Additionally, you can apply fertilizer at will to to advance your garden. If you want to harvest patches of tall grass, you may as well harvest every day. If you want very tall grass, you have to wait until it is there - either via natural growth or fertilization. The breakfast garden dropdowns therefore gave you just those two choices. But get_campground() returns the pack of grass seeds with a count from 1-8 so that scripts can decide what to do: harvest 6 tall grass or fertilize twice and harvest very talll grass (on count = 8) or whatever.
All of the above types of garden let you look at the garden in the campground and know what you were getting.
All of the above types of garden will grow every day with no attention.
The mushroom garden broke both of those things. You cannot look at the garden in the campground and know what is in it. And if you don't fertilize it, it won't grow.
My initial support for it listed the various mushrooms in the drop downs and also put them in get_campground(). When the dictator (I believe) asked me to change it to the count of mushroom spores (like grass seeds), since it would simplify his coding, I agreed, since the feature was still under development. I stored the crop progress in terms of mushroom spores and set up the drop downs so that people could continue to specify the desired crop to harvest (stored in the properties I listed) using mushroom names.
That is the user-friendly approach.
For ASH programs, well, now they have to know what you get for each day of progress. Not obvious to me that it simplifies the code. In fact, my own Garden Harvester script ended up being more complicated, since its configuration mirrors the user-friendly "expected crop" that you get for built-in breakfast harvesting - which was the whole point; you can configure ALL your gardens, just like KoLmafia internally allows you to do for one garden at a time. But, since the feature was still under development, I was willing to change it.
Changing earlier gardens to have the same convention? As I showed with the mushroom garden, you can still have user-friendly descriptions of expected harvest even if the internal representation is different. But changing what shows up in get_campground() would break existing ASH scripts - including mine, which, as I said, has to map user-friendly expected crops to whatever get_campground() says is currently available.
I could provide an ASH function to tell you what kind of garden you have. "pumpkin", "peppermint", "skeleton", "beer", "winter", "thanksgarden", "grass", "mushroom"
I could provide an ASH function to tell you how many days it's been growing. So, "skeleton" + 6 means you have a Skulldozer, which my_campground() represents as skeleton (-1).
A Thanksgarden on day 6 has 15 cornucopias. New functions might return "thanksgarden" + 6. get_campground() would return cornucopia (15).
Yeah. No backwards-incompatible changes to get_campground(). If we'd done it from the beginning as SEED_PACKET_NAME (DAYS) that would have been consistent with what we now do with grass and mushroom gardens, but I think it is too late.
