Discussion and suggestions about changes for the default Creawesome Creality printer profiles.

[JohnEdwa]

The new Creawesome profiles have some odd choices, some missed Cura features and in my opinion, could be better. After a very small Reddit discussion, I compiled my proposed changes and would like to get some feedback and as a possible result, have updated and better default printer profiles included into Cura.

For reference, these are all changes for the "creality/base/base_global_standard.inst.cfg" using the printer "creality_ender3.def" that itself is based on the "creality_base.def.json" definition.

The comments are mostly mine, and might (will) have factual errors and misunderstood functionality as I'm not a Cura expert.
Cura Profile: creawesome_ender3_change_suggestions_v1.zip

---

#Suggested in the discussion but I don't know about them

• Print Thin Walls should be enabled.
• Minimum Extrusion Distance Window: 10 is to large of a value according to /u/Liger_Phoenix
• Line Width should be equal to Nozzle size, according to /u/Liger_Phoenix

---

creality_base.def.json

#Shell

• Outer Wall Wipe Distance: 0 -> 0.2mm // this is supposed to reduce the Z-seam, so why not use it?
• Filter Out Tiny Gaps: False -> True // the tooltip just says "Filter out tiny gaps to reduce blobs on the ouside of the model". Sound fine to me
• Seam Corner Preference: None -> Smart Hiding // Hiding works rather well and looks good.
• Z Seam X: 117.5 -> 0 // Using the Relative Z seam instead
• Z Seam Relative: False -> True // see above
• Optimize wall printing order = true # helps reducing unnecessary travel (Pimentoso)

#Material

• Retraction Extra Prime Amount: 0 -> 0.064 // see Enable Coasting at the bottom - should be a nozzle-based function and not a hard value.

#Infill

• Infill: Cubic -> Gyroid // /u/Liger_Phoenix: "I find it works everywhere and everytime... ...the gyroid is the optimal starting point for any stock machine."
• Infill Overlap Percentage: 30% -> 15% // 30% can cause issues in narrow spots without much benefit
• Infill Before Walls: False -> True // Much better overhangs and the infill showing up is never going to be an issue with the default 3 walls.

#Travel

• Combing: Infill Only -> Not in Skin // Faster priting, but seems to be practically the same quality
• Z-Hop When Retracted: True -> False // Easily causes uneven layers as the leadscrew can bind and the nut has backlash. It's also not really needed for anything if you aren't overextruding and avoid printed parts is enabled.

#Support

• Support Type: Buildplate Only -> Everywhere // Supports should always default to everywhere for newbies. Supports = I want the print to succeed.
• Minimum Support Area: 10 -> 5 // Helps support smaller details
• Use Towers: False -> True // Helps reduce the generation of tiny thin supports with no chance of staying up Liger0: "I'd disable the towers tho, because towers are bugged and are created randomly even if they don't have to support anything."
• Support XY Distance: wall_line_width_0 * 2 -> machine_nozzle_size // Liger0: "if you enable supports everywhere, you have to use a littler x-y support to model distance
• Minimum Support X/Y Distance: wall_line_width_0 -> machine_nozzle_size / 2 // now same as old fdmprinter default
• Support Interface Resolution: 0.2 -> layer_height // Should this be kept at a hardcoded 0.2?

#Build Plate Adhesion

• Build Plate Adhesion Type: None -> Skirt // Skirt is always good for priming the nozzle and checking first layer squish
• Skirt Line Count: 4 -> 2 // ...but you don't need 4 lines for it.

#Special Modes
* Relative Extrusion: False -> True // /u/Liger_Phoenix: "Relative extrusion can be enabled and is always recommended on Marlin." Breaks scripts. Should not be used.

#Experimental

• Slicing Tolerance: Middle -> Inclusive // /u/Tarasque_1024: "anything else might drop details on some models"
• Enable Coasting: False -> True // /u/Liger_Phoenix: "it will work always fine and make seams and underextrusion disappear.
• Overhang wall angle = 50 (Pimentoso)
• Overhang wall speed = 66% # helps having good overhangs at higher speeds (Pimentoso)
• Enable Conical Support: True // These work kinda like support towers but they don't bug out.
• Conical Support Angle: -2
• Conical Support Minimum Width: 10

---

Printer definitions:

• machine_head_polygon should be removed to let One-At-A-Time print with the head clipping over the build plate edges as Cura uses the "machine_head_with_fans_polygon" to set how close models can be to each other.

---

