Fix inexhaustible granite mine production

[DevOpsOfChaos]

Summary

• keep INEXHAUSTIBLE_GRANITEMINES focused on preventing granite resource depletion
• add a separate GRANITEMINES_WORK_EVERYWHERE addon
• create a finite granite resource below a work-everywhere granite mine when no explicit granite resource exists
• keep normal resource depletion semantics unless INEXHAUSTIBLE_MINES or INEXHAUSTIBLE_GRANITEMINES is enabled
• add regression coverage for the separated addon behavior

Motivation

The original issue is that granite mines with the granite-specific inexhaustible behavior still depended on FindPointWithResource(ResourceType::Granite) before production could start.

Review feedback pointed out that "inexhaustible" and "can work without a granite resource spot" are separate game rules. This version keeps those rules configurable independently:

• INEXHAUSTIBLE_GRANITEMINES only prevents granite resource depletion.
• GRANITEMINES_WORK_EVERYWHERE allows granite mines to create a finite granite resource on otherwise empty mountain spots.

This keeps regular depletion behavior intact: without the inexhaustible addon, the created resource can be depleted normally.

Validation

• Built Test_integration locally with Visual Studio 2022 / Debug
• Ran Test_integration.exe --run_test=Production/GraniteMineWithoutResourcesNeedsAddon --report_level=short
• Ran Test_integration.exe --run_test=Production/InexhaustibleGraniteMineStillNeedsResourceSpot --report_level=short
• Ran Test_integration.exe --run_test=Production/GraniteMineWorkEverywhereCreatesDepletableResource --report_level=short
• Ran Test_integration.exe --run_test=Production/GraniteMineWorkEverywhereResourceIsInexhaustibleWithGraniteAddon --report_level=short
• Ran Test_integration.exe --run_test=Production --report_level=short

[Flow86]

what about creating a separate addon to allow granite mines to work everywhere (e.g with some "random" granite chance) which will be inexhaustible with the 2nd addon.
That would keep the addons simple and configureable

[DevOpsOfChaos]

That makes sense. I agree that "inexhaustible" and "can work without a granite resource spot" are separate rules.

This PR currently folds both behaviors into INEXHAUSTIBLE_GRANITEMINES, which is simple but less configurable. I can rework it so the existing addon only controls depletion, and add a separate addon for allowing granite mines to produce on mountain spots without an explicit granite resource.

For the production behavior, I would keep the first version deterministic rather than adding random output immediately, unless you prefer the random-chance variant. That keeps the PR smaller and the tests clearer.

[Flow86]

Yes feel free to rework.

By random I meant "a resource spot with some reasonable (random) amount is created below the granite mine", so if you don't play with exhaustible mines, the granite mine will deplete (we need to check that you cant build a new one on that spot then. I don't know how we currently handle the resource maps though ...)

[DevOpsOfChaos]

Reworked again based on your clarification.

The work-everywhere addon now creates a finite granite resource below the granite mine when no explicit granite resource exists. Without `INEXHAUSTIBLE_MINES` or `INEXHAUSTIBLE_GRANITEMINES`, that resource is depleted through the normal miner path. With the granite-specific inexhaustible addon enabled, the created resource remains available.

Validation:

• Built `Test_integration` locally with VS2022 Debug
• Ran `Production/GraniteMineWithoutResourcesNeedsAddon`
• Ran `Production/InexhaustibleGraniteMineStillNeedsResourceSpot`
• Ran `Production/GraniteMineWorkEverywhereCreatesDepletableResource`
• Ran `Production/GraniteMineWorkEverywhereResourceIsInexhaustibleWithGraniteAddon`
• Ran `Production`

[DevOpsOfChaos]

Additional scope note:

This PR now keeps the two rules separate:

• INEXHAUSTIBLE_GRANITEMINES only controls whether granite resources are depleted.
• GRANITEMINES_WORK_EVERYWHERE only controls whether a granite mine may create a finite granite resource below itself when no explicit granite resource exists.

Without an inexhaustible-mines addon, the generated granite resource is still depleted through the normal miner path. That keeps the work-everywhere behavior useful without turning it into an implicit inexhaustible-resource rule.

[Flamefire]

@Spikeone pointed to #1501 which is a more general version of this: For each mine type it allows to choose:

• Current behavior
• Settlers IV like
• Inexhaustible
• Everywhere

So we don't need the other "inexhaustible" plugins anymore as that one replaces them.
To avoid conflicts with them I'd use the existing IDs, setting "1 == inexhaustible" (so it corresponds to the "ON" of the current addon) and only add new IDs where an inexhaustible doesn't exist yet. Then remove the others.

Otherwise we'd need to handle the case where one is set to "Settlers IV" and the other to "inexhaustible = ON"

[DevOpsOfChaos]

Right, that makes sense.

The current rework split the two rules because they are different:

• INEXHAUSTIBLE_GRANITEMINES only means the granite resource is not depleted
• GRANITEMINES_WORK_EVERYWHERE only means a granite mine may create a finite granite resource if none exists

So this avoids making “work everywhere” implicitly inexhaustible.

But I see your point that #1501 would solve this more cleanly as one mining-behavior setting per mine type, instead of adding another granite-specific addon. I don’t want to push this in a direction that conflicts with that.

Would you prefer this PR to be reworked into the existing-ID/list-setting approach for granite, or should this be left for the broader mining overhaul?

[Flamefire]

I would rather get the addon(s) from #1501 done. If we want those eventually it will only cause conflicts with the one added here.

[DevOpsOfChaos]

Makes sense, thanks for the clarification.

Then I won’t push this PR further as a separate granite-specific addon, since that would likely create exactly the conflicts you mentioned.

I’m willing to help move #1501 forward instead, but I think it should be split into small, reviewable steps. The first useful step would probably be to bring the old branch/design up to date, clarify the intended addon/list-setting model and ID migration, and then implement one focused part at a time with tests.

This PR can then either be closed in favor of that broader approach, or kept only as a reference for the granite-specific behavior/tests.

[Spikeone]

@DevOpsOfChaos I'd be happy if you'd finish the settlers IV mining - or rather "fine tunable mining" Addon(s) 😃