Jump to content
Developer Wiki and Function Reference Links ×

How to build confusion when scripting


Recommended Posts

 

 

Hello

Using as well the VW data bases and Marionette I find confusing the “height” terminology.

In marionette it is use to define length and in the data base the height, which is named “depth” in Marionette.

It is confusing when you start naming Enveloppe or using “get” functions

Knowing it would be a huge task to change names … Any ideas?

screen Mar.png

screen data.png

Truss.png

script.png

Link to comment
  • Marionette Maven

This is an issue I've been trying to find the best solution to. It comes up because in 2D, we reference the Y dimension as height, but in 3D objects, the Z dimension is often considered its height. Some nodes (such as Get Poly Bounds) have been updated to reflect dimensions rather than the confusing terminology.
For this node, Height refers to the Y dimension and BotZ and TopZ allow you to set your lower and upper value for a 3D height.

If you have any suggestions as to how these can better be defined, please let me know and I will absolutely take it into consideration.

Link to comment

Hi Marissa

The hardest but only solution I found is to change scripts.

In the workflow more and more projects are in 3D. Therefore, it becomes difficult to know with height what is what. Unfortunately, it is the same in 3D where people use height and others depth (like Marionette).

Here is the first changed node.😊

Capture d’écran 2025-01-23 à 16.33.44.png

node modified.vwx

Link to comment
4 hours ago, Marissa Farrell said:

This is an issue I've been trying to find the best solution to. It comes up because in 2D, we reference the Y dimension as height, but in 3D objects, the Z dimension is often considered its height.


Prefacing my post with not having any experience with Marionette — but regardless of whether an object is 2D or 3D, shouldn’t X - Y - Z always refer to the same polar coordinate dimensions?


Referencing the Y dimension for a 2D object as ‘height’ seems confusing & incorrect, at least to me. If I were describing the dimensions for a 2D rectangle representing a bookcase, for example, it would be:

Length (X dimension) by Width (Y dimension).
If I wanted to describe it as a 3d object I would add the Height (Z dimension).

 

So in the first node example that the frog posted, would it be less confusing if ‘nWidth’ became something like ‘dimX’ or ‘nXdim’ ? And ‘nHeight’ were ‘dimY’ or ‘nYdim’ ?

Link to comment
39 minutes ago, rDesign said:

Prefacing my post with not having any experience with Marionette — but regardless of whether an object is 2D or 3D, shouldn’t X - Y - Z always refer to the same polar coordinate dimensions?

Yes, they probably should. But design decisions made back in the 80s/90s when 2D was first added to MiniCAD (now Vectorworks) created the problem. And now it is even harder to "fix" because a large part of the user base understands how it works and the question for VW is do we piss off all (most) of the existing customer base by changing something they have been using for years/decades? Or do we suffer along with an idosyncracy for new users to have to learn and get used to?

 

Glad it is not my job to make that decisions.

 

My $0.02

Not affiliated with VW except as a volunteer moderator of the forum and long time user.

  • Like 1
Link to comment
1 hour ago, Pat Stanford said:

Or do we suffer along with an idosyncracy for new users to have to learn and get used to?


Agreed. Also as a long time user of VW, idiosyncrasies like this was something I just had to learn to accept.
It is the way it is and probably always will / should be.
 

Perhaps any XYZ nomenclature clarifications that Marissa was seeking input for can / should only be made inside Marionette nodes. Especially since they are the ‘New Kids on the Block’, so to speak.

  • Like 1
Link to comment

I too being a longtime user (since mac +) first Macdraw and of course minicad, I was thinking of Marionette only. Specifically in the scripts. It struck me because if you start working with data base info at a certain point (picking the info) to insert them via a node you get one word for two info.

Of course, when I draw there is no problem with Y being height.

Link to comment
  • Marionette Maven

It's also hard since when Marionette was introduced (before I came to work at VW), all of the nodes were written to match the underlying Vectorscript calls and nodes mostly just matched the functionality of what already existed. At this point, I've reworked a lot of the library to minimize redundancies and try to make things more user-friendly, but I've tried to not overwhelm users experienced with Marionette as it was originally implemented with big changes.

Another tricky thing is making sure that users understand that these dimensions are referring to an object's coordinate system, and not the drawing's coordinate system. When a user is querying an existing object, if it's rotated on the drawing area, they may not realize that they're not pulling from the x/y that they see on their screen. 

I do like the idea of referencing by x/y/z dims, I just want to make sure it's not MORE confusing than it already is, especially with Marionette being what I consider the "hand-holding" way of custom scripting. I also am an advocate of users eventually migrating to traditional python/vectorscript, so I don't like to stray too far from that syntax in the process.

  • Like 4
Link to comment

Yes I approve the path you are following. I think there is no optimum solution. x,y,z alone can easily be confused with math parameters so Dimx , Dimy, Dimz could be a solution. Then again is that case we lose the connection with our habits without gaining any improvement from the data base. Back to the start of the discussion. There is an issue if Marionette nodes are referencing digits from the VW data bases. Otherwise life in Marionette can be “simple”.

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
Reply to this topic...

×   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...