[EDIT] Removed support towers, added support XY distance and interface skip heigth
[EDIT2] Support XY distances.
[EDIT3] Remove "machine_head_polygon" from printer profiles.
[EDIT4] Overhang wall angle, Overhang wall speed, Optimize wall printing order, Enable conical supports.
[EDIT5]RElative extrusion breaks scripts and other things as they almost always assume absolute extrusion and will default to them at the end.

[nallath]

Coasting on a direct drive printer? Are you sure about that? I've only heard complaints about coasting being enabled by default (the main reason for it is that it does work for Ultimaker printers).

[Liger0]

Creality machines are all bowden.
I'd also disable "perimeter overlap", it always gave me bad results.

[FITPrinting]

Coasting on a direct drive printer? Are you sure about that? I've only heard complaints about coasting being enabled by default (the main reason for it is that it does work for Ultimaker printers).

Creality machines are all bowden.
I'd also disable "perimeter overlap", it always gave me bad results.

Between this thread and the other where "nallath" is defending the forced adoption and overwriting of saved profiles, it seems obvious that they don't know anything about the machines that are being affected. Opt out (not that there's a way to opt in now) is never the proper procedure and I wonder how badly the code has been written if the only way to update it was to force it to overwrite where it wasn't welcomed.

[nallath]

Between this thread and the other where "nallath" is defending the forced adoption and overwriting of saved profiles, it seems obvious that they don't know anything about the machines that are being affected.
You're right. I have absolutely no idea how ender printers work. I also never pretended to do so.

So we simply rely on what others tell us in that regard. As I've stated before, although this feedback is welcome, it's a bit on the late side to change it.

[JohnEdwa]

They probably don't, Cura is from Ultimaker designed for the Ultimaker printers, everything else is a bonus supported by the community. That means us.

In any case, let's concentrate on fixing and making them better than bicker about who did what wrong, it doesn't help anything.

[Liger0]

Only who used the creawsome mod knew that was going to be incorporated to Cura because they followed the creator, its group, posts, etc, there is no way other people would have known it.
So of course we had really no way to complain about it before it was done, since none of us was asked and no plublic announcment was ever made, and none of us ever focused on what was happening to that useless mod. That just seemed a different alternative for lazy users (read: not new entry, because new entries can just learn like everyone else), so that shouldn't have affected so much people which had everything ready and optimized profiles that may even use it for work and made a reliable profile, which become unreliable with this new mod without them being aware of it in any way.

By the way, I think who made this mod wanted to help but doesn't really have a clue on what is better for creality printers, so I hope someone will make the changes suggested here.

[nallath]

You could have found out by means of beta's, forums and github. The sad truth here is that we simply have to give priority to people that do involve themselves in the entire process of a Cura release.

The argument regarding that those profiles are bad is re-iterated over and over again, but I've talked to numerous people that claim that the profiles are a vast improvement over what was already there. So who are we to believe then? People who take the time to try and improve Cura or those that we only hear if their workflow is affected? I try to facilitate both, but the earlier we get feedback, the easier (or at all possible) it is.

Even if I were to agree that the change was bad now, I would still not change it back, because it would simply be doubling down on the issues in the next release. I think it's a much better idea to do what @JohnEdwa suggests; Use the profiles as they are and improve on them further.

[JohnEdwa]

Issue #6134 is the first proper one to come from the current stock Creawesome settings. Supports are limited to "Touching Buildplate" so they aren't being generated as people expect using recommended settings.

This should be changed immediately to "Everywhere" even if no other changes are made.

[Liger0]

If that gets to everywhere, I'd disable the towers tho, because towers are bugged and are created randomly even if they don't have to support anything. This would ruin the surfaces if they are printed on the model.
Also, if you enable supports everywhere, you have to use a littler x-y support to model distance, which could make normal supports harder to remove but helps with supports generated in the mid air oinly partially touching a piece.

[JohnEdwa]

The main reason I like using Support Towers is that without them Cura likes to generate supports like these and they have absolutely zero chance of staying attached to the build plate. Well, now that the prime tower got it after over two years of being in the "top 50 important features" list maybe they can add them for the supports as well.

---

The old XY distance from the fdmprinter default was 0.7mm, Creawesome has it as wall_line_width_0 * 2, meaning with the 0.4mm nozzle * 1.1 * 2 -> 0.88mm.
Should it be one line width from the wall instead or would that be too close and risk fusing... Maybe 1.5?

[Liger0]

