Jump to content
  • 0

align distribute 2021 working?


jnr

Question

8 answers to this question

Recommended Posts

  • 0

Hi

 

Related to the Marionette Command, which do not support PDFs on Screen-Plane:

 This Command uses the  Technical speaking this is not ab bug in the script it is a limitation(or bug, sometimes it is not so clear) in the Move-Node,

wich was not my idea 🙂

If you put your PDFs on Layer-Plane instead of Screen-Plane (which is hardly recommended) the PDFs will move.

To have a working Script for Sheet-layers I provide a 2nd Version, that just move every Object as a 2D Object. Which can be used on Layouts. But maybe will fail on Design-Layers which some Object Types. I want to avoid making an own Version of the MoveNode.

 

Regards
DomC

 

 

Background:

Internally there are two commands to move Ojects. For some objects this is "vs.Move3DObj()"  for other objects this is "vs.HMove()". As example you can't move a 3D Object with "vs.HMove()" and can't move a planar Object with "vs.Move3DObj()". The Standard-MoveNode (which the Script uses) has a function which sorts the Objects in "3D-movable" and "2D-movable" Objects. This Funktion is called "Marionette.Is2DObject()". And this function has the limitation, that not every object Type on every alignment combination(Screen-Plane, Layer-Plane ) is supported.


However, I will commit a report related to the Move-Node. Viewports on screen-Plane and PDFs on Screen-Plane ( on Sheet-Layers we are on Screen-Plane) should be supported. Thanks you very much for reporting this!


Further Details:

The Function which sorts the Objects in "2D moveable and 3D moveable":

 

def Is2DObject(h):
    t = vs.GetTypeN(h)
    result = (t >= 2 and t <= 6) or t == 8 or t == 10 or (t >= 12 and t <= 14) or t == 17 or t == 21 or t == 22
    if t == 11:
            obj = vs.FInGroup(h)
            while ( obj != None ):
                if Is2DObject(obj):
                    obj = vs.NextObj(obj)
                    result = True
                else:
                    result = False
                    break
    return result


The code say, that it is 2D if it matches any of the critieria after "result =". Else it will moved by 3D Command. As far as I can understand it. A PDF Page is Object Type "86" (PIO) which then will have the Value Is2DObject() == False. And the Node will try to move with  3D-Command which do not work.  Also I think in older Versions of "Is2D" a group just will move with the 2D-move which maybe works in your Situation.

 

Related to the Menu Command:

I heared this is already reported and should be fixed in next SP.

 

Edited by DomC
Link to comment
  • 0

Dom C

Thanks for the thorough response. My observation still stands and is part of a larger issue with the software. This feature works as advertised in 2020 without any complicated or additional steps, but in my world, it's broken in 2021. Why take away what already works? While innovation is critical for growth in this industry, the balance between stable, functional software and new bling, is out of balance. NNA is not alone (one only need to read up on Revit woes). Users have been screaming for years for stability and good functionality (witness the piece of crap that is the stair tool) and doesn't take 6-9 months of crashes and bug submittals before we can trust that it won't blow up. 

 

This needs to be fixed. 

 

  • Like 2
Link to comment
  • 0

Hi
Good idea. Unfortunately it does not solve the problem. You can get True and False for the same object type if it on is aligned by screen plane or by layer plane. As example a PDF is type 86 and should be moved with 3D command (I guess). But if it is aligned screen plane (sheet Layer) it would be marked (by checking this Object Variable instead of Object Type) as an object which have to be moved with the 2D Command.

Link to comment
  • 0

I notice now that this is not the Vectorscript forum. 

 

Anyway: You can move 2D and it will silently fail on 3D objects. The problem is the view: HMove is a screen view move and will move your object wrongly, depending on the active view. If you are in a command, you can simply save view, launch DoMenuTextByName('Standard Views', 1); { top plan } and restore at the end, after using HMove.

 

Objects can also be "put flat" using SetPlanarRefIDToGround before doing move actions. For very complex plane situations it gets REALLY tricky. The absolute king of the move is @MullinRJ (Raymond Mullin) . He'll know all about this.

 

More important, on my opinion: you should parse for locked objects.

Referenced objects are also locked objects. They don't silently fail, they rise error if you try to manipulate them.

isLocked := GetObjectVariableBoolean(h, 700);

 

Other useful things (for those who don't know) and need to manipulate move actions:

activePlaneIsScreen := GetPref(1099);
objectIsScreenPlane := GetObjectVariableBoo(obj, 1160);

 

  • Like 1
Link to comment

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.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...