cube needs to stay parallel to the ground.
The shadow level is almost identical. That way I can copy the behavior of the lasers to the real level.
Indeed, that is a big vague. The map has three copies of the main level, each with their own cubes. The cubes are all connected to the player's via logic_measure_movement. Whenever the player's cube moves, the other cubes move, exactly matching the distance traveled and orientation. With the geometry exactly the same in each level, everywhere the player's cube can go is where the duplicate cubes can go (and be visible in their respective windows). Additionally, each copy of the level has duplicates of the testing elements whose effects are shown in the others and can interact with the duplicate cubes.
Anyways, I believe I am misunderstanding your situation. A bit of pride. My apologies. 
To spawn multiple entities at the touch of a button, look at point_template. Add the names of entities you wish to respawn and send it the ForceSpawn input to produce more copies. Be careful with naming.
The shadow level is almost identical. That way I can copy the behavior of the lasers to the real level.
Indeed, that is a big vague. The map has three copies of the main level, each with their own cubes. The cubes are all connected to the player's via logic_measure_movement. Whenever the player's cube moves, the other cubes move, exactly matching the distance traveled and orientation. With the geometry exactly the same in each level, everywhere the player's cube can go is where the duplicate cubes can go (and be visible in their respective windows). Additionally, each copy of the level has duplicates of the testing elements whose effects are shown in the others and can interact with the duplicate cubes.
Anyways, I believe I am misunderstanding your situation. A bit of pride. My apologies.
To spawn multiple entities at the touch of a button, look at point_template. Add the names of entities you wish to respawn and send it the ForceSpawn input to produce more copies. Be careful with naming.
No, I think you understand my situation pretty good. From what I now understand, the logic_measure_movement is a lot better. I will look into it tomorrow and hopefully by the end of the week I can have a very very very rough version of what I'm planning in the WIP section...
Final question of the day:
Can I make a brush that can take damage, detect that it is taking damage, and as long as it is taking damage gives an output, and as soon as it stops receiving damage, stops the output? 
Can I make a brush that can take damage, detect that it is taking damage, and as long as it is taking damage gives an output, and as soon as it stops receiving damage, stops the output?
I've experimented with this. The brush will continually fire the "I'm taking damage" output and, as a result, will not fire the outputs you want until you stop the damage (think constantly starting a timer at 0). Once the damage stops, the output will persist and keep firing your desired damage effect while not taking damage. That was before the Peer Review update, so I don't know what'll happen now.
Alternatively, you can have a breakable brush (func_breakable, func_physbox, etc) tied to a point_template. Give the brush a low health and every time it breaks, fire the OnBreak output to both the point_template to spawn a new one and your desired damage effect. The amount of health the brush has will dictate the frequency your output fires in this case. Just be sure to get rid of any sounds/debris the brush will make on breaking. It'd be a little odd otherwise.
once again, my previous question was stupid.
The thing I want is some sort of prop_laser_relay but it needs to be:
* slightly bigger then a cube
* Preferably invisible/mostly invisible
So I'm thinking about a bush, but if you have any suggestions: I'm all ears!
And if anyone could me a 40x40x40 transparent model which I can use in hammer I'd be extremely happy 