Matching Rhino Options - Help?

I’ve just had a to do two hardware switches, both on my personal laptop and my work workstation. This has presented some problems/shortcomings to me in terms of achieving consistency across them, in terms of plugins, scripts, options, stuff added to localization and other customisations. So with various rhp/rvb/py/rhi files that reference, for example, aliases I have set up.

Does anybody have tips for the best way to organise this? Just to save constantly pinging across, for example, latest aliases / new plugin/script finds etc as and when they surface. Also attempts to try and organise it can cause problems as the PlugInManager points to a location, so ideally I should load it in from a Good Place if I want to continue that way.

Maybe there should be a documentation update?

There is no tool for making two installations of Rhino identical that I know of.
Maybe this will help a bit:

Thanks for offering this up John.

The out of the box options are okay to export. Although there is still the problem with Display modes not importing.

For me it’s the wider issue of .py files, any number of custom scripts and so on. I think that’s one of the reasons why I oftn wish for things to be incorporated as features (and for others). Because otherwise, all the things you build up ober time go (and can require discourse digging).

I think it could be good as something to suggest anyway, to answer the question of ‘How can we better port all of our custom scripts and plugins of various formats to a clean build’. Even if that is just advising users the best file location (or shared method) to place any customisations to begin with.

As an example, even just working between WIp and V6, the discrepancy can be a bit nightmareish with regards to scripts, plugins and the like. I guess what it would be wondering how scripts and plugins could form part of an OptionsExport / OptionsImport. Unless I’m the only person who is experiencing this, that is.

I would assume that is true as the SDK for the wip is not frozen yet, and as such everything is still in flux. Differences between a shipping product and a beta are to be expected.

scripts and plugins cannot reasonably be assumed to transfer perfectly yet… wip = work in progress…

plugins will need to be updated by their respective developers once the platform is frozen and stable.

Hello - what do you mean, exactly? Can you give an example?


If you have, say, 25 aliases that link to 25 script locations on one computer, it’s just a bit of a faff to then be able to get these working on a totally different machine, that I will need to find all the relevant aliases and redirect them. It serves me for having a different way of organising between work/personal. I use the case of aliases, because that intuitively seems like the most convenient way of keeping py scripts consistent between machines. Let me know if that seems a bit clearer.

here’s one… C:\Users\j.hutchinson\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins\PythonPlugins\JHutchinson {4a3ff42f-607d-4862-a829-e3f1a423b78c}\ has disappeared from my Rhino 6 install…

Or at least, so I thought it had for a moment. That is just the py location my alias will point tobecause it’s imported from a different machine, a location which doesn’t exist on the other one. Maybe this makes it a bit clearer, because if I was to amend an alias on this other machine, I couldn’t export the text file and import onto the other machine, because I would be back to the start again. I would kind of have to keep a track of which one or two plugins I’ve added since last time, add their different link because they’re from a different file path.

Maybe this is just a a case for me using the rhinoscriptsyntax alias commands isAlias etc. if this is my preferred way. Let me know if this makes what I’m saying a little clearer.

Alternatively, is a good method considered to be packaging lots of .py files into a plugin that you can just shift around? Then the dependency is all linked to the .rhp file. Open to absolutely any advice really.

Hello - Since, currently, Rhino does not care where you put scripts on your machine, exporting the paths to these would generally be completely useless on another machine. I’d make plug-ins from the script compiler.


Hi Pascal,

I am wondering if the below method is the way out, to do all of these .py files as commands? Is that method considered to be the script compiler? I see there is also a V5 ‘script compiler’, and an old topic mentioning Microsoft VisualStudio.

Mostly I’m trying to make sure I am prepared, were this to happen in future, just so I can feel like I have come kind of control.

Hi pascal,

I’ve since found the below:

Is this the plugin compiler, in V7, you made reference to?