# Local COMP system and interdependent variables

This is a reflexion about local COMP variables system and interdependent variables.

In many cases, variables are defined according to other variables, which one calls here: “interdependent variables”.

Within the present local COMP system, it is impossible to do so without rising an infinite recursion warning into the variable evaluation, as there is only one ‘variables DAT’ by local COMP.

Therefore, the local COMP system is limited to independent variables only, as it is now.

I would suggest for overcoming that limitation, the ability to define several variables DAT inside a same local COMP, and which would be evaluated sequentially:

First would be evaluated variables_1 DAT, then variables_2 DAT, etc.

Thus, one could define all of our interdependent variables into the same local COMP, that is, even if they actually depend on other variables already defined there.

By example, if I have ten variables among others, each one depending on the previous one for being evaluated, I presently have to spread those ten variables into ten different local COMP structured hierarchically for them to work together with the current local variable system.

With multiple defined variables DAT, one could define and evaluate the ten variables into the same local COMP, thanks to ten different variables DAT evaluated sequentially.

My method for making variables dependent on others

Hello Ennui,

Strangely, I can’t see the image you just uploaded. Perhaps a momentary issue with internet connection.

What is a bit not obvious with the actual local variable system is that in the case of several variables depending of each other:

1 then 2 then 3 then…10

One has to set up variables inside the network from the last variable to the first, the last variable being on the top level network and the first variable being on the deeper level inside it:

local with variable 10 then within it: local with variable 9…etc, then within it local with variable 1…

local variable 10
-local variable 9
–local variable 8

—local variable 1

So, this works a bit the other way around of one’s usual construction logics, which would say that the more one advances the more one goes deeper. In fact, there, the more one advances the more one has to go towards the top level network, so one has to know at first what will be the deeper network level…

I notice too that it is the same for the logic involving mouse interaction and containers with a click through action: it works the inverse way of what other softwares generally do when working with layers: in TD, the top layer is in fact the deeper network level, and the top level network is in fact what would be the bottom layer in some other softwares.

It is not that it is inconsistent but rather something that one has to be aware of when building one’s networks inside TD.

Yeah particularly with organised control panels the opposite layering can be annoying however with materials I’ve always found it more logical somehow.

Try this link for the image:
[url]http://richard-burns.com/junk/local.PNG[/url]

What I’m doing here is just referencing the table rather than the variable, doing the calculations I need to do to get a ratio from the contents width and height variables and then evaluating that and merging it. It will then work as a variable. As long as a variable dat within the local component has the correct values in it everything works as expected.

Ah, I see, thanks…

There you don’t use the actual variable directly, this is why it is working.

I was refering when using by example \$VAR1 when defining VAR2:

VAR2 = some_stuff_involving \$VAR1

When calling other variables with \$ syntax, a hierarchical network of local COMPs is needed.

so, the way is to define literally the variables without calling their \$ expression, as you did, and it will be effectively more simple.

yeah its a hack in reality but its not too bad it being messy as it’s all enclosed within the local component anyways.

i just realized that what i was explaining in the first message could be done if the base COMP had top and bottom connectors for parenting, exactly like the container COMP.

This way one could set up different variables DAT into the same local COMP network.

But this would also involve some more things as it will also imply that the base COMP could parent any kind of operators and not just COMP, and also that the different Variables DAT can have different names (which may be an issue).

Anyway, it was just for not having expanded variables measuring several meters on screen. :mrgreen:

Well, after playing a bit with nested local variables into local COMP, it seems that there are some inconsistencies finally.

It recognizes variables defined on the level just below but not deeper.

This is a bit “ennuyeux” as one says in french language.

theres a reason for my username

yes, perhaps it is why also they are called “local”. they only work onto the actual network…

so i finally found a solution: by overriding the variables names with their own names one can nest variables locally.

So, this cool trick partially solves the issue and makes my day with TD. thanks again for the comments Ennui.