[deepSubDiver]

ZZ hat Potenzial, das wissen wir nun. ZZ reduziert das F2L auf [RUL]. Warum nicht auch den LL dahin reduzieren? Vollständige 2GLL Listen existieren schon und sind zu einem großen Teil sehr schön auszuführen.

Beispielscramble: D2 U2 B U2 L U' R2 B2 D2 B' R' D F2 R' D' R2 U' R2

Rotation:
Ich komme nur mit rot, orange vorne, gelb/weiß oben zurecht. Daher:
z2 y'

EOLine:
Falsch orientiert sind: UL, UB, FL, BR, DF, DL
Die Line Edges liegen bei FL und UR. Daher:
U R2 D F' R' L2 B

Das F2L ist hiermit auf [RUL] reduziert.

LHB:
L' U R L U R' L U L2

Hiermit haben wir das F2L auf die Gruppe [RU] reduziert.

FLCP:
Hier beginnt der Tricky Part. Wir slotten die letzten beiden FL Corners. Dabei ist die Orientierung irrelevant. Das benötigt höchstens 5 Moves und sollte intuitiv machbar sein.

Bei dem Beispielscramble haben wir einen FLCP Skip. Glück für uns

LLCP:
Hier lösen wir die CP des LL. Wir wissen, dass wir diese nicht in der Gruppe [RU] beeinflussen können (zumindest auf den LL bezogen).
Dementsprechend wird hier ein kleines Set von kurzen Algorithmen benötigt. Das wird zur Zeit aufbereitet und demnächst zur Verfügung gestellt. Hier:

U2 L' U R U' L

RHB:
Der Rest des F2L wird in [RU] gelöst:

R' U2 R2 U' R' U2 R' U R2 U' R'

LL:
Hier kann nun 2GLL genutzt werden. Da ich diese Cases aber nicht kann, habe ich das in zwei Schritten ([RU]-OLL und [RU]-EPLL) gelöst.
Dabei ist wichtig zu wissen, dass [RU]-Algorithmen die CP nicht beeinflussen und somit die während der LLCP gelöste Permutation erhalten bleibt.

U R' U' R U' R' U R U' R' U2 R
U R2 U' R' U' R U R U R U' R

Die 2GLL Alternative wäre:
(U2) R U2 R' U' R U' R' U' R' U' R U' R' U2 R (U)

Jetzt brauche ich euren Senf - wo hakt es, wo gibt es Vorschläge?

\\Edit: Danke an Basti für die Korrektur meines Weltbildes.

[Ct Fatal]

hmm ich bin nich ganz mitgekommen...
du löst also wie folgt: ?

1. FL-Corners einfügen
2. LL-Corner permutation lösen
3. F2L lösen
4. LL

Ist es denn nicht ein wenig aufwendig die letzte Seite so lösen zu müssen, dass man die Cornerpermutation beibehält? Und warum macht man die LL-Cornerpermutation nicht in der Form eines F2LLs, sprich beim lösen des letzten slots? Kann es außerdem sein, dass man viele Multislotting-algos, welche nur auf 2Gen bezogen sind nicht mehr anwenden kann?

Außerdem finde ich es ziemlich langsam Seite für Seite zu lösen... Die meisten Multiblocking/-slotting - szenarien beziehen sich ja nur auf F2ls, wo die vorderen beiden, bzw. die hinteren beiden Slots zu befüllen sind.

Ansonsten großes Lob für deine Arbeit!

[deepSubDiver]

hmm ich bin nich ganz mitgekommen...
du löst also wie folgt: ?

1. FL-Corners einfügen
2. LL-Corner permutation lösen
3. F2L lösen
4. LL

So wie es im ersten Post steht. EOL, LHB, FLCP, LLCP, RHB, LL

Ist es denn nicht ein wenig aufwendig die letzte Seite so lösen zu müssen, dass man die Cornerpermutation beibehält?

Aufwändig? [RU]-F2L ist m.E.n. wesentlich schneller.

Und warum macht man die LL-Cornerpermutation nicht in der Form eines F2LLs, sprich beim lösen des letzten slots?

Weil da die Algorithmen erheblich länger sein werden, da das F2L wieder hergestellt werden muss.

Kann es außerdem sein, dass man viele Multislotting-algos, welche nur auf 2Gen bezogen sind nicht mehr anwenden kann?

Das weiß ich nicht, ich löse mein F2L intuitiv.

Außerdem finde ich es ziemlich langsam Seite für Seite zu lösen... Die meisten Multiblocking/-slotting - szenarien beziehen sich ja nur auf F2ls, wo die vorderen beiden, bzw. die hinteren beiden Slots zu befüllen sind.

Kannst du das bitte näher erläutern? Ich glaube, ich missverstehe dich.

F2L ist (für die meisten) kein stupides Algorithm-mashing sondern sollte möglichst intuitiv (aufgrund von Zuglängen) gemacht werden.

Ansonsten großes Lob für deine Arbeit!

Danke

[moritz]

hört sich ganz gut an. (leider kann ich kein ZZ)

bei FLCP würd ich empfehlen dass man einfach nur die beiden corners nach D bringt und bei LLCP dann halt eventuell in den opposite case löst. (was ist eigtl da der algo für diagonal swap?) dann hätte man bei FLCP maximal 3 züge (aber man müsste es dann umbenennen xD vllt FLCD für FL corners nach D)

und wie viele 2GLL cases gibts? ich komm überschlagen auf 80 (aber da sind noch etliche gespiegelte dabei) also so ca. 50?

[deepSubDiver]

hört sich ganz gut an. (leider kann ich kein ZZ)

bei FLCP würd ich empfehlen dass man einfach nur die beiden corners nach D bringt und bei LLCP dann halt eventuell in den opposite case löst. (was ist eigtl da der algo für diagonal swap?) dann hätte man bei FLCP maximal 3 züge (aber man müsste es dann umbenennen xD vllt FLCD für FL corners nach D)

und wie viele 2GLL cases gibts? ich komm überschlagen auf 80 (aber da sind noch etliche gespiegelte dabei) also so ca. 50?

Es gibt 85 2GLL cases. Zirka 50 ist also ganz gut geschätzt.

Die Version mit den Corners nach D funktioniert genausogut, jedoch teste ich das bisher nur ab und zu und habe es noch nicht komplett getestet.

Die algos sind:
adj-swap URB-URF: L U' R' U L'
opp swap: L U' R2 U L'

Ich kompiliere gerade eine Liste für die isomorphen Fälle.

---

Für dich als OH'ler ist das bestimmt auch was, oder?

[tim]

Nette Idee soweit. Mir gefällt nur der FLCP-Part nicht. Hier zerstört man sich eventuell ein paar schöne Blöcke und steckt die Ecken in eher unschöne Positionen.
Vielleicht kann man hier ja alle Algorithmen für die Permutationen auswendig lernen. Allerdings kann ich mir grad noch nicht vorstellen, wie man die Fälle dann erkennen soll . Beziehungsweise welche Bedingungen müssen für die Ecken erfüllt sein, damit sie mit <R,U> lösbar sind?