If we want the supports to be created from the model overhangs, 0.8 is way too high. 0.3 to 0.5 should be for a 0.4 nozzle.

[JohnEdwa]

Would seem logical to then set them to be based on the nozzle size.

• Support X/Y Distance: wall_line_width_0 * 2 -> machine_nozzle_size
• Minimum Support X/Y Distance: wall_line_width_0 -> machine_nozzle_size / 2 (which would be the same value it used to be with the old fdmprinter setup)

[huginen]

It should be a good idea to let the user choose either to use Creawsome or a standard profile, my cr-10s prints great with a slightly modified standard profile, and not any better prints with Creawsome

Every printer is not the same

[Liger0]

The only setting that makes sense on the creawsome mod is the 0.04 layer height interval on adaptive layer.

[JohnEdwa]

I think it's too conservative, 0.02mm or even the old stock 0.01mm should be perfectly doable if your leadscrew and stepper are aligned. The Creality printers have 1/16th microstepping on the Z-axis with the 0.04mm lead so it can move in 0.0025mm increments (in theory, it only has 6.25% of the max torque so asking it to do just that has a very high chance of not working), and those would be 1/2 and 1/4th steps.
It's not like a printer that homes, uses babystepping or even mesh bed calibration will ever actually be doing perfectly aligned full steps when changing layers.

I think the Creawesome dev jumped on the "Magic Numbers" bandwagon slightly too hard.

[Liger0]

The 0.04 increments actually help in accuracy.

[JohnEdwa]

If it was actually moving with full steps I would absolutely agree, going from a full step 0.04mm to a full step 0.08mm has 100% the torque and it will hit that step position exactly. But it's not. You home your printer and the stepper stops at a 6/16th microstepped position because that's where your end switch is. Now when you start printing with those 0.04mm incremental layers, you are asking it to move from 0.00mm + 6/16th microstep to 0.04mm + 6/16th. Then to 0.08mm + 6/16th. Then 0.12mm + 6/16th and so on.

It makes very little difference for it to move to that 0.04mm + 6/16th or to 0.04mm + 12/16th, it has to move to a microstepped position anyway. Only diffrence is that if you ask it to move from 6/16ths to 7/16ths, the static friction will most likely prevent it, until enough small steps have accumulated and it can "unstick" itself and move to wherever it should now be. This is why you shouldn't do too small movements.

[EDIT]

---

@huginen What they should have done is to leave the old printers as legacy for us with custom profiles, but made it so that all new ones are created with (fixed) Creawesome profiles, because the old defaults really weren't that good. For theEnder 3, yeah it had some tweaks, but a CR-10 S4 and S5 for example had nothing. The only difference for the Cura defaults that aren't tuned for any printer was setting the build volume, and that's it.

---

I noticed the printhead size is configured wrong as it prevents you from printing one at a time to the edge of the build plate - I think it is the same as Issue #5590. I've fixed it before but I can't remember how I did it...
It's not the skirt/brim thing either, as those clearly fit.

[EDIT2] Ah, it was removing "machine_head_polygon" and leaving only "machine_head_with_fans_polygon".

[/EDIT]

[Pimentoso]

I might suggest some too.

• Overhang wall angle = 50
• Overhang wall speed = 66% # helps having good overhangs at higher speeds
• Optimize wall printing order = true # helps reducing unnecessary travel

[JohnEdwa]

Oh neat, hadn't even noticed those overhang ones exist.

Another one in the experimentals is "Conical Supports". When you set it to a small negative angle they work how I want Support Towers to work like without the buggy behaviour of generating supports that don't do anything randomly. That is, it makes sure the support is a certain minimum size at the bottom.
I still gotta test how it works in more situations though.

[Liger0]

Also default first layer height to layer height instead of them being kept separated values.

[Ghostkeeper]

Another one in the experimentals is "Conical Supports". When you set it to a small negative angle they work how I want Support Towers to work like without the buggy behaviour of generating supports that don't do anything randomly. That is, it makes sure the support is a certain minimum size at the bottom.
I still gotta test how it works in more situations though.

I really like conical support myself and use it quite often. We have to re-evaluate to put it outside of experimental. As far as I know the last bug that was in there recently was fixed in 4.2: That it could expand to outside of the build volume.
Conical support is very effective when combined with supporting to build plate only, because the support can crawl around your object then similar to tree support.

[oofiksoo]

