I’ve written hundreds of extensions, and cannot remember having too many issues with extensions not initing on start of TD.
Up until now, when one of my two extensions in a project refuse to init on start, unless I turn this toggle on, which I never had to before (guess it’s an undocumented newish 2025 feature? at least I cannot find any info except for the ((misspelled)) tooltip).
Have I been living a lie? What gives? Can someone please explain?
I find it so strange that there’s this new toggle which implies in the past extensions were not supposed to initialize on start? (cause Off is the default)
And since I have tons of tools that init on start, and I don’t have it turned on, yet they initialize makes me puzzle, especially there’s this specific one that does NOT init unless I have it on.
Getting weirder. I copy-pasted the same exact extension code to a different COMP, and magically that one inits. Cleared storage on both to make sure. Practically no difference between the two comps: extinittest.toe (17.0 KB)
Well originally and as long as I can remember extensions only init if something in their COMP has a cook dependency downstream. That was the whole reason for that other thread. Sooo i would expect that concept to stay the same, but now you can force init with this toggle. Sorry on mobile will check files soon
Really curious how I have not hit this before.
Also, what about an extension that has a debug() call in its init? Those don’t need the toggle, and I have in this example debug calls too. Something stinks, and hope I’m just missing something super obvious.
Init on Start toggle was added about 2.5 years ago. It is an easier way to than using an Execute DAT to onStart function to initialize extensions, when they are not triggered by nodes cooking. And yes, related to the forum link posted by @nettoyeur .
For the 2 extinittest.toe. In the one file with the parameter dialog showing in the upper right, there’s nothing causing the node to cook and extension to initialize. There are some recent changes so having a parameter dialog open no longer causes a node to cook.
For the example where the initialization does happen on one COMP, it is because the viewer is on so the node cooks and initializes the extension.
Thanks for the info. I am a bit flabbergasted I’ve been going around not aware of this (not really documented anywhere) all these years without an issue.
I’ll update the docs in the coming week, but yeah this has always worked the same way generally… TD has to be asking for info from the extension in order for it to initialize. You rarely notice this because so many things trigger it.
When subtle changes are made to cooking, like the par dialog thing that Selina mentions above, that can change whether extensions are initialized or not. We try to be careful not to mess up older files, but in that case the initialization would depend on something arbitrary (par dialog open) and so the init was never reliable in the first place.
Extension initialization is always a bit of a black box to those of us that develop in Python, so keep the questions, clarifications, and reports coming if you have anything come up!