Another local/variables feedback - big problem... solution?

I think the concept of local variables, organized hierarchically, is cool.

I have a hard time though translating this concept to something that’s general enough for me to use, and that fits the production module I’ve gotten used to, at mine and other companies.

I obviously can take advantage of hierachical/local definitions/macros/variables etc., but that’s not enough.

For example, I have the following component types:

GLOBAL - contains macros, variables, materials, user interface templates, etc. that are common to all the toe file components (there’s a start script in there that’s called by /start and defines variables and aliases which will then be known to all)

JOBS - contains all the projects I want to have available/load in my current toe file
JOBS/MyProject - an individual project.
JOBS/MyProject/ACTORS - all the actors (ie. characters/props etc.) in my project
JOBS/MyProject/COMMON - common variables, scripts, materials, templates, master components, etc. shared by all scenes of a given project.

Problem:
if I want to have “global” macros available to any project, I have two choices I see:
a - move my JOBS component under GLOBAL so the GLOBAL/local would be visible to JOBS and below.
b - use JOBS/local to store global macros/variables that are common to all projects.
in case of a) this would make it impossible to save GLOBAL as a separate component that can be mantained separately, because it would contain all my current JOBS/*
in case of b) this would either break the nice encapsulation of GLOBAL (ie I can now save my GLOBAL component knowing it has all I need, but in this case some of it - renders templates developer modules etc. etc. - would be under GLOBAL, some under JOBS/local) or force me to have a local/macros local/render etc. (I have other data other than macros and variables I want to be accessible to all my projects) and anything else I conceptually consider GLOBAL (configurations/data/materials/etc.) under JOBS/local.

The same problem is valid for project’s scenes, all of which need to have some access to the project’s settings. In that case, I can have a MyProject/local which is basically equivalent to my MyProject/COMMON, but again I would have to put everything I considered shareable between scenes into MyProject/local.

The bottom line is that you’re telling us that the word “local” as a component name is now reserved: can we put whatever we want inside it? inside, “macros” and “variables” are also reserved words. What others will be reserved in the future that I may be using today? And following this model, the “local” component at every level would always be called “local” and yet I would have to savecomponent a lot of them - all with different functions (scene’s local, company’s local, etc.). While I appreciate the localization of variables, I’m starting to feel forced into a way of working and organizing data that may not fit the flexibility I’m writing into my current production tools, organization wise tested by 12 years of many different production requirements, and may collide in the future with whatever I’m doing.

How about this?
How about if a component could have a “macros” field and a “variables” field (with more to come to your leisure) that by default could contain “local/macros” and “local/variables” but that I may change into “local/macros /GLOBAL/macros” (NOTE two paths are searched in that order) and “local/variables /GLOBAL/variables” (same, two paths searched) or such? That would allow the user to:

  • leave things as they are by default, keeping your local/macros and local/variables system working as it is now.
    or
  • choose their own way of naming components where macros and variables are stored, and further
  • have multiple locations that are searched at anyone level, adding a lot of flexibility to the system which otherwise falls upon you to structure for every production requirement.

in addition, this could solve the cloning problem you mention in the release notes: By adding the two macros and variables fields to the Common Tab of all operators, a clone could look into the same locations as its master (have toggle - on by default - that specifies the start path is the master’s, inherit parent - for components inside clones - or current path) or in entirely different places just by untoggling the master’s start paht toggle and/or specifying different locations (as the fields can be changed since they’re at the top level of the clone.

I’m not actually working on this feature so I can’t address all of the points. Two things though:

/local/variables and /local/marcos are essentially the same thing as the old macros/variables dialog. So at the very least you can use the work flow you were previously using until things settle down.

We haven’t decided what the rules for the ‘local’ components will be yet (if you can add nodes to them for example). For now I wouldn’t put any nodes inside any of the ‘local’ components until that’s decided.

Hey Dani, you can still use macros and variables just as they worked before by just using root’s /local component. The macro and set command adds macros and variables to /local by default. So the functionality from before is not lost in any way. However, we did generalize tit so that if you need a local variable or something to travel around with a subcomponent or your project, you can do that too.

Note that if a variable or macro is not found in a component (ie there no local component inside or they are not defined there) then it will look at the parents level for a local component, and if not found, look further back until it gets to the root and it will find the default /local component. So you could think of the base /local component at the root as the place to put macros and variables that you want to be accessible to all networks in your project. Local to root = global :confused:

and you can also select DAT variables from another component. Just name the select DAT “variables” and put it in local. Only issue is that you can’t use “set” anymore.