I hope to be able to give this a look in a couple of weeks or so!

Hey this is great!

I recently copied and cleaned up all the wiki content into markdown files here (https://github.com/ndom91/orcaslicer-docs) available as preview deploy here https://orcaslicer-docs.vercel.app/docs

We've been talking about it in the discord here.

I'm not necessarily married to using that docs framework but I'd love to get that version of the docs deployed and released officially. But maybe we can at least collaborate on the markdown content? Ive tried @-ing SoftFever there to move that repo under the Orcaslicer github org and try to get the Vercel deploy under the Orcaslicer domain, but haven't heard back from them yet.

Hey this is great!

I recently copied and cleaned up all the wiki content into markdown files here (https://github.com/ndom91/orcaslicer-docs) available as preview deploy here https://orcaslicer-docs.vercel.app/docs

We've been talking about it in the discord here.

I'm not necessarily married to using that docs framework but I'd love to get that version of the docs deployed and released officially. But maybe we can at least collaborate on the markdown content? Ive tried @-ing SoftFever there to move that repo under the Orcaslicer github org and try to get the Vercel deploy under the Orcaslicer domain, but haven't heard back from them yet.

@ndom91 Thats great! I had searched for any relevant doc change or something like that in the Discord Server but didint gound this.
I don’t have a strong preference between the MKDocs PR and your proposal, both are excellent and bring that "something extra" that the GitHub Wiki lacks.

That said, your approach, which depends on migrating to MKX, will always lag a bit behind updates made here, while PR #7497 MKDocs implementation only requires a bit of copy-pasting to stay in sync.

Whichever path we choose, I’m more than happy to contribute to the transition. My goal is to help Orca become the go-to FDM slicer, which is why I try to integrate everything I’ve developed and make the tool accessible to as many users as possible.

As for MKX: it's a bit of a mixed bag for me. I love MK, but I’m not a fan of JS. Still, I do find MKX to be an interesting and practical format for this kind of use case.

To reiterate, if we decide to move forward with it, I’m here to help with updating the documentation. Even if the current content is a bit outdated, none of the work done so far is wasted, as it all serves as a solid foundation.

Yeah so the way I'd like to see it is that we'd then only have 1 source of truth for the docs content. We would no longer have the wiki baked into the github repo. Only then the orcaslicer/docs repository (or wherever SoftFever would want to transfer my repo to, for example). That's a really common setup for opensource projects.

Regarding the md/mdx thing - I don't have a strong feeling here. I mean mdx is strictly a superset of normal markdown, right. So folks could just write their normal markdown content in the .mdx files, but we could then still incorporate more advanced widgets / components in alongside the text content when necessary. The way I see it is you don't lose anything, but gain a lot of flexibility.

And to your last point - we can obviously then copy out any newly added content to wiki into whatever docs format / repo we end up going with when that time comes, so yeah no effort wasted there 🙏🥳

I'm on mobile and I cannot contribute, but I think that before the tolerance check (it's not really a calibration) a mention of the califlower scaling test should be made, so that prints are as accurate as possible by compensating shrinkage.

I'm on mobile and I cannot contribute, but I think that before the tolerance check (it's not really a calibration) a mention of the califlower scaling test should be made, so that prints are as accurate as possible by compensating shrinkage.

The Orca Tolerance Test can be used with X-Y hole/contour compensation and it was already in the calibrations wiki.

The Califlower Calibration Tool Mk2 its a paid and register tool and i want to be away from it.
But i will try to design a better tolerance calibration and add it as i previusly added the input shaping and junction deviation tests.
NOT FOR THIS PR, BUT A FUTURE CALIBRATION.

The Califlower Calibration Tool Mk2 its a paid and register tool and i want to be away from it.

FYI: There is also an open source alternative called the Calistar: https://github.com/dirtdigger/fleur_de_cali
(This isn't an endorsement, I haven't tried it yet)

The Califlower Calibration Tool Mk2 its a paid and register tool and i want to be away from it.

FYI: There is also an open source alternative called the Calistar: https://github.com/dirtdigger/fleur_de_cali (This isn't an endorsement, I haven't tried it yet)

It looks good, i will give it a try becouse i was thinking to add a Skew calibration too.
But is not going to be in this PR for 2 reasons

1. This will require some test and i will try to add the tests to orca (not just mentione them in the wiki).
2. I'm going on vacation so I'm not going to be active for the next weeks. This way I allow that if someone wants to upload another improvement they can do it and already have this improvement/modularization to facilitate the wiki.

If nothing is changed or updated upon my return, it is possible that some development will go to the discord, so those who want to participate stay tuned there.

Hey this is great!

