I would like a map controlled by picking up a cube. When picking up the cube, you find yourself in 'the same place', but somehow, what was left is now the floor. Or any other direction. (Just, pick up a box)

Imagine
(I imagine a row of rotated identical rooms, created down one direction X or Y or Z. Now to the tricky part..)
In a room of coloured walls, floor and ceiling. Would it not be fun to have six different coloured cubes; and when you grabbed one of them, that coloured-brush became the floor? Where is the exit? Oh.. there it is, in the upper left corner. Hint: The left wall is blue, so find the blue cube. Pick it up and exit. Simple.

I also imagined Magnetic plus+ anc minus- Cubes, where any of them made a robot capable of walking on metal (sideways and upside-down). And being repelled or attracted by magnetic forces in-game, when holding the plus+ or minus- cube. A cube would not be magnetic, unless held by a robot.

1# Alternative A: Gravity direction change.
I would like to change which X-Y-Z direction is which X-Y-Z in-game ). Any suggestions would be appreciated.

1.1# Alternative B: teleporters
Using the positive and negative area in X-Y-Z plane, two identical rooms can be made. The second is turned upside-down, or upside-[direction]. With the two identical + and - spaces, you can teleport the player from one room to the other (simulating a gravity change). The teleport-destination would be each the X-Y-Z co-ordinates multiplied by (-1), and a relativity-fix. From +X+Y+Z to -X-Y-Z, and from -X-Y-Z to +X+Y+Z. When you get the picture, you'll know what I mean. A teleport-mapping-table would do the trick.

1.2# Alternative C: portals
Using a second set of portals, able to be placed anywhere (preferable to be invisible). Place a portal that activates and transfers the player, to a destination portal relative to another room; when the player picks up the cube. (bumping-portals, may be enough to eliminate collisions) Any suggestions would be appreciated.

Duplicates are easy, select and copy, move then rotate, easy. Now the confusing part:

Q1# What about placing portals?
When picking up a cube, you teleport into space A, when you let go, you teleport back into space B (where you picked up the cube). -No portals can be placed in space A, because of this behaviour.

Q2# The user portals are in the other room. How?
To remedy the missing portals, you have to let go of the cube, before hitting the wall (where the portal is in the other room). If we can place duplicated portals in space A, the issue is solved. We only need to place the second set of portals in their relative positions.

I'll upload my try at this, but it may take a while. Be patient, or try yourself. I have no idea yet, how to implement the magnetic's, but I'll have a go at the LeftSide-Down-Gravity-room.
It would be fun to turn things around, instead of upside-down.

MasterLagger wrote:
A bunch of interesting ideas, let me know how the gravity thing turns out.

I've created some maps (Hammer Level Design), and made a few attempts of different ideas of Gravity Cubes.
I posted one I made, since it is fairly simple: CompanionCubeTeleporter

The idea was to place a prop_portal, under where the player will be standing. Activated by a Cube.
And it works. In CompanionCubeTeleporter 'proof of concept'; I used 6 prop_portals; covering three Portal-able areas, of two adjacent rectangular rooms (with different orientation). You can't exit any of the two rooms, without picking up a cube. Placing your own portals is useless in the 'proof' ; since I Activate all 6 prop_portal entities, thereby erasing any player placed portal(s) inside the rooms.

I tried to use Teleport_trigger, but the Cubes weren't teleported. I guess the only option, is to use several prop_portal.

Now that I got one workable solution, I can move on;
Completing the map: CompanionCubeTeleporter: Where to get Momentum?.

scetched Intro:
-: I love Cubes, especially the one with the Heart. I think, It told me 'I love you' the other day. That was when, the other Cubes got jealous. You think I'm Joking? I thought so too. I thought I was going crazy. Then a Cube showed me a sign. It said something to me. I'm sure of it. Then placed a portal infront of me. Sure enough, as soon as this happened; other cubes placed portals too. Now; I don't know which cubes like me, and which do not. That 'incineration' back there sure didn't give my popularity any help, now there are portals everywhere. Do not use a cube as a Shield. They are sensitive. Luckily there was a flaw in the test and I got a portal out of there; Otherwise I would have been stuck for ages.

You asked, I replied. Simple.

Sven.

Using prop_portal, I have successfully made my Gravity room. As suggested with 6 multiple copies, each a rotation. And It got me going. I've been learning Hammer editing as I went along, so that is why the long intervals. The room in itself is not it, it is the ideas it spawns.

NOTE: using prop_portal entities will cause errors, unless familiar with:
A : Orientation XYZ. (get this one wrong, and you end up outside the map) (3DView: Red - into room; Blue - H/V)
B : Portal Identification Pair number. (this one can get you messed up. See Below: Answer B)
C : Maximum number of visible portals is four. (Try more and see for yourself)
D : Open AND Close, all prop_portal. (SetActivatedState = 1 , 0)
E : Always set a prop_portal to default Inactive, it starts of Active. (A 'known' issue)

If you keep these four under consideration, your half-way there. You can twist the view-angle, to make the rooms 'Appear As' they where rotated the same way. Have Fun.
A map or a test of a map, will be available Only: when a new consept needs to be addressed, or when the map is finished.

Answer B:
I had many issues indeed. First lesson, always incremet an iteration-number when building maps. I use _0_0_0_0_0 on the end of my maps. Don't worry about storage-space, the .VMF's are small. (How U use the numbering is up to U. I rarely get to use the first three digits before I am done.) I accidentally left some prop_portal entities un-Closed, it resulted in some odd behaviour. The issue was solved by adding OnTeleportedToMe, and *FromMe events to disable the prop_portal (scripted or automated). The player can place two Portals, so that leaves only 1-2 portal pairs to play with; when considering the maximum -four at a time visible. Somehow when I ran my map, my portalgun acted up on me. After triggering a few of my portals and movements I had predictable, un-predictability. Confusing to say the least the player-placed portals, had connected to my mapped ones. The confusing part, was when I took a different path through some portals; everything seemed fine. I tried to find out of it, but went for a different approach after identifying the issue. I probably had too many portals open, with uniqe ID's, in my previous map (not to be explored, as I solved my issue: reverting to a previous file_0_0_0_0_x, where x= x-1).

First; I used unique ID for each portal-passage. I don't reccomend this approach; too many prop_portal.
Second; I changed the ID for each portal-passage. I don't reccomend this approach; too many ID's.
Third; I use two IDs, 1 and 2. Explicitly closing every portal after entry/exit. The pair ID 1 is used everywhere. ID 2 is not usually used; unless I need a 'Portal Copy' in another room, or some Special-Effects.
You only need four prop_portal, if you change the (XYZ pos) and (XYZ yaw); but I'll look into that later.