Files

8.3 KiB
Raw Permalink Blame History

Bounded base gameplay audit: starting kit and casualty recovery

Current implementation update: an independently authored prisoner prefab now specifies its starting inventory; Core observes all-incapacitated survivors and supports explicit administrator abandonment. Separate native prisoner, medical and casualty mechanism fixtures have been added. Their actual evidence and remaining limits are recorded in the companion documents and validation log. The audit below is the original finding record, not a claim that these implementations remain absent.

This source audit covers the first Everon release for up to 12 players. It identifies the next three implementation/acceptance priorities; it does not claim that the ordinary escape route is impossible. No health settings, loadouts, original missions or shared staging were changed by this review. No engine was launched.

1. Establish an explicit successor starting kit

Observed implementation gap; not a reproduced spawn or progression failure. addons/core/Configs/ERR/VanillaFactions.conf:4 selects vanilla Character_US_Unarmed.et. That prefab changes headgear/jacket and the jacket inventory target; it does not clear the inherited pants inventory or equipment slots. Its inheritance is:

  • {2F912ED6E399FF47}Prefabs/Characters/Factions/BLUFOR/US_Army/Character_US_Unarmed.et
  • {284E735C6C70DAD2}Prefabs/Characters/Factions/BLUFOR/US_Army/Character_US_BaseLoadout.et
  • {836E7E39AAC5888B}Prefabs/Characters/Factions/BLUFOR/US_Army/Character_US_Base.et
  • {37578B1666981FCE}Prefabs/Characters/Core/Character_Base.et

Installed vanilla Character_US_BaseLoadout.et:4–16 authors binoculars and a watch. Its InitialInventoryItems at lines 39–53 authors a handheld radio, compass, map, two dressings, tourniquet, morphine, E-tool, two flares and flashlight. Read-only unpacked evidence is available under /tmp/erri-vanilla/Prefabs/Characters/Factions/BLUFOR/US_Army/. The unarmed child keeps the pants contents and changes the jacket target to its rolled-up jacket. Actual inventory initialization/capacity and the exact retained runtime item count still need a native inventory assertion.

Thus “unarmed” currently means no weapon, not stripped prisoner equipment. Maps/binoculars and medical supplies cannot be balanced solely by reading the successor's site stock. Author a successor prisoner prefab that explicitly retains or clears each intended inherited slot/item; preserve vanilla character health and interaction components. Then assert actual starting inventory, compatible magazine capacity, clue pickup and finite stock across a representative 12-character setup before manual testing.

EveronSites.conf:14–17 stocks five PM pistols, eight magazines and one map in the prison. Five pistols for 12 players is not established as a defect: seven initially unarmed prisoners may be intentional. The two subsequent caches contain eight plus four AK-74s. Decide the desired scarcity explicitly and test the first guarded escape at that loadout; do not automatically increase weapons or remove inherited medical supplies based on this audit.

2. Prove treatment and casualty loading through real vanilla interactions

Acceptance gap; no broken medical item or missing character component was demonstrated. EveronSites.conf:82–97 provides a hidden medical stash with 12 dressings, six saline bags and six morphine injections. Its position is 6340/7400, discovery radius 25m, and RevealOnEscape is 0. The visible clue caches provide dressings, but neither provides saline or a medical-stash clue. Finding the advanced stash therefore currently depends on approaching it; that is a route/discovery decision, not evidence of an impossible route.

The current native base fixture restores consciousness directly with CharacterControllerComponent.SetUnconscious(false) (ERR_NativeBaseSmoke.c:389). The extraction fixture boards conscious actors using native GetInVehicle (ERR_NativeExtractionProbe.c:78), then makes a passenger unconscious while already aboard (:120). These tests establish mission handling of consciousness and occupied seats. They do not establish treating real blood loss, consuming medicine, transferring an injured player from ground to a seat, or remaining aboard during treatment and flight.

Relevant installed sources are scripts/Game/Components/Damage/SCR_CharacterDamageManagerComponent.c, scripts/Game/Components/Gadgets/SCR_ConsumableSalineBag.c, and Prefabs/Items/Medicine/SalineBag_01/SalineBag_01_base.et. The saline effect checks damaged blood, target saline-storage availability and occupied treatment slots; ApplyEffect moves the real bag into the treatment slot. The concrete bag's inherited configuration applies a 1500-unit restoration over 90 seconds after a 10-second action. These resources were inspected directly from the installed addons/data/data*.pak archives; no original Escapists medical implementation was reused.

Next scope: a native wounded-character fixture using actual stock and vanilla treatment APIs, followed by manual action/animation checks. Verify bleeding control, tourniquet application/removal, saline consumption/effect completion, morphine, regained consciousness without directly toggling it, drag/carry/load of an unconscious casualty, and release of treatment/seat state after interruption. Keep finite supply depletion and failure cases. Only then decide whether the hidden medical site needs a clue or earlier saline availability.

3. Design an outcome when every survivor is incapacitated

Concrete unhandled policy branch; a persistent native hang has not been reproduced. ERR_PlayerRoster.c:80–86 reports any living used-life actor as a survivor. ERR_GameMode.c:320–330 starts the 30-second defeat grace only when that method returns false. Therefore an entire living but incapacitated group does not enter the defeat grace. This correctly preserves a recoverable unconscious player, including reconnect reservations, but does not distinguish a whole group that cannot recover or help one another.

Installed scripts/Game/GameMode/Misc/SCR_GameModeHealthSettings.c defaults m_bKillIndefinitelyUnconsciousPlayers to false and permits unconsciousness. The successor inherits the empty health-settings component in vanilla Prefabs/MP/Modes/GameMode_Base.et without overriding that policy (addons/core/Prefabs/ERR/GameMode.et). Installed SCR_CharacterDamageManagerComponent.c:789–819 explicitly distinguishes indefinite unconsciousness, including blood below the unconsciousness threshold. A test that simply restores consciousness after 35 seconds does not exercise this state.

Choose and test a recovery policy before changing code. Concrete options are:

  1. Preserve vanilla recovery indefinitely, but provide a clear shared “no conscious rescuers” state and an explicit round-abandonment/restart path. Define who may invoke it and how reconnecting rescuers affect it.
  2. Add a separate all-incapacitated grace, longer than the supported treatment/recovery window, that resets when someone becomes conscious. Defeat must wait for the chosen grace and account for reserved actors, ongoing treatment and possible recovery; do not replace Alive with CanFight in the existing defeat check.
  3. Offer an explicit voluntary give-up decision while retaining recoverable unconsciousness. This requires its own player-facing authorization/confirmation design and must not silently consume another life or kill a recoverable teammate.

Reproduce an actual low-blood incapacitation case with damage enabled before selecting thresholds. Test one recoverable casualty with a rescuer, a recovering all-unconscious group, an unrecoverable group, interrupted treatment, reconnecting rescuers and extraction with unconscious passengers. This is deliberately separate from the already-tested 35-second unconscious survivor protection and from multiplayer transport validation.

Scope limits

No confirmed shortage of core medical components or incompatible medicine was found from the inspected inheritance. Runtime inventory, normal user actions, medical animations, medical balance and physical casualty loading remain unproven. The supported 12-player limit is a release target, not proof that five starting weapons are wrong. Original feature parity, manual flight/navigation, multiplayer and measured performance remain tracked elsewhere.