Benson Shaw Posted June 14, 2022 Share Posted June 14, 2022 Objs by Crit node can "get" an object, eg by selection status. If that selected object is duplicated via the Duplicate Object node, the result is that both objects are selected. Is there a node that will deselect the original. Or a script that can be put into an Mnode to deselect a selection? Probably best if deselection happens prior to the duplication. -B Quote Link to comment
Pat Stanford Posted June 14, 2022 Share Posted June 14, 2022 It does not look like there is a node for this, but it SHOULD be easy to duplicate and change the SetSelct node. You SHOULD be able to replace everything in the #Script section of the code with a single line of: vs.SetDSelect(h) You would also want to change the name and description in the header also. Not tested but should work. HTH Quote Link to comment
Benson Shaw Posted June 14, 2022 Author Share Posted June 14, 2022 Excellent, Pat! Many thanks!!! I made it work in a test file and duplicate file (attached). But a syntax error results if all elements are copy/paste into a new blank file (also attached). Any trouble shoot appreciated. -B Deselect&Dupe.vwx Dupe Fail.vwx Quote Link to comment
Pat Stanford Posted June 15, 2022 Share Posted June 15, 2022 I don't know why, but if you Wrap the nodes into a single node you can copy that between files and then Unwrap if you want and it will work (after you adjust the criteria). @Marissa FarrellAre we missing something about copying networks between drawings? Quote Link to comment
Benson Shaw Posted June 15, 2022 Author Share Posted June 15, 2022 Nice, the wrapper copy/pastes OK. Then unwrap. Thanks for the tip. Buuuuut . . . Goal: Run the network. A new object is created and remains selected. Subsequent run commands create new object from the selected object from previous run. A different outcome if run the wrapper: New object is created and offset as expected, but it is not selected. Even worse if the wrapper is converted to Mobject: The Mojbect disappears and relocates to the same layer as the new object from the network. Sort of expected. I guess the Mojbect is intended to be (and converts to) the thing which is manipulated. In this case, the invisible Mobject can be selected via Edit>Invert Selection. But cannot be selected via marquee. also, it's invisible, so, um, where exactly is it? Also, too bad the Reset script doesn't affect the wrapper. It only works on the Mobject. Oh, well. At least some progress today. -B Quote Link to comment
Marionette Maven Marissa Farrell Posted June 15, 2022 Marionette Maven Share Posted June 15, 2022 13 hours ago, Benson Shaw said: But a syntax error results if all elements are copy/paste into a new blank file (also attached). I didn't run into an issue when copy-pasting to a new file. Let's look into this more. Could you try it again? 10 hours ago, Benson Shaw said: Goal: Run the network. A new object is created and remains selected. Subsequent run commands create new object from the selected object from previous run. This will be tricky because objects created by Marionette are replaced on each run 10 hours ago, Benson Shaw said: Even worse if the wrapper is converted to Mobject: The Mojbect disappears and relocates to the same layer as the new object from the network. Marionette Objects are Plug-In Objects. All objects within (created by) a Marionette Object will be on the same layer, just as with every other Plug-In Object. 10 hours ago, Benson Shaw said: also, it's invisible, so, um, where exactly is it? It's likely there's something within your script that is working incorrectly, or unexpectedly. This will result in an empty Marionette Object (there's an open bug for this) Quote Link to comment
Benson Shaw Posted June 16, 2022 Author Share Posted June 16, 2022 18 hours ago, Marissa Farrell said: On 6/14/2022 at 4:48 PM, Benson Shaw said: But a syntax error results if all elements are copy/paste into a new blank file (also attached). I didn't run into an issue when copy-pasting to a new file. Let's look into this more. Could you try it again? @Marissa Farrell I can reliably recreate the problem. I think is result of order of reproduction. My theory is that the nodes manifest first, then the Marionette classes are formed after. The nodes are not connecting to (recognizing? recognized by?) their classes. Here is the scenario: Create a new blank file. Note that none of of the standard Marionette classes are present. Copy/paste the network into the new blank file. When the network is pasted into the blank file, the nodes are pasted, the classes are automatically formed, but none of the wires are present. Connect the wires and adjust layer designations in the Objs by Crit and Set Layer. Run. Result is a Syntax Error focused on the Objs by Crit node. Solutions: The Marionette classes are now present in the new file. Soooo . . . Delete the network. Paste it again (or copy/paste from original file). The wires are present and the network runs as expected. Or As @Pat Stanford discovered, Wrap the network, copy/paste the wrap to new file. Marionette classes are automatically formed. Unwrap or Edit to adjust the variables (wires are present). Network runs as expected. -B Quote Link to comment
Marionette Maven Marissa Farrell Posted June 16, 2022 Marionette Maven Share Posted June 16, 2022 4 hours ago, Benson Shaw said: @Marissa Farrell I can reliably recreate the problem. I think is result of order of reproduction. My theory is that the nodes manifest first, then the Marionette classes are formed after. The nodes are not connecting to (recognizing? recognized by?) their classes. Classes do not matter for the purpose of wiring, that shouldn't affect this at all. I still am unable to reproduce this following the steps you've given me. Which build are you using? I was able to see the error you mention in the file you shared with the error already present, but I cannot get my own copy-paste to have the failure. This, however, is similar to another issue that was posted on the forum recently, so I don't doubt it's happening, I just need to be able to reproduce it to further investigate. Quote Link to comment
Pat Stanford Posted June 16, 2022 Share Posted June 16, 2022 @Marissa FarrellI was able to replicate the issue in SP3.1 646432. Which is why I asked you to take a look in the first place. Thanks. Quote Link to comment
Benson Shaw Posted June 16, 2022 Author Share Posted June 16, 2022 @Marissa Farrell & @Pat Stanford Many thanks for looking at this. I tested in both SP3 636848 and SP3.1 646432. Same result. Something is happening in the paste operation if Marionette classes are not present in the new blank file. The network pastes without wires and, if wires are then manually connected, the network does not work. No blink. Nadda. Also, dissociating then reassigning the classes to the nodes does not resolve the problem. Those nodes seem inoperable. But . . . Now that the classes are present . . . If those pasted nodes are ignored or deleted, and the paste operation is repeated, this second copy of the network includes wires and when the layer parameters are adjusted, the network runs as expected. -B Quote Link to comment
Marionette Maven Marissa Farrell Posted June 20, 2022 Marionette Maven Share Posted June 20, 2022 The good news is I was able to reproduce in SP3.1, but not in my testing builds, so it appears to me that come next SP things should be in good working order for you 🙂 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.