def state breaks viewport rendering when script is docked in layout

m_adam

Hi @C4DS thanks for your report.

The issue is within the implementation of the GetState call of a Python Script so nothing you could fix in your own. I made a bug report and a fix will be provided in an upcoming version.

One side note could you please mark your next topic as a question as described in the Forum Guideline. I did it but would be really nice if you could do it the next time I also did set it as resolved since the bug is logged in our internal system and just waiting for the bugfix to be delivered, that's why I added the Tag "To Fix" to your topic, so I will bump your topic once the fix is released.

Cheers,
Maxime.

C4DS

@m_adam
Thanks for the reply.
I did mark the post as a question. But didn't see any difference.

I also still don't see any notification, (notification bell remains unchanged), even though there are new notifications when I press the bell icon.
Using Firefox (94.0.1 = latest version).
No big deal, but it might be related to the failed mark-post-as-question.

jpageau

We had a very similar issue. Only our viewport was fine, but a script that had a def state() function in it prevented another python script from drawing it's UI. So that script would bring up a window with no content in it.

Once we commented out state function everything worked fine. I think we only had it in there from copying some online examples. If I use the script editor to make a blank script, I noticed that the sate function is already commented out in it. Seems like it is best to avoid using it.

I would love to hear a comment from a SDK Specialist on the state of this bug in C4D 2003.2.2.

ferdinand

Hey @jpageau,

Thank you for reaching out to us. @m_adam who handled this case is currently on vacation. According to our bug-tacker, this issue has been fixed and verified in R25.603 by @m_adam.

I gave it quick spin myself in 2023.2, and could not reproduce the bug anymore. What you describe also does not really seem to be related. Moreover, Script Manager scripts should not spawn any form async dialog. Because opening an async dialog will create an object that exceeds the lifetime of the script, as scripts are intended to run from start to finish instead of acting like a host like a CommandData plugin. What you describe sounds more like you are violating this rule and are therefore running into redraw problems with such dangling dialogs.

Cheers,
Ferdinand

jpageau

The script we created at work was simply assigning object to a default layer if they had no assignment. It had no ui dialog but did have a state function that served no real purpose. But just having the event affected an unrelated script causing its ui to be blocked.

The script that had its ui blocked when the other script was docked to a toolbar was not mine. it was this one.
https://github.com/HerzogVonWiesel/TexToMatO/
Note that script also requires these python libs.
https://github.com/HerzogVonWiesel/Custom_Redshift_API

You should be able to see what I am talking about if you try to run TexToMatO. When any basic script that has a state function is docked to a visible toolbar TexToMatO won't draw its ui window.

ferdinand

Hello @jpageau,

The script that had its ui blocked when the other script was docked to a toolbar was not mine.

I find that a bit confusing, because when I look at the git repo, the first thing I find is this script opening an async dialog, i.e., is doing exactly what I described as not supported for scripts.

When the problem does persist with this script properly being wrapped by a CommandData plugin, you should open a new thread for your problem and share the code of the other script.

Cheers,
Ferdinand

jpageau

Yes... the git hub repository is a 3rd party whose TexToMatO script was blocked by my simpler one when the simple one was pinned to a toolbar. The simple script did not block TexToMatO if the state function was removed. Which in my case... did not seem to be needed.

But it indeed sounds like the 3rd party TexToMatO script is doing an action that is not proper in the first place. So, it is likely to have other unforeseen issues. I will let the developer know about it.

HerzogVonWiesel

Hi @ferdinand !

I'm the developer of the other script, and as you mentioned, it seems like I am doing some illegal stuff by calling an asynchronous dialogue; sadly that was the only option to get a functioning GUI going as a script. I already reserved a plugin ID on plugincafé, though I'd love to hear the differences of what a script is allowed to do, what it isn't, and the same for plugins.
Would be lovely if you could point me in the right direction to convert my script to a plugin to fix this issue!

Thank you a lot!

Jérôme

HerzogVonWiesel

EDIT: managed to turn it into a plugin, hopefully it all works smoothly now!

https://github.com/HerzogVonWiesel/TexToMatO/releases/tag/2.0

ferdinand

Hey @HerzogVonWiesel,

There is nothing that is strictly illegal to do with Script Manager scripts, but threading is not supported. Scripts are intended to be little blocks of code that run and while they run block the execution of other things. They are not intended to spawn dialogs which then dangle forever without an owner. Because when the user closes a dialog, it is not deallocated (because dialogs can be re-opened). This contrasts for example with a node, tool, or command plugin, which always sit there and do stuff even when they are not the focus of things. When they own a dialog, it is bound to the plugin instance and when properly implemented, the plugin also uses one dialog which is simply opened and closed instead of allocating a new dialog for each execution.

In the end you can do pretty much anything with scripts, but you should avoid the c4d.threading module and async dialogs. There might be a minor feature I am overlooking here, but the yardstick is async execution. When something is async in nature it might not work properly in Script Manager scripts.

edit: You should also avoid (attempting) to draw into a viewport from a script, or more precisely, manipulate the draw buffer of a BaseDraw. Cinema 4D won't let you do this anyways but there might be cases where you can still mess up things when you add drawing instructions. Getting information, e.g., calling myBaseDraw.GetDisplayFilter() or doing other things which are not drawing instructions is fine. You can also manipulate the parameters of a BaseDraw or switch the camera.

Cheers,
Ferdinand