Jump to content

David Bengali

Member
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

1 Neutral

About David Bengali

  • Rank
    Greenhorn

Personal Information

  • Occupation
    Theater Designer
  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi I am wondering if anyone can advise - I have enabled the reset on move and reset on rotate flags in my PIO, and the handling of these events seems to work correctly when a single PIO is selected. However, if I select other objects along with the PIO, there are some issues. If the other objects are simple objects like rectangles, etc, their 'preview shadows' move as expected while the operation is in progress, but they do not redraw correctly after the move or rotate operation is completed. The other object appears to remain drawn in its old location. But if I move my mouse around, I can find that the object did in fact move / rotate correctly but is now invisible except to selection highlighting. If I select it and change an attribute, the drawing correctly refreshes. The incorrect 'old' object disappears. If I have multiple instances of my PIO selected, and perform a move or rotate, one of them behaves correctly. The others mostly behave correctly, but appear grayed. If I select them and change an attribute or otherwise force a reset, they return to normal. In addition, I sometimes observe drawing objects that were not part of the selection becoming grayed when I perform these operations. Is there something I am doing wrong or a step I need to add?
  2. Hi I am wondering where we can find documentation on new functions in 2020 such as vsoStateGetRotN and how they differ from the previous versions? The function reference wiki currently has no information other than the parameter names. thanks!
  3. Just one quick followup @Vlado - It looks to me that if a parameter is a Dimension or a Control Point, then indeed vs.GetRField returns the value with full precision. However, if the Parameter is a Number, vs.GetRField returns a string representation that is truncated at 8 decimal places, even if the value shown in the OIP has more precision. Not sure if this is related. best, David
  4. Thank you @Vlado (and @Pat Stanford and @MullinRJ ) for tracking this down with me! And for the current workaround info. David
  5. Hi Pat, I am working on a scale of meters and feet, and using the values of control points and other parameters to perform calculations that then determine how the object is drawn, as well as what the values of other parameters will be, in addition to the position of various control points, as a result of the math. The errors pile up surprisingly quickly with a series of relatively simple mathematical operations, which is how I discovered this issue -- in some cases I start to see numeric errors appear in the first three decimal places of results when the underlying Parameter values can only be accessed to 6 decimal places and this error propagates. Without going into to much detail, one of the main issues (but not the only one) is that this limitation also prevents control points or drawing elements whose position is driven by mathematical calculations (or even simply by the value of another parameter) from landing in the spot that one would expect when using snapping. Two drawing elements that should be in the same place in the drawing end up slightly offset, which is not what a user will expect from snapping. Since Vectorworks clearly has access itself to more precision, and can show it in the OIP, I am surprised that it prevents us from getting those values inside of a script, especially since the values are already stored in a float, which does not have this limitation intrinsically.
  6. Hi, thanks Raymond, Just to clarify, float variables in Python do have more decimal places than this, I believe the same internal precision as REALS in VectorScript. Float's in Python are already the equivalent of double's. Can you verify that, in the case of a PIO built with VectorScript, when you access the Parameter values inside the script, you are getting all the available decimal places of precision, e.g., matching what you see in the Object Info Palette with the document unit preferences set to display 9 or more decimal places? What I am observing is not an issue of float variable precision. It specifically refers to what Vectorworks does, not to variables in general, but to PIO Parameters when it accesses them, at which point it seems to truncate the value, even when more decimal places are displayed in the Object Info Palette. I can assign a float value with greater precision than this to any variable within Python. But Vectorworks appears to have dropped that available precision when it stores Parameter values in the vs object's "P" variables, which is where we must look up these values from within the code. So, the precision is not being lost when storing the parameter value into another variable. It seems to be gone from the beginning of execution. There is no way that I know of to access Parameter values other than via vs.P[parameter name], and it does not look like there is anywhere to specify greater precision in the plugin definition parameter list, at least that I have found so far. Also to clarify, I am observing this not just with Control Point parameters, but with other Number parameters as well
  7. To make matters worse, if I expose the control point fields in the OIP, and turn up the decimal places document unit preference to a high value, I can see that if I snap the control point to a reference object whose position requires a large number of decimal places to represent, the PIO's control point field shows the correct value, with all the decimal places. But I just am unable to access that value from inside the scripting environment. If I expand the Globals -> vs module in the variable inspector (I am using Aptana as recommended on the wiki), the value of PControlPoint01X or PControlPoint01Y is truncated to 6 decimal places even though the OIP field shows more decimal places. I have tried changing units between feet and meters to see if that makes a difference, but it does not. In fact, this is not limited to control points (perhaps I should change the post title). For example, if I type a value with 9 decimal places into the field for a plain Number parameter, the value is accepted and displayed. But if I inspect the value of that parameter from inside the scripting environment, it has been truncated to 6 decimal places. Is this simply a (severe) limitation of scripting in Vectorworks? Or is there a way around this?
  8. Wondering if anyone can advise on this - I'm having some trouble with control point precision that is leading to erroneous behavior in a plugin object. I detected this issue in part through the debugger. Basically, when I drag a control point, it seems that the values I get when I access its coordinates from inside the scripting environment are truncated to only 6 decimal places. This introduces error into calculations based on that value. I have tested further by creating an object to use as a snapping location, and setting the position of this object to coordinates that require more than 6 decimal places to represent. If I increase the decimal place precision in the document unit preferences, I can see all of these decimal places in the OIP for the reference object. If I drag a control point in my plugin object to snap to this reference object, and then, by setting a breakpoint, inspect the value I get inside my script by accessing the control point (with, for example, vs.PControlPoint01Y), I see the value is still truncated, regardless of the document unit / precision settings. At only 6 decimal places, this can introduce pretty significant error. Is there some obvious thing I am missing to correct this behavior? I would expect that when I snap a control point to a location, the control point would be assigned a value as accurate as possible, or at least as accurate as the document settings indicate. Not sure if this is specific to Python scripting or not.
  9. I think I may not have enough info to answer this regarding batch encryption. For one plugin at a time, I think that what I have done in the past is to delete the __pycache__ folder and the .pyc files within, leaving only the vsm or vso file, the xml file, and the source .py files, then following the steps in which describes encrypting a single plugin from the Plugin Manager (as an alternative to EncryptVSPluginFilePath call) holding Ctrl+Shirt+Alt on win or Ctrl+Option+Cmd+Shift+CapsLock on mac and double click on a plugin. I'm not sure how encrypted this actually makes things, and how easy it is or is not to decompile / unencrypt in some way, but I think the code is not listed in plain text at least @Vlado may be able to clarify further on the process and its relationship to .pyc files, and how to ensure that the source code truly cannot be accessed in some way.
  10. Thanks Raymond, yes, that is what I had been doing essentially; I was just curious if there was a shorthand the way there is in VectorScript
  11. Vectorscript includes a way to specify points in distance-angle mode, by using a pound sign. Is there a way to do this as well in Python Scripting in Vectorworks?
  12. It has been a little while since I have dealt with this, but if I recall correctly, with python based plug ins, you have to get the code out of the main vso object in order to actually encrypt it and hide its code. i.e., make an external _main.py file, and then in the script that you can see from within the Vectorworks plugin manager, you would only have import _main _main.execute() You can use the xml file to identify this external file to be bundled

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...