Portal 2 - Rubik's Cube
I'd be interested in a quick explanation on how it's done with them, I sat and thought for awhile before deciding on using logics, I couldn't think of another way.
I also thought about if for a while:
1) Since you cannot rotate the cube itself the centers are in a fixed position.
2) Since the centers are in the middle the solution is fixed. (because you already know where each piece has to be.
3) Since you already know where all the pieces have to be you only need to check 17 positions: Front plane (9) Back plane (9) and 5 for the pieces in between. MINUS the 6 centers that are in a fixed position. I just realized.
4) you also need to keep track of the orientation of course. I'd probably use two math counters for it: turn forward +1; turn backwards:-1 min -4; max 4 onhitmax !self setvalue 0. So now I'm at 17+34=51 logics.
4) Then I would have a math_counter that's called ?ber counter that is the sum of the absolute value of all math_counters. TBH I don't know if absolute values are supported in default logic; it could be possible a custom logic needs to be written for this. If that is the case we have two add 2 logics; otherwise we'd add 1.
It needs to be absolute values so fake 0's: a point where there are as much +'s as -'s don't trigger the solution. If they do that and the pieces are on the correct location a messed up orientation will still count as solved.
5) Finally I'd add a relay that is fired when all ?ber_counter hits 0 to check the positions. That'd be around 55 entities
EDIT: Fixed a couple small errors and explained it a bit more.
I had considered it that way too, problem is, when the cube rotates a face AWAY from it's original side the math counters would be thrown off, and then, the only way to keep track of the faces and to maintain a logic branch of true and false for EACH position it COULD be in, While maintaining a set of logics for the solution would be a math counter, it would still require a set of logics (24, for the number of different positions they could possibly be in) for each of those 20 (I could do 8 front, 8 back, and 4 for the edges inbetween) which is a result of 480, just to monitor position, double that to account for clockwise/counterclockwise turns, and add in the actual solution logics, it's about 1000, is the lowest number I can come up with for an actual solution trigger.
I could be going about this all wrong, and if I am, I'd love to know it, cuz that's just way too much work to go through again any time soon, lol
Insert long and smart explanation here I hate to say it, but there is a much easier way than to rack your mind full of maths. When I was trying to make one, at first I thought I had to create a million different entities for every possible solution, the I realised that individual cube can be dynamic, so the RedYellowBlue side once turned downwards one (Red top side, blue Right) will then become the OrangeYellowBlue piece. When turned again the original RedYellowBlue is now BlueOrangeWhite.
/rubiksCubeNerdSpeech
EDIT: Of course this would be much easier with scripting, but the only scripts then was .lua. And I was no expert.
ok, so I get how you made it now, and agree that this is a MUCH simpler way of making a cube in general, but my problem is that I want the cube to be a solution to a puzzle, I want a door to open when I finish the cube, and with your method, the cube just thinks it's in position A after every turn, which, again is a MUCH easier way to make a cube for us to play with, but my method would be required in order for a door to open on completion, correct? or am I still over complicating things?
This makes complete sense, however 99% of the population do not know how to solve a rubiks cube. I suggest making a 2x2 cube as the puzzle instead of a 3x3 one.
For making this happen, try creating a move-check system, where (again) you will have brushes parented to the main cube which will have filters which will only activate when the original cube is in its' proximity. Using a number of logic_branches and a logic_branch listener (or a math_counter), when all cubes are in correct place it will finish.
Only problem:
The cube can be in the correct place but the faces can be rotated in the wrong position. Therefore I suggest having 3 brushes* which interact with triggers to determine whether or not it is in the correct position AND correct rotation.
* If you are smart with logic you only really need 2
EDIT: The checker triggers will have to be parented to one of the corner cubes AND not be unparented. Otherwise it will only be solved when it goes in the original position it started from.
EDT2: You could use a classname change for the original names and targetname change for the movement as I used to do this in scripting servers. To quickly kill whole groups of entities under different names but same classname.
Insert long and smart explanation here I hate to say it, but there is a much easier way than to rack your mind full of maths.
Yes, usually the easiest solution is the best but I'm too much poisoned with math I'm afraid 
[quote=Jexim]I had considered it that way too, problem is, when the cube rotates a face AWAY from it's original side the math counters would be thrown off[/quote]
Hmz...
Same
I liked the idea that someone gave me earlier about having it be a, SOLVE THIS CUBE... OR go do this long string of somethings that would take an equivalent amount of time in order to open the same door instead, something I'm probably gonna use in an upcoming map pack I'm working on now.
and chicken, what you're describing is very similar to my current method, just docking it down to a 2x2, which would involve a great number less logics, I could, in theory, create a 2x2 by simply stealing all my corner logics from what I have now and voila, 2x2, and again logics for atleas 8 of the faces would be necesary in order to keep track of where they're at at any given time.
and btw, I LOVE your drawings, lol
Edit: I finally added a vid of my solve of my rubik's cube to the original post, it's super fast or anything but I'd been meaning to make it.
Holeeeeeee shiet....
some of you are too fuckin smart O_O
Quite impressive.
However, TWO would be twice as impressive :-p
"Such monstrous sucking-constructions aren't built within one afternoon"