Hey @BretBays, Thank you for your clarification. I think I understand a bit better what you want, but there are still some question marks for me. The edge loop and ring loop tool work via point indices (and a bunch of other settings). I.e., you set MDATA_LOOP_FIRST_VERTEX and MDATA_LOOP_SECOND_VERTEX and that determines the edge you want to loop (the screenshot above is for toolloopselection.h, the file which defines the loop tool IDs). As I said above, some of the modelling command options can be bit finnicky, but I would help you crossing that bridge when we are there. But we would have to have a foundation we can work on to get started. Sorting Selections But from what I understand, you do not primarily want to select loops, but rather sort existing selections into loops, or more generalized: edge strips you consider to be semantically/topologically connected. For something like shown in your screenshot, this is trivial, but a general solution is not. That you have an existing selection is almost irrelevant, it is only slightly easier to solve than the general problem of sorting all edges of a mesh into strips. I wrote something like this myself a long time ago (while still at university at not a member of Maxon) and struggled quite a bit then to get it right, because you have then to deal with intersecting strips, self intersections of strips, etc. The problem of yours lies generally in the field of topological sorting, which is pretty wide, the concrete term used for the particular problem is often 'edge extraction in mesh processing'. The popular Python mesh processing library PyVista implements for example edge extraction. If your concrete problem is solvable, depends entirely on how well you define it. For just an given input set of edges, there exist often many solutions. You have to define things like a maximum angle of change between edges in a strip, how to deal with intersections of strips, if you want continuity of non-manifold edges, etc. And even then, you will often end up with multiple solutions. E.g., in the example below, there are three possible ways to sort these edges into two strips (and even more when you do set this conditions to minimize the number of strips). Which can be deemed undesirable. [image: 1764675234807-untitled.png] Implementing an Edge Selection Tool Yourself I do not understand all details of your tool, but when edge selections are part of it, you could also 'simply' integrate them. Your tool looks currently more like a dialog/command and you could also do it there, but an actual ToolData would be better. The general drill would be to add a button/mode with which the user can select edges. Once running, you would use c4d.utils.ViewportSelect to get the points/edges the user is clicking or hovering. Once the user wants to commit to a selection, you get the two relevant hoovered points (i.e., edge) and run ID_MODELING_LOOP_TOOL with it. Because you would inspect the user creating the loops one by one yourself, you would naturally know what is a strip in the final selection. Here are also some hoops to jump through and there might also be obstacles you cannot overcome which I do not see at first glance either (as actual ToolData tools are not very often implemented in Python and therefore a bit niche), but generally this should be possible and this might be less costly than writing a full blown edge extraction solver. Sorting Edge Selections Without Intersections If you want to sort edge selections without intersections (or touching), this is relatively easy to implement, you only have to get the selected edges, convert them into point pairs, and then sort them into strips by finding point pairs where one point matches the end of another pair. The problem of this route is that it is pretty much guaranteed not to suffice in real world scenarios. Cheers, Ferdinand

@ferdinand Thank you. It works well. --> tag.Message(c4d.MSG_EDIT)

Thanks for @ferdinand awesome answer! I found DescLevel and DescId always confused to me, but them do can access more than simple set item, time to dive deeper to the DescLevel part Cheers~ DunHou

FYI, there has been a verified fix for the Booleans crash, it will be included in an upcoming release of Cinema 4D.

Hi @ferdinand Thank you for the reply and I totally understand your point. I think I will try to find another solution and will adjust my rigs to maybe get rid of the python tag thats causing the issue. I wasn't aware that this is considered "dark magic" python code^^ haha Thank you once again for your efforts! Cheers, Ben

Hello @CJtheTiger, I am not quite sure how your question is meant, and generally new questions should constitute new topics. When you are asking, if when there is an ID_FOO: int = 12345 in V1, if we then just silently switch out the numeric value to ID_FOO: int = 54321 in V2, then the answer is sort of yesn't. We try to keep identifiers persistent. And for things like plugin IDs this is true without ifs and buts. I.e., once Ocube: int = 5159 has been defined, it will stay like this. But parameter values, e.g., PRIM_CUBE_LEN: int = 1100, can technically change. The goal is also to keep them persistent but in ABI breaking releases we sometimes have to modify descriptions. That is why we recommend that you always use symbols and not numbers. Cheers, Ferdinand

