[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [54773] trunk/blender/source/blender: fix for error in the blenderplayer caused by r54727 (can't assume G. main is valid on load).

Campbell Barton ideasman42 at gmail.com
Sun Feb 24 08:48:30 CET 2013

On Sat, Feb 23, 2013 at 1:02 PM, Dalai Felinto <dfelinto at gmail.com> wrote:
> Hi Campbell,
> I see blenderkernel/intern/node.c still using a lot of G.main. Is it in the
> plans to handle them eventually?
> For example:
> 1881    /* XXX hack, should be done by depsgraph!! */
> 1882    ntreeVerifyNodes(G.main, &ntree->id);
> Just yesterday I closed/rejected the following report because although the
> G.main above is NULL, and it crashes the Blenderplayer (when opening old
> files) I thought this would be tackled only in the overpraised depsgraph
> refactor:
> http://projects.blender.org/tracker/?func=detail&atid=306&aid=29730&group_id=9
> Anyhoo, I'm not that comfortable with changing the nodetree and depsgraph
> code now, specially if there are undergoing changes. But if you are still
> going to work on it, I thought it wouldn't hurt to see if this (now
> abandoned) report get fixed "by chance".
> Thanks,
> Dalai

Hi Dalai,
The commit I made was for a common case loading a scene (without
versioning), so to me thats a clear case where it shouldn't crash
(otherwise the blender player would be unusable for armatures), but
the case with ntreeVerifyNodes() Im not so sure of, if its crashing
the blenderplayer shouldn't we try to fix it?.

Adding a Main arg to ntreeUpdateTree() is reasonable to prevent
crashes on read IMHO.

More information about the Bf-committers mailing list