Hello guys. I know you can do it because I saw it in a few of custom levels.
I want to know how to rotate a room of 90? (in the axis I want, the 3 ones chould be possible. Not in the same time for sure.)
The idea is when I press a switch, the room we see trough the glass rotates from 90?.
Is it really difficult ? I think it is and this is why I ask here. I have no idea where to start to do this and maybe it's very complex to make.
The entire should rotate when the button is pressed and all the objets too (doors, buttons, switches...)

I'm guessing... which is something I'm slowly learning not to do..... but......

Parent everything in the room to a func_door_rotating, set the door to have a 90deg turning angle, open/close the door ?

If anything its a place to start testing....

[EDIT] ... oh wait, this is for Portal 1... erm... never mapped for Portal 1 but I'm sure the principles is the same... you should at least be able to move everything that is "static" that can have a parent...

... I'd expect you will get some odd lighting issues, and depending on the desired effect some kind of gravity/push mechanic will be needed to stop cubes etc falling around and tumbling about....

This sounds like a very interesting idea... ... Good Luck!

It's basically the same in Portal 1.

One thing you certainly need to do, is make every floor, ceiling and wall piece into a separate func_brush. (So for a simple box room you'll end up with 6 entities.) Portals can only be placed on the outside of brush entities, and if you turn the entire room into one entity, portals cannot be placed inside it any more.

Aside from that you'll just need to experiment. You may run into other anomalies, like the ones mentioned by RustyDios.

Thanks for answers guys. I'm a begginer with Hammer and I don't know how to process. Can you explain me the rest of the process ? i've created my 4 brushes (there is 4 brushes to rotate. No ceiling and no floor. The 4 walls should rotate by 90? when the switch is pressed).
But after that, I have no idea of what to do. Can you guys explain more ?

So the floor and ceiling stay stationary and just the walls spin ?....

If that is the case, tie all your four walls to a func_door_rotating, set the rotating door to open 90deg (I think this is the default anyway)... open and close the door... .... you will need to put the whole room inside a bigger world brush room... ... of course this is just for portal2 (I've got no experience with portal mapping, and to be honest not much experience with portal2 mapping!)....

But if it's all similar .... ...

Thanks for answers I'll try this.

RustyDios wrote:
So the floor and ceiling stay stationary and just the walls spin ? ...

For the 1st rotating room yes but the opther rooms will work different. The ceiling and floor will also need to rotate. Does it work same ?

Short Answer; Yes.

Long Answer!
||It should do, providing everything is travelling in the same direction, just parent the floors and ceiling.... imagine it like putting a big spike into your room and turning the whole room on a axis (default axis is the z-axis)... there is a good thing about rotating doors on the VDC about learning what axis you actually want to move around (the one that is NOT mentioned in the 2D view you want to move in.. see the wiki it explains it better then I can!).....

If you wanted things to spin/revolve completely in all axis, make a three single axis doors in the "centre" of the room, and use triggers and setparent commands to parent each "room" to one of the doors, move it, setparent to next direction door, move it.....

Once you've got the basics working there is a lot I think you can do with this, might try something similar myself now I've put so much thought into it!... And yet again I'll stress that I'm thinking of Portal2 mapping here, not portal1, but if the principles are the same.... Take the idea, go and play in a testmap in Hammer, test it on rotating a small cube with each face a different texture so you can see what happens for each door movement. Apply the theory to bigger stuff until your moving rooms! I'm sure you can get it working how you want... Good Luck...||

Thanks. I tryied to make a rotating room as my 1st exemple (rotating 4 walls but not the floor and ceiling).

The button rotates them it works, but when the button has been pressed once, the 2nd time I press it, the walls back to their originical angle instead of going even more 90?.
It looks logicial for a func_door but then I don't know how to do, because I need my walls to rotate from 90? each time the button is pressed and not only once and back to their original place a 2nd time pressed. I hope you can help me with that case at 1st.

That is relatively simple:

1) Add three outputs to your door entity:
- "OnFullyOpen -> walls: ClearParent"
- "OnFullyOpen -> !self: Close" (note the "!" before "self")
- "OnFullyClosed -> walls: SetParent: door"

2) Change the output of the button to "Open" instead of "Toggle".

Now what will happen is that the door will open first, rotating the walls with it. Then it immediately closes again, but without moving the walls. When it's fully closed, the walls will re-attach, so they will rotate another 90dg on the next activation, and so on.

You will need to set a long enough reset time on the button, so it can't get pressed while the door is still closing.

HMW wrote:
- "OnFullyClosed -> walls: SetParent: door".

I don't understand how to do that because my walls are themselves a func_door_rotating. I cannot set my walls parent to my walls who are my doors also. I don't really understand this part.
Apart that, my button was already in Open and not Toogle (I made my switch by following the tutorial on valve wikia).

Oh ok, I assumed that you made the walls a func_brush, and made a separate, invisible func_door_rotating.
It's probably easier if I make a quick demo. Hold on...

Edit: here it is. (see attached file)

I made the func_door_rotating entity visible so you can see how it rotates back after moving the walls. You should of course change its texture to "toolsinvisible" so the player doesn't see it. (It is already non-solid.)

It turns out that you also need to add small delays between the movement and the various SetParent / ClearParent signals to prevent visual glitches.