Please or Register to create posts and topics.

Moving Stairs Issue

PreviousPage 2 of 2

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

[insert visually obtrusive graphic or witty comment here]

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.

PreviousPage 2 of 2