does anyone feel like this "upgrade" ruined your prints? it appears as though simply upgrading cura has caused my brim lines to be separate. It doesn't appear as though I am able to achieve the proper "squish" any more no mater how I adjust the build plate or adjust the z probe offset. This issue became prevalent after the upgrade, as I use my printer daily, I noticed the change immediately, but chalked it up to me needing to fine tune based on the new functionality. I do not see a way for me to "fine tune" this to the level I had it tuned prior to the upgrade. To put it simply, I do not see a benefit in this change, and believe this should have been optional, or should be further exposed in the configuration allowing me to adjust the "improved" values. basically, I feel like I am dead in the water right now. Nothing I do brings my quality back. I will be compiling a ver 4.1 release and not upgrading going forward.

[Liger0]

Because the line width is now set to 1.1*nozzle size, so it risks to cause underextrusion, while before you risked overextrusion. Either set manually the line width each time or calibrate the flow.

[Liger0]

Let's show you what the creugly mod implementation has caused to users:
https://www.reddit.com/r/CR10/comments/ctlspe/left_print_is_older_cura_right_print_is_newest/

In a few words, only issues.
The only way I can succeed printing now is enabling firmware retraction, but that causes a lot of stringing.
Also, 30% of infill overlap causes issues with material on the corners, I lowered it to 20.

Then another stupid thing is skirt gets disabled when enabling support.

[oofiksoo]

I can fully confirm my issues are resolved fully by reverting to a fresh copy of cura 4.1. I lost my customizations because I wanted to ensure there was no leftovers, and did a full uninstall reinstall. Even without customized profile, my prints are of better quality than 4.2 prints. I feel confident that there are issues with this functionality that should not have made it to production, without further testing. I do not believe the issues are limited to configurable changes within cura 4.2.

[Liger0]

Edit: now the skirt disabled when support enabled has been fixed by ghostkeeper. Still I have issues with retraction causing clogs with 4.2.1 unless I use firmware retraction.
There are a lot of people reporting how shit the creugly implementation was, yet just another one:
https://www.reddit.com/r/3Dprinting/comments/ckq73i/thanks_cuts_for_forcing_the_creawesomemod_upon_us/

[oofiksoo]

I feel so strongly about this issue, and the way that Ultimaker is handling the issue, that I am compelled to copy/paste my message left on a seperate thread. I challenge all readers of this post to make your voice heard as well. Although I personally will no longer have a vested interest in the ultimaker cura development process, For your own sake, Please challenge the pride and ego of the development resources responding to our posts, and request this functionality be corrected.

" Ok, I will not be purchasing an ultimaker printer, and I will no longer be using the ultimaker software. The consistent response of "we made this change, your not happy about it, you should have done something about it, we're open source" is bogus. Not everyone in the world has time to help ultimaker make money and build as a company. Even if you offer an open source product, it is possible that your small group of people made a bad decision. The Creawsome functionality should not have been introduced, and your pride will simply not allow you to admit that this was a rush job. You guys saw a few happy campers within the same cohort, and though this functionality was great. This is a direct failure by the "open source community" working on Cura, and you are being absolutely rude, condescending, and off putting. You are not special because you are offering an open source product, and the users of the product should not be made to feel like we owe you something, we should be happy with what you give us, and we should shut up if were not contributing to your growth.
As I said before, I will not purchase an ultimaker printer, And I will not be using the Ultimaker Cura platform. I can deal with issues, bugs, and things that need my attention, But I will not support a company so off putting, and whom responds with the remarks such as yours. It is obvious that this is an issue, it reaches many of your users, and you refuse to take any other position than for us to contribute or shut up.

The functionality is NOT correct, It does not improve the software, and IS AN ISSUE. Try to sweep it away any way you want, but this is a MAJOR FAILURE! "

[Liger0]

Since with the creugly implementation, using the creality machine definitions has become impossible, I will have to use and set from 0 a generic fdm machine from now on. Thanks for making life so hard to the community making your software unusable...

[hessius]

(Maybe the general complaints about how unfair, wrong or plain evil people seem to feel the well intentioned decisions of the people making free software (and mods of that software) for us can be kept to reddit / facebook etc. Or at the very least another thread as this was intended to actually try to remedy the situation. Everyone knows that you are dissatisfied, the point has been made. Several times. Maybe we in the creality community can start trying to fix things?)

For me I’ve found that the retraction set as default for this profile has been insufficient to prevent stringing, I’ve seen the suggestion of enabling coasting and have yet to try it, maybe retraction distance should be upped to 6.0 anyway?

