I am attempting to create stairs that are similar to those in chamber 14 using a series of func_brush's attached to func_door's.

Using that method, I can trigger the transition from stairs to collapsed and back again.

The problem is that when I place a portal on the stairs in their collapsed position and then a 2nd portal anywhere else, I can see the seams of the stairs in the 2nd portal.

Any ideas on what I'm doing wrong?

my thought...

make a box 1 unit tall, 1 unit floating above the floor (make sure it doesn't touch anything)

apply a nodraw texture...

only problem with that, is the portal on the floor will be 2 units above the floor...

OR

make a brush the size and shape of the floor, make it a func_brush
if the stairs are up at the start of the map, disable this new func_brush, if they are down, disable the stairs func_brushes

on door full close (or open, however it is when the stairs are all the way down) disable the stair brushes, enable the new brush

Trigger that moves stairs up, disable new brush, enable stairs.

hopefully that would work, pretty sure you wouldn't see the transition as long as you textured them right

[img]ftp://joelbell:[email protected]/public_html/Portal/seams.JPG[/img]*

Those two lines are the seams I am talking about - they are the dividing edges of the steps that the other portal is on.

did you try any of the suggestions I mentioned?

Ok, so I was able to determine that those "seams" are in fact the top bit of the side of the step.

A method I came up to combat this is to have two steps for each step (one with nodraw sides) and enable/disable as necessary - not sure how efficent that is though.

As for your methods Artesia:

First method: Looks very odd, not the right solution.

Second method: This one looked very promising, but has a problem. When the stairs are half up and half flat, the flat section is either unportable or will produce the seams I mentioned earlier.

A fix for this could be to have numerous brushes that are constantly enabled/disabled as the stairs go up and down - but seems a little excessive.

I'm not which one I'll go with, though right now I'm leaning towards the double step method since it seems the simplest to set up.

Have any opinion or other ideas? - is there a way to open up the official maps and look at what they did?

indeed I do...

an addition to method 2:

1 unit below the surface of the top stair, make a func_noportal_volume the size of the stairs/floor and parent it to the door running the top stair...

I haven't tested this but I think as the top stair started moving up, it would fizzle any portals in the area...

If im not mistaken that happens to any portals on that surface in the ingame level

EDIT: are there more states to your stairs other than all the way up or all the way down (not counting movement)

if not you wouldn't want the surfaces portal in the meantime, you can't portal to moving surfaces if im not mistaken

• The portals on the flat stairs already get auto-fizzled when the stairs go up.

• There are only the up/down and moving states on the stairs.

• If i have 20 stairs and they are half way though transition (ie. 10 are flat and the other 10 are still up) the player should be able to fire onto the flat section.

Artesia, looks like your first idea was right after all, and all I can say is ROFL.

[img]ftp://joelbell:[email protected]/public_html/Portal/underTheStairs.JPG[/img][/img]

By shooting a portal down between the steps, you can get under the stairs and portal on an invisible plane. They didn't even try to it.

The plane (from what I can tell) floats 1 unit above the stairs when they are in their down position. It is really only noticeable if you are completely focused on it; however, I checked it out with no clip on to make sure and it is indeed floating above the stairs when they are down.

I understand why they did this though - the invisible plane is NOT an entity since entities (even func_brush) don't handle portals well; however, I don't understand why they didn't put a portal-blocking volume above this surface that toggled with the stairs.

Oh well, I think I have what I need ; maybe I'll make a tutorial.

Using a nodraw texture turns the texture on my steps to solid black and I can't seem to find another transparent texture that takes portals - any ideas?

• the nodraw brush is 1 unit above the steps when they are in their closed (flat) position, and the steps are always black in every position.

it might be because its touching other brushes when its compiled, you could try an invisible texture... not sure if its portable though

I'm pretty sure I fixed the blackness issue, had to do with an invis brush, but now I have a new issue I'm working on too:

If I make the nodraw brush into a func_brush, it has a VERY hard time accepting portals when the player is standing on it and looking down. The player either has to stop moving and wait a second or two, or jump to get a lock on the floor.

I would like to be able to use it as a func_brush because of how my stairs move but this issue really hinders the players ability to place portals.

• As far as I can tell, all func_brushes have this issue, not just ones with nodraw.

I've been struggling with the piston steps myself. I initially solved it by placing a nodraw brush that was 1 unit thick on top of the place where the steps lay flat. I managed to get rid of the lines by having the func_door steps be flat when they are open and steps when they are closed; I'm not sure why this works any differently, but it does. Then when I needed to be able to shoot portals through the gaps to get to the area underneath, I turned the nodraw brush into a func_wall_toggle that turned invisible when the steps were raised. The problem I'm trying to overcome now is that phys objects won't pass through a portal that is placed on the nodraw brush above the steps, even though the player can. This actually causes some amusing glitches if you place a cube on that end of the portal and then try to pass through the cube from the other end.

Instead of using func_wall_toggle, try using func_trackchange.

I'm not sure if another func_ works, but func_trackchange accepts portals properly when a surface is made up of 2 or more aligned moving brushes and allows for the passing of prop_physics.

The only downside I have found so far is that the game throws the error "Can't find top track for track change!" to the console for every func_trackchange used in this manner.

The error its self doesn't seem to affect anything though so it seems to be a good trade off for the use of such a useful brush.

Using func_trackchange will let you build better stairs than the ones in test chamber 14.