Quote from Rockroot on February 17, 2012, 6:06 pm

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
[spoiler]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.

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?)

3. Why did they use a func_brush, not a func_detail? Is the func_brush not messing with the visual leafs?[/spoiler]

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)

[spoiler]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.[/spoiler]

Hope this helped, see ya around.

Quote from CamBen on February 17, 2012, 7:44 pm

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.

Quote from Rockroot on February 17, 2012, 11:26 pm

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.

Quote from Jexim on February 18, 2012, 4:24 am

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

Quote from Lpfreaky90 on February 18, 2012, 6:40 am

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

Quote from portal2companioncube on February 18, 2012, 5:48 pm

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.

Quote from CamBen on February 18, 2012, 6:15 pm

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.

Quote from ChickenMobile on February 19, 2012, 12:58 am

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.

Quote from portal2companioncube on February 19, 2012, 9:24 pm

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?