You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two ways to break prop_physics entities with ent_fire command:
break
sethealth 0
Break input breaks all prop_physics in the map. SetHealth 0 breaks only those prop_physics which can be broken with weapons or gravity.
But using both methods results in prop_physics entities simply disappearing when they are all broken at once, no gibs are produced. For example with this command: ent_fire prop_physics sethealth 0
In opposite, if first parameter contains a target name or !picker, gibs are produced giving effect that object was actually broken.
Steps to reproduce
Steps to reproduce the behavior:
Load a map and find breakable prop_physics entities. Beginning of d2_coast_01 is good example.
Launch ent_fire prop_physics sethealth 0
prop_physics simply disappear.
Restart the map.
Now face one specific physics prop and launch ent_fire !picker sethealth 0
prop_physics now breaks producing gibs.
Expected behavior
When using these commands, prop_physics entities break producing gibs as if broken by a weapon or gravity.
The text was updated successfully, but these errors were encountered:
Oooh, this is a very interesting situation. I think this is working as it should. Gibs don't have their own entity, they are simply themselves prop_physics with a spawnflag set to indicate that they're a gib. When entity I/O is executed, it scans through all the entities in the map, checks if they match the name, runs the input code, then continues to the next entity.
So what is happening here is that for each prop in the map, it gets broken, spawning gibs. Those gibs are then added to the end of the entity list. But the IO code is still processing entities, so it keeps going, finds the newly spawned gibs, and promptly fires Break/SetHealth at the gibs too. So they also break, just vanishing.
You can see this pretty clearly if you first do ent_fire prop_physics addoutput "targetname orig_props", so all the existing props get a name. Running the break command with developer 2 on, you'll see all the unnamed gibs receiving the input.
I'm thinking your actual intention is to break all non-gib props, right? I think you'd need to use VScript to check for the spawnflag (SF_PHYSPROP_IS_GIB = 0x400000). Maybe we should have filter_activator_flags, then you could use point_advanced_finder.
This actually game me an idea how to actually break all physics props and produce gibs. prop_physics actually break when you launch this command afterwards: ent_fire orig_props sethealth 0.
I'm not a modder and I know very little about C++. Instead I am making a .cfg script that breaks everything in the map when executed so this was a major problem. But now it's fixed. Nevertheless, I would still like this issue from Half-Life 2 to be fixed here in Mapbase.
Describe the bug
This is a Half-Life 2 bug.
There are two ways to break prop_physics entities with ent_fire command:
Break
input breaks all prop_physics in the map.SetHealth 0
breaks only those prop_physics which can be broken with weapons or gravity.But using both methods results in prop_physics entities simply disappearing when they are all broken at once, no gibs are produced. For example with this command:
ent_fire prop_physics sethealth 0
In opposite, if first parameter contains a target name or
!picker
, gibs are produced giving effect that object was actually broken.Steps to reproduce
Steps to reproduce the behavior:
Load a map and find breakable prop_physics entities. Beginning of d2_coast_01 is good example.
Launch
ent_fire prop_physics sethealth 0
prop_physics simply disappear.
Restart the map.
Now face one specific physics prop and launch
ent_fire !picker sethealth 0
prop_physics now breaks producing gibs.
Expected behavior
When using these commands, prop_physics entities break producing gibs as if broken by a weapon or gravity.
The text was updated successfully, but these errors were encountered: