@Jesper_Lindeberg Simplify3D is closed-source, commercial software witha $140 price tag. That’s nearly half the cost of my little PrintrBot Simple!
I’ll stick with open-source; it just seems to fit the idea behind (most of) the printers this community uses.
I know, but for me software is just as large part og a perfekt print as the hardware. So if I, pay 500-1000$ for a printer, 140$ is a small part. I used all the opensource slicer’s, but they all have bugs and missing things. Then I found kisslicer which was all most perfect, but I dead now 
Now simplify 3d does it for me. Maybe some day I will use one of the open source slicer’s again when they catch up. Still recommend cura for friends as a perfect beginner slicer. 
Create ranges in Z and specify # of perimeters and infill density for those ranges.
Full contact support all the way, aiming at disolvable support.
I want an "inset"option to counteract the perimeter of prints spreading out further than it should, so that parts don’t fit together. This would make it possible to increase the tolerance between parts at slicing time rather than design time (only on X and Y, as this is where the printers are bad at producing accurate tolerances due to the shape of the plastic being laid down).
@Whosa_whatsis as you probably know Kisslicer had this and I use it quite a lot, not to mate raw printed parts but to account for building the surfaces when painting. Very usefull feature indeed.
@ThantiK yep… I’ve played with meshmixer but I find its not as effective as good old ‘solid’ supports, particularly with curl prone ABS. I just want the same capability as the UP! Supports-wise.
@Dale_Dunn Ok, you’re quite right, I was being sloppy in the interests of brevity. How about: algorithm driven, non homogeneous infill density in order to maximise part strength while minimising material costs and print duration?
One of my ideas for this is a graduated infill foam, where the infill is effectively a bunch of hollow spheres with very small spheres at the edges and progressively larger ones towards the centre. This would solve any issues with supporting flat surfaces, as spheres tend to print well enough, even if the top few layers might sag a touch. Granted this would be time consuming to code and probably be processor hungry wrt slicer use but I bet the resulting part would be very strong.
I think improved support usability and reference calibqrtion tools would be very helpful, especially to those learning.
@Tim_Rastall , I suspected that might be the case, but I was apparently feeling pedantic. I was thinking similar thoughts to what you just described, actually. The previous conversation with @Gary_Hodgson about alternative fills had me thinking about octahedrons instead of spheres, with solid meshing algorithms borrowed from FOSS FEA.
I’d like selective support. Have it where you highlight a box around the desired area then extrude the selection box and areas within that box that can take support get it those not selected won’t
@Tim_Rastall I want to expand on your configuration stls:
what would be better is if the slic3r could output a gcode with a bunch of different settings in one print. ie -
do a number of bridges at different speeds.
do a number of retraction tests at different speeds
some acceleration tests - lay down an extrusion line, zip back and forwards a couple of times, lay down an extrusion, repeat at increasing levels of acceleration andor jerk.
looks at the result and see where the extrusions stop matching up (from missed steps)
sorry this is a bit long.
@Jonathan_se5a_Sorens Yes, absolutely. As above, I’d tried to keep it brief to start with but I’ve also had that idea in mind. I figured you start with hollow calibration cubes, then solid ones to dial in flow and temperature, you then move on to bridges, ooze towers lash mazes etc. Each printed part produced would be identifiable in some way, perhaps by notches in the perimeter, that way you can just tell the slicer which one was best and it could adjust it’s settings accordingly. Some pictographic comparisons would also help.
@Jonathan_se5a_Sorens @Tim_Rastall I think that type of thing would make the slicer bloated. A better way would be to have an external script that runs a model through the slicer with various settings (and in different locations on the platform), then combines the output into a single print for testing. If it was built into the slicer, it would have to be in a special calibration section that is clearly segregated (select an item from the menu bar that opens a new window that looks very different) from the parts of the program used for normal, everyday printing.
FYI @Daid_Braam & @Alessandro_Ranellucc number 1 thing that people want from slicers (based upon this highly scientific survey) is Snap Away supports.
@Tim_Rastall The number 1 thing people want, on google-plus, is snap-away support. Do not confuse “people on google plus” for everyone that 3D prints.
Better support material. Controlling outer perimeter speed. Z-Hop and better bridging support. That’s the main things people ask from Cura.
@Daid_Braam wtf did you think “(based upon this highly scientific survey)” meant?
@Daid_Braam , @Tim_Rastall did acknowledge the fact that his sample size was neither terribly large nor necessarily representative (though I don’t see any reason to assume a bias) with his tongue-in-cheek reference to the survey being “highly scientific”. Considering that the poll was about several slicers and not just Cura, and and the feature @Tim_Rastall mentioned is the only one on your list that users aren’t requesting because the other slicers mentioned have more comprehensive support for them than Cura currently does, I’d say his results coincide pretty well with your other feedback, so I don’t see any need to get snippy about it.
It was not my intention to get snippy about it. Just stating this before people will start shouting “everyone wants X”. Sorry if it sounded snippy.
I agree that support material needs some big improvements. It’s high on my wish list, and I’ve been thinking about different ways to achieve it (not just an idea, but actually something that I can implement, but so far I’ve always ran into some problems that I haven’t found a full solution yet). I’m also improving model compatibility, refactoring a lot of GUI code, and fixing the GUI<->engine interface for Cura. And I’m improving the GCode rendering code so it’s faster (and ready for more features later on)
Adding outer-perimeter speed is on the “todo-soon” list, as well as “z-hop”.
Other things that people have asked from me, but I do not see in the above list is “inter island combing”, and variable-layer-height slicing.
@Daid_Braam perhaps I should have attempted to be a little less funny in my FYI. But as above and imo, supports that come away cleanly is a really key feature that the closed source machines like UP! have nailed but it’s still a bit sketchy with all the open slicers. I don’t mind you getting snippy, I use Cura more and more and I appreciate your community involvement, just wanted you to know that this is what this particular group thought was important. Tbh, if your support feature had configurable interface layers like your excellent raft feature does, it would likely be a winner.