I work for a university and I’m deploying Grasshopper plugin to over 100 comps.
I’m not a user of the software, but I’m trying to get it work in our environment.
Main question is… is there a variable that can be set in windows to force the defaultFolder (away from c:\ladybug)?
Users can’t write to the C drive which seems to be ignored and appdata folder is not attempted to be written to.
Some EPW outputs, it will complain ‘not connected to the internet and you do not have the weather files already on your computer’.
If I manually create c:\ladybug then everything works as expected.
If I create a panel and set the default folder to a writeable area, everything works as expected.
If there is an environment variable that could set this - it would help a lot…
Can you clarify how you install the Ladybug Tools plugins? Are you using the Pollination single click installer? My understanding is that we don’t use C:\ladybug as the default folder anymore. It is a different story if you are using the legacy plugins.
In any case, @chriswmackey is the better person to help you with this question.
It’s pretty clear from your description, @optimus , that you are installing the Legacy plugin, which is 4 years old, was partly deprecated in Rhino 7, and is fully deprecated in Rhino 8. Legacy also has no way to change the default folder where weather is downloaded to be anything other than c:\ladybug.
So you should no longer be using the Legacy plugin and should instead be installing something like Ladybug Tools 1.8, for which you can find the release notes here:
As you see at the top of the notes, LBT 1.8 can be installed via a single-click installer that should make your IT department happy and not give you any permission issues by default. This is because all weather is downloaded to a location in the User’s folder by default (instead of C:\ladybug, which is no longer used).
Moreover, LBT 1.8 has the ability to change the default folder from command line if you really need to but, like I said, you should typically not encounter any permission issues if you just use the defaults.
Lastly, if updating old Grasshopper scripts from Legacy to LBT 1.8 is currently what is blocking your university from updating, you should take a look at the first item in the release notes (the new LB Legacy Updater component), which is meant to help you more easily make the transition from Legacy to LBT.
Thanks for getting back.
I downloaded what I believe was the latest one available at the time (and only a few weeks ago).
I guess this is why ‘old’ is plastered across it…
Please remember - I’m not a user of the software, and I’ve only been figuring stuff out in the last week or so.
If I click on the link that you have referenced in your post, it takes me to a page to ‘download the latest version’ (when I select downloading and running the FREE SINGLE-CLICK INSTALLER
Grasshopper Plugin
The file is:
plugins_release_PollinationGHInstaller-1.46.0.exe
–was 1.43.6 a few weeks ago
What am I missing? (probably something I’m doing).
Doesn’t point to 1.8.
Also looking forward to trying out the silent install as previously, I’ve had to reboot the computer and create a local account to do the installation due to the installer needing to write to appdata folder (configuration manager).
The Pollination installer 1.46.0 will install the Pollination Grasshopper plugin with the same version. 1.46.0 in this case. And it also installs the latest version of Ladybug Tools which is currently version 1.8.
With the new LBT plugins, you should not need to edit the default folder. It should work out of the box after the installation.
I think I see what is going on.
The version installs correctly, but the file I have been provided with is referencing an older version of ladbybug 0.68…
I should direct students to follow these instructions.
Doing the above allows me to download to local profile after making some changes.
The display version of Ladybug tools is listed as 1.38.175 in windows control panel, but if I add in a ladybug module in grasshopper - default version is 1.8.0 so all good.
I can’t make all the changes required, as I’ve no idea what I’m doing with grasshopper/rhino - but this should be enough to allow me to work with the students.
You can probably tell that we’ve done a lot in the last few years to try and make you job easier but there are still many people using the old version of our software from years ago.
If your students or professors have any issues upgrading to the new software, you can always have them direct their questions to the forums and I’ll help as best I can.
We version the installer package differently using semantic release, but the Grasshopper components are versioned manually which is what we/people refer to as the Ladybug Tools version. I know it can be confusing, but these are implicit agreements that we simply take as granted. I’m glad that you found your way around!
Yes - all that really helps and our students will really appreciate it.
Just an observation, if I deploy through configuration manager / sccm - the installer (at least for 1.7, not tried 1.8) hangs.
Looking at the log files, it tries to write data to appdata folder - which the system account doesn’t have, so the install will just time out.
The workaround is to have a script create a local account, restart comp and install with that local account - which is something we would rather avoid.
It is not urgent, as I’ll be using the method above, but I’ll keep an eye out next year.
Hi @optimus, Thank you for the detailed explanation. We never faced this case as the users usually have a user folder, and a local account. We create those folders to use them later to save the user weather files, settings, etc. Where do you suggest us to save the user information on a local machine instead?
