So far we were talking about MAX_ID_NAME . Non-data-block names are managed by MAXBONENAME , MAX_NAME etc. Not sure there is some implicit requirement for them to match?
Applying the dynamic strings to something more than just IDs also increases the complexity of the project.
I only brought that up, because the patch is changing more than just ID names. If it’s just about ID names, I’m fine with increasing the size as mentioned in my previous post and also in the core module meeting we just had.
As said in my previous comment, since they all have the same user-facing size currently, if we increase ID names without increasing other ones (bones, modifiers, nodes…), we need to ensure that there is no implicit assumptions in our codebase that all these names have the same length.
I hope this is not the case, but… that kind of hopes have often been crushed by code reality in the past.
Am also not entirely convinced that this would be a real problem in practice. But on the other hand, Jacques’ suggestion could be a neat way to introduce dynamic names for these sub-structures without breaking too much (forward) compatibility. I suspect that this would not be as trivial of a change as it looks though. Among other potential sources of complications:
Sub-targets of constraints or modifiers (mainly bone names I believe).
Animation curves, liboverrides, and RNA paths in general.
Ensuring name uniqueness in legacy fixed-size char arrays when writing blendfiles.
Checking the DNA, nodes are using the current 64 bytes size for a lot of strings (names, idnames, labels, socket names and identifiers!). Moving all of these to 256 bytes is not something we should do I think.
So I’m starting to wonder if keeping all non-ID data names to what they are currently, and carefully checking that there is no evil-inspired assumptions about these length matching the ID name max length in the existing code, might actually be the simplest way to go.
I believe that working on a patch is a bit too early, IMHO we should have a well-defined, agreed-on design task first. Will work on it next week, unless someone beats me to it.
Am i understanding correctly that for your main goal increasing ID name is the important part, and the other non-ID names (bones, modifiers, nodes, sockets, etc) is less important?
ID names are a primary target, bone names would be also nice but we don’t hit the limit that often with them.
Character skeletons usually follow HIK naming standard inherited from early MotionBuilder schema, so there’s not so many cases where we need names to be that long.
The patch I’ve made is my way of task refinement. It’s a good way to figure out the risks and effort needed to implement things but can be also scrapped and made from scratch.
For minimizing risks etc we probably will do the increase in separate steps.
Also think the team is now investigating possibilities of using dynamic strings for such non-ID data, as it seems to be easier to do than IDs, and will minimize the memory usage impact.
I have one question - UI_MAX_DRAW_STR was set to 400, I’ve increased it to 550 but found no actual reason why it was set to 400 in the first place. Seems oddly specific, arbitrary number.
