So… The other day, a guy spent hours on IRC insulting everyone about “Blender always breaking its API for mere renames”. Today, I got this comment below:
By breaking the existing script interface and changing the way curves work you have done a tremendous disservice to the people that need FBX export the most.
The fact that you got the funds to do this development in part from Unity Tech, but couldn’t be bothered to keep the old interface intact tells me you are not competent for this kind of work. You don’t understand the priorities, at all.
All you would’ve needed to do is to keep this path to the ASCII code intact:
You could’ve had named the new export “save_bin” or “save_new”, or something like that, instead of keeping the name but breaking the interface nonetheless. Instead, you expect Unity (and everyone else) to clean up after you. The idea that you couldn’t just easily support this is nonsense.
Secondly, you don’t understand that people absolutely *need* the classic FCurve workflow. The new “baking” workflow is a nice feature, but only if it is optional. It can’t just replace the old workflow, and you shouldn’t be wasting everyone’s time by just changing this without being explicit about it.
I sincerely hope you can be bothered to keep the old ASCII export around, as long as you have these regressions in the binary exporter.
So, to that specific case first. I did not remove nor renamed io_scene_fbx.export_fbx.save, as everyone can see in that history page. So people could first stop talking about things they do not know about. Actually, I added new “bin” exporter in a new py file, with a new name.
Oh, and by the way, FBX export to Unity itself is not broken at all, the only thing that is broken is a helper script in Unity itself that “hides” FBX exporting, making it looks as if Unity could directly open .blend files…
Nevertheless, it somehow broke that Unity’s script… What the heck? Seriously!
- Blender is free and open source;
- Blender is an application, not a library;
- Blender features several extensions (“addons”);
- A third party society reuses an addon’s code (free and open source, if I may remind) to provide a feature in its own, closed and (at least for the full version) charged application;
- Some changes are made in the free, open source addon, which somehow break that third party society’s product;
- And some guys go reproaching the new, enhanced addon, yelling about breakings, raging over IRC (and, I guess, forums etc.), insulting, …
That does not make me happy. Not at all.
I’ve spent let’s say about three months of full-time work (probably more, actually) on the mess that’s called FBX. I would not wish that to my worst enemy. I’m already really sick of it, I’m pushing myself to complete the last pieces of needed features in new exporter (and importer) for 2.72… All those guys might gain is me dropping completely and definitively this task. They are free to take it over, since they are so wise ans full of knowledge and competent and super heroes and all that, I’d wish them good luck.
Now, back to the general case. Again, Blender is not a library. Let alone its addons!!!
We do have a few pieces of library inside Blender – some helper modules in python, PY RNA interface itself (how properties are defined, how operators are called, that kind of stuff). But! Operators themselves, data access themselves, RNA types themselves are not an API, in the sense they offer a direct acces to Blender’s internals, and Blender’s internals are not, were never meant to be, and will (probably) never be a library. Which means we do not have to twist and tweak to keep compatibility. We do try to do it, to some reasonable level, of course. We rarely do mere renames, and when we do, we keep old names (as deprecated) available at least for one or two releases. When we add a new parameter to a function, we try to make it optional as much as possible. But when we change how an operator works, or remove one, because it’s no more needed inside Blender or was doing bad work, we won’t keep it as a stupid “proxy” just for our py interface. Nor do we when we change data structures inside Blender.
As a side note, let me say you how much a mess can come from trying to keep compatibility – I had to experience it while working on (yes, again!) FBX format, and this does not give a nice result. At all.
So, as a final word: we do not need people which are just yelling, without actually doing anything, not even being constructive, which do not simply know how to talk with others! To those: STOP WAISTING OUR TIME!