Prevent blown-up vehicles from spawning excess flying components#4967
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Prevent blown-up vehicles from spawning excess flying components through the damage sync layer, by adding
IsBlownguards 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_EXPLOSIONor theBLOW_VEHICLERPC - both callFuckCarCompletelylocally on every client;SyncDamageModelis never involved in the initial state, so theIsBlownguard only blocks subsequent re-syncs.Motivation
Fixes, in combination with #4966, issue #4916.
Without #4966: a blown plane stuck in
STATUS_PHYSICSproduces 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 sentCGame::Packet_VehicleDamageSync: ignore incoming damage syncs for blown vehicles; do not broadcastCNetAPI::ReadVehiclePartsState: suppress flying component spawns when applying damage to a blown vehicleCPacketHandler(two sites receiving damage syncs): sameIsBlownguard on theflyingComponentsflagNo bitstream format changes. The guards are purely behavioral.
Test plan
vehicle_engine_autostartdisabled4
Checklist