OptionsImport V7 pretty broken

Trying to transfer a few V7 settings from one computer to another. A number of things seem not to be working. First, an .ini file was created using OptionsExport and transferred to the new computer.

Attempts here to import some individual settings by checking boxes in OptionsImport results in the following:

Mouse: No change
Modeling Aids: No change
General: No change

and the worst:

Appearance: completely messes up my custom toolbar layout because the command prompt, docked at bottom, goes to the top, while the toolbars that were docked alongside it stay docked on the bottom.

In principle, Appearance should have nothing to do with toolbars, but I think the command prompt checkbox included in there is causing a reset of the placement - which by default is on top, and getting it to stick on the bottom has been buggy from the beginning - the only way being to actually undock it from the top and then redock it on the bottom.

On top of that, importing the Appearance section does not change the stuff it’s supposed to - the interface colors.

Hard to believe this stuff is so badly messed up.

Oh, and also, the Help entries on both of the above are also pretty ‘unhelpful’…

1 Like

Hi Mitch - ugh. thanks, I’ll test.


Well, in my humble opinion this whole system needs to be completely redone from scratch. The basics of this date back to V3 (IIRC); many things have radically changed to the point where some of the entries don’t even make sense anymore. Here’s the list for reference:



The detail of what can be imported is confusing and no longer granular enough. Most of the options pages now have sub pages; OptionsImport mostly refers to the top-level pages, it’s not clear if it imports settings from the sub pages or not. In one or two cases, there are redundancies, such as General and Never Repeat Commands - which is a subcategory of General; also the Context Menu entries which are sub-pages of Mouse.


  • Advanced display: the name makes no sense - that refers to the pre-display mode days settings. What does this cover exactly - all of the display modes? IMO, this should be removed from OptionsImport; importing display modes should be treated separately (see later).
  • Display: what does this cover? How is this related to the above/display modes?
  • View: again, now display modes are under the View page… covered? Not covered?
  • File: the option page is named Files. It also has a sub-page “search paths”. Included? Search paths is also a separate item further down. Importing paths (including autosave and template files) is always risky as paths may differ from one installation to another; maybe this needs to be handled differently.
  • Appearance: includes languages? Colors?

All of the above needs to be completely detailed out in the Help entries as well.

Final note concerning display mode export/import:

Within the same version, normally not a problem, except perhaps if a display mode includes a custom material that references a texture file that doesn’t exist on the importing machine…

We have had problems importing display modes from previous versions because certain types of settings had changed. IMO, we need a separate “display mode converter” module that can convert display modes to be compatible between versions - ostensibly to allow custom display modes to be imported from previous versions and work correctly.


Same problems on MacOS…


In the snip from the help file that Mitch included in his original post, under “Options Export”:
“…saves Options to a file.”

What is the name of the file and where is it saved? Seems like this would be a good thing for the help to mention.

It just brings up the standard save dialog, you can name it whatever you like .ini and save it wherever…

You’re right; it’s a pretty old system. I’m not sure why we are even making ini files anymore as the settings system is all xml based now and you could probably achieve what you want by copying your settings.xml file to a different computer.

1 Like

A post was split to a new topic: Crashing with rotating view

I thought about that too, I didn’t do it because I was not sure if all the settings should transfer safely between two different machines/setups and simply copying the whole file over doesn’t allow one to choose which options one wants to transfer.

If the old .ini system is obsolete as it seems, it should be completely removed and a new system that parses the .xml settings file and allows one to choose which settings one wants to transfer should be implemented.


hi Mitch,
Has this ever been fixed? Were you able to properly import options in V7 now or found a good workaround?

Asking since we plan to transition to V7 finally with full production and this part working will be quite important.



Hey Jarek,

To be honest, I haven’t tried since. I simply did what Steve suggested above and copied over my entire settings.xml file. That seems to work fine, but of course it isn’t granular - you get all or nothing. I guess you could go about editing the .xml if you want to customize, but that’s a lot of work.

I have no reason to believe that OptionsImport has been fixed however, there is still a Youtrack item open:


(I added a comment referencing this thread)

1 Like

Thanks Mitch, agree it would be nice to have the selective import work again.
@stevebaer - would the xml copy method work for copying settings between V6 and V7 without a major mess? Up until now I was counting on OptionsImport but seeing that it’s broken/obsolete I am trying to find a better way to migrate from V6 to V7 retaining all of the custom settings.


I would recommend backing up a copy of the settings xml file first and then copy the V6 one over. I wouldn’t expect problems, but if you do it would be easy to roll back by using the backup.

1 Like

That seems to work OK, thank you for the suggestion.


1 Like

I tried copying the settings.xml file as a ‘template’ for new users in our firm. It worked for one user like I would expect. Then another user tried it and it properly overwrite the xml file with the new one, but when they ran Rhino, it overwrote it with their old settings.

Is all I need the 'settings-Scheme__Default.xml" file? or are there other files that I need to overwrite?

Hi -

If they were running Rhino with a different scheme, copying that xml file wouldn’t do anything.
You write that, when they ran Rhino, it overwrote the settings - how do you know? Did you check the xml file before and after running Rhino and saw that it was changed the moment Rhino was run?

I did verify that the “settings-Scheme__Default.xml” contained the ‘new’ settings before running Rhino. Then after they opened Rhino, it changed the “settings-Scheme__Default.xml” back.

I assumed since it overwrote the “settings-Scheme__Default.xml” instead of creating a new xml with the new scheme name that they are not using schemes?

I installed Rhino 7 on my Windows 10 laptop a few months ago but since my settings did not automatically import I kept using Rhino 6 and only now got around to figuring out how to import them.

When I opened v7, the command panel was gone! (How can that even happen!?) There’s no menu command I could find to unhide it. So I used this thread’s suggestions, and they worked, but I think maybe some clarification would help others who like me are not as adept under the hood:

There is no single “settings.xml” file, rather a folder called “settings” with two .xml files in it: C:\Users[user]\AppData\Roaming\McNeel\Rhinoceros\7.0 [and/or 6.0]\settings. (Note “AppData” is hidden by default in File Explorer)

I renamed my Rhino v7 settings folder and copied in the settings folder from v6.

When I restarted v7, the layouts came up as in v6, although the instance uses the Rhino 6 icon in the taskbar, even though it is v7 that is running.

Screenshot 2021-06-07 125827

Yes there is, it’s called CommandPrompt - follow the options (Show/hide etc.). It’s also available via an Options>Appearance checkbox.

Yes, but the main settings are in “settings-Scheme__Default.xml”. It is possible that the window positions file might have info that the command prompt is hidden, but I didn’t find that entry.

I wanted to provide an update for my specific issue above (copying the xml file not working) - The issue was 100% on our end. It was all how our VDI manages the appdata folders. The solution that fixed it for us was to copy the xml file when Rhino was running. Then all was good.

To help others here is exactly what i did that works:
1-I got my personal Rhino exactly how i wanted the template to be.
2-i copied my settings xml file to our server. (the xml file in windows is located here %appdata%\McNeel\Rhinoceros\7.0\settings )
3-I then edited out a few lines to remove my recent files
4-for users i have them run a bat script that backs up their settings file, then copies that template file to their settings folder. They way our VDI is set up, they need to run the script while rhino is running.

the bat script i created:

robocopy.exe "%appdata%\McNeel\Rhinoceros\7.0\settings" /e "%appdata%\McNeel\Rhinoceros\7.0\settings\backup"
robocopy.exe "\\Your Server Path To The Folder With The Settings File" /e "%appdata%\McNeel\Rhinoceros\7.0\settings"

Thanks everyone for the help and workarounds!