cube needs to stay parallel to the ground.
for a level I am currently working on I need to make a cube so that it can move in the xy plane, and in height, but it shouldn't move in the xz or yz plane. So in other terms: it should be parallel to the floor, but I should be able to move it up.
any idea's?
~Lp
The level is a map with multiple colored lasers. Because this is impossible I made various copies of the level, but say 1000px higher. The copy is what I call the "shadow" level. I have a shadow level for red, green and blue.
Each shadow level represents a color, and the result of the shadow map is then used in the "real" map. Which uses colored env_lasers.
The cube in the shadow level is parented to the real level, so that if you move/aim your cube in the real level, it does the same in the shadow level, which can process stuff.
The problem with the cube tripping over is that the "shadow" are normal laser cubes/reflectors thus they can influence the others when they somehow come in the wrong shadow level. So if a cube trips over say the "blue shadow cube" can go into the green shadow level, and doing things there, thus breaking the map.
To make it even harder for myself I thought It would be fun if the level has multiple floors. So you have to be able to walk up a staircase, but you cube is not allowed to trip over.
I hope that was somewhat helpful!
Thysterectomy your cube to a phys_slideconstraInt
bruzag wrote:
now im sort of retarded, and never mapped before, but how about walls that lasers can not pass trough in between each of your shadow levels? - that way you can have the lasers tip over without any effect
that won't work because the distance needs to be exactly the same all the time, if I would allow cubes to stay on a place they will lose their position relative to the cube, so that the puzzle is broken 
spongylover123 wrote:
I don't think this has been used in portal 2 before,
Thysterectomy your cube to a phys_slideconstraInt
I don't think that's gonna work, because I still need to move to object freely in the xy-plane, what I could do is create some sort of elevator for the cube, but that limits my level design possibilities so I'd rather not do that...
What do you think of an onpickup phys_keepupright disable, ondrop phys_keepupright enable?
that might work?
~Lp
ScpfgaKb1fk
Also, are the shadow levels identical to the actual level?
If so, logic_measure_movement is probably what you'll need. There was a script that added proper collisions to the shadowed cube, but I need to find it again.
Rand0mNumbers wrote:
Is something like this what you are looking for?
youtubeAlso, are the shadow levels identical to the actual level?
If so, logic_measure_movement is probably what you'll need. There was a script that added proper collisions to the shadowed cube, but I need to find it again.
I'm not sure what I'm looking at
The shadow level is almost identical. That way I can copy the behavior of the lasers to the real level.
Skotty wrote:
phys_keepupright is exactly what you need. It keeps the cube all the time parallel to the ground but you can move it in any direction.
w00t 
=====
Another question: is there an easy way to spawn prefabs/instances (a series of objects, linked to each other) with the press of a button? Like spawning a cube with a phys_keepupright? 
lpfreaky90 wrote:
I'm not sure what I'm looking at
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.
Rand0mNumbers wrote:
lpfreaky90 wrote:I'm not sure what I'm looking at
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...
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?
lpfreaky90 wrote:
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?
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.
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 