Make monstergroups work the way one would expect #52284
Labels
[C++]
Changes (can be) made in C++. Previously named `Code`
Code: Infrastructure / Style / Static Analysis
Code internal infrastructure and style
Good First Issue
This is a good first issue for a new contributor
[JSON]
Changes (can be) made in JSON
(P3 - Medium)
Medium (normal) priority
Spawn
Creatures, items, vehicles, locations appearing on map
<Suggestion / Discussion>
Talk it out before implementing
Is your feature request related to a problem? Please describe.
The
monstergroup
JSON object is quite difficult to use, and as a result we have a lot of poorly made monstergroup entries that are basically duplicates of each other. They're also very difficult for humans to read.Describe the solution you'd like
I have four core suggestions that would deeply enhance human-readability of monstergroups. I have set these up in order of what I believe is easiest to hardest, but also the later entries are at least partially dependent on some of the earlier ones. The first two should be quite easy. Each should definitely be a separate PR.
"starts"
and"ends"
to use standard time units instead of hours, so where they are currently1440
, it would instead be"30 days"
. I assume for backwards compatibility if just an int was entered, we'd still read that as hours. Note that if standard time units are used, they should still be affected by monster evolution speed as the hours measurement is.cost_multiplier
field optional and have it default to 1. It's something we rarely need at all, yet it's required, creating a ton of clutter. Run a find and replace and remove every instance of"cost_multiplier": 1
. Ideally, remove all cost_multiplier entries in upgrade-only zombie lists, since they do nothing there."freq"
, which is currently a number out of an implied 1000, to instead use a weighted list like itemgroups do. It would no longer be a required field - assumed to be 1 if not entered. The chance of a given monster being selected from the list is equal to(freq of this entry) / (sum of all freq in the list)
. If you wanted to change the name fromfreq
toweight
at this point I would not object. This would also remove the need for the current"default"
field. Warning: as the default field can includemon_null
, this will probably result in some big glitches to monster spawning that will need shaking out later. This might be allayed by addingmon_null
as a possible spawn to those lists.Describe alternatives you've considered
Things technically work in their current form, but I think all these changes are actually quite necessary to make monstergroup auditing a sane task. Number 4 in particular will allow us to condense a huge number of redundant groups into much smaller entries.
I wouldn't mind an option for some functional metadata in monstergroups, such as flagging upgrade lists with "upgrades" and throwing an error if they are used elsewhere.
Additional context
In the future, we may want to consider replacing
start
,end
, andcost_multiplier
withdifficulty
. We'd have a difficulty value of the game that slowly increases over time, a rate which can be adjusted in settings, and perhaps in the distant future have that rate change dynamically based on how the game is going. That is not within the scope of fixing monster groups.The text was updated successfully, but these errors were encountered: