Scale alliance cost by the bloc's share of all prestige

[Drefvelin]

What

An alliance now costs more diplomatic capacity the larger the two factions are together.

New cost for a relation type that sets bloc-scaling:

cost × prestige scale of the target × (1 + bloc-scaling × bloc share)

Bloc share is the two factions' combined prestige divided by the prestige of all factions (0 to 1). Relation types without bloc-scaling are priced exactly as before.

The default ally in diplomacy.yml changes from cost: 3.5 to cost: 1.5 with bloc-scaling: 8.

Why

The flat cost made an alliance between the two strongest factions as cheap, relative to their size, as one between two small factions. With live prestige on 2026-10-01 (alliance cost: 2 on live):

Alliance (payer → target)	Before	After
Sunsora → The Holy Order	94	189
The Holy Order → Sunsora	74	148
Jolly Sprockets → Aureate Coterie	64	105
Hraftar → The Village (hypothetical)	42	45

Rollout

A server with its own diplomacy.yml keeps its current alliance cost until cost: 1.5 and bloc-scaling: 8 are set on ally there.

Existing alliances are not broken when their cost rises; a faction over capacity only cannot set new relations.

Tests

• RelationManagerDiplomaticCostTest: bloc share maths, off by default, negative and zero prestige.
• RelationLoaderWarPickableTest: bloc-scaling is read, defaults to 0, negative clamps to 0.
• Full mvn verify: 2506 tests pass.

🤖 Generated with Claude Code

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: bd07f7ce-8982-452a-bc88-3e51ce9c3698

📥 Commits

Reviewing files that changed from the base of the PR and between 0ea90db and f1b83c4.

📒 Files selected for processing (5)

• src/main/java/net/tfminecraft/simplefactions/diplomacy/RelationType.java
• src/main/java/net/tfminecraft/simplefactions/managers/RelationManager.java
• src/main/resources/diplomacy.yml
• src/test/java/net/tfminecraft/simplefactions/loaders/RelationLoaderWarPickableTest.java
• src/test/java/net/tfminecraft/simplefactions/managers/RelationManagerDiplomaticCostTest.java

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Summary

Summary by CodeRabbit

• New Features
  • Diplomatic costs for alliances now scale with the combined prestige of the factions involved. This scaling can be configured and defaults to off for relation types without a setting.
• Changes
  • The configured alliance cost has been reduced, with prestige-based scaling applied.

Walkthrough

Relation types can configure non-negative bloc scaling. RelationManager applies a prestige-share multiplier to eligible diplomatic costs. The ally configuration sets scaling to 8 and lowers its base cost from 3.5 to 1.5. Tests cover configuration loading and cost calculation edge cases.

Changes

Diplomatic cost scaling

Layer / File(s)	Summary
Scaling configuration and relation type contract src/main/java/net/tfminecraft/simplefactions/diplomacy/RelationType.java, src/main/resources/diplomacy.yml, src/test/java/net/tfminecraft/simplefactions/loaders/RelationLoaderWarPickableTest.java	RelationType reads bloc-scaling, defaults it to 0.0, and clamps negative values to 0.0. The ally cost changes from 3.5 to 1.5, with bloc-scaling: 8. Tests cover configured, negative and missing values.
Bloc-share cost calculation src/main/java/net/tfminecraft/simplefactions/managers/RelationManager.java, src/test/java/net/tfminecraft/simplefactions/managers/RelationManagerDiplomaticCostTest.java	Eligible costs use the multiplier 1 + blocScaling × blocShare(from, to) after the vassalage reduction. Tests cover faction prestige shares, zero scaling, negative prestige and zero total prestige.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~12 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant RelationManager
  participant RelationType
  participant FactionManager
  RelationManager->>RelationType: Get bloc scaling
  RelationManager->>FactionManager: Read factions for prestige totals
  FactionManager-->>RelationManager: Faction prestige values
  RelationManager->>RelationManager: Apply bloc-share multiplier to eligible cost

Loading

Suggested reviewers: ryanbarlow97

Merge Risk: ⚪ Minimal · up to f1b83

This adds an opt-in prestige-based cost modifier, and the default ally cost changes as described in the PR. No merge-blocking risk was found.

Security Architecture Review

Security architecture risk: 🔵 Low · up to f1b83

The change is limited to diplomatic pricing. Pending alliance requests can still be accepted without checking their current capacity cost; this behavior predates the PR, but global prestige scaling adds another way for the cost to change before acceptance. The supported impact is bounded to faction relations and capacity policy.

Retained concerns

• Low · security · inferred: Pending mutual alliances are committed without revalidating current diplomatic capacity. With bloc scaling enabled, unrelated factions’ prestige changes can alter the cost between proposal and acceptance, allowing a relation that the current selection screen would reject. Unchecked acceptance predates this PR; the new global input broadens its repricing exposure rather than introducing a new authorization route.

Security review details

Security Blast Radius

• inferred — Repricing can affect capacity usage across factions with scaling-enabled relations in the same registry. The supported sensitive outcome is a two-party relation being committed despite insufficient current capacity; broader service, credential or infrastructure compromise is not established.

Security Findings and Attack Paths

• inferred — A proposal can pass the initial capacity checks, then become unaffordable as prestige or other capacity usage changes, and still be accepted. Bloc scaling adds unrelated factions’ prestige to this window. Deliberate player manipulation within the timeout was not verified, and the unchecked acceptance mechanism already exists in the base revision.

Trust Boundaries and Controls

• observed — Normal selection checks both parties’ capacity. Requests target an online faction leader, acceptance requires the receiving player to lead a faction and rechecks wartime restrictions, and mutation retains relation-limit, threshold and vassalage checks. These controls constrain the path but do not validate capacity at acceptance.

Hardening Proposals

• proposed — Validate both factions’ current post-transition capacity at the authoritative acceptance or commit boundary, before either relation write. Keep the intentional policy of retaining already-established alliances after later repricing separate from admission of a pending alliance.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

_{Comment @coderabbitai help to get the list of available commands.}