Hey Jacob, Thank you for the added data. First of all, I have invited you to the forum to end this middle man communication, which is a bit odd. The pyz file is part of python ... I am aware of what pyz is, I just pointed this out because I of course looked inside your package and found all the py_armor obfuscated code and the injected binaries in there. So, I pointed out that this is bit more than just "packaged in a pyz file for ease of distribution [...]" as Lasse/you put it, the goal is here clearly obfuscation. Which is also relevant for support, as it limits what you and I can see (without getting hacky). My finding with the 10mb file freeze comes from my trial and error ... mean[t] when you run a script from Extensions -> User Scripts. Your code also freezes when you load it as a Script Manager script. That is what I did with the last package from Lasse, and now also yours. The code in your script is again wrong, which is why it won't freeze until you fix it. This is the code I found: [image: 1760086817339-2bd4290e-78b2-43d4-936d-1e2a7eaf366b-image.png] And I fixed it then to this. When I ran it then, Cinema 4D froze for two minutes or so, after that it opened a myriad of dialogs to then terminate into two crash dialogs (it was pure luck that I let it run for so long, Lasses previous version might have acted similar, but there I killed the C4D process, as soon as I saw the 'beach ball of death' cursor on MacOS). [image: 1760086755748-69fcb5da-ac49-477e-8f70-9daeb1daa1aa-image.png] Please read my answer below carefully, as I already pointed out most of this in my previous posting. I would STRONGLY suggest debugging this without obfuscation. Maxon also cannot debug larger sections of code or test further packages for you. I understand that obfuscation might not be your choice, but it will make your life harder in debugging this, as you always fly blind. We of course still will provide support, but you have to provide more than "it does not work/crashes/freezes, please help us", especially when this is not code tied to our APIs. Attach a debugger from the Script Manager and see why your code crashes/freezes (see link in last posting when unsure how to do this). But you need an un-obfuscated code base for this to make any sense. Defer your loading to a later point, e.g., C4DPL_PROGRAM_STARTED, when you have issues in the direct plugin registration context. In that case you would always register your plugin, but then only execute it when the your own license check succeeded. But you absolutely cannot ship a plugin which freezes Cinema 4D for multiple minutes on startup or when invoking your plugin because your licensing takes so long. When we see this in the wild, we will have to blacklist your plugin IDs, as this damages the brand Cinema 4D. Please use threading then to not block the main thread with your long running code. What I did not notice before is that you apparently try to open multiple dialogs (for me it opened multiple dialogs when I ran the script). The GUI and many other systems are not yet available when Cinema 4D is still booting, e.g., in the splash screen. You can expect all systems to be up and running when C4DPL_STARTACTIVITY is emitted, but it is better to wait for C4DPL_PROGRAM_STARTED for long running tasks (i.e., the two events I tested in my previous posting). Please also keep in mind that Cinema 4D has its own anti-piracy measures. Python plugins are sort of special in that they work slightly different than native C++ plugin modules (the Python C++ module shipped by Maxon sort of acts as a surrogate for Python plugins in the module registration phase). But Cinema 4D won't allow plugin threads to start their own processes at this point (which you might be trying to do with your injected binaries), and threading should also be avoided at this point, as the job system of Cinema 4D might be still booting. What you are meant to do in PluginStart (or the __main__ context of a pyp file), is register your plugins. You can run some quick logic there, but you are certainly not meant to start communicating with servers and opening GUIs there. You can read here a bit more about this from a C++ system perspective. I would recommend to do your license check in the background in its own thread once C4DPL_PROGRAM_STARTED has been emitted (so that you can also open dialogs to signal errors). An alternative would be to do it when the user clicks the button of your command. But you should also here put it into its own thread, so that it does not block everything else. Cheers, Ferdinand

Thank you for the C++ code—it's been very helpful! Cheers！