[TOGoS] [0.17.51] Possibly unintended map generation changes

[zsoc]

It seems like someone decided copper is bad?

0.17.50: https://i.imgur.com/v5AbLTy.png

0.17.51: https://i.imgur.com/SDHAQLj.png

Some patches (such as the large copper fairly close to the right of start) have simply changed from copper to iron? some are just gone, or are smaller. I guess this has something to do with the autoplace api changes?

Exchange string:
>>>eNp1UT1Iw0AUfmct1gqi0EXQUsE1RauDiPROQUREdzfb9CqBN
idJOqiDHRx1c9HJVQU3B7eCIAoKooO4VQVxUKkIugj1LrlrQsUP3
st33/u7dwHohhS4KJPDg4N0pFVnmYI4AVSI+EZ1trxMLY1Z1JNcw
+26VcpRjRmFgEqi1KTFFS2bsXlyGcvOOGJYzGzqQMK2w0yugFQIC
TsWpbY8YVHYUbIyplEqerV+Q0Dnd5f95Y04CKuvQ6JeF8ZZlSdUA
fxMrkmgPp2ZjsUKmk0dxzCXxorMsJ2SRceyRsZu1waTqUGBsF4w8
nmAxAS3SbcU0FrsaPphdRsjr1mSSFKTSiWrlBlF5sm/oQFFRgJ9h
l18Bog31OEjZFaE+MQLboggQltvx3vfZ9dp9LP/cTOXXcRoaCr2X
ksdpXmwTazQ0nC7OwInahVQPatYhu4xuroUeMUoLCpiwpFR7iqzI
UBdnZztbXKX6AV1tbRqEyMo7+JLbfKkyC1u3oM/xLhoHhfuXDh3Y
ONmSNIF4gV6/CgvTUFwfM5f7kJNPA2MbrrD338QXKFJGQg8fFTMy
TXcS6hxCf6C123qRNZJCHzUMDzGk8+/Plis6A==<<<

[TOGoS]

Here's what happened!

The way ore patches are placed is that for each region of the map, one long list of points on the map is generated (attempting to keep space between the points), sorted by favorability (descending, such that candidate points with the highest favorability are the first to be chosen to become actual ore patches), and each ore gets a different offset into the list. So normally iron gets points 0, 6, 12, 18, copper gets points 1, 7, 13, 19, and so on. The total number of points is specified on a spot-noise expression either by the 'candidate_point_count' parameter, or the 'candidate_spot_count' parameter, multiplied by skip_span (the number of different ore patches). In 0.17.50, candidate_point_count was set to 128, somewhat arbitrarily. And as we all know, 128 is not divisible by 6! Which meant that iron and copper got 22 points, using points at offsets 126 and 127 from that big list, while other ores only got 21. Which is kinda weird, bit gives the result you were used to.

The changes for 0.17.52 were primarily to allow mods to add their own resource patch types (tin or gold or whatever) using the same system that places the vanilla ore patches. This means that instead of having a hardcoded 6 for ore count, that number has to expand as new ores are defined.
Since 128 points might not be enough if a lot of new resources were added, I switched from specifying 'candidate_point_count = 128' to 'candidate_spot_count = 21'. This means that the long list of points only has 126 candidate points in it instead of 128. If those last two points from the 128-long list had had very low favorability then they wouldn't get used anyway, and the result would be the same. But in some cases those last 2 'extra' points would have had high favorability, which would result in them being sorted somewhere into the beginning or middle of the list, which would move the other points around and lead to a visibly different result than when using only 126 candidate points.

Now, whether we should keep the new, 'more correct' behavior or change things to specify

Code: Select all

candidate_point_count = noise.var("regular-resource-patch-set-count") * candidate_spot_count + 2

(or some other solution) to make things match the 0.17.50 ore patches is another question.

[TOGoS]

Giving this a day or two for feedback, but leaning towards "Won't fix"

[zsoc]

Specifically for me, this affects my ability to run Any% on a number of different maps that I've previously spent many hours on planning. I know that supporting speedrunning the game in general is probably not very high priority, but I figured I'd at least voice my case there.

Separate from this, the changes *appear* to seriously nerf copper (specifically the close~ish patches to starting area), in particular. The way you described the cause, I would not think so at first, but looking over various types of seeds and map settings, it's always copper that takes biggest hit, sometimes to a pretty high degree. To me, that means this is more than just "shuffles the ore around a bit" but also actually affects the core gameplay experience.

[AntiElitz]

I don't mind any changes in generation during the experimental phase if they are favorable for the game. It's a risk we live with when running the experimental. (Speedrunner myself)

[TOGoS]

