Jump to content

Tolu

Vectorworks, Inc Employee
  • Posts

    531
  • Joined

  • Last visited

Everything posted by Tolu

  1. No, a "Save and Commit" action is an all or nothing action - either all your changes go in or nothing goes in. You cannot check out resources. Multiple users can modify the same resource. The 2nd user to commit his/her change will be forced to resolve the conflict. I think you are mixing symbols and symbol instances. A symbol definition is a resource. It shows up in the Resource Manager. However, a symbol instance is an instance of a symbol definition. You can insert a symbol instance into a wall. You can check out the symbol instance, but its check out status is different than that of another symbol instance. As I mentioned above, you cannot check out a symbol definition. I agree. We are working on a solution, and it would be available in a future version of Vectorworks.
  2. On what type of server is your Project File located? Check that your PF is indeed writeable. Vectorworks shows that message whenever it is unable to write to the PF
  3. Well, "resources" are not the only thing that gets updated. Your layers (if you are referencing layers) does too, so that checkbox has to refer to the "reference" (i.e. referenced layers or referenced resources). Furthermore, an update will only "automatically" happen at file open if the reference is out-of-date (i.e. the source file has been modified at its source). As such, the label has to be "Automatically update out-of-date references during file open" Given that the checkbox label has to cover different aspects, it might not be intuitive to users. This is where help texts come in handy. Help texts provide additional information that cannot be put into the label of a control. Having said that, we'll look into making the checkbox label and/or help text clearer. We appreciate the feedback. Thanks, Tolu
  4. Could you please describe your workflow and explain the complexity issues you are experiencing? Copying and pasting will work, but it's error-prone. For example, you can only copy objects that are visible. You have to make sure you select all objects in the drawing, etc.
  5. If your Project Sharing Setting is configure to only allow SMB connections then you must connect to the share containing your PF using SMB. This alert is saying you are connected to the PF using AFP but the Project Sharing Setting is configure to only allow SMB connections. Note that the MacOS allows you to connect to a sever using both AFP and SMB (at the same time). Essentially, the PF will appear as separate files - they will have different file paths. As such, you should make sure you are connected to the server using the correct protocol (try using cmd+K and specify the correct protocol). Also you should make sure you are using the correct path. I actually recommend that you configure your Mac mini server to only accept connections for a specific protocol - AFP or SMB, but not both.
  6. The "Select Source..." button is disabled because your Reference Setting is set to use "Layer Import" and not "Design Layer Viewport"
  7. Could you please clarify the problem you are experiencing? Also what version of Vectorworks are you using? Once you check out a layer, you own all the objects on that layer. You do not need to check out individual objects on that layer. As far a filtering out objects, have you used the "Custom Check Out..." menu command under the Tools menu? Thanks, Tolu
  8. Hello Anton, What version of Vectorworks are you using? You cannot reference resources from a Working File since Working Files are temporary files . You can, however, reference resources from a Project File into your Elevation & Section files. You should be able to browse a Project File using the "Browse a Document..." menu action of the Resource Manager. Regards, Tolu
  9. @Asemblance Thanks for taking the time to do a screen recording. I was able to reproduce the clipping problem. We will fix this for SP2. After watching your video, I strongly advice that you check your Server and Network configurations. Your server (or network) is extremely slow in responding to object/layer check outs. Checking out a layer should be much faster. You shouldn't see the progress bar at all. Vectorworks is spending too much time waiting for your server to respond. Again, I think this is attributed to serious hardware problems - Server or Network configurations issues. Vectorworks tries a number of times to communicate with the PF and if that communication fails or the communication times out, you will get that message. Best Regards, Tolu
  10. @Asemblance Are you seeing this problems in both Vectorworks 2017 SP4 and Vectorworks 2018 SP1? I just tried this on my side and no communication was attempt with the PF. How are you noticing the communication with the PF? I see your specs as using OS X 10.11.6, are you also using a Mac OS Server? Thanks, Tolu
  11. I would recommend a workflow where each user use one single WF. This will simplify the management of WFs and it will eliminate the problem where objects are locked in other WFs. Note that if you work, save / commit / release, this will only release object is the active WFs. If you have other WFs they are not affected. Thanks, Tolu
  12. If that's your workflow then soft locks plays no part. Soft locks are only created when you are using object-level check out. Working Files will be helpful as well. Thanks. This alert is triggered when Vectorworks detects that your Working File data is out of date (i.e. the data in the WF no longer correlates with the PF). This often happens when using a WF backup but it is also possible if Vectorworks crashed after commit but before WF was saved. Are you experiencing frequent Vectorworks crashes during "Save and Commit"? If you are still seeing this, could you please send me your PF and WF? I can determine what's causing the alert. Are you using Vectorworks 2017 SP4? What happens if you select only the "_Pohjapiirustus 1 .krs. alapohja" layer only? Best Regards, Tolu
  13. The Release (as an admin) provides this option. If an admin (or any user) knows he/she will be out, he/she must issue a "Close and Release" before leaving otherwise other users will be blocked. If you want everyone to be Admin, Project Sharing will still work. You, however, must understand the consequences of releasing someone else's lock - lose of work. If the work being done within the team overlaps (i.e. the objects/layers that I modify today will likely be used by another user tomorrow), then you might need a process in place. For example, you could require each member of the team to "Save and Commit" their changes (with auto release locks option turned on. This is an option on the Commit dialog) or "Close and Release" at the end of the day (or more frequently). In addition, each member of the team must use the same Working File, so that all locks are cleared once they commit (or close and release). If you create a new WF and you check out an object/layer, that layer/object will remain checked out in that WF. Deleting the WF will not release the locks and "closing and releasing" in another WF will not release the lock in the first WF. If this happens again, could you please send me your Project File? I would investigate the issue. Best Regards, Tolu
  14. In Vectorworks 2017, drawing a rectangle on a non-checked out layer will not prompt you to check out the layer. My assumption all along was that you are using Vectorworks 2017. Is that not the case? Project Sharing requires frequent short file I/O operations. It's requirements are vastly different from non-project sharing files. Regards, Tolu
  15. 2. This will happen if another user has created an object on that layer. That is another user has a soft lock on that layer. There are 2 types of lock - exclusive lock and soft lock. With exclusive lock, only 1 user owns that lock, and only that user can modify that object. However, multiple users are allowed to hold soft locks on an object. These objects are always container objects, e.g. layers, groups, etc. With a soft lock, users are allowed to modify the contents of the object, but they are not allowed to modify the object directly. If a user checks out an object or a layer, that object or layer is exclusively checked out to that user. If a user modifies an existing object (or creates a new object) on a layer, that object is exclusively checked out to that user. In addition, that user owns a soft lock on that layer. Scenario: If User1 adds a Rectangle on Layer-1, User1 owns the Rectangle and he/she has a soft lock on Layer-1. If another user, User2, adds a Circle on Layer-1. User2 then holds an exclusive lock on that Circle. In addition, User1 and User2 each own a soft lock on Layer-1. In this scenario, no one on the team will be allowed to directly check out Layer-1 since other users already own objects (or have modified objects) on that layer. If any user goes to the Project Sharing dialog, Layer-1 will not be listed in blue because it is not checked out. However, as an Admin, if you select Layer-1 in the Project Sharing dialog, the Release button will become enabled since there are soft locks on Layer-1 that can be released. If as an Admin you click the Release button, you will be notified that 2 users will lose work (User1 and User2 in this scenario to be specific). 3. We have heard a lot problems with Synology drives. From our internal testing, we have found that these drives do not respect exclusive read/write access when you mix protocols. Specifically, we've found that 2 users are allowed to open the same file with read/write access. This is bad; it would most likely result in loss of work. If you search online, you will read posts from a lot of Synology users complaining about these problems (with different applications). As far as RAID 6 is concerned: extra parity data must be calculated and written separately. This means your writes will be slower. I propose you eliminate the RAID configuration and see if the delay problems go away. I will also recommend SSDs (if possible) over disk drives. Project Sharing requires frequent short file I/O operations; as such, you need your write as fast as possible. Thanks, Tolu
  16. 1. Static or dynamic IP differences shouldn't come into play, but static is better actually 2. Could you please provide specifics on the issues you are seeing with "Check-outs" and "Release"? Are you getting error messages? etc. 3. When a user "Saves and Commits" into the PF, some of the work is done in the background. That is, we allow the user to continue woking while data is being transferred to the server. If you are on a 1 Gbps network, this should only take a few seconds (not minutes). Are you connected to the network via WiFi or Ethernet cable? If your WiFi is on, turn it off to see if it makes a difference. Are you using SSDs on the server? Is the server setup using some RAID configuration? Could a process be slowing down the write operations on the server (e.g. Antivirus, etc.)? Thanks, Tolu
  17. You make valid points; and you are correct (if you go 30 minutes without hitting Ctrl+S) your back up will have the latest information. You will be better off with a backup that is ~3mins old versus a WF that's older.
  18. If it's 3 minutes old in most cases it might not be a problem; but I would advice against it (or say be very careful). Take the following scenario: 1. 12:00pm - You check out "Design Layer-1" 2. 12:01pm - You make some changes on "Design Layer-1" 3. 12:03pm - Backup of WF gets created 4. 12:04pm - You "Close and Release" your WF and you choose to discard all changes At this point, the backup WF thinks it still owns "Design Layer-1" and it has changes on "Design Layer-1" but the PF says it doesn't. This is an over-simplified example, but this is an example where the information in the backup does not correlate with the PF. Now, you will actually get a warning (alert dialog) when you reopen the backup file. Vectorworks will detect some discrepancies like the one mentioned above. Thanks, Tolu
  19. 2. You should always Commit and Refresh into your last saved WF. In the case that you have to recover work from a backup copy of your WF, I recommend you open the backup WF, and copy & paste information from it into your actual WF. Never "Save and Commit" from the backup copy. This is necessary because the WF stores information about which objects you own, and the changes you have made in the WF. Some of this information is also present in the PF. Specifically, the information in the WF must correlate with the information in the PF. The information in a 3-day-old backup WF, for example, will not correlate with the information in the latest version of the PF (well, unless the PF is also 3 days old or the owner of the WF has not done any work in 3 days). 3. "...so being able to override that from another user is handy". Yes, it might be handy but releasing someone else's work means that other person will all lose work (i.e. the work is present in their WF but it cannot commit it into the PF). If 3 people working on the project can perform an admin release, it is difficult to identify what got released and when it was released.
  20. Just wanted to chime on this report: 1. It is recommended that your Working Files (WF) are saved locally. 2. Do not use auto saved backups of your WF with Project Files (PF) . It is best to always reopen the PF to get a new WF. 3. Do not make all users an Administrator. The original poster mentioned all users are administrators. This is dangerous. This means any team member can release the exclusive lock that another user owns on one or more objects. If this happens, that user will lose work. Thanks, Tolu
  21. Hi Lars, If other users are able to access the PF on the server, I suspect it is a permission issue. I would recommend checking the permissions on the PF and its containing folders. You mentioned all users are using a MacOS. Do you know what protocol the affected user is using to connect to the server? Is everyone using the same protocol? Thanks, Tolu
  22. Hi Batch convert only requires one pass; and it should not require 12 hours to convert 32 files. Something is wrong here. In addition, you should not be required to click on any button. Could you please post a screenshot of the dialog to which you are referring? Thanks, Tolu tfapohunda@vectorworks.net
  23. Hi Genie, Could you please send me your files (tfapohunda at vectorworks.net). Regards, Tolu NNA
  24. In the master file, do you see a Record Format named "NNA#3__NNA_Wall_Style_Format"? If you do, delete the format. You should stop getting the message. Regards, Tolu
  25. The eyedropper tool does not work on DLVPs in Vectorworks 2008. This feature was added for Vectorworks 2009. Regards, Tolu
×
×
  • Create New...