ahoeben

It was reported already here:

You can shift-drag to reposition the camera. There are also options to zoom towards the mouse pointer and the move the camera to the center of the selected model in the General preferences.

Voor mij zul je altijd erry blijven 😉

Do you know if this has been reported on github?

Realise that if it were as easy to use a "load a file with a texture into Cura, slice and print a perfect end-result", it would have already been included as a feature. Last I heard the state of the art is a CuraEngine that can only be used through the command-line with quite a bit of manual editing of profile files.

I think you meant to say it isn't part of Cura.

The initial layer height is meant to compensate for a non-flat buildplate. It is generally a good idea to keep it a bit higher than the rest of your layers. Lowering the initial layer height willmean that less material is extruded for the first layer, so you DON’T get better layer adhesion that way. To do what you wanted to achieve (squish the print into the buildplate), install the Z Offset plugin. That will allow you to move the whole print down into the buildplate a little, up to the height of the initial layer.

The leak involving the camera image was fixed in Cura 3.6

Perhaps you could explain what it is you have an issue with? Your layer view is in "Compatibility mode". For the more advanced layer view, you need a GPU that supports OpenGL 4.1. If your GPU does not support this, it switches to this "Compatibility mode" which only requires OpenGL 2.

There currently is no better way Postprocessing scripts are executed right before saving/printing, not right after slicing. On top of that, for performance reasons, layerview gets specially crafted data from the slicer so it does not have to parse gcode after slicing. That data would not get postprocessed. So there are two hurdles here.

What if you use Export, instead of Save?

The firmware updater has been changed though (as in: the part that flashes the firmware). Unfortunately, I don't have an UMO+ to test with.

I’m fieldOfView on github.

Have you tried the Z Offset plugin from the Marketplace?

STL is a rather simple format. It does not support including properties (eg "this is a support blocker", or "print this with extruder 2"), nor does it really support separate objects in a single file (they will become one "body"). With a more "intelligent" file format such as 3MF, it is possible to add metadata and multiple models.

If you have set temperatures etc in a profile (Alf Profile 0.2), those will override what you set in the material.

My previous reply ("bugs happen") was not very helpful, sorry for that. I'll try to do a better job at explaining why what you are asking may sound obvious, but is actually more complicated than you would think. You use the word "backwards compatibility" from the perspective of the file. "Backwards compatibility" sounds like a very obvious thing to exist with any software, right? But there's the thing: from the perspective of the software, what you are asking is *foreward compatibility*. Backward compatible software can (eg) load files created with previous versions of the same software. Cura can do that; it contains code that detects the version a file was saved with, and version-by-version it applies changes to the file until it matches the version you are trying to load with. So if you are loading a project file, or a profile file created with 3.1 into 3.6, the file will be converted first from 3.1 to 3.2, then from 3.2 to 3.3, from 3.4 to 3.5 and finally from 3.5 to 3.6. Not all of those steps are complex (because the settings format does not normally change all that much between versions), but all these steps are performed. Foreward compatible software can load files created with future versions of the same software. This is a lot less straightforward. You could think "just do all those steps backwards". That *could* work (even if creating the backwards step is not always straightforward), but the real problem here is that the old version of the software cannot yet know what changes are made in future versions of the files, because the future software did not exist yet when the old version was made. So Ultimaker would somehow have to update all the old versions of Cura with information about how the current version has been changed. And the result would still be less than perfect, because the new files could still rely on features that are simply not available in the old version. The bug that "happened" is that Cura tells you that the profile was succesfully imported, whereas it should tell you something like "sorry, this file was saved with a version of Cura that is newer than what I can handle". Also note that this bug will probably not be retroactively fixed in previous versions, because Ultimaker has not released updates for previous versions since Cura 2.3 was released.

> it does say it is imported succesfully but doesnt show up to select. Bugs happen.

Generally it should be possible to import profiles and configurations from older versions, but newer versions may not import correctly.

Cura is not a “MakerBot software”, unless you mean it is software for 3d printing in the same way that all copiers are called xeroxes. There is a z-offset plugin in the marketplace (or toolbox, depending on your Cura version). Also note Lulzbot has its own version of Cura specifically for their line of 3d printers, and their own support forum.

Correct. It would be nice to *see* the settings though. Perhaps I'll have time one of these days to finally implement that.

What GPU are you using? Please update to the latest version available.

You can sort-of get the setting back in the sidebar with the Printer Settings plugin from the Marketplace, though it will be in another category.

The sliced data can only be saved as gcode, not as a polygonal model. Mostly because the sliced data is not polygonal in nature.

A version of the plugin compatible with Cura 3.6 is now available through the plugin browser Toolbox Marketplace.