Engine COMP: accessing parent pars during __init__ issue

When loading a tox with extensions: During init() it seems that parent().par.Somepar returns that parameters default value instead of the value set for that par from the engine COMP

engineIssuePars.zip (18.3 KB)

Start the file and monitor the logs file:

  • Both project1 and engine1/project1 init with par.Str == “default”
  • Delaying the logging by 1 frame logs the correct par value: “customized”

Any ideas for a workaround?

Thanks, this and your other Engine COMP extension issues issue are now logged.

Hi Achim - I think this is probably an unavoidable limitation of the Engine COMP - we need to allow extensions (and everything else) to init before we have a full picture of the final parameter layout of the component to send back to the Engine COMP - and only then can it set any parameter values.

Hopefully you can work around it by not relying on parameter values until your first frame. Some issues with parameter evaluation in the Engine COMP have been fixed in the next release - one of them caused the default value to be output for the first frame in this case, which further complicated your issue.

revisiting this, but I’m afraid the situation go worse

engineIssuePars.zip (29.7 KB)

issue 1:

The custom parameter “Str” is not properly queried inside the engine until I modify its value. I understand from our previous talks that unfortunately it’s impossible to get at the current par value while the loaded tox is initializing (hence todays RFE ), but I guess it should at least query those values once everything is initialized

issue 2

OnStart() is not fired inside engine, but it should. Instead OnCreate() is fired, which should not be fired, because imho we are loading the tox into the engine, which should behave the same as loading a toe file with an embedded tox. Either way, tox files that rely on onStart() being executed won’t work properly

issue 3

And finally, why is name of the loaded OP changed from “project1” to “project2” ? See the “extension_property1” output

Hi Achim

issue1:
Fixed in the next update, sorry about that - and thanks for the report.

issue2:
Yes we’re thinking about the best way to handle these callbacks in TouchEngine where component lifetime is a little different - we’re aiming to have things work intuitively.

issue3:
This only affects the name you’ve chanced on, “project1” - we’ll see if we can avoid it.