- User Since
- Jan 10 2010, 2:45 PM (413 w, 12 h)
Aug 19 2017
May 7 2017
Wow, a bug report from seven years ago! Since then I've discovered how to wait for the next event loop:
Apr 13 2017
Mar 21 2017
Dec 16 2016
Apr 27 2016
Mar 21 2016
Mar 15 2016
Mar 14 2016
Feb 5 2016
Jan 9 2016
I've been stalked! :D
Dec 18 2015
Thanks Campbell, it did. I must have forgotten to run the "install" project.
Dec 13 2015
Mar 29 2015
Aug 10 2014
Jun 6 2014
Check D113 for the latest on this patch. It does seem to have stalled, unfortunately. I can't do much more on it as I'm now employed as a Modo developer. :-/
Mar 22 2014
Thanks for the commit!
Feb 7 2014
Feb 6 2014
Since I added Python 3.3 to the list of affected platforms the bug has been getting a bit of attention, but seeing as it was reported two years ago let's not hold our breath...
Jan 29 2014
Jan 28 2014
Jan 25 2014
Jan 24 2014
Jan 23 2014
Closed by commit 1f2136b3.
Jan 19 2014
Jan 12 2014
Only one shape key is being edited. My add-on exports to a format that requires corrective shape keys to be relative to the shape combinations they correct, so this is a major issue for my users.
Jan 11 2014
Jan 10 2014
Jan 1 2014
Dec 17 2013
Instead of creating an smd_export_list collection, you can create a python set or map to do a quick lookup from the poll callback.
I'm going to take that last sentence back. There is zero infrastructure for Python callbacks when setting a value from a button; the RNA property is definitely the correct place for it. Anyone writing a cast function will just have to do this:
The case for cast is subtle: you don't need to cast an ID, but you do need to cast other types provided by UILayout.prop_search. In existing C code the job is done in the set function (more about that in the patch description above).
Dec 16 2013
So I prefer option 2, and this can be set at the moment you define the property. The PropertyGroup being a special case is a bit strange, but follows the convention that all data is owned by Blender, there's no loose data, it's either an ID block owned by BlendData or owned by an ID block.
I initially went to create a diff, but the diff page suggests that sizeable changes are submitted as patches instead. I've made one now: D113.
Attaching a third version which adds support for copying, linking, and appending.
Dec 11 2013
Attaching an updated patch which keeps a hash set of ID Prop references.
Dec 10 2013
Sound good, where can I download one? It looks like they are only distributed on DVD?
Dec 9 2013
I've run some benchmarks with this script, which creates 9999 empties with 3 DatablockVectorProperties containing two references, all to the same object. It then deletes the pointed-to object.
The trouble with PointerProperty is that it doesn't currently support assignment, which I presume is because scripters aren't supposed to be creating their own PropertyGroup objects? CollectionProperty is the same.
It's handled on line 191. I'll have to test performance, but I would be surprised to see much of a difference unless loads of datablocks actually have datablock ID-props set.
Makes sense, but I've found that the overreaction happens to exactly the same extent even when there is only one node in the whole blend. If this is about the resize operation being re-applied for each node then the bug should only appear when there is more than one node, right? I'm also seeing the bug in my current node tree even though each list ID includes the node's name.
Dec 8 2013
Whoops, I was editing the poll function!
context.node is the same as context.active_node. Sounds like that's the bug!
I was going to report a bug about the list heights being shared between nodes, but that can fixed by making using the node's name as the template_list list_id value. :)
Dec 6 2013
It turns out that the appearance of console errors differs between builds, but the bug remains. Add a breakpoint at action.c:720 (the id_us_min call in BKE_pose_channel_free) and you'll see that pchan->custom has already been freed.
Removing the scene won't repro, you need to unload the whole blend file.
Dec 5 2013
Weird that it's not in Datablocks too, it's right there for me.
By "freeing custom bone object" I mean that the error occurs while freeing the scene if there are custom bones present. I missed out the all-important repro step #2 of opening a new file, sorry!
I just tried with a release build and couldn't repro, but it happens 100% with a MSVC debug build.
Dec 4 2013
Nov 25 2013
Here's what I've got so far. It uses some C++11 features, but I read on the mailing list that Audaspace is going to require that soon anyway. :)
Nov 21 2013
Thanks for getting back!
Nov 19 2013
Here's a patch that makes context creation and destruction dynamic.
Nov 14 2013
I agree that shutting the context down after inactivity isn't amazing, but that doesn't seem like much of an argument for not doing it. If it's difficult then could context creation be delayed until required instead?