Not installing Packages from Dynamo, but downloading the ZIP from https://dynamopackages.com/
and then unzip it and place it in the (your) correct folder works better. At least for me it does.
Note Rename the ZIP to the package + version you downloaded (instead of the default name).
@bvs1982, I tried that I think the problem is that I’m currently working on Dynamo 1.3 and Revit 18.2. Guess I’m gonna need to update to be able to install the newest version of the Loci node.
Best is so remove ALL packages and reinstall the ones you need manually.
Your packages don’t even have to be in the Roaming folder. They can be in any folder.
Also best is not to have the same package(s) in multiple files and locations.
Maybe bit off-topic, but do you also have a way to remove the single PDFs after the merge.
The OOTB node File System > DeleteFile only work for a single File.
I need a way to remove FileS (so i don’t have too look them up and remove them manually).
Pretty sure I’ve used this for more than one file at a time. Post your current graph and a testable Revit file (asking for both as noted above, Revit and Dynamo version play a key part in the complexities here), and I’ll try and find time to review later.
When i use @Alban_de_Chasteigner solution to created a merged PDF and i want to delete
the unnecessary files afterwards - using the FileSystem.DeleteFile node - two of the PDFs are in the merged file (and are deleted) and the last PDF isn’t in the merged PDF and isn’t deleted either.
The other files are Deleted even tho the Node gives nulls.
There are sometimes problems with the speed of execution of actions between the different nodes. Passthrough does not always manage to force the execution order.
By the looks of this the file may still be in use from an application (Revit or the pdf combining action), though its admittedly hard to tell.
Try restarting Revit, freeze the delete node, run the graph, unfreeze the node, run the graph again. As long as no inputs change then the other nodes shouldn’t execute, and whatever ‘held’ the last PDF may have let it go.
If that pans out then it might be possible to write a delayed combinator via python, but this is something I haven’t experimented with yet.
It’s probably the same problem with the order of the operations and the speed of the virtual PDF Printer than @bvs1982 :
Try that instead. It will wait 10s before merging the pdf together :
Did i wire it correctly like this (for ‘my’ problem)?
I get the expected result this time (3 files in the merged PDF and all of the deleted),
but i wanna make sure it is not ‘by accident’.