• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.

Wiki Discussion Thread

Hey everyone! I upgraded https://www.speedsolving.com/wiki/index.php?title=4x4x4_parity_algorithms to have a (much needed, IMO) DARK theme! I also fixed the previously messed up abundance of vertical spaces. FYI.

And don't worry. The "printable version" wasn't good before anyway.

(And I couldn't do anything about the Table of Contents. It looks okay I guess...)

EDIT:
I can certainly write 2 more templates to factor out more code (for formatting of the headings) if desirable.

EDIT2:
Never mind about that. Adding any more templates to be loaded into the sheet will probably cause a:
Template include size is too large. Some templates will not be included.

Error message, where it will display the template name in place of where the output of it should be. (At this point, the page can only take a few dozen more algorithms before it starts to failing to display "algorithm bars" at the end of the page (output from Template:Alg6).

I may even need to remove the templates that I added recently, should there be a sudden burst in new algorithms to add to the page.

EDIT3:
I reduced the size of the template so that the template include size is at 74.9% capacity.

Turns out that for the revision before the dark theme, it was nearly at 100%. So this error would have happened when adding just a few more algs to that previous revision! But I updated that revision's template (Alg5) to reduce its capacity (for revision history log sake).

In summary (for this edit), we have a little more room now to add more content to the page without having to split it up. But of course, should the number of new algorithms come close to about 25% of what's there now, then we will have to (unless the template include capacity limit is increased, of course).
 
Last edited:
And don't worry. The "printable version" wasn't good before anyway.
I notified our beloved @rokicki about me updating this wiki page. After he looked at it, he suggested that I removed the urls (from the algorithm rows/bars) from the printout. One thing led to another and ... go check out the printable version! (You can remove the headers/footers by the printing settings in your internet browser.)

(But in order for me to accomplish this, note that I had to make clicking on the SS cube logo the means to navigate to alg.cubing.net to see the animation. I have updated those instructions in the Introduction, but just an FYI for anyone reading from here.)

I also (with very little extra template include space cost) made the majority of columns in the algorithm tables line up. (Another suggestion by Tom Rokicki.)
 
Last edited:
I have also updated the template that 4Z4 Method and ZZ44 Method use so that their printable version is at least not hindered by the "algorithm bar" template that they now use (Alg4b).

In addition, I have added the line of code to the very beginning of their page code:
HTML:
<div style="print-color-adjust:exact;">

and this at the very end:
HTML:
</div>

So that they print out in color. (More specifically, they print out looking as close to what they appear online as possible, I believe.)

For wiki contributors (and if it's okay with @pjk ), feel free to add these 2 lines of code to whatever wiki pages you wish that you want to print out "correctly" (with regards to retaining the original page's color).

Although it may be desired to have them, for both pages mentioned above and the 4x4x4 parity algorithms page, I also included an additional part to the code above so that it omits the external link superscript arrows.
HTML:
<div class="plainlinks" style="print-color-adjust:exact;">

However, I am guessing that these arrows may be desired by some, as it differentiates an external link from an internal link (and they appear on Wikipedia as well). But there are external links on Wikipedia which do not have these arrows. And therefore, that alone makes omitting them a logical choice.

EDIT:
And while I'm at it, I will share one other (important) thing I learned regarding controlling how the printout looks. Should there be any section of the page which we do NOT wish to be printed, we can just sandwich those lines in between the following 2 lines of code as follows:
HTML:
<div class="noprint">
<!-- Desired code lines to omit from printout.-->
</div>
(I don't think we can put wiki dividing lines (for example, ==Heading==) between these lines of code and it actually work. The lines to omit probably need to be within a subsection.)
 
Last edited:
At this point, I'd recommend switching to Twizzle:
  • Remove the scheme param (alg.cubing.net never supported it properly, Twizzle doesn't support it yet).
  • Change cube= to puzzle=
  • Change animtype=solve to setup-anchor=end
  • The alg param uses normal URL param encoding (e.g. the prime symbol is not converted to -)
Example: https://alpha.twizzle.net/edit/?puzzle=2x2x2&setup-anchor=end&alg=R2+U'+R2+U2+y+R2+U'+R2
Instructions followed. Now pages that use Template:Alg6 (currently 4x4x4 parity algorithms) and Template:Alg4b (currently 4Z4 Method and ZZ44 Method) go to alpha.twizzle.net instead of cubing.net.

(Better late than never!)
 
With Gil's kindness to add a parameter for Old WCA notation support, I have switched the cube applet that the 4x4x4 parity algorithms page uses to cubedb.net. (And 100K bytes of SiGN notation translations have been removed.)

(I have written a notification at the very top of the page.)

All algorithms are now linked to his online applet with the exception of the algorithms in this section (I wanted to show the 4x4x4 supercube for those) and the last 2 algs in this section (as one is 3150 half turns and the other is 4680 half turns of which cubedb couldn't load. I have kept them linked to alpha.twizzle.)

I initially was going to modify Template:Alg6 which links to alpha.twizzle (well, I did, but I reverted the change), but the fact that I still needed it for those 2 very LONG algorithms and the fact that maybe someone wants to use it for another page, I made Template:Alg7 to link to cubedb.net instead.
 
I complained about the F2L page being a dumping ground of mid/bad/terrible algs, and so I decided to take it into my own hands and clean out some of them. Some of these like U F' L' U L F R U R' are baffling and the only usecase I can imagine is for FMC which shouldn't be on this page anyway. I would make a mention on the talk page, but it's been broken for years.
 
I complained about the F2L page being a dumping ground of mid/bad/terrible algs, and so I decided to take it into my own hands and clean out some of them. Some of these like U F' L' U L F R U R' are baffling and the only usecase I can imagine is for FMC which shouldn't be on this page anyway. I would make a mention on the talk page, but it's been broken for years.
I can see there were a lot of bad algs you deleted, so thanks for that. A few of the deleted algs I would have kept. Some of them were intended for when you're solving into a back slot. The wide f insert into back slots is standard and should be on the wiki. F/F' <RU/LU> F'/F algs are a good way to handle bad EO cases without rotation. I don't these very much, but it is a thing some fast solvers do. Also check out any Brian Sun F2L video if you want to see some mindblowing algs.
 
I can see there were a lot of bad algs you deleted, so thanks for that. A few of the deleted algs I would have kept. Some of them were intended for when you're solving into a back slot. The wide f insert into back slots is standard and should be on the wiki. F/F' <RU/LU> F'/F algs are a good way to handle bad EO cases without rotation. I don't these very much, but it is a thing some fast solvers do. Also check out any Brian Sun F2L video if you want to see some mindblowing algs.
My opinion is that solving into other slots is useful but shouldn't be on the main algs page. Otherwise we would have algs for y, y', y2 which is confusing for the front right slot algs that require a rotation for unoriented edges. If the alg has a special reason like EO or OH, it should be noted so people don't get confused.
 
This seems to be a problem, I am not sure I can revert/delete it. Go to home page, click on the CFOP, Roux, ZZ or Petrus link to see that ArF! text and infobox.
 
I've been an administrator on the Wiki for just over 7 years now - originally I was added to clear up pages created by spambots but those are rare these days. I've been checking the recent changes every couple of days and trying to keep some order on the Wiki.

However I haven't been active in the cubing community for many years, and this is starting to feel like a chore. This is compounded by the feeling that as I'm not up to date on recent developments any more, all my edits and rollbacks are "reactive" - deleting pages and reverting edits rather than contributing anything myself. The main issue the Wiki faces these days is the amount of pages created for users' personal methods, which 90% of the time already exist in some capacity, and the rest of the time are a minor variant of an existing method. These method pages are typically created with no peer-review process, without even linking an algorithm sheet... I tend to leave them up as they're harmless if they're self-contained but I can't help but think we need some quality control.

So this is a call for outside help... the Wiki is an invaluable resource, albeit outdated in some respects. If anyone has the spare time & the knowledge to review these method threads and perhaps patch up the gaps of missing knowledge that have widened over the years, it would be a great service to the community. Another mod/admin would be nice too, so I don't have to keep doing everything myself, and so I don't feel like I'm overstepping my authority and potentially upsetting someone for deleting their method page.

Cheers
 
I suppose a notability policy for method articles would be fair. Perhaps at minimum there should at least be one other place detailing the method, even if it's just a forum thread. A common problem I saw years ago was people deciding the best place to publish their new method was the wiki article itself.
 
I've been an administrator on the Wiki for just over 7 years now - originally I was added to clear up pages created by spambots but those are rare these days. I've been checking the recent changes every couple of days and trying to keep some order on the Wiki.

However I haven't been active in the cubing community for many years, and this is starting to feel like a chore. This is compounded by the feeling that as I'm not up to date on recent developments any more, all my edits and rollbacks are "reactive" - deleting pages and reverting edits rather than contributing anything myself. The main issue the Wiki faces these days is the amount of pages created for users' personal methods, which 90% of the time already exist in some capacity, and the rest of the time are a minor variant of an existing method. These method pages are typically created with no peer-review process, without even linking an algorithm sheet... I tend to leave them up as they're harmless if they're self-contained but I can't help but think we need some quality control.

So this is a call for outside help... the Wiki is an invaluable resource, albeit outdated in some respects. If anyone has the spare time & the knowledge to review these method threads and perhaps patch up the gaps of missing knowledge that have widened over the years, it would be a great service to the community. Another mod/admin would be nice too, so I don't have to keep doing everything myself, and so I don't feel like I'm overstepping my authority and potentially upsetting someone for deleting their method page.

Cheers
I could do it, although I don’t know how anything works…
 
I've been an administrator on the Wiki for just over 7 years now - originally I was added to clear up pages created by spambots but those are rare these days. I've been checking the recent changes every couple of days and trying to keep some order on the Wiki.

However I haven't been active in the cubing community for many years, and this is starting to feel like a chore. This is compounded by the feeling that as I'm not up to date on recent developments any more, all my edits and rollbacks are "reactive" - deleting pages and reverting edits rather than contributing anything myself. The main issue the Wiki faces these days is the amount of pages created for users' personal methods, which 90% of the time already exist in some capacity, and the rest of the time are a minor variant of an existing method. These method pages are typically created with no peer-review process, without even linking an algorithm sheet... I tend to leave them up as they're harmless if they're self-contained but I can't help but think we need some quality control.

So this is a call for outside help... the Wiki is an invaluable resource, albeit outdated in some respects. If anyone has the spare time & the knowledge to review these method threads and perhaps patch up the gaps of missing knowledge that have widened over the years, it would be a great service to the community. Another mod/admin would be nice too, so I don't have to keep doing everything myself, and so I don't feel like I'm overstepping my authority and potentially upsetting someone for deleting their method page.

Cheers

This is a long shot, but my opinion is that a wiki system that doesn't have an approval process will always have the problem of off-topic or inaccurate stuff added indiscriminately. If the goal is to create a repository of accurate information, I quite like the MDN model of a git-based wiki system. I propose a github pages based wiki system, or, as a less radical change, a wiki where changes need to be approved.

At the very least, upgrade the Mediawiki version so that certain pages aren't completely broken. The benefit of github pages is modern tooling and less mediawiki hassle. As a programmer, I am partial to git-based histories over the linear histories of mediawiki, and I can help set it up. I don't have experience in mediawiki moderation tools.
 
Back
Top