I recently copied and cleaned up all the wiki content into markdown files here (https://github.com/ndom91/orcaslicer-docs) available as preview deploy here https://orcaslicer-docs.vercel.app/docs

We've been talking about it in the discord here.

I'm not necessarily married to using that docs framework but I'd love to get that version of the docs deployed and released officially. But maybe we can at least collaborate on the markdown content? Ive tried @-ing SoftFever there to move that repo under the Orcaslicer github org and try to get the Vercel deploy under the Orcaslicer domain, but haven't heard back from them yet.

I'm checking it out.

https://orcaslicer-docs.vercel.app/docs/adaptive-pressure-advance should mention my remark from #9610 which is that adaptive PA does not strictly require the full matrix of acceleration and speeds, the user can manually remove test patterns and leave only those which correspond to actually useful combinations or ranges. Typically, the acceleration for inner, outer perimeters and top surface should be optimised for a range of speeds, since the layers can be slowed down.

Proposal: after
"We, therefore, need to run 12 PA tests as below:

Speed – Acceleration ... (table follows)"
add:
"Remark for advanced users
It is possible to speed up the calibration by manually removing unneeded combinations of acceleration and speed after generating the set.
In practice, this involves leaving only the following patterns:

• acceleration and speed used for bridges (typically low acceleration and low speed, not used anywhere else),
• the accelerations used for inner and outer perimeters and optionally top surface, combined with 1/3, 2/3 and the max speed used for printing.

This reduces the number of test patterns to 1+2x3 = 7 patterns, or 10 if the acceleration for the top surface is also included."

The PA step of 0.001 is excessive, it becomes difficult to pick between lines. It's basically always sufficient to use 0.0025 and then, upon need, just interpolate in between. Since the Wiki is for the average user, not for special cases, we should really not make life difficult by giving huge patterns which are more difficult to read and which provide an accuracy which is more than the algorithm needs to begin with (PA is not linear, so nothing is gained by going to 0.001 accuracy).

Aux fan: is anyone else experiencing the bug here? #8078

https://orcaslicer-docs.vercel.app/docs/calibration
"Flow rate" is based on the old monotonic top patterns, not the Archimedean chords, which apparently have some issues #9609 so it might need to be reworked sometime in the future.

"Pattern method" should not repeat the instructions for adaptive PA.

"Max Volumetric speed" should add this:
"It is known that in most printers layer adhesion starts to worsen from 50% of the max flow, and the worsening becomes significant above 65% of the max flow.
It is therefore recommended to set the maximum flow to no more than 65% of the value calculated with the test tower, unless the user can perform further tests on their own to ensure the layer adhesion is sufficient for the intended purpose."

Advanced users will know what to do, generic users will not start complaining about parts falling apart the first time they fall on the ground, or similar.

f 0.001 is excessive, it becomes difficult to pick between lines. It's b

I usually use the PA tower (it works fine in my setup), but I think I understand your point.
The Vercel app is still waiting for an official implementation.
This PR is aimed at the GitHub Wiki (and maybe later for use in Vercel).

I see 3 options :

1. Edit this PR’s PA doc

   1. I can give you access to my fork
   2. We can do some pair programming via Discord
   3. You can comment here on how you think it should be, and I’ll edit the file and @ you in the commit

2. Wait for this PR to be merged (if it ever gets accepted), and then you can make a PR

3. Discuss via Discord (with @ndom91, @Neko-vecter, and anyone else interested) which platform to use — MkDocs, Vercel, or any better alternative — then write a definitive but alternative guide, maintain it, and eventually propose it to the Orca maintainers as the official version.

Hey thanks for the detailed feedback, however, the contents there are just copied from the github wiki from about 2 months ago.

Anyway, I don't want to hijack this PR any further with my alternative 😅. I agree with what @ianalexis has proposed above. So in that vein, here's my sales pitch haha

My version from https://github.com/ndom91/orcaslicer-docs (demo deploy: https://orcaslicer-docs.vercel.app/docs) is using a JS docs framework (fumadocs) that comes with a nice UI out of the box and many little docs page widgets / features that would allow us to ship much nicer docs project than your average mkdocs or similar from the 3D printing ecosystem. It generates a static output bundle, so no running node server required. It's compatible with the whole JS remark/rehype ecosystem, unlocking a ton of expandability, and I've used it extensively at other opensource projects im involved with as well as at my previous job.

I appreciate that the 3D printing community doesn't have a ton of overlap with web dev, but that whole part really doesn't need much work / maintenance after we ship it once, I've already done all of that work in the repo above as well as copied over all of the content from the GH wiki (as of ~2 months ago at this point, as you pointed out can definitely use some updates). The docs content itself is written in markdown files, in this case in the content/ sub directory, so anyone can contribute docs updates easily. There is a link at the bottom of each page actually that takes you to the GitHub "edit" page for that specific markdown file making it super easy to contribute.

Long story short, this project / version of the docs is already ready to ship imo. Of course only if we agree, but from there it's basically just @SoftFever that would then need to help out with pointing the docssubdomain, or however he wants to organize it, at the Vercel project.

Regarding Vercel, it's just a hosting provider for this static site. They have a relatively good free tier and a great dev experience imo, but it really doesn't matter what we go with. Happy to chat about this as well

I am working from mobile or, in little scraps of time, from my work PC :) so I can only contribute in discussions like this one or in Discord, provided it's a Discord discussion without background noise, so few people contributing in a concise and efficient manner, not messages lost in a long dispersive chat with 50 people writing one line or two and disappearing (discussing here already filters this kind of noise).

Maybe better merge this one to the Github one, then sync the two, then we can efficiently iterate on corrections in the external one, and once done propose a change to the official wiki.

Refactored the "How to Build" page using the steps from the current README, and updated the Windows section accordingly.
If anyone has suggestions or updates for the macOS or Linux parts, feel free to comment or review! I always try to credit contributors as co-authors in the commits.

Removed the fake sites from the main README because listing them poses a real risk.
Search engines like Google can crawl and index these URLs, potentially treating them as legitimate resources. This can lead to accidental promotion of malicious sites.

To avoid this, I replaced the list with a simpler CAUTION message and added clearer, more prominent official links and badges.

@SoftFever @Noisyfox consider applying this change either in this PR or in a separate one if you don’t find all the other proposed changes necessary.