Portals placing sideways on panel brush
I'm trying to make a level where panels move a platform from a wall 90 degrees, to make it able to be used for flinging. For some reason, when the panel is raised, all portals placed on it are being forced into a specific orientation.
(I fired the portal from the exact position I took the picture at, and the panel rose from the south wall).
I even tried info_placement_helpers to try to force it into the other, more natural orientation, but it's not working.
Any way to fix this? Or, like with most of my other ideas for Hammer, am I dealing with a Source engine quirk that can't be helped?
Plus, I kinda find all this white a little blinding.
Weird.. I'd go for the panel not quite having a full 128x128 visible square, therefore the game is trying to apply the portal in the only space it can...
Or, your info_placement_helper is set up wrong.. remember you want to set it up where the panel will be once raised, and get the flags(angles) correct... If I recall its Red Large for facing (up away from the panel), Blue large is the length (large at the top), Green handles the width, set for a 64 radius to effect, force orientation on, at the centre of the panel, either flush with the face or 8 units apart...
Its been a while since I last done any mapping though, I know the mind plays tricks with remembering specific details like that...
Or, your info_placement_helper is set up wrong.. remember you want to set it up where the panel will be once raised, and get the flags(angles) correct... If I recall its Red Large for facing (up away from the panel), Blue large is the length (large at the top), Green handles the width, set for a 64 radius to effect, force orientation on, at the centre of the panel, either flush with the face or 8 units apart...
Its been a while since I last done any mapping though, I know the mind plays tricks with remembering specific details like that...
Nope, the brush is perfectly 128x2x128, and it's perfectly flush with the wall before the arms are deployed. I'll have to try the placement helper thing though.
Is there maybe a bug with the "makeramp" animations in the arm64x64_interior model?
Plus, I kinda find all this white a little blinding.
It's possible that the panel is tilted at a very slight angle, with the bottom of the slope on the left.
Portals like to place themselves with their bottom facing the bottom of a sloped platform if you haven't noticed (it's impossible to shoot an upside down portal on an angled wall.) This happens on obviously angled panels, but also "flat" surfaces actually tilted at 0.0001 degrees as well.
I'd double check and triple check the orientation of the panel. Try cl_showpos 1 and walk around on the panel, your Z coordinate shouldn't change at all.
Portals like to place themselves with their bottom facing the bottom of a sloped platform if you haven't noticed (it's impossible to shoot an upside down portal on an angled wall.) This happens on obviously angled panels, but also "flat" surfaces actually tilted at 0.0001 degrees as well.
I'd double check and triple check the orientation of the panel. Try cl_showpos 1 and walk around on the panel, your Z coordinate shouldn't change at all.
That could be it, maybe the animations on the arm are leaving it at a very slight slope. I'll have to check it out when I get a chance. For now I've moved which wall the panel comes from, so that even though the portals still have a fixed orientation, at least it's at the most useful orientation.
I haven't tried the placement helper again yet, but I will when I get a little free time.
Worse comes to worst, I'll make the panel start deployed and non-animated. Though I feel like it would kinda ruin the feel, considering I'm doing it in the Reconstructing theme.
Plus, I kinda find all this white a little blinding.
worst case you put an invisible brush at the same place where the attached brush stops, and when the animation stops just hide the attached brush and enable the pre-placed brush. If the pre-placed i at the same position, the switch is not noticable at all, and it would be perfectly flat and with a placement helper no issues. This way it would also have proper lighting 
(btw I usually start the arms/panels at their final position for good lighting calculation at compile, and then I move them (the arms) to their starting position at mapstart quick, so they always have the best lighting on them witch matches their final position's surrounding if they have similar adjacent textures)
worst case you put an invisible brush at the same place where the attached brush stops, and when the animation stops just hide the attached brush and enable the pre-placed brush. If the pre-placed i at the same position, the switch is not noticable at all, and it would be perfectly flat and with a placement helper no issues. This way it would also have proper lighting
(btw I usually start the arms/panels at their final position for good lighting calculation at compile, and then I move them (the arms) to their starting position at mapstart quick, so they always have the best lighting on them witch matches their final position's surrounding if they have similar adjacent textures)
That's actually a good idea, I'll try that!
I actually start mine deployed and un-deploy them at mapstart too!
It makes the lighting look perfect when they're deployed, but can make them look a little awkward pre-deployment depending on how lighting is set up.
I know none of the Portal games are likely to get a Source 2 port, but I'm left wondering if Source 2 improved dynamic lighting and brush lighting at all.
Plus, I kinda find all this white a little blinding.
@Crawfish: can you post an example little map with the panel, arms etc doing the animation you need? I can't believe the info_portal_placements aren't working for you, maybe you set them up incorrectly. I'd like to make a try.
useful tools and stuff here on TWP 
[spoiler]
[/spoiler]