mp_coop_wall_5 - Hard light bridge manufacturing
Quote from Moth on September 18, 2011, 5:51 pmI want to re-create the assembly line of hard light bridges from mp_coop_wall_5. I've got the original VMF, but rather than do an ugly copy,paste and fix, I want some help actually understanding the logic and application.
From what I can see, Valve have used a template spawner to spawn a light bridge prop. This template spawn is parented to an invisible tracktrain. What I don't understand is how the prop is spawned, enabled, disabled, then destroyed and replaced with a dummy light bridge prop (named dummy_prop)
Presumably there's some kind of trigger that calls @activator kill to remove the prop when it reaches the end of the 'conveyor' ?
Copying and pasting will teach me nothing, and I'm in over my head on logic entities, I'm still new to Hammer, though I'm reading all the tutorials I can find. Guys, I need your help to bring life to my current WIP project.
I want to re-create the assembly line of hard light bridges from mp_coop_wall_5. I've got the original VMF, but rather than do an ugly copy,paste and fix, I want some help actually understanding the logic and application.
From what I can see, Valve have used a template spawner to spawn a light bridge prop. This template spawn is parented to an invisible tracktrain. What I don't understand is how the prop is spawned, enabled, disabled, then destroyed and replaced with a dummy light bridge prop (named dummy_prop)
Presumably there's some kind of trigger that calls @activator kill to remove the prop when it reaches the end of the 'conveyor' ?
Copying and pasting will teach me nothing, and I'm in over my head on logic entities, I'm still new to Hammer, though I'm reading all the tutorials I can find. Guys, I need your help to bring life to my current WIP project.

"Such monstrous sucking-constructions aren't built within one afternoon"
Quote from Skotty on September 18, 2011, 6:08 pm!activator kill
The name "!actvator" everytimes sends the output to the entitiy that sent a input. For example:
You as player walk into a trigger_once with the output "OnTrigger !activator kill", then you will be the activator (because you activated the trigger) and you get removed.
If you throw a prop_physics into the trigger, it will get removed because it activated the trigger.
For other variable names like !activator see here: http://developer.valvesoftware.com/wiki ... r#Keywords
!activator kill
The name "!actvator" everytimes sends the output to the entitiy that sent a input. For example:
You as player walk into a trigger_once with the output "OnTrigger !activator kill", then you will be the activator (because you activated the trigger) and you get removed.
If you throw a prop_physics into the trigger, it will get removed because it activated the trigger.
For other variable names like !activator see here: http://developer.valvesoftware.com/wiki ... r#Keywords
Quote from Moth on September 18, 2011, 6:17 pmThanks for the correction. I understand now, the mover is the activator of the trigger, so it is removed from the world. Then they are spawning a new one at the bottom of the track.
However, my problem is understanding how the bridge prop is spawned, moved to a central path on the track, then dissapear and replaced with an enabled bridge prop for a few seconds, then turns off and converts into a dummy mover along the path and out of sight.
Thanks for the correction. I understand now, the mover is the activator of the trigger, so it is removed from the world. Then they are spawning a new one at the bottom of the track.
However, my problem is understanding how the bridge prop is spawned, moved to a central path on the track, then dissapear and replaced with an enabled bridge prop for a few seconds, then turns off and converts into a dummy mover along the path and out of sight.

"Such monstrous sucking-constructions aren't built within one afternoon"
Quote from ChickenMobile on September 18, 2011, 10:41 pmif the dummy prop they are using is a prop_dynamic, the input 'enable' and 'disable' are used to make it visible and invisible, or even remove it altogether.
The prop is probably parented to some sort of func_tracktrain which moves along a path of path_tracks, which are spawned together by the same point_template. Once the func_tracktrain reaches the path_track where the lightbridge stops, it uses the 'onPass', -> '!activator' -> 'DoThis' output to disable the prop and enable the real light bridge.
Check the outputs in each of the path_tracks to see if this is the case.Please note I am just guessing, however I didn't totally read your top post till now and realised I got it mostly right.
if the dummy prop they are using is a prop_dynamic, the input 'enable' and 'disable' are used to make it visible and invisible, or even remove it altogether.
The prop is probably parented to some sort of func_tracktrain which moves along a path of path_tracks, which are spawned together by the same point_template. Once the func_tracktrain reaches the path_track where the lightbridge stops, it uses the 'onPass', -> '!activator' -> 'DoThis' output to disable the prop and enable the real light bridge.
Check the outputs in each of the path_tracks to see if this is the case.
Please note I am just guessing, however I didn't totally read your top post till now and realised I got it mostly right.
