Skip to content

Group friendly fire: warn on Harmony conflicts (4/4, part of #277) - #304

Open
Zaldaryon wants to merge 1 commit into
feat/issue-277-group-friendly-firefrom
feat/issue-277-ff-harmony-watchlist
Open

Group friendly fire: warn on Harmony conflicts (4/4, part of #277)#304
Zaldaryon wants to merge 1 commit into
feat/issue-277-group-friendly-firefrom
feat/issue-277-ff-harmony-watchlist

Conversation

@Zaldaryon

Copy link
Copy Markdown
Contributor

Summary

Fourth of four follow-ups to #300, and independent of PRs 1 to 3. Adds a targeted Harmony-conflict warning for the group friendly fire toggle.

Base branch is feat/issue-277-group-friendly-fire (#300). Rebases onto indev after #300.

Change

StratumHarmonyVisibility already logs every mod Harmony patch at boot for triage. This adds WarnFriendlyFireConflicts: when /friendlyfire is off, it walks the patched methods for the ones the toggle depends on (Entity.ReceiveDamage / ShouldReceiveDamage, EntityAgent.OnInteract, EntityBehaviorHealth.OnEntityReceiveDamage, ServerMain.CreateExplosion, ServerSystemEntitySimulation.HandleEntityInteraction, EntityProjectileBase.CanDealDamage / DealDamage / ImpactOnEntity) and logs a warning naming any mod that also patches one.

  • sources/VintagestoryLib/Vintagestory.Server/StratumHarmonyVisibility.cs: the watchlist and the walk.
  • sources/VintagestoryLib/Vintagestory.Server/ServerSystemStratum.cs: calls it from OnBeginRunGame, right after LogPatchedMethods, which is after mod Harmony patching.

It runs regardless of Diagnostics.LogModHarmonyPatches (one short feature warning, not the full dump) and stays silent when the toggle is on or nothing patches those methods.

Why only a warning

There is no Harmony-safe seam. A prefix that returns false and applies damage itself defeats any single check, and no platform solves this (Paper cannot stop a plugin calling LivingEntity.damage() outside the event system either). The friendly fire stack enforces the rule at four independent points across three assemblies to narrow it; this makes the residual risk visible instead of a mystery.

Gates

  • Two-pass build green, 4 pre-existing NU1904.
  • bash scripts/smoke-test.sh: PASS ... 13 console command(s) verified. WarnFriendlyFireConflicts runs at boot with no output (toggle default on, no conflicting mods).
  • scripts/extract-patches.sh: no patch or vanilla-source change (both files are sources/).

Type

  • Bug fix
  • Performance
  • New feature
  • Refactor or cleanup
  • Docs or build

Checklist

  • scripts/extract-patches.sh ran clean (no patch touched).
  • dotnet build VintageStory.slnx -c Release -p:EmbedPatchedFiles=true is green.
  • Every vanilla edit has a // Stratum marker (none in this PR).
  • No vanilla source committed.
  • Tested on a real server start, not just compilation.

Related issues

Part of #277

StratumHarmonyVisibility already logs every mod Harmony patch for
triage. This adds a targeted check: when /friendlyfire is off, walk the
patched methods for the ones the toggle depends on (the damage entry
points, the melee interaction handler, the projectile impact path,
CreateExplosion) and log a warning naming any mod that also patches one.

A mod that replaces one of those and does not call the original can
silently defeat the toggle. Nothing can prevent that, so the goal is
just to make it visible instead of a mystery. Runs regardless of the
Diagnostics.LogModHarmonyPatches flag, since it is one short feature
warning rather than the full patch dump, and stays silent when the
toggle is on or nothing patches those methods.

Part of #277
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant