Multi level elevators? NEEDS TEST

[Plague Bringer]

Is it possible (I haven't touched GTK Radiant for months, much less messed around with func_trains)? I know it'd be a pain to make it look good as the three buttons would (realistically) be in roughly the same area (causing you to hit all of them with a swipe or walking in to them. D:)

edit
THIS IS RELEVANT:

Speaking of buttons, Urban Terror has (or had) a button feature for lifts that would bring up a dialogue window with a list of floors on it with corresponding numbers. When a number key was pressed, the lift would activate and move the player to that floor.

Is this clever use of scripts, or coded into the game engine?

[Amanieu]

game engine

[God, maker of the world]

A multilevel lift could theoretically be done with a func_train. I've just read in an old post, that every Tremulous mover triggers its targets when it reaches a final state (just set a target, ignoring that radiant doesn't tell you about this possibility) / that the func_train triggers its next path_corner when it has just reached the previous one.

Since trains can be started and stopped, this could theoretically be used (via an intermediary trigger_multiple or target_relay) to make the train stop itself once it reaches the next target.

This, in turn, could theoretically be used to make a lift (out of func_train) that moves from floor to floor on every button push.

[MrFish]

It is possible. Also, don't use trigger_multiple because it doesn't work on korx for whatever reason. Instead use target or target_delay

[Plague Bringer]

Fish, has it been done?

(You guys are both so clever.)

[MrFish]

I've done something similar, and yes, it's possible.


This button starts and stops 3 particle systems and a door (1 p-system and the door is not showing). I've also got a func_train on another map that moves around the map and stops back at the original spot.



Edit: You guys know this is over a year old? XD

[Plague Bringer]

Yeah man, I'm OP.

[A Spork]

If someone could make some fairly simple instructions on how to get an elevator working with three floors you'd be my bestest friend forever

[MrFish]

Doesn't this explain it? Make a relay with the same targetname as the path_corner. When the train targets the path_corner it will also target the relay which will in-turn target the train and stop it. When The train moves to the next path_corner it will target the next "stopper" and wait until it's re-enabled by a button somewhere. It will have to move all the way up before it can move back down. If you want it to move up or down relative to the level that was pressed (like a real elevator) then it begins to get really damn complicated. Possible but I'm not going to **** up my own mind trying to figure that one out.

[UniqPhoeniX]

It's not possible to have a func_train go either up or down depending on which button you pressed, it's going to follow a certain linear path no matter what. It is however possible to make 1 button make the func_train go to the next path_corner and stop there, then open the doors, and other button make it go full circle to the previous path_corner. Making it look good is tough tho.

[MrFish]

It's not possible to have a func_train go either up or down depending on which button you pressed, it's going to follow a certain linear path no matter what. It is however possible to make 1 button make the func_train go to the next path_corner and stop there, then open the doors, and other button make it go full circle to the previous path_corner. Making it look good is tough tho.

I believe it could be done but you would need several trains, invisible platforms, and AMP.

[UniqPhoeniX]

That actually gave me an idea You could have a fake elevator behind each door made of 2+ pieces that are moved out of the way when a button is pressed, and replaced with elevators all going up or down by 1 level depending on which button was pressed, and at reaching destination those are again replaced by the fake elevators. Now about having the right doors open and close at the right time, and making it not fail when someone gets squished...

[MrFish]

Oh man! I didn't want to think about it!

[A Spork]

It's not possible to have a func_train go either up or down depending on which button you pressed, it's going to follow a certain linear path no matter what. It is however possible to make 1 button make the func_train go to the next path_corner and stop there, then open the doors, and other button make it go full circle to the previous path_corner. Making it look good is tough tho.

curses....I was hoping to make it so I had 2 buttons, one to go up, and one to go down....

[Draeke]

Easiest way to get multi-floor lifts is to use GMOTW/MrFish's method. The only downside is that the player may see the lift going all the way to the start before it goes to the destination floor.

Alternatively you can do it a harder way.
----------
*Doesn't work.
Description:
Multi-floor lift system that allows players to go up and/or down one floor from their current one. The main idea is that the system uses separate trains for up/down travel for each floor.

Pros:
- Can be extended to allow players to choose which floor they want.
- Provides players fluid travel (no go back to the start stuff).

Cons:
- Players must exit the lift once reaching the desired floor.
- Players can only go up/down one floor at a time.
- Lifts must have unobstructed entrances.
- Lifts must be playerclipped in all directions besides the entrance.
- Lifts and surrounding area must be wide otherwise blocking may occur.
- Unrealistic unless you provide a reason why the lift evicts/kills you.
- Abusable if players deliberately block the area between lift doors.
- Requires much more entities compared to a two-level lift system (27 per lift button, 9 per floor, 3 shared). A 3 floor system requires 138 entities, while 4 floors require 174.
- System breaks if two buttons are activated at the same time (shouldn't happen unless done deliberately?).

Floor 1 Up Button - Diagram:

The others buttons are setup in a similar fashion.

Helpers:


floor1up - Button that players press to go up from floor 1
door1 - Prevents players from entering the shaft when lifts are moving.
door1b - Acts like door1.
train1up - The lift that goes up from floor 1.
push2 - Pushes the player out of train1up when it reaches floor 2.
kill - Kills the player if they are still standing in any lift after it has reached its destination for some time.
door2 - Same as door1.
door2b - The area between door2 and door2b acts as a safe zone for players just exiting the lift.
shield - Blocks use of buttons until a lift has finished its cycle.
block - Blocks players from moving into a safe zone that someone has just exited.

[MrFish]

Bravo! A clever system but I think there is a flaw in your algorithm. With only 3 path corners the train never leaves the elevator shaft to make room for any other elevators directly above or below it. This would crush any user moving to another floor. Also, you would need the middle elevator to switch out with another if the user decides to move in the other direction. If anyone could pull this elevator off the whole map could just be a level field with the elevator in the middle. People would be fighting to use it.

I think with netradiants current arsenal the cost to make one of these would far exceed the benefit. By the way, what did you use to make that flowchart? It looks similar to netradiant but I don't think it is.

[Draeke]

Thanks.

Ah that's what I forgot to mention. The first path corner sits in an idle area outside of the lift shaft, the 2nd sits at the entry position and the 3rd sits at the exit position (this is the same for every lift). So in effect the shaft is always empty until someone pushes a lift button (train: idle -> entry -> exit -> idle). Since lifts always return to their idle position, any players staying inside would end up falling into the shaft or squished which is why players get pushed out and eventually deliberately killed if they stay inside the lift for too long.
The lift shaft is never visible to players until someone pushes a lift button.

The flowgraph was done with a personal Game Maker program.

[God, maker of the world]

[...]So in effect the shaft is always empty until someone pushes a lift button (train: idle -> entry -> exit -> idle). Since lifts always return to their idle position, any players staying inside would end up falling into the shaft or squished which is why players get pushed out and eventually deliberately killed if they stay inside the lift for too long.[...]

Honestly, I haven't really tried to figure out precisely how you do it. But couldn't you kinda just make the lift stop itself at the target floor, and when the player exits, a door is triggered, also the lift goes to its next position (which is outside the shaft)?

[UniqPhoeniX]

IIRC doors don't return to their original position if triggered twice, they just reset their wait time. There is a way to change that with AMP tho.
You could use keys target2 to target4 and targetname2 to targetname4 instead of all the relays... tho I don't remember if those keys require AMP, haven't mapped for a while.
I think it's possible to implement my idea and make a perfectly working elevator without having to push anyone out or risk killing them (unless someone hops on another player).

[Draeke]

@GMOTW: Doesn't seem to work because you'll have to avoid 2 things: the player dying/disconnecting in the lift and stuff getting triggered twice if you decide to compensate for this.

@UniqPhoeniX: Yeah that was one of the many errors I discovered after I built the floor 1 up system in radiant. Other errors include inconsistent func_train activation, func_train/path_corner bugs, and trying to toggle trigger_hurt/trigger_multiple. There's probably also some bugs I haven't discovered yet. I really should've tested the individual parts of the system before making the flowgraph.

That's a good relay/delay tip, cheers.

In your idea, doesn't the player still have to leave the shaft before another lift is used (possible squish)?

[God, maker of the world]

I really should've [...]

Thank you for that.

[UniqPhoeniX]

...
That's a good relay/delay tip, cheers.

In your idea, doesn't the player still have to leave the shaft before another lift is used (possible squish)?

Wait, do those keys work without AMP then? I really don't remember anymore
And no, the player would not have to leave the elevator. When you first activate it, the fake elevator is surrounded by the up or down elevator which comes from directly behind and is 1 gu higher so it doesn't touch the player before it is in place, then the fake top and bottom pieces are moved out of the way (first up/down a little, then to the side), and at destination it's switched again, with the up/down elevator moving directly backwards. The fake elevator stays in place until the next activation. However this does require doors to be open only at 1 floor at a time, but it can be done.

[Draeke]

I see how that works now, very nice. The only flaw I can see is the single floor access, which also opens up the possibility to deny lift access to all floors by camping whichever the lift is on. Otherwise that's a pretty robust system.

I interpreted your tip as taking out target_relays/delays that have targets common to each other (targeting the func_train for example). I've re-read your tip, and the entity below doesn't work in vanilla Trem (test1 and 2 being func_doors).

Code: [Select]

{
"classname" "target_relay"
"origin" "1 2 3"
"target" "test1 to test2"
"targetname" "testrelay"
}

[UniqPhoeniX]

Uhh it was meant as: target = door1, target2 = door2, etc, and for example func_train can have targetname2 = door1 so it gets triggered whenever door1 does, which also allows using less relays (since you only get up to 4 target keys).

[Draeke]

Ah well, I can optimise later.

This is what I've got so far that works:
MAP - http://pastebin.com/xU37xB9C
PK3 - http://www.filefactory.com/file/b2a68ed/n/map-multilevel8.pk3

Does the lift work correctly for everyone?

[UniqPhoeniX]

Works, but still a long way to go... Add a fourth corner to the train path, directly behind the 2nd floor. I recommend making the whole structure smaller, and OPEN, so it can be observed from the side, possibly with damageable buttons so you can shoot it from wherever and then see what happens.

The only flaw I can see is the single floor access, which also opens up the possibility to deny lift access to all floors by camping whichever the lift is on. Otherwise that's a pretty robust system.

The buttons can be on each floor tho, and also inside the elevator (fake button brush as part of elevator, and invisible brushes where the button will be at each floor would be the actual func_button).

[Draeke]

Add a fourth corner to the train path, directly behind the 2nd floor.

Wait..why?

I recommend making the whole structure smaller, and OPEN, so it can be observed from the side, possibly with damageable buttons so you can shoot it from wherever and then see what happens.

I use r_showtris 1 and noclip for tests.

The buttons can be on each floor tho, and also inside the elevator (fake button brush as part of elevator, and invisible brushes where the button will be at each floor would be the actual func_button).

I guess you could give multi-floor access by ferrying players up/down through multiple lift changes. You'd have to keep track of the lift position in some way though (unless you evict players).
----------
Here's the previous system upgraded to support 3 floors:
MAP - http://pastebin.com/MjjT8fJJ
PK3 - http://www.filefactory.com/file/b2adfdg/n/map-multilevel10.pk3

And the graph thing:

[UniqPhoeniX]

Add a fourth corner to the train path, directly behind the 2nd floor.

Wait..why?

So you don't have to push players out when you replace the up/down elevator with the fake one, it will be moving directly backwards and not intersecting the space players are in.

I recommend making the whole structure smaller, and OPEN, so it can be observed from the side, possibly with damageable buttons so you can shoot it from wherever and then see what happens.

I use r_showtris 1 and noclip for tests.

IMO it's easier to see what's happening when you have more then wireframe.

Here's the previous system upgraded to support 3 floors:
MAP - http://pastebin.com/MjjT8fJJ
PK3 - http://www.filefactory.com/file/b2adfdg/n/map-multilevel10.pk3

And the graph thing:
[ img]http://img806.imageshack.us/img806/3316/multilevel10.th.png[/img]

Oh wow, that is messy
First of all, you need only 1 up and 1 down elevator if you can keep the distance between each floor the same by having the single up func_train include elevators going up from all floors (same for down elevator). Btw, if you could color the lines so that the same part on each floor uses same color lines, would make that graph easier to understand.

EDIT: at top of the graph the 1st target relay is unnecessary; 3rd target_relay targeting the func_train is unneeded. The target_delay below with 0.05 delay should be triggered by the path_corner where func_train needs to stop (or preferably the train would be targeted directly, do target2 and targetname2 keys work?), so the func_train is stopped immidiately on arrival.

[Draeke]

Yep those optimisations are all valid; unfortunately I've stopped working on it .

So, to answer the roughly year old OP:

Is it possible (I haven't touched GTK Radiant for months, much less messed around with func_trains)? I know it'd be a pain to make it look good as the three buttons would (realistically) be in roughly the same area (causing you to hit all of them with a swipe or walking in to them. D:)

Yes it's possible, but it's very tedious if you want good results (true multi-level, eg. UniqPhoeniX's idea). Mediocre results on the other hand are quite manageable (loop-around multi-level, eg. GMOTW/MrFish idea).

[UniqPhoeniX]

unfortunately I've stopped working on it .

I haven't. Only need to add button covers, perhaps adjust timing.