Faction

The central record of the simulation — a named group of players with land, roles, diplomacy, and a power score.

A faction is the unit of political organisation: a named group of players that can hold land, make war, and be inherited into a feudal hierarchy. Everything else in the domain model either belongs to a faction or describes a relation between two of them.

What the record holds

MfFaction is an immutable Kotlin data class. Its fields fall into four groups:

• Identity — an id, a name, an optional chat prefix, and a description.
• People — members, outstanding invites, and pending applications.
• Governance — roles (see Faction Role), defaultPermissionsByName (see Faction Permission), and flags (see Faction Flag).
• Territory — a home position and an autoclaim toggle. Note that the claims themselves are not stored on the faction; see Claimed Chunk.

The version field is not domain data — it exists for Optimistic Locking.

Power is computed, not stored

power and maxPower are computed properties, derived on every read from the members' Player Power and from vassals. Nothing writes a faction's power to the database. This is what makes Faction Power a live quantity that responds to players logging in and dying, rather than a value that has to be recalculated by a scheduled job.

The exception is bonusPower, an operator-granted constant that is stored — and which the faction can decline by turning off the acceptBonusPower flag.

Where it lives at runtime

MfFactionService loads every faction into a ConcurrentHashMap when the plugin starts and serves reads from memory. Writes go through the same service so that they can fire Faction Events and be persisted through the Repository Pattern. Code should never reach past the service to the repository — see Service Layer.

Membership is stored sideways

The members list on the record is a view, not the storage. Membership lives in its own mf_faction_member table, and the repository's "which faction is this player in?" query is a subquery against it.

In memory, though, the service answers that question by scanning every cached faction's member list until one matches. That is fine at the scale these servers run at, and worth knowing before calling it inside a loop over online players.

Note also that the player record itself holds no faction reference — see Player Power. The edge is stored in exactly one place, which is why a player cannot end up in two factions through disagreeing records.

Related

Diplomacy lives entirely outside the faction record in Faction Relationship.