Macros sound interesting, and the function is close to the idea of blendercast.
Does a script (addon) have access to the latest operations (and their settings!)? If every op is recognized by the script and stored in a way like "bpy.ops. ...", then each op could be redone easily, I think. I'll trust in the dev's opinion ;) Am 23.11.2013 17:41, schrieb patrick boelens: > A long, long time ago I remember there being a discussion about macro's in > Blender. Iirc the core concept of those was the same: allow a user to record > a set of actions and replay them. > > To me it seems like the proposed Blendercast would rely heavily on such a > feature. If macros ever get developed in the future, this may be something to > keep in kind. For example, they could be extended to allow saving to and > loading from files (i.e.: boxModelHouse.macro), jumping to a particular time > or "step", setting a playback speed and show the name and parameters of the > action being performed in real-time (i.e.: Extrude face (0, 0, -0.5), Scale > face (0.2, 0.2, 0.2)). > > Perhaps something like that would be a more feasible alternative. It could > then be used as an addition to tutorials for instance, both written and > screencasted, as well as having a wider use-case. > > Just my two cents. > > -Patrick > >> From: brechtvanlom...@pandora.be >> Date: Sat, 23 Nov 2013 17:11:59 +0100 >> To: bf-committers@blender.org >> Subject: Re: [Bf-committers] blendercasts reloaded... >> >> On Sat, Nov 23, 2013 at 4:44 PM, Gaia <gaia.cl...@machinimatrix.org> wrote: >>> On 23.11.2013 15:30, Brecht Van Lommel wrote: >>>> For me the reasons not to do this are: >>>> >>>> * It shifts work from tutorial makers to developers, and it's the >>>> developers that are already the bottleneck at the moment, we have many >>>> people making tutorials. So developer time seems a more rare resource >>>> at the moment. >>> I am not sure why this would shift work from tutorial makers to developers. >>> Or do you mean "creating this tool would need developer resources" ? >>> Otherwise why would tutorial makers not use such a tool ? Its not so >>> different >>> to use compared to creating screen casts ... >> I think you would want to implement this feature to make it easier for >> people to make tutorials or to help them make better tutorials? So >> basically that means you will have developers spending time helping >> out by implementing this feature (which is really complex), and it >> seems like those resources would be best spent elsewhere. >> >>>> * I have never seen such a system done well in other applications, the >>>> few times I've come across it, it's always been pretty frustrating. >>> What made these tools frustrating ? Is this a bad concept or did you >>> only step >>> into tools which had it badly implemented ? >>>> I'm not sure why, maybe it's just a coincidence and there are >>>> applications (of Blender's complexity) out there that do this very >>>> well. >>> This actually keeps me on track :) Actually this is a good argument for >>> continue thinking about how it could be done better :) >> My guess is that it is a bad concept because it's a fragile high tech >> solution to a problem that already has a proven low tech solution >> (video tutorials), where the tutorial creator has more control by >> being able to take their recorded video into a video editor to cut and >> enhance it, without working within the inevitable limitations of a >> solution like blendercast. >> >> Brecht. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
