InterestChain

Remarks

[16](../../../docs/plan/16-networking.md) asks for composable resolvers "in evaluation order: scene scope → explicit visibility overrides → distance grid → LOD rate reduction", and this is the first three of those. The fourth is deliberately not here, and the reason is worth stating because implementing the sentence as written produces a bug that looks like the feature working.

Rate reduction is not an interest decision. Leaving an object out of the observed set does not mean "skip it this tick" — ReplicationServer treats an object that has left the set as one the client should drop, because leaving interest and being destroyed are deliberately the same mechanism. So an LOD written as a rule would despawn and respawn every distant object on every tick it skipped. Rate belongs to the record writer, where skipping is already what the bandwidth budget does; see IReplicationRate.

The fallback is Observed, so a chain with no rules is the behaviour a new project already had. Adding a rule can then only ever hide things, which is the direction in which mistakes are visible: an object that should not be there is noticed, and one that silently is not is debugged.

Fields and properties (5)

• public IList<IInterestRule> Rules

  The rules, asked in order until one has an opinion.

• public IInterestSource Source

  Where candidates come from. Every networked entity, unless replaced.

• public Interest Fallback

  What to do about an object no rule had an opinion on.

• public int ConsideredCount

  How many candidates the last resolve considered.

• public int HiddenCount

  How many of them were hidden.

Methods (2)

• public void Resolve(World world, PlayerId player, List<Entity> observed)

  Fills with what this player should be told about.

• public Interest Decide(World world, PlayerId player, Entity entity)

  What the chain says about one object, for a test or a diagnostic.

Used by (2)

• InterestTestsVixen.Net.Tests
• NetworkSpawnTestsVixen.Net.Engine.Tests