Background: A project was required to have graphic scales on every view, so I wrote a script to place all of them, but also need a way to place the family for specific viewports. I ended up with a seperate script, but rerunning it moved a single family. Based on this thread I think the issue is that I need to close the transaction after each run. I haven’t done much python (really only copy/paste other scripts) can’t figure out how to modify the python script in that thread to work with placing instances by view api. Dynamo also doesn’t seem to have any nodes/packages that can do the job.
I need to be able to rerun the script where I select viewports without cutting and pasting each family to stop it being relocated.
I’d like to have one thread that can place the family for all viewports on the designated sheets, or specific viewports but ran into several issues:
- List.LaceLongest fails when their is a one item list
- I’m not sure the toggle works back and forth between the large list and the small list
- Select Model Elements doesn’t work with viewports, so I have to select them one at a time
Script images: Placing the family on all selected viewports, an attempt at toggling between selection methods and placing on selected viewport.
I think if you use dynamo player with your existing script you likely won‘t run into the issue you‘re describing.
Have you seen this node from clockwork?
I’m using that node from clockwork to place the instances - I thought using the export workspace from dynamo would get all the nodes, but it doesn’t look like it did - if you have suggestions for how to get the whole thing I will reupload them.
That might be an option, but I’d like to get it working without player until I’ve worked out all the bugs, and since a number of packages have to be added most people would need to open dynamo anyways.
Yeah, you might need to zoom in then export, or do several images for us to review. Also, sharing the graph helps. But sometimes people can’t share for a variety of reasons.
Ok, this version of all the views should have the node titles, and the scripts.
4709 View Titles v 0.14 multiple.dyn
4709 View Titles v 0.15 single DRAFT.dyn
4709 View Titles All.dyn
If you modify the user’s package path settings to a shared network location and set that above the C drive location you can ensure that everyone has the same package and that it’s consistently up to date. This folder has to have read/write access for some packages, but overall that’s a good practice.
Also running via dynamo player is often faster as it doesn’t have to load so much of the UI and graph previews/graphics on each run, so double bonus.
Interesting, I’ll have to investigate that. How does that work for running the scripts while building them? Can you have two package directories? I’ll end up installing ones to play with or test, but most users won’t need that many. I haven’t played with it in 2018, but browsing for scripts in 2017 player is really clunky compared to opening through Dynamo, so I haven’t tried building scripts for the player.
I’d still like to get this working without the player.
It’s no different but you have a degree of certainty that all packages in use are accessible and run on every machine in the office.
I advise you to keep the package count to a minimum in your “test” location, but that was my method. I actually used my C drive and made quick decisions if something should be kept (Clockwork) or lost (Create List Test Number 39795).
If you set the player package up right it’s not too bad. One directory for each major ‘type’ of script, linked into a single “dynamo player” directory which things default to at first launch. Users then navigate into the given location. Don’t let your "working’ scripts live there. Most scripts can be marked ‘read only’ but depending on packages used that can be modified, but long term I dont’ think that’s viable. Create a “read only” copy of the folder incase someone clicks the edit button and modifies something for a project specific use, breaking your firm wide almost always applicable in some what but will always at least be a better starting point than an empty graph… * takes a deep breath *
Yes that is possible, you just have to manage it in advance.