[Ghostkeeper]

Could you share a project file that reproduces the problem?

[Ghostkeeper]

Can we consider these changes complete for now? We haven't had big complaints recently.

[kazooless]

I guess so. Personally, after using the new profile names, I still would prefer to see them renamed back to the old names. When I switch to a printer which doesn’t have a Creality base definition, I can’t share my printer profiles. I find that very annoying.

…

_____ Jeff Kazules Sent from my iPhone

On Jul 23, 2020, at 5:36 AM, Ghostkeeper ***@***.***> wrote:  Can we consider these changes complete for now? We haven't had big complaints recently. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Ghostkeeper]

If the profiles are not specific to Creality printers you could share custom profiles with other printer types that don't have printer-specific quality profiles. However that would also mean that the Creality profiles would be part of the global profiles. They are specialised to Creality printers though, so I don't think that would be a good idea.
Basically, the requirement for using a custom profile is that the profiles that the custom profile was based on need to also be available for the printer that you're using. This requirement is preventing access to custom profiles based on Creality profiles when you're using non-Creality printers.

This thread was about individual setting default values though, not about custom profiles.

[kazooless]

Ahh, you’re right wrong thread. Sorry about that. For printer profiles, I am not seeing many complaints in the communities I hang out in any longer, so I’d say this can be closed. On the custom profiles topic, I understand everything you said there and I’m just putting in my 2 cents that after using it this way for all these months, I am definitely of the opinion this is not a good thing. Especially now that I have added other branded printers. If there is still an old thread on that topic open, I can add these comments there. Thanks Ghostkeeper! Jeff

…

On Jul 28, 2020, at 4:07 AM, Ghostkeeper ***@***.***> wrote: If the profiles are not specific to Creality printers <https://github.com/Ultimaker/Cura/blob/56fc5f9706c9d7e7d3f70a7fc166ad91aedbbc0e/resources/quality/creality/base/base_0.4_PLA_standard.inst.cfg#L4> you could share custom profiles with other printer types that don't have printer-specific quality profiles. However that would also mean that the Creality profiles would be part of the global profiles. They are specialised to Creality printers though, so I don't think that would be a good idea. Basically, the requirement for using a custom profile is that the profiles that the custom profile was based on need to also be available for the printer that you're using. This requirement is preventing access to custom profiles based on Creality profiles when you're using non-Creality printers. This thread was about individual setting default values though, not about custom profiles. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJIUPM3CJ5ZUM3GFFKOPKLR52WONANCNFSM4IIK3LSA>.

[Ghostkeeper]

#6124 is the closest bug report that I could find. If you want to open a new discussion about how/which profiles are matched to each printer, that's fine too. It's a complex topic and there will not be an answer that works for everyone, but if there are ideas out there on how to improve I'd certainly like to hear them.

[Liger0]

I think that removing "adaptive layers" from 0.16mm layer height on the cr10s would be good.

[Liger0]

@Ghostkeeper I'm not sure it's present in other settings depending on the nozzle size, but removing adaptive layers in all the profiles where it's enabled would be useful.

[Ghostkeeper]

I thought Adaptive Layers was kind of the point of the "Dynamic Quality" profile. What would make it "dynamic".

[Liger0]

Well, I only consider the basic layer height when using a profile, and I think that having a basic 0.16mm one would be useful. Since none of the other layer heights has adaptive layers, only using it on a profile would be confusing as you may not notice it and just select it because of its layer height.

[kazooless]

@Ghostkeeper So, to pick up or start or restart the topic about "how/which profiles are matched to each printer," you would prefer we go to #6124 and discuss? Or would you just like a new discussion dedicated to the idea started?

Regarding "Adaptive Layers," here are my two cents: If "Dynamic" has that name because of adaptive layers, then to make that clear, move the option to the Quality section so it stands out. I realize it is in experimental now and I don't know how you decide it is ready to be moved to a permanent section, but that is my first suggestion. If that isn't possible, code a flag that turns on in that section which calls attention to the fact it is turned on.

[Ghostkeeper]

I'd prefer keeping that discussion in its dedicated issue at #6124 indeed, Kazooless.

We can't move Adaptive Layers to the "Quality" setting category since its implementation is experimental. The problem is not that the settings haven't been properly tuned or anything, but that the setting breaks the following settings:

