[Togos] [0.17.36] Autoplace settings cause pathological behavior in map generator

[AngeloidBeta]

I have a mod which adds a new resource with autoplace constraints intended to create a density somewhere between stone and uranium. However, when using LuaSurface:regenerate_entity() and providing only the new resource entity and an area 400x400 chunks in size to operate in, the game takes an extreme length of time in attempting placement - I've been letting it spin (and watching my system's RAM usage spike over and over) for 16-plus hours and it hasn't completed. (UPDATE: As I was writing this, it finally did complete. Total time to do so was a bit over 17 hours, and as a final insult it didn't actually place any of the new resource in the process!) Previous experiments show it takes almost 10 minutes to operate on just a single chunk for the same resource. Triggering regeneration for any other entity does not impose this exponential behavior. I'm filing this as a bug report rather than under modding help because I don't believe such extreme delays operating on such a relatively reasonable span of map can be intended regardless of the provided settings. For reference, the autoplace specification most recently tried is included below; several other variations have provoked the same ridiculous time usage.

Code: Select all

    autoplace = resource_autoplace.resource_autoplace_settings{
      name = "lead-ore",
      order = "b",
      base_density = 1.0,
      base_spots_per_km2 = 1.25,
      has_starting_area_placement = false,
      random_spot_size_minimum = 20,
      random_spot_size_maximum = 100,
      resource_index = resource_autoplace.get_next_resource_index() + 128,
      regular_rq_factor_multiplier = 1
    },

[TOGoS]

I will look further into this, but my impression based just on the description is that it's trying to make patches that are far too large.

Code: Select all

      random_spot_size_minimum = 20,
      random_spot_size_maximum = 100,

Usually random_spot_size_minimum and random_spot_size_maximum are numbers close to 1. Maybe 0.5 to 2.0. These will multiply the quantity of individual spots (by changing both radius and peak value) without changing the overall quantity to be placed (which is determined by base_density). Using very large numbers would result in all of the resource going into a single patch in each region. I never tested the system with such large values, so it's possible there's something else going on, but that's my guess. If you don't mean to make gigantic patches, try using smaller random_spot_sizes.

[kovarex]

I will look further into this, but my impression based just on the description is that it's trying to make patches that are far too large.

Code: Select all

      random_spot_size_minimum = 20,
      random_spot_size_maximum = 100,

Usually random_spot_size_minimum and random_spot_size_maximum are numbers close to 1. Maybe 0.5 to 2.0. These will multiply the quantity of individual spots (by changing both radius and peak value) without changing the overall quantity to be placed (which is determined by base_density). Using very large numbers would result in all of the resource going into a single patch in each region. I never tested the system with such large values, so it's possible there's something else going on, but that's my guess. If you don't mean to make gigantic patches, try using smaller random_spot_sizes.

In that case, we should probably limit those numbers to be reasonable.

[TOGoS]

Could you send me the list of mods you're using?

Actually I think the problem isn't random_spot_size_minimum, but resource_index.

I've attempted to reproduce this by using the same settings for uranium-ore and patches do show up. So some other questions:

1. Is this still a problem with the current version of Factorio?
2. Are you using the built-in resource_autoplace.resource_autoplace_settings or one provided by a mod?

The reason I ask is that as of 0.17.51,

resource_autoplace_settings has been made public (require('resource-autoplace').resource_autoplace_settings) and the API improved. It will automatically allocate a unique resource index for each patch_set_name. 'patch_set_name' and 'autoplace_control_name' can be independently specified. 'seed1' can be specified as a parameter. The global function 'get_next_resource_index' is obsolete and has been deleted.

If you're using the newer version of the built-in function, resource_index will be ignored and you should get at least one large spot per region. If you're using the version provided by some mod from 0.17.50 or earlier, a resource_index of anything + 128 would mean that only the points N where N % 6 == 128 from the point list are candidates for a resource patch, i.e. none of them.

That doesn't explain the long wait times, though.