I also compared a few different maps and indeed, copper ore tends to be more abundant in the 0.17.50-like version (that's data commit ID f8eb4d01).

I did anticipate that there would be a few map generator changes before 0.17 stable, though. "That's what experimental releases are for"

[SoleGlo]

I ran into this issue doing an any% run and it kind of sucks finding out two hours into a run that copper patch you rely on, has now turned into an iron patch.

I do not mind intended mapgen changes that are communicated.

The the following entry in the modding feature patch notes doesn't communicate to me that I should double check my ore patches before playing.

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.

This feature doesn't appear to intend to change the ratio of copper patches and I understand this as a side effect. It does have a big impact to me for the same reasons zsoc has stated: lots of time spent finding a good map string, tweaking settings, designing a run, and executing runs. I would love to see (selfishly) the original patches being generated, but completely accept the current state. Note that speedrunners are the first to detect these consequences, but there are will be other players that start over many times due to various reasons that will be affected later.

I will chalk this up to a learning experience and realize the risk of mapgen changes is higher than I am ready for, and look at this as an opportunity to get into default settings runs.

Mapgen has affected me previously in 0.17:
.41 : unintentional change (similar to this issue)
.42: intentional revert of .41
.44 : intentional feature change

[zsoc]

Just to summarize my stance (if it matters at all ):

• I agree with AntiElite that this is a known risk we take doing this on experimental versions

• I agree that any changes favorable to the game overall should be prioritized against the minority

• I am still concerned that this *is* a core gameplay change as it affects the balance of resources near the starting location - specifically reducing copper.

If the reduction in copper is known and acceptable to game balance - then I can't further complain at all.

As a resolution:
I would love for anything with the *possibility* of affecting map generation to be communicated as such in the changelog/patch notes - if this is not an unreasonable request.

[TOGoS]

I was tempted to leave this as "Won't Fix" for the reasons given above, but I wanted to know why the ooverall change in copper was happening.

In 0.17.50, candidate_point_count was 128, which means when divided up among 6 resource types, the first 2 types (iron and copper) got 22 spots, while the rest only got 21. I wanted to see if giving copper its old 22 spots back would result in the overall amount of copper going back to its old (0.17.50) value, and so overrode the spot count on iron and copper to 22 without doing the "candidate_point_count = spot_count * spot_type_count + 2" hack ("what is that +2 there for?", I imagined people of the future asking, after being surprised that their modded ore patches weren't showing up quite as expected). This got things mostly but not quite matching 0.17.50. It turns out that was because using spot-noise with different candidate_point_counts (either explicitly indicated or derived from candidate_spot_count) will give totally different point lists (i.e. not just a differently-lengthed slice from the beginning of the same infinite list). This is because minimum_candidate_point_spacing (which is used to skip points that are generated too close to those earlier in the list), when not indicated explicitly as an argument to spot-noise, is derived from candidate_point_count. So the other part of the fix was to hard-code minimum_candidate_point_spacing (which I've renamed to 'suggested_minimum_candidate_point_spacing', since it's not a hard minimum) to the implicit value used by 0.17.50. In case you wondered about details.

Anyway, the upshot of all this is that 0.17.57 should restore ore placement as it was in 0.17.50.

[slippycheeze]

Anyway, the upshot of all this is that 0.17.57 should restore ore placement as it was in 0.17.50.

I'm jumping way to the side of the topic here, I think, but I'm not certain. If it is irrelevant, just tell me so and I'll not trouble you further.

Anyway, when mods add additional base resources right now, as in the last two 0.17 versions, they have a huge tendency to sit right exactly underneath one of the core resources, overwritten by them.

For example, Krastorio adds "sand" as a core resource in the starting zone, and I usually get ~ 75k sand at the edge of a patch of coal. By "at the edge" I mean "a two or three tile wide crust on about a third of the outside of the coal patch."

Is this something these changes are likely to have influenced, and that may improve in the future?

[Bilka]

Sounds like the mod is doing "adding resource" wrong, that problem was fixed a while ago.

[BlueTemplar]

What is the intended resource balance ?
Do these changes actually modify it in any way, globally speaking ?
If they do, which distribution is closer to the intended one ?
If they don't, how much does the local impact matter (this is likely to be quite subjective...)

[TOGoS]

What is the intended resource balance ?
Do these changes actually modify it in any way, globally speaking ?
If they do, which distribution is closer to the intended one ?
If they don't, how much does the local impact matter (this is likely to be quite subjective...)

The 'correct balance' was determined for 0.17.0 by sending the new ore generation to Twinsen and asking if it "seems about right" or not. 0.17.51 accidentally decreased the amount of copper by a significant amount on some maps. It may have been perfectly acceptable for gameplay purposes but it didn't match what people were used to, so now it's back to 0.17.0..0.17.50 amounts.

[TOGoS]

Anyway, the upshot of all this is that 0.17.57 should restore ore placement as it was in 0.17.50.

I'm jumping way to the side of the topic here, I think, but I'm not certain. If it is irrelevant, just tell me so and I'll not trouble you further.

Anyway, when mods add additional base resources right now, as in the last two 0.17 versions, they have a huge tendency to sit right exactly underneath one of the core resources, overwritten by them.

For example, Krastorio adds "sand" as a core resource in the starting zone, and I usually get ~ 75k sand at the edge of a patch of coal. By "at the edge" I mean "a two or three tile wide crust on about a third of the outside of the coal patch."

Is this something these changes are likely to have influenced, and that may improve in the future?

The 0.17.51 change that kicked off this whole thread was intended to address precisely that problem.
It looks like Krastorio is using a copy of the resource autoplace functions supplied by another mod from before the built-in ones were fixed up and made available to mods.

Code: Select all

	autoplace = resource_autoplace.resource_autoplace_settings{
		name = "kr-sand",
		order = "b",
		base_density = 6,
		base_spots_per_km2 = 1.25,
		has_starting_area_placement = true,
		random_spot_size_minimum = 1,
		random_spot_size_maximum = 5,
		egular_blob_amplitude_multiplier = 1.2,
		richness_post_multiplier = 1,
		resource_index = 96, -- some random number, because "resource_autoplace.get_next_resource_index()" resets to 1 (iron-ore) if used from outside
		regular_rq_factor_multiplier = 1
		},

For the built-in resource autoplace library, resource_index is no longer an effective parameter. 'patch_set_name' or 'name' will be used to generate a unique index to avoid overlap.

Also they misspelled "regular_blob_amplitude_multiplier".

[slippycheeze]

Also they misspelled "regular_blob_amplitude_multiplier".

All passed on to them, by pointing at this. Thank you so much for the personal response.