So, it seems like that the TDEngine has some sideffects from the way it handles components. In general, I think they are a good idea, but sometimes the hinder the workflow.
From what I understand, a tox will be loaded in to the engine as a container. Unloading, I assume, does the same as disabling Cooking. This of course results in incredible quick change-times after a component got loaded the first time.
But this also results in unwanted behaviour:
- Changes to the tox file will not be registered. I assume the path of the loaded tox is also used as the name.
- Changes to ENV-Variables will not be registered as they are taken the first time the engine starts.
The only way to have a clean slate right now is to actually destroy the engineCOMP and recreating it.
It would be nice If we could either have a way of actually telling the engine to really unload the comp (clearing cache) or to actually restart the engine process without having to destroy the operator.
We have a lot of changes planned around all of this. Right now, the closest comparison in TouchDesigner terms to what’s happening in TouchEngine is to think of a .tox being dragged into an empty network (loaded) and then deleted (unloaded).
Do you mean that if you save a new tox file, overwriting the original, those changes aren’t picked up in the running TouchEngine? That is the intended behaviour at the moment.
To better understand the effect of this on what you’re doing, can you elaborate on what changes you’re making?
What specifically are you seeing that’s remaining after unload (presumably to adversely affect a subsequently loaded component)? We can possibly improve on this.
coming!
In fact, I was wrong about this at it seems, I did some tests and in fact changes where registered correctly after a reinit. COuld have sworn that I did not work yesterday. So see this as scratched.
I’m passing information about viewports, networkports, resolutions etc.
I suppose I could instead simply use custom-parameters, but I feel mor comfortable with env-variables instead. But atm this means that changing the variables will not be noticed by the engine as they are read once the engine starts up.
See first answer. This seem to be no longer the case. I was under assumption from what I observed, that the engine is not correctly deleting the tox but instead just pausing it, as it looked like it would
Thanks for the details - it’s super helpful to hear how people are using the Engine COMP.
Generally I would advise against the use of environment variables - particularly in a case like this where a reliable alternative exists - use custom parameters - or a DAT or CHOP, or a config file you write and read.
That said, we’ll discuss this as there are some cases where the use of environment variables is unavoidable for third-party tools - and we could update them on load.
1 Like
I’m doing a lot of dynamic loading and unloading of components that are not always authored by me or someone I work together with directly. Using ENV-Variables allows me to simply push out the important information from the host process without me having to check for the customparameters or having to create boilderplate for the developers.