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

The current implementation of the 'riot damage' generator is hardcoded except for the flag which controls whether it runs. This is not ideal for a variety of reasons:

-Changing or tweaking any values require compiling C++, raising the effort bar for contributors.

-The same (re)compilation means turnaround time for testing changes to it is slow. JSON changes have almost 0 overhead, C++ changes have a very sharp minimum.

-The settings are not always appropriate for different gameplay experiences. Right now they are tailored towards vanilla CDDA, but not everything wants vanilla CDDA settings! For example we have the 'No Hope' mod, which aims for a darker bleaker world. It likely wants more riot damage, crazier stuff. But it has no way to do that, it can only toggle the riot damage on or off.

Solution you would like.

The solution is obvious: We offload most of the specific values into JSON, where mods can overwrite, extend, and modify it as they see fit.

The way I envision doing this requires a new JSON object type.

Here's an example of what the JSON format would look like:

  {
    "id": "PP_RIOT_DAMAGE",
    "type": "pp_generator",
    "generators": [
      { "id": "move_stuff_around", "attempts": 20, "min_distance": 1, "max_distance": 5 },
      { "id": "smash_stuff_up", "attempts": 20, "chance": 20, "min_bash": 6, "max_bash": 60 },
      { "id": "place_blood_streak", "attempts": 2 },
      { "id": "place_blood_circular_pool", "attempts": 1, "chance": 50 },
      { "id": "start_a_fire", "attempts": 1, "chance": 10 }
    ]
  }

This data would be attached to the overmap_terrain object and could be copy-from'd or extended/deleted, as a whole. That is if we added the above to generic_city_building_no_sidewalk it would apply to anything copying from that abstract. But it would not apply to rural buildings, as they would "delete": { "pp_generator": [ "PP_RIOT_DAMAGE" ] },.

If buildings needed finer control over which generators run, they would create a new pp_generator object. Here's one that only sets a bunch of fires:

  {
    "id": "PP_RANDOM_FIRES_ONLY",
    "type": "pp_generator",
    "generators": [ { "id": "start_a_fire", "attempts": 10, "chance": 100 } ]
  }

This allows granular control over the exact 'noise' applied to mapgen, to a degree. (If even more granular control becomes needed, we could do away with the pp_generator object and apply generators directly as part of the overmap_terrain.)

This will require some refactoring of the existing C++ code in addition to the new json objects. Let's take a look at some of it. Pretend we are running the program with our earlier riot damage generator, on smash_stuff_up.

{ "id": "smash_stuff_up", "attempts": 20, "chance": 20, "min_bash": 6, "max_bash": 60 },

https://github.com/CleverRaven/Cataclysm-DDA/blob/master/src/mapgen.cpp#L446-L449

The post-changes code would look something like this:

        for( auto generator : md.all_generators ) {
            switch( generator_type ) {
			
			    // insert other sub-generators as individual cases

                case generator_type::smash_stuff_up:
                    for( int i = 0; i < generator.attempts; i++ ) {
                        if( x_in_y( generator.chance, 100 ) ) {
                            tripoint_bub_ms current_tile = random_entry( all_points_in_map );
                            md.bash( current_tile, rng( generator.min_bash, generator.max_bash ) );
                        }
                    }
                    break;

                default:
                    break;
            }
        }

Notice how we've reduced the "magic numbers" down to a single one, 100. As an overarching rule this is much better for readability and maintenance. As a side benefit, breaking these up into individual "sub"-generators will eliminate much of the math weirdness I introduced. Instead of having to calculate 3-4 dependent events which may preclude your math from having the exact chance it says that it does, we run them independently at the exact chance. This will head off confusion before it starts.

Describe alternatives you have considered.

No response

Additional context

No response