Gina Häußge

This isn't just an improvement, this is a full blown feature request. Belt style printers don't necessarily have to have the z axis be infinite, it could also be x...

Marked as task and tentatively scheduled for 1.9.0 (more to have it on recall than anything else really).

Sorry, but no. OctoPrint 1.8.x clearly states it is compatible to 3.7 through 3.10. Releases cost time. Usually half a day to a day, plus a TON of support overhead...

Was indeed caused by the viewer attempting to render billions of grid lines. I've limited the value range for width, depth and height to 9999mm. If someone shows up here...

Ah, good to know that's a general thing then, and that just have me the right words to Google and I came across this: https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/ So, yep, builds are done...

So, moving `octoprint_setuptools` into its own pypi package sadly doesn't solve this for `setup.py` based isolated installs. `setup_requires` in `setup.py` can (obviously) only be evaluated once `setup` has been called....

I've extracted `octoprint_setuptools`. So plugins that already use or want to switch to using `pyproject.toml` can now do this by adding this to `pyproject.toml`: [build-system] requires = ["setuptools>=40.8.0", "wheel", "octoprint-setuptools"]...

> either by recognising `LFN_WRITE` Is that a newly introduced capability flag that gets included in the `M115` response?

Thanks, that clarifies that.

Implemented and ready for 1.9.0. If `LFN_WRITE` capability is reported as supported, OctoPrint by default now will upload SD files to the printer under their full name instead of shortening...