ahoeben

The best way to test Cura 2.5 would be to make a copy or backup of your configuration folder. You can easily open that folder by going to Help -> Show Configuration Folder inside Cura 2.3 and going up one folder. Create a backup of the folder named "cura". Note the path of the folder (should be something like C:\Users\[youname]\AppData\Local) Now you can install the Cura 2.5 beta and run it. If you are not happy with Cura 2.5, uninstall it and go back to the AppData\Local folder you noted down, delete the cura folder and put back the backup. Now you can run Cura 2.3 again and it will be like nothing happened.

What OS are you using? What is the resolution of your screen?

There are no manual printer controls in Cura 2.x yet. They will likely return in a future version.

There is no way to edit the number of extruders in the GUI. I am working on that for Cura 2.6 If you want to add a custom dual extruder printer, you have to write a machine definition (and multiple extruder definitions). See the Ultimaker Original Dual Extruder definition for an example.

No, that is not intended. The intention is to have to authorize a computer only once.

The modeler you used uses a different "winding order" for normals. So the part of Cura that visualises overhang actually thinks your model is inside-out, which makes causes overhang to be shown on top surfaces instead of bottom surfaces. http://cmichel.io/understanding-front-faces-winding-order-and-normals/ CuraEngine (the part of Cura that does the slicing) does not use the normals of the geometry, so it is no problem for printing.

@bagel-orb is the CuraEngine man, not so much the front-end man. Rotation should not be affected by whether or not the object fits the buildplate. Something to check is whether the other axes work in the other tools (move, scale, mirror). It sounds like the "picking" of the axes model is broken for you. I vaguely remember reading that before but can't remember if it was resolved.

Check out postprocessing scripts. See plugins/PostProcessingPlugin/scripts

Aww, come on! You break it, you fix it ;-)

Pro-tip: it is a good idea to keep a backup of that whole configuration folder, in case something goes wrong and eg Cura will no longer start.

PVA supports are supposed to be dissolved in (warm, not hot) water over the course of a couple of hours.

Yes, that would be useful to have too. I've been waiting for Alephobjects to create a PR of their usb rework, but I might go ahead and implement my own proposal for 2.6: https://github.com/Ultimaker/Cura/issues/1049 https://github.com/fieldOfView/USBConnectionMockup

The values are stored per the GUID value. Unfortunately when you duplicate a material this also duplicates the GUID, and so it "links" the materials together

It does save the settings in the cura project file. How do you load the project back in? You have to use the "Open Project" menu, or else the project is loaded as a model, without settings

They are saved in cura.cfg

It is called a "prime tower". It is printed there to make sure each extruder is "primed" (topped up with material) before starting its part of each layer. You can turn it off if you wish in the custom settings

Beat ya to it: https://github.com/Ultimaker/Uranium/pull/235

The best cookies are Cura cookies:

Better tl;dr: "Yes it's possible, but would slow down your computer or cost a lot of resources to build" Spend enough time & resources on it (that cannot be spent on anything else), and it should be possible to get it to perform well on OpenGL 2.1 too.

That is how the feature works. It only works on the x and y axes, so it does nothing on the top/bottom of a print.

Most straightforward way is to remove the USBPrintingPlugin for now.

No problem. You do make a valid point with the zooming. It would be a shame if it gets lost in this thread. Posting requests like this on github has a larger chance of being noticed (and remembered!) by devs. http://github.com/ultimaker/cura/issues

Why do apples taste different than oranges? Both are fruit! The new layerview in Cura uses geometry shaders to offload most of the heavylifting of making the layers look spatial to the GPU. This way it can be done without too much change to the underlying code without a bug impact on performance. Replacing the entire architecture of Cura to improve layerview just wasn't going to happen. The new layerview is an evolution, that leverages more modern GPUs in a smart way. PS: remember layerview in Cura 2.1? Woah, things improved over the past year!

The "Wall Thickness" setting got disabled because it was overridden by the value you entered in "Wall Line Count". Just because you hid the "Wall Line Count", it does not mean this value has gone away (it is like sweeping the value under the carpet; it is still there). If you press the "revert arrow", this removes the absolute value and reverts back to the value that is calculated from the "parent" setting. To make you understand, keep both the "Wall Line Count" and the "Wall Thickness" visible. Now change the "Wall Thickness" value and you should see the "Wall Line Count" value update automatically. The latter is calculated from the former. When there are nested settings, CuraEngine always only uses the last setting in the branch. The parent settings are mostly convenience settings; it is often easier to think in millimeters than in the number of perimeters and calculate that back from the line width.

I don't know, is it too hard to suggest this as a feature without sounding like a nag? ;-) There are lots of things that may not be too hard to implement, but there is a limited amount of time. Ask nicely, and make sure the usecase or usability improvement is clear, and it may get implemented.