Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:

  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

opTransform returns error ILLEGAL_MODIFICATION

lemon1324lemon1324 Member, Developers Posts: 170 EDU
edited March 2018 in FeatureScript
So I was trying to use the Auto Layout feature in an assemble->in-context->copy-in-place->operations workflow like that demonstrated on this top-down weldment, but the feature was not packing my mostly-rectangular parts anywhere near optimally. Looking at the resulting layout, it looked like what would happen if somehow the bounding box was being calculated incorrectly (by significant margins). According to the bounding box documentation, if tight is not specified, it should default to true, though, so I tried to debug and see what the computed bounding box actually was.

To debug on the same geometry I moved that in-context derived tab into my copy of the auto-layout feature script, but now attempting to opTransform any of the bodies throws an ILLEGAL_MODIFICATION error, which I can't find further documentation on.  I can, however, manually insert a transform feature and transform the exact same part.  For testing, I've commented out everything except a debug and the opTransform.

  1. What is an ILLEGAL_MODIFICATION error?
  2. What could cause a difference between doing an opTransform in FS and manually inserting a transform feature?
  3. Does it matter that the in-context relation is broken by moving it to a new document? (The odd behavior from the unmodified Auto Layout still remains, so I don't know if that's it)
  4. I attempted to change FS version from 275 to 765. This seems to have broken something, though trying the minimal "select the first body and transform it up by 5 inches" doesn't seem to be working in 275 either.  No errors, but the body hasn't moved.  There's a lot of changes between these, but would any of them result in this behavior?
Document for reference.
Arul Suresh
PhD Candidate at Stanford University


  • Jake_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 1,505
    edited March 2018
    Hi @lemon1324

    The illegal modification you're seeing is a restriction we place on in context parts.  If you notice during manual editing of in-context part studios, you can't actually modify the ghosted in-context parts.  For example, if you try to do a transform without "Copy part" checked you have a similar problem:

    The reason this isn't an ILLEGAL_MODIFICATION is that the transform feature catches these parts early and throws an error if "copy part" is not checked. You can see this in action around line 297 of the `fTransform` feature:

    If you DO have the "Copy part" option checked, the transform feature actually uses opPattern instead of opTransform to create a transformed copy in the desired location.

    SO, how does this affect you?  You could use `fTransform` instead of `opTransform` and specify the `makeCopy` option,  but the `fTransform` feature does not take raw transforms so that may not be a great option. You'll probably want to do something like this:
    const modifiableEntities = qModifiableEntityFilter(definition.entities);
    const nonModifiableEntities = qSubtraction(definition.entities, modifiableEntities);
    and then use opTransform on the modifiableEntities and opPattern on the nonModifiableEntities.

    As for your last question, it's probably best to bring your copy of the feature up to current while you do this if possible.  There have been a lot of bug fixes since December 2015 :) .  Fun fact: V275 is when we came out of Beta.

    Hopefully I've answered all 4 of your questions.  
    Jake Rosenfeld - Modeling Team
  • lemon1324lemon1324 Member, Developers Posts: 170 EDU
    edited March 2018
    Ah, got it.  So it looks like when you in-context edit and then copy-in-place everything, the hidden non-modifiable bodies are still there.  In a part studio with 24 actual parts, querying all solid bodies returned 48 things.

    Adding the filter fixed everything, and also explains why those specific errors happened--modifiableEntities wasn't in 275, which is why it was failing silently, and obviously when doing it manually, I was clicking on the visible, modifiable part, which worked.
    Arul Suresh
    PhD Candidate at Stanford University
Sign In or Register to comment.