How do make a lift in a Portal 2 map like the two in sp_a4_laser_catapult? I'm trying to make a map with a lift that takes you to several different chambers on several different floors.
Thanks!

Hey there,

I am desperate to help, but you might want to be more specific in matters of what is actually your problem.

I assume that you do not mean the maps elavators for entrance and exit, but the two platforms you need to reach the upper floor.

As you could have made out by yourself, I figured that it is a prop_dynamic parented to a func_door, which opens under specific circumstances (in the maps case several logic_relay's and logic_branch_listener's).

The func_door is not visible ('nodraw'-textures) and acts like a dummy (you could place it anywhere it's not in the way, or give it a texture and a shape so it makes sense).

You will also need a func_brush (with 'nodraw'-textures) so you do not fall right through your visible prop_dynamic. It is parented to the func_door as well.

For the lifts piston they used a prop_dynamic as well (parented to the func_door) and another prop_dynamic for the idle part of the piston.

List of prop_dynamic - models used:
The lift: models/anim_wp/arm_interior_192/arm_interior_128_paneltop.mdl
(inner) piston: models/props_bts/straight_piston_tip.mdl
(idle) piston: models/props_bts/straight_piston_base.mdl

Question by me for more experienced developers than me
||1. They used a trigger_push -box right above the panel. I assumed to limit the risks of getting stuck in the func_brush. But the push-direction is set to 0 90 0, which is not UP (-90 0 0) with a pretty great speed of 100.
Then I saw the Flag on Physics Objects.
I don't get why this is even there.

1. The trigger_push is parented to the func_brush which itself is parented to the func_door. I dont get why they don't parent it right to the func_door in the first place?)

2. Why did they use a func_brush, not a func_detail? Is the func_brush not messing with the visual leafs?||

In Short:
1. func_door (open und circumstances of your liking)
2. prop_dynamic 's (for the visual apperance of the lift, parented to the func_door)
3. func_brush ('nodraw'-texture, flagged 'Solid', parented to the func_door, placed right atop of the lift)

To be honest, I didn't know wether to awnser, 'cause it sounded a bit like a troll (no offence, dude). You could have figured this out all by yourself by using the forums search-tool or opening the map in the editor.
On the other hand I just could have explained something you already know, in which case you should describe your problem more accuratly.
Anyway, t'was fun.

Hope this helped, see ya around.

You could always use a lift model as a prop dynamic, place 1 linked pathtrack entities for each elevator stop, and link it to the next stop. repeat the process for all the floors and have it stop at the different pathtracks by figuring out the time it takes to reach the next stop. take that time and make a trigger for it. on the trigger, set the speed to 0. then, on re-trigger, set the speed to whatever you have it as. repeat the steps for all the floors.

much more roundabout than the above post, but if you get it, it works like a charm.

I agree, i like your method even more.

I'd suggest you just use the "OnPass"-Output on each path_track you use to stop the lift, rather than experimenting with timing. This way the lift shouldn't act strange if you use it to often.

I actually spent quite a few hours last night reverse engineering the lifts in that levels and finally (after quite a bit of asprin) figured out how they worked and why they had so much going on, it's a very convaluted system that Rockroot covered most of in his first post. It uses a neat system of Logic_branches to determine starting and stoping of the multiple doors involved in a multistop elevator.

In short the easiest way to do it, would be to have a separate func_door for each "floor" that your elevator is going to be moving between, parent them from top to bottom (aka, the highest one is parented to the next lowest one, then that one is parented to the one below it, so on so forth) have them all set to start open (and stay open) then have your triggers set up to operate the individual doors, the others will follow suit (because of parenting)

Also make sure that "touch to open" isn't checked in the flags, I had a headache with that till someone helped me out.

this might have been a bit of a confusing post, but if you need anymore help or want an example I could probably mock up an example vmf pretty quick. just ask

1. They used a trigger_push -box right above the panel. I assumed to limit the risks of getting stuck in the func_brush. But the push-direction is set to 0 90 0, which is not UP (-90 0 0) with a pretty great speed of 100.
   Then I saw the Flag on Physics Objects.
   I don't get why this is even there.
   I THINK that this is to remove objects that are blocking the panel, the 0 90 0 direction will push the cube away from the platform, thereby removing the problem.

2. The trigger_push is parented to the func_brush which itself is parented to the func_door. I dont get why they don't parent it right to the func_door in the first place?)
   I think this is just a mapping style. If you wanted to move the elevator itself for example this is a better way, because then you can set a different parent for the func_brush and still move the entire thing. Without changing the parent of the trigger_push. But if you don't want to do something like this you might as well just parent it to the func_door indeed

3. Why did they use a func_brush, not a func_detail? Is the func_brush not messing with the visual leafs?
   because a func_brush can have a parent and a func_detail cannot

CamBen wrote:
You could always use a lift model as a prop dynamic, place 1 linked pathtrack entities for each elevator stop, and link it to the next stop. repeat the process for all the floors and have it stop at the different pathtracks by figuring out the time it takes to reach the next stop. take that time and make a trigger for it. on the trigger, set the speed to 0. then, on re-trigger, set the speed to whatever you have it as. repeat the steps for all the floors.

much more roundabout than the above post, but if you get it, it works like a charm.

Could you explain that with a little more detail? How do you tell the path_track what you want to use as the train? I don't quite understand everything you're saying.

Basically you just need to make a prop dynamic for the lift, and make the parent be the name of the func tracktrain. The func tracktrain should have an option for first stop point. Make it be the name of the first pathtrack, on the groundfloor. The groundfloor pathtrack should have an option for next stop target. Set this to the second floor. That is basically how it would work.

CamBen wrote:
Basically you just need to make a prop dynamic for the lift, and make the parent be the name of the func tracktrain. The func tracktrain should have an option for first stop point. Make it be the name of the first pathtrack, on the groundfloor. The groundfloor pathtrack should have an option for next stop target. Set this to the second floor.
That is basically how it would work.

Tracktrains are definitely the way to go here. Appropriate sounds etc. can also be played when the lift 'passes' the tracktrain. If you want to press a button to enable the player to go to different levels: add the output so the train moves to the appropriate track.

Hopefully this will be my last question on this topic:
If I want the lift to go to a specific path_track, what should I use as the output?

MoveToPathNode also good page to look at: linkToVDChere

chickenmobile: Thanks a lot!
One more thing:
I compiled the map to try it out. When you first walk in the lift is a floor below you. There's a button on your right to make it come up to your level. When I pushed it, the lift came up, but instead of being horizontal so you can actually walk on it, it was vertical and pushed up against the wall. In Hammer I have it horizontal. For some reason it flipped it. I attached the vmf and the bsp so you can see what's happening. Anyone know what happened or how to fix it?
Note: attachments removed so they aren't always available from this post

Just change the settings in the func_tracktrain so then it has a "Fixed Orientation" inside the flags tab (it won't flip them then)

Also it would probably be easier if you parented the buttons to move the lift on the tracktrain and use logic such as a math_counter with a logic_case in order to decide which level the lift should stop at.

sp_lift.vmf

chickenmobile wrote:
Just change the settings in the func_tracktrain so then it has a "Fixed Orientation" inside the flags tab (it won't flip them then)

Also it would probably be easier if you parented the buttons to move the lift on the tracktrain and use logic such as a math_counter with a logic_case in order to decide which level the lift should stop at.

sp_lift.vmf

Thanks a lot!
One thing still isn't working, though. The lift still shifts over a unit or two. Checking the "fixed orientation" flag made it horizontal like it should be, but it still isn't lined up with the shaft. Also, for some reason it wouldn't go down when I went up to the top level and back down to the middle one (where you start the level). I went up, and back down, and then it would only let me go between those two levels. It wouldn't go down to the bottom one. To try and fix this, I put in the following output on the path_tracks:

My Output: OnPass
Target Entities: lift_levelCounter
Input: SetValue
Parameter Override: [1 for the bottom level; 2 for the middle level; 3 for the top level]

I compiled and tested. When I pushed the first button to make the lift come up, it came up, but right before it stopped at the middle level, my computer locked up. I had to open the task manager to close Portal 2. I tried again and the same thing happened. Do you know how to fix this?

When I tested it, it worked perfectly. I could press the buttons to go up and down. You SHOULD NOT put any outputs that use 'OnPass' that will set the value of the counter or change where the lift will go to. There is a good chance that the lift went into an endless cycle and tried to move the same point when it passes the track it as just at. THAT'S WHY IT CRASHED. I have a picture here if you need a clearer explanation.

If you do not want the lift to move when you multiple press the call lift button, lock the calling button 'OnPass' for the same level's track and enable it again once you press one of the two buttons for raising and lowering the lift.

I realised that for the call button it was incorrect as setting the lift's position will not change the counter's value. Therefore you need to change the counter's value to set the position of the lift.

sp_lift.vmf