Skip to content

Prevent blown-up vehicles from spawning excess flying components#4967

Merged
Lpsd merged 2 commits into
multitheftauto:masterfrom
Lpsd:blown-veh-sync-fix
Jun 21, 2026
Merged

Prevent blown-up vehicles from spawning excess flying components#4967
Lpsd merged 2 commits into
multitheftauto:masterfrom
Lpsd:blown-veh-sync-fix

Conversation

@Lpsd

@Lpsd Lpsd commented Jun 21, 2026

Copy link
Copy Markdown
Member

Summary

Prevent blown-up vehicles from spawning excess flying components through the damage sync layer, by adding IsBlown guards across all paths that propagate damage state changes.

This is a defense-in-depth fix. The triggering scenario for issue #4916 is resolved at the source by PR #4966 (which prevents blown aircraft from re-entering STATUS_PHYSICS). These sync-layer guards enforce that a destroyed vehicle should never spawn flying components or sync damage, protecting against any future path that might trigger damage on a wreck.

The initial blow damage reaches all clients through PACKET_ID_EXPLOSION or the BLOW_VEHICLE RPC - both call FuckCarCompletely locally on every client; SyncDamageModel is never involved in the initial state, so the IsBlown guard only blocks subsequent re-syncs.

Motivation

Fixes, in combination with #4966, issue #4916.

Without #4966: a blown plane stuck in STATUS_PHYSICS produces GTA-native flying components locally on contact. This PR ensures that even if those damage events occur, they are not propagated to other clients where they would cause additional spawns.

Without this PR: if any code path (a Lua event, a new special property, a GTA edge case) ever triggers panel damage on a blown vehicle, every client receives the sync and spawns a full set of flying components. These guards prevent that class of bug permanently.

Changes:

  • CDeathmatchVehicle::SyncDamageModel: skip the entire sync if the vehicle is blown; no packet is sent
  • Server CGame::Packet_VehicleDamageSync: ignore incoming damage syncs for blown vehicles; do not broadcast
  • CNetAPI::ReadVehiclePartsState: suppress flying component spawns when applying damage to a blown vehicle
  • CPacketHandler (two sites receiving damage syncs): same IsBlown guard on the flyingComponents flag

No bitstream format changes. The guards are purely behavioral.

Test plan

  1. Start a server with vehicle_engine_autostart disabled
  2. Spawn a Dodo, blow it up, walk into the wreckage
  3. Verify no cascading flying components or explosions appear (requires Fix repeated aircraft wreck components when engine autostart is disabled #4966)
    4

Checklist

  • Your code should follow the coding guidelines.
  • Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.

@Lpsd Lpsd changed the title revent blown-up vehicles from spawning excess flying components Prevent blown-up vehicles from spawning excess flying components Jun 21, 2026
@Lpsd Lpsd merged commit f43b1c6 into multitheftauto:master Jun 21, 2026
9 checks passed
Lpsd added a commit to Lpsd/mtasa-blue that referenced this pull request Jun 22, 2026
…titheftauto#4967)

#### Summary
Prevent blown-up vehicles from spawning excess flying components through
the damage sync layer, by adding `IsBlown` guards across all paths that
propagate damage state changes.

This is a defense-in-depth fix. The triggering scenario for issue multitheftauto#4916
is resolved at the source by PR multitheftauto#4966 (which prevents blown aircraft
from re-entering `STATUS_PHYSICS`). These sync-layer guards enforce that
a destroyed vehicle should never spawn flying components or sync damage,
protecting against any future path that might trigger damage on a wreck.

The initial blow damage reaches all clients through
`PACKET_ID_EXPLOSION` or the `BLOW_VEHICLE` RPC - both call
`FuckCarCompletely` locally on every client; `SyncDamageModel` is never
involved in the initial state, so the `IsBlown` guard only blocks
subsequent re-syncs.

#### Motivation
Fixes, in combination with multitheftauto#4966, issue multitheftauto#4916.

Without multitheftauto#4966: a blown plane stuck in `STATUS_PHYSICS` produces
GTA-native flying components locally on contact. This PR ensures that
even if those damage events occur, they are not propagated to other
clients where they would cause additional spawns.

Without this PR: if any code path (a Lua event, a new special property,
a GTA edge case) ever triggers panel damage on a blown vehicle, every
client receives the sync and spawns a full set of flying components.
These guards prevent that class of bug permanently.

Changes:
- `CDeathmatchVehicle::SyncDamageModel`: skip the entire sync if the
vehicle is blown; no packet is sent
- Server `CGame::Packet_VehicleDamageSync`: ignore incoming damage syncs
for blown vehicles; do not broadcast
- `CNetAPI::ReadVehiclePartsState`: suppress flying component spawns
when applying damage to a blown vehicle
- `CPacketHandler` (two sites receiving damage syncs): same `IsBlown`
guard on the `flyingComponents` flag

No bitstream format changes. The guards are purely behavioral.

#### Test plan
1. Start a server with `vehicle_engine_autostart` disabled
2. Spawn a Dodo, blow it up, walk into the wreckage
3. Verify no cascading flying components or explosions appear (requires
multitheftauto#4966)
4
#### Checklist
* [x] Your code should follow the [coding
guidelines](https://wiki.multitheftauto.com/index.php?title=Coding_guidelines).
* [x] Smaller pull requests are easier to review. If your pull request
is beefy, your pull request should be reviewable commit-by-commit.
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