Moving Stairs Issue
Quote from Artesia on November 9, 2007, 6:30 pmit might be because its touching other brushes when its compiled, you could try an invisible texture... not sure if its portable though
it might be because its touching other brushes when its compiled, you could try an invisible texture... not sure if its portable though
Quote from taco on November 9, 2007, 7:53 pmI'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'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.
Quote from thehermit2 on December 10, 2007, 9:20 amI'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.
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.
Quote from taco on December 10, 2007, 11:55 amInstead 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.
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.