Websockets / Threading

GillesKontrol

Hello!

I am trying to set up a websocket client inside C4D that can listen on localhost to messages from a websocket server.

I've got the actual websocket client to work, but when I test it currently it freezes up the entire UI (currently using the Script Manager - have not gotten to making it an actual "plugin" yet - that's another rabithole to go down next + including the websocket python library in said plugin).

I'm assuming I need threading or another way of asynconiously listening to the server's messages or otherwise C4D will continue being stuck?

I've tried what was suggested in this thread by ferdinand: https://developers.maxon.net/forum/topic/14395/c4d-threading-in-python-doesn-t-work-as-expect - but I'm getting stuck on the Plugin ID part. I've made an ID and replaced it, but I keep getting these errors:

Traceback (most recent call last):
  File "scriptmanager", line 3, in <module>
ModuleNotFoundError:No module named 'urllib2'
Traceback (most recent call last):
TypeError: thread object is dead
  File "C:\Users\Gilles\AppData\Roaming\Maxon\C4D_CE91A9A0\library\scripts\Threader.py", line 138, in <module>
AttributeError: 'traceback' object has no attribute 'Main'    RegisterPlugins()
  File "C:\Users\Gilles\AppData\Roaming\Maxon\C4D_CE91A9A0\library\scripts\Threader.py", line 132, in RegisterPlugins

"OSError: cannot find pyp file - plugin registration failed"

Sorry for the fairly vague post, but i'm running into different problems at the same time. In short:

Websocket client in C4D - best practice for this?
Plugin_ID - why do I need to do this, how do I properly do this?
If it won't work in the scriptmanager, (because scriptmanager will freeze up even with threading) how do I do it without the scriptmanager?

Thanks,

GillesKontrol

Ended up solving it by doing it with regular sockets and a timer. Also figured out why and how to make a standalone plugin panel - though it took me a lot of time and effort. Your documentation could really benefit from some step by step examples as searching for things you don't know the names of or why you even need them is next to impossible.

ferdinand

Hello @gilleskontrol,

welcome to the forum and thank you for reaching out to us.

Websocket client in C4D - best practice for this?

You must use a third party library, e.g., the popular websockets as our NetworkWebSocketConnectionInterface has not been ported to Python and CPython does not support the WebSocket protocol out of the box.

Plugin_ID - why do I need to do this, how do I properly do this?

You can get them here in the forum with the little plug icon at the top. See How to get Plugin IDs[URL-REMOVED] for details.

If it won't work in the scriptmanager, (because scriptmanager will freeze up even with threading) how do I do it without the scriptmanager?

The script manager is blocking by nature. It is not your thread which is blocking, but the fact that you have likely put some code into your script which wait for the spawned thread to end. Which will then run as all Script Manager scripts on the main thread therefore block it. You could technically omit waiting for your threads to end and therefore have a non-blocking script, but that would result in dangling and never ended threads which is a bad thing.

When you launch your thread in a plugin, this problem can either persist or go away, depending on what you do. There is no general answer to that. Let's assume you have the method MyPlugin.Foo. When you spawn the thread T in Foo, you wait for T to end before you exit Foo, and Foo runs on the main thread, as for example CommandData.Execute, you will experience the same problem. What you can do is:

Wait for a thread T to end from a function f which runs on the non-main thread S. Doing this makes rarely sense in Python but you would not block the main thread doing this. You check for being on the main thread c4d.threading.GeIsMainThread.
The more common and sensible approach is to defer reacting to your thread having ended to other places. In a dialog or MessageData plugin this could be a timer to parodically check in Message for your threads having ended. For nodes you could simply make the thread send the node a message once it has ended.

Your documentation could really benefit from some step by step examples as searching for things you don't know the names of or why you even need them is next to impossible.

Hm, I agree that our documentation lacks an abstract subject-matter access which can make traversing its content over subjects something in between laborious and impossible. However, the solution to that would be subject indexing and not having a perfectly matching tutorial for every possible information need of users (although that is of course what all users want). In which area did you find step-by-step information to be lacking in your case?

Cheers,
Ferdinand

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.