@KamilDrakari do you have a GitHub? You could probably contribute quite a bit to this

Ok so it worked fine, then it didn't. For no reason. Now I've got about 40 bugs

Well not "no reason" but no good reasons anyway -_- I'm gonna go to bed and finish squashing little Unicode bugs tomorrow. 🐛 🐛 🐛

@MDXF Now that you mention it, I wonder how Lua handles Unicode...

So, I was wondering... what is the reasoning for using a custom code page to implement the turns, instead of a pair of plain ascii characters? Such as Ri24, where i2 indicates the second inner layer. Wouldn't that be a little harder to program, but a lot more typable? And also it would make it easier to programatically select which layer, since you select it with a number and not with a strange character?

@rexroni It'd definitely be easier to type, and it's worth thinking about, @MDXF. You could select which layer with a command (i? l?) and any future rotations are made on that layer.

As for why Ri24 wouldn't be implemented, it's because that goes against the command system. Ri24 would call the command i for arguments 2, then 4. No rotations would happen.

Well... it is true that the current command system that would not work, but I guess I was thinking that an "i" or "I" subcommand of fixed arity would not be a huge change to the command system. So R is set as the command, then i/I is parsed, which opens a subcommand that takes exactly one argument, then 2 sets the layer, then all remaining arguments (just 4 in this case) do actual turning. I mean the "R⁵2" syntax changes the command system as well.

@rexroni R⁵2 changes the command system too, but we'll probably want a codepage in the future too. I'm not sure I agree that R⁵2 is the best way to implement selecting layers, but I think it's a good idea to get a codepage started for future operations.

@TehPers I'm going to implement a safety net so that it'll just do nothing

As for the command system, R⁵2 isn't changing it any more than the way we do loops. I mean, the syntax is non-digit sets command, digit calls command. Loops are all digits until the next non-digit are added to the current command buffer, then it's called and the command buffer is reset.

@rexroni Less bytes, less syntax changing, looks cooler :P

@TehPers lua-users.org/wiki/LuaUnicode

Oh and @TehPers if you wanted to try the visualizer out, I fixed it

@MDXF I'll give it a look sometime! I can't compile it on this computer, though.

Ok. Btw I just finished Cubically 2 (inner turns) literally five seconds before you sent that, it's out of beta, everything's working :D

Nice!

@MDXF have you answered whether the layer-offset capability works with multi-digit numbers?

@KamilDrakari It does offline but there seems to be a problem on TIO

The layered turns don't work at all >.<

rip

@MDXF Currently to see if the notepad is solved, we are using !0{:1+1=2?6{...}}, but this resets the notepad

@KamilDrakari You should probably put some input in as well.

Is there some way to check if the cube is solved without overwriting the notepad?

Basically, i'm trying to subtract ab from the notepad. a is stored in the cube, and b is in the input.

@MDXF Erm, &%0 outputs "0" now...

But &1%0 doesn't

This was a lot of fun...

@TehPers Is it supposed to reset the notepad?

Or is it a bug?

@TehPers That's... less than good, I think I know why that happened

Can't look at it rn but I'll fix it later

@MDXF It's not a bug, just an idea for a feature. There's no easy way to check if the cube is solved. The only way to be sure it's solved is to do checks like that, but it replaces the notepad value when you do a comparison so you end up losing whatever was stored there.

The issue is, you'd need to check if the cube is solved if you stored a value there, but you'd probably only store a value there if you wanted to store another value in the notepad. If you lose whatever was stored in the notepad when checking if you've solved the cube, it kind of defeats the purpose lol.