Greetings<br>Sometime ago my blender (compiled from svn) started to act strange when importing files..<br>The problem was that in rev 14202 the struct RenderData had an attribute modified from short to int and the handling of files started to act strangely.<br>
I tried to find the problem.. and it turned out that a fresh compile would solve the problem.<br><br><br>When trying to figure out what was going wrong I found some small/tiny things that now I describe (in case you are interested):<br>
<br>1) source/blender/maksdna/dna.c isn't being updated correctly by dependencies<br><br>2) When the attribute RenderData.scemode was modified from short to int.. there was some parts of the code that still assume it to be short<br>
<br>Index: source/blender/python/api2_2x/sceneRender.c<br>===================================================================<br>--- source/blender/python/api2_2x/sceneRender.c (revision 14264)<br>+++ source/blender/python/api2_2x/sceneRender.c (working copy)<br>
@@ -2156,7 +2156,7 @@<br> return EXPP_ReturnIntError( PyExc_ValueError, <br> "unexpected bits set in argument" );<br> <br>- self->renderContext->scemode = (short)value;<br>
+ self->renderContext->scemode = value;<br> EXPP_allqueue( REDRAWBUTSSCENE, 0 );<br> <br> return 0;<br><br><br>3)<br>I noticed that most bitsets in blender structs use a signed type (short/int).<br>
I think this might be a "problem" if they are later resized.<br>
Since it becomes unpredictable to know how old data will be expanded.<br>I recall that in signed data types the MostSignificantBit will be expanded.<br>
<br>
Its not a serious "problem" but maybe fields that are supposed to be bitsets should be declared as unsigned and that make things more consistent.<br><br><br>//P.S.<br>I'm not sure if this is the right place to send this.. maybe it should go on bugtracker (I'm not sure :S)<br>
<br>André<br>