Page MenuHome

allow property names longer than 32 bytes
Closed, ArchivedPublicPATCH

Description

Another bug I ran into this while porting my 2.49 script. Apparently, the property name length is limited to a lousy 32 bytes. The attached patch (against revision 34804) increases it to a more reasonable bound, namely 128 (maybe it should be even higher).

(After having had to live for years with Blender 2.49's annoyingly low maximum object/bone name length, losing this limitation might just be that one killer feature which would convince any Blender python scripter to upgrade his scripts to Blender 2.5!! :-) )

Event Timeline

What would happen if one were to load a .blend created after this change into a blender version from before the change where the length is 32 bytes?

The original patch does not feature a problem with .blend files, but you're quite right that the properties would not be preserved properly on load and save (because blender cannot store them properly). In fact, the IDProperty name length is hardcoded to 32 (and not to MAX_IDPROP_NAME). If I change IDProperty's name to be of MAX_IDPROP_NAME size (see patch 0003), with MAX_IDPROP_NAME=128, then old saves are no longer compatible.

Note that this appears to be a regression. My script with the long names could be imported with Blender 2.52. It broke somewhere between 2.52 and 2.56.

Attached two more patches, which would make it work, but which obviously break old save games.

But yes, it seems that the maximum IDProperty name length is hardcoded in the .blend format. It seems to me that the best approach regarding this in the .blend format is to allow for strings to be written in a length independent way (for instance, simply zero terminated), and to drop the limit on the IDProperty name length accordingly. If that sounds ok, I'll try to come up with a much better, and hopefully acceptable, patch.

Before I give this a serious try, an obvious question first: where should the pointer to the name be stored? A proposal follows; does it make sense, or should the name pointer move to IDPropertyData, or .....?

typedef struct IDProperty {
struct IDProperty *next, *prev;
char type, subtype;
short flag;
char _old_name_1[4]; /* IDProperty names used to be stored here. Must be kept or old saves will break. */
char *name; /* IDProperty name is stored here because it is variable length */
char _old_name_2[20]; /* IDProperty names used to be stored here. Must be kept or old saves will break. */
...
} IDProperty;

The split in _old_name is needed for memory alignment. I know it is awkward and I'd prefer to use a union, but makesdna doesn't like that.

Recently, all the names in Blender were bumped up to 64 chars. While probably not as generous as the 128 you propose (Grease Pencil uses that too BTW), this should hopefully last us for a while. AFAIK, at this stage there are no further plans for any further changes to these strings or the way they are handled.

Joshua Leung (aligorith) changed the task status from Unknown Status to Unknown Status.Jan 22 2012, 11:54 AM

so the variable now is MAX_ID_NAME and is in DNA_ID.h ive changed it to 128 just build blender 3.2 and seems to work fine. Thanks @Amorilia (amorilia) for the post :)