• Top Thickness
• Bottom Thickness
• Maximum Skin Angle for Expansion
• Gradual Infill Step Height
• Gradual Support Infill Step Height
• Infill Layer Thickness
• Support Infill Layer Thickness
• Support Z Distance ([4.1.0] Adaptive Layer & Support Z Distance #6188)
• Support Roof Thickness
• Support Floor Thickness
• Support Overhang Angle ([3.4.1] Adaptive layering interferes with support structure generation #4396)
• Support Stair Step Height
• Tower Roof Angle
• Ooze Shield Angle
• Maximum Model Angle
• Infill patterns that have a variation over the layers (like Gyroid or Cubic Subdivision).

Basically everything that needs a certain measurement of height across different layers is not calculated correctly any more.

Just because one profile wants to use the setting is not a reason to consider this bug any less serious.

I know that the standard response from some developers to being unsure of something is to put warning messages in the user's face, but 99.9% of the time that's not what the user wants to see and just annoys them. We try to prevent having warning messages that always trigger upon doing something normal (like switching to a certain profile). The better solution is to make sure that the user needs to explicitly enable experimental things (which is why this setting is in a category called "experimental") or to accept that they might get a less-than-optimal print result sometimes. Since these profiles have been optimized by users of this third-party printer, we trust on them that they've accepted the results as they are. Maybe the printer deals with wrong overhang angles or thin skins particularly well, or maybe the settings have been tuned to accommodate for such discrepancies when they occur.

[Liger0]

@Ghostkeeper wouldn't it be better to make the line width parametric by default, so to set it as "nozzle_size" rather than a fixed value? You can easily use the same profile for multiple usages when swapping nozzle in this case.

[Ghostkeeper]

Indeed the default in fdmprinter sets the line width to be equal to the nozzle size.
The creality_base definition overrides it with the same formula, I see. Unnecessary, but harmless.

[andrew-benjamin]

@Ghostkeeper @Liger0 , thanks for merging the thread, having read the above I understand why 'adaptive layers' still experimental but perhaps this is just a title issue. The default profiles in Cura are Super 0.12, Dynamic 0.16, Standard 0.2 and Low 0.28. Can the '0.16mm' text be removed from the 'Dynamic' description as by the settings it will often not be anywhere like 0.16mm?

[Ghostkeeper]

Cura actually adds that itself. The profile is just titled "Dynamic Quality".

Maybe it would be good to make the layer height a bit smaller in the header bar than the rest, to make it clear that it's not part of the profile title. But that could also look a bit weird with different font sizes on one line.

[andrew-benjamin]

Perhaps change 'Dynamic Quality' to 'Dynamic Layer Height (Experimental)' so it is clearly different from the tried and tested layer heights. Then, add a new 'Fine Quality' default 0.16 with no dynamic setting.
This would fix any risk of user misunderstanding on this feature since its experimental.

[Liger0]

I have tried to print but am having consistantly bad results under some circustances.
When there is a traveling move that goes outside, for example if there is a support inside of a part, the perimeters end up Deformed and "go inside", like if a compensation happens.
The correlation with the gcode is very clear, as that is exactly around where the travel move happens.
The image doesn't show that much as white is hard to photograph, so the deformation on the front won't be visible, but it is at least as much as the one on the left side, which is a bit visible. The face is straight in all directions, so there shouldn't be such a deformation/concavity toward inside, the left side should be straight as a \ symbol. Instead, it seems the first mm of the left side are vertical...
This is ruining much of the things I print and I can't end up with a solution.

This is happening on cura 4.8 at least, but I didn't do extensive tests with previous versions.
@Ghostkeeper any hint about what the possible causes would be is welcome, just in case no one ends up noticing this thread.
Unfortunately the Ultimaker forum isn't of any use, I never get any replies in any section and any kind of topic.

Deformation when travel.zip

[Ghostkeeper]

@Liger0 It's doing that because the Combing Mode is set to "Not in Skin". So it won't travel through the skin then, which is only an issue down at the first few layers in your case. Try setting that to "All".

[Liger0]

When I tried, it had that travel without and with all combing modes..

[Ghostkeeper]

This is what I'm seeing with "Not in Skin":

And this with "All":

This is by loading your project file in the current 4.8.

[andrew-benjamin]

I don't think this is a slicing issue, I think the OP is saying the first few mm of print height is vertical when it should be tapered or sloping (used / symbol). I think this is just elephant foot issue. Edit.. the photo shows this not the sliced image.

[Ghostkeeper]

Ah yeah the deformation is probably because there is an internal hole at that height which makes the inside of the model less stiff and then more prone to shrinkage.