nallath

Not as often as i'd like But it's pretty open; as long as it might result in some improvement for Ultimaker. I've worked on model subdivision (cutting up objects automatically so they can be printed) and fan cap detection (see if a fan cap is open or closed by using the camera on the UM3). But it can also be a lot different than stuff you'd normally do: some people have also worked on making a tablet based system for our meeting rooms to show if they are available. This is also where cookies come in, you can always try to convince a developer to put his two weeks of research project into a certain subject Suggestions are always welcome!

I've made a rough graph. The left axis can also be used for speed of development. The horizontal axis can be used for either quantity or quality of cookies

We are working on some more resources for that. It's up to @msuurmond to give us some more time for that But if people have questions, i'm always open to answer questions. I'd recommend looking at our current plugins and work from there.

As weird as it may sound; Speed. But we're not talking about speed of the software in itself, but speed of development. Python won't result in the fastest software (far from it, we've had to pull a lot of tricks to get it faster), but it's so much faster to build stuff in it. We're getting a lot of remarks regarding the almost punishing speed by which we can push out new releases and it's mostly caused by using python. That enables us develop that fast. Another big advantage is that python is much easier to learn. Now that we are (finally) focusing more on getting third party plugins, i think that will help us get more of them. Originally i'm a c++ software egineer (with some jumps to Java) and coding in python also feels like a breeze. It's way more fun to be actually achieving things.

Hmm. Tough question. I'm going for the cop out answer of; Make it a settable preference. But yeah, if i really, really had to choose; Morgan Freeman.

I really want the manual supports feature, but i also want it right. There already is something that sorta does it (anti-overhang meshes), but that is far from perfect. Every so often we have "research sprints" (which have resulted in our packing, improved layer view, etc). It could be one of those things to do in one of those (as in that case you can be a bit more experimental, as it's okay if it fails). Another option would be that if someone has a cool engine that generates supports to slap it into a plugin. Cura can already mark an object as a "support mesh".

By all means I don't think we have any UX for it. I prefer to have a feature that isn't fully fitting with the rest of the application compared to not having it at all. If the UX becomes a problem, it can always be tweaked. Having a feature makes it a bit more of a discussion piece (and much easier to show how it works)

I strongly believe that software can and should be a platform as much as possible. For those of you that know the term, Cura is set up to be really "data driven". It's a concept that i learned from game development. Instead of hard coding a lot of things, you try to make a very strong core that dynamicly, based on the data it gets, performs certain behaviour. This is why there is a theme system, plugin system and a new machine system. This makes Cura changeable. Based on what data you "feed" it, it can be many things. I built those things so that as much people can join in on adding features & possibilities. I'd love to see Cura go the same route as other platforms (and if I dare dream, one day it could be something like Android or Drupal!)

This has quite a bit more to do with hardware & materials. We put a lot of time in getting those profiles right. Getting hardware up and running is also something that takes quite a bit of time. Cura can already support different nozzle sizes. It does take a bit of in depth knowledge to fully set it up right, but there are some doable work arounds. If you only change the layer width setting, you can already print with those nozzle sizes. "real bridiging" has been on our wish list for quite some time now. I'm not a 100% sure at what priority it is now, but other things have taken priority over it.

The visibility pre-sets is in our top 50 issue list. It's also a feature that I really want myself. This system could also be extendable to custom pre-sets (or pre-sets per extruder)

A thousand users isn't a whole lot. It used to be, but it isn't by a long shot anymore. The logs that you posted are partial and regarding another issue. They don't contain the right parts to be able to debug why its going wrong in your case.

The file that you saved is not a project file, but a regular 3mf file. That's why it's not being loaded as a project.

Could you share your logs (and your project?)

The same argument as you used can be held here; Thousands of users are able to connect with Cura using the appimage. So are you really sure it's the appimage? We've had this discussion a ton of times; Provide us with logs. Just complaining this don't work isn't going to change the situation. We're not going to switch back to .deb images due to a lot of issues with backwards compatibility due to Ubuntu failing to have a proper packager for python related libraries. Unfortunately there aren't enough users on Linux for us to be able to invest into getting those packages up and running.

The original design that we got only had room for 4-5 settings at once. I changed the margins so we could have at least a reasonable amount of settings on screen. Setting visibility pre-sets is something that is pretty high on the backlog.

Don't encourage people to tinker? Wait what? We hide most of those settings to make it easier to get in to. The fact that all those settings are there (much to the dislike of some voices in the company that want to hide the "technical bits" of our software) means that we promote you from doing exactly that. So yeah, Cura is developed by us to make money. Of course it is, we're a company. That's what companies do. But if it was just about that, this isn't the way we would have done it in the way we are doing it. We wouldn't have made a system that allows you to add machines that aren't ultimaker machines. So to answer your question; Yes, you are over dramatising something that is going on. To go even further; it's not true. Do do have some points in what you say, but you are dead wrong on that point. As for the patents; Releasing early and often is indeed one strategy. But it doesn't give equal amount of protection. If you only release, you never have bargaining chips. A large part of the protection that UM has is indeed by means of releasing ideas and technology, but in order to play in the big league, you need a bit more.

Every single issue that you reported has absolutely nothing to do with the appImage. The debian package manager only works in theory; In practice it causes gazillion issues. The whole "your system can handle dependencies" simply moves the responsibility of having the right packages to the OS mainainers. In quite a few cases this made Cura not work at all, leaving us with no power to actually do something about it.

No settings are loaded from the machine. Cura is in control of them. In some cases settings do get sent to the machine, but never the other way around. As for material temps; Materials have a "default" temperature. Certain qualities will modify them (and use the default temp as a base). Retraction is something that is overridden by the quality profile. Cura uses a "stack" approach to settings, so the top most setting holds the used value. As the quality (even though it depends on the material) is above the material, it's settings get overridden.

This is exactly what we designed them for. Glad to see it works like that in the real world

Cura uses the models origin to merge models. I think that solid works doesn't actually preserve that origin. The feature to manually move items is still there. Just group / merge objects and use ctrl click to select objects inside the group.

Have you updated your graphical card drivers?

It does not have a new material model.

Right. I thought it crashed due to the loading of the file. It seems that it's actually crashing somewhere while requesting the file loader. This is unfortunately in code that we have little control over (as we use third party software to handle these things).

Probably because the STL file is corrupt. Did you create it with sketchup? its rather infamous for creating incorrect stls. If that's not the case, we will need log files to help you.