rotating room
When you make then a brush, you they will be on toggle for solidity, if you want to be able to toggle the state from solid to not solid, leave this alone. Otherwise, set it to Solid BSP (Or always solid, I forget what it is.)
protoborg wrote:
The issue is that I want to rotate a large cube brush that has a laser emitter on each side. The idea is that you have to arrange all the laser emitters so that they align with the laser receivers on the walls, ceiling, and floor.I figure I can setup a Rubik's cube sort of thing. The player will have to rotate the inner cube until the laser emitters line up with the collectors. First, though, I obviously have to get the inner cube to rotate.
I don't see the issue; parent the laser emitters to the rotator!
Well, it's not too hard to let it rotate; use a func_rotating or a func_door_rotating and parent the brushes and laser emitters to them.
protoborg wrote:
I could have the faces rotate 90 degrees in one direction. Each row or column would rotate in a different direction to "randomize" the combination of faces.
well, then use a logic_timer; a few logic_cases and shuffle your thing randomly 
Lpfreaky90 wrote:
protoborg wrote:I could have the faces rotate 90 degrees in one direction. Each row or column would rotate in a different direction to "randomize" the combination of faces.
well, then use a logic_timer; a few logic_cases and shuffle your thing randomly
That could work nicely. Then when the player enters the room with the cube, they push a series of buttons to rotate the faces until they get the laser lined up correctly. The problem is how do I force the solution when the player gets frustrated? By that I mean how do I provide a "cheat" button that solves the cube for the player if need be?
If someone would be willing to help me with the logic of making this work, I will credit them in the final level somehow. The laser emitters are placed as follows:
http://steamcommunity.com/sharedfiles/f ... =132747733
http://steamcommunity.com/sharedfiles/f ... =132747822
I had another picture but I accidentally deleted it from the cloud. I hop these two are helpful in picturing the cube.
Monitoring the laser's direction could be difficult, though.
But maybe some logic branches and invisible laser catchers point_laser_targets could do the trick?
You could have outputs to change the travel distance of the second set of rotating entities. Maybe.
Just throwing out ideas 
TopHATTwaffle wrote:
I think you may also need to disable the lasers when they are moving, and enable them once they are stopped. I could be wrong though.
There is no need for that. The lasers move with the emitters while active, although in a bit of a jittery manner. I've tried a track_train & a func_rotate to use as parents (on separate occasions) and both work dandy enough. Just be sure to make the emitters stop moving if you need them to keep focus on a catcher when they connect.
Make sure to use the Auto Aim option when trying this. It'll keep the jittery motion from interfering with the alignment.