Init Extension on Startup Toggle

I am not sure if this is a bug or has always been the was that extension in fact do not init on startup but get initiliazed on time. I have the feeling that this has not always been the case. At the moment I, just sometimes, have the situation that certain extension not always initialize in time, which leads to bugs. The strange thing is that this only started somewhere arround the mid of the current release cycle to lead to errors and is hard to repdoruce for me.
To fight this I will have to implement executeDAT with the onStart directive to initialize the extension, but it would be nice if I could define that behavior directly in the extensionParameterComp instead. Load times might get longer but this will fight performanceDrops or issues with uninitialized extensions suddenyl getting initialized (which can get heavy with bigger systems).


+1 for a COMP toggle to auto-init its extension on TD start.

Usecases is some COMPs have no cook dependencies downstream (for instance if the extension only writes to python objects) so they are not cooked automatically but I still need them to work from the start.

1 Like

imho this should be looked at in a bigger context.

Because in every more complex project it is such a long and painful task to get rid of all those initialization/cooking related issues and spikes

What about a generalized “preload/init/cook on start” toggle for all OPs? So that not only extensions reliably initialize, but also that geos/textures will not cause frame drops when we display them for the first time during a show.

And that should include everything needed to get a node ready for display / use ( including stuff like “generating mipmaps”)


I like the ideas here. Would also very much like any example files where extensions don’t initialize on time. They can both be fixed and will be relevant to decisions about adding the features suggested.

Hey @Ivan I build a simplified example to clarify the need for an auto-init option.
Similar but more complex situations I encounter more often in my work.

To make it a bit more visual, each extension, on init, makes a Container COMP background green. The behavior I’m looking for is both black squares in the output to be fully filled with green on startup. But this does not happen until I have zoomed into every COMP in Designer mode (see instructions how to zoom in DATs in the network) . It does not matter if I start in Perform mode or not.

In the field this issue happens in COMPs/extensions which don’t have a direct node output on which other nodes downstream depend. For instance they perform data mangling in Python (websocket/ HTTP data receive/send, database, etc) and use the result of that data to set pars / call Python methods in the rest of the network. As there is no cook dependency to signal these COMPs to cook once on startup, we now have to add Execute DATs with several run(delayFrames=10) onStart scripts to make sure all our COMPs have initialized.

I would like a more robust & more simple to implement solution for this, something which can guarantee an extension will initialize on startup.

example made in 2020.28110
init-test.toe (4.7 KB)

1 Like

Confirmed that this is still the case in 40k branch. Fun example :slight_smile:

I’ll discuss this with the team. On first look, I like @Achim’s idea of a universal toggle for all nodes that need to preload.

Hello, I am encountering quite strange behavior when it comes to extension initialization on startup. Looking at this old thread I feel like it is basically the same issue - present in latest 2022 versions. @Ivan I am attaching an example scene that would hopefully help you investigate this problem.

It was quite hard to somehow isolate the issue, so here is a brief explanation of what is happening in this scene file. Problem lies in extension initialization of component /role_manager. This simple component was supposed to configure project based on ROLE environment variable during startup. I have assumed its extension will be initialized on startup, but it isn’t the case in following scene file.

test.1.toe (6.8 KB)
launcher.bat.dmp (400 Bytes) (rename this file to end with .bat)

Please run launcher.bat and see that scene opens in master mode instead of render_node mode - even though launcher sets the ROLE=render_node. This is because extension of /role_manager wasn’t initialized on startup. You can hit button named “Try to access node” that explicitly calls op("/role_manager").cook() and see that extension was only now initialized - as the scene changes to render_node mode.

Now lets look at the weirdness happening here. Please go ahead and open the scene in TD (without using the launcher.bat). Go inside /role_manager and on try adding some comment on line 9 in RoleManagerExt. Save the scene and run it with launcher.bat. You will see that the extension was now properly initialized on startup.
The same thing happens if you delete /tcpip1 node instead of editing RoleManagerExt. Once deleted and saved, extension is correctly initialized on startup.

It seems quite non-deterministic whether extension initializes (or not) during startup. I feel like there should be some kind of guarantee what is going to happen.

This is a tricky subject that we are still looking into. I’ve pointed the dev team to this new example. In the meantime, have you tried using an executeDAT to force your extensions to initialize at start?

1 Like

This actually explains a behavior I haven’t been able to properly hunt down, which is that a project with a modified version of @Jarrett’s sceneChanger doesn’t properly load extensions for all of my scenes until I manually launch all of them at least once or twice. I’ve written a few execute onStart scripts to try and get around this, but the run delay time must not be long enough because there are still certain scenes that aren’t properly initializing when i try to force them to, and lately i’ve resigned myself to having to launch all of them at the beginning of a session manually, which is a bandaid but not a solution

Yes, thanks, currently I am using executeDAT to force initialization of components that misbehave this way.

1 Like

I’m suspicious this is only partially an extension problem, if pulsing init doesn’t work. Could it be that some viewers need to be displayed for stuff to cook properly? Or could it be that you are not initializing all the necessary extensions? As a test for that last one, you could write an onStart callback that recursively initializes all your extensions: like do a comp.par.reinitextensions.pulse() for everything in root.findChildren(type=COMP)

Just a side note, we’ve recently discovered and fixed an issue where pulsing parameters were sometimes missed when executed on consecutive frames, in case its relevant here.

1 Like

Is this fixed in any of the recent builds?

No, not published yet, just in final testing stages.