Ah, OK, that was confusing… sorry for the mis-info.
It is confusing… I always have to look at the top of the list to see what it starts with to remember how to read the thing.
@pascal ;-( it is back, and I can’t seem to fix it this way anymore. Wonder if I did the steps correctly:
-Open…(getting the Save changes to Untitled dialog)
-Save as template
-check to open that as default
Hi Gijs - is this all in V6? Try New - find the template you created - make sure it has a recognizable name so you’re sure to get the right file, and then check the box there for using that file when Rhino starts…
yes it’s V6, and that’s exactly what I did. i just don’t understand why this worked and now all of sudden is broken again. But what’s even more odd, if I open a file and first after that try to open another file, I get the same dialog asking me to save the changes to the file I just opened…
I think that some folks at McNeel deserve a pay raise, and others (like the guy in charge of the interface) could enjoy a well earned retirement.
The contrast between exciting stuff and old recurring lameness in Rhino is blatant.
this part is driving me nuts, should I just completely reinstall? Anything else I can try?
Sounds like all else failed so far…
Time for a step-by-step approach?
Start with factory-default templates as your default (i.e. what Rhino starts with) and run in safe mode. Do you encounter the issue then? If not, gradually introduce plug-ins and stuff that you need in your customized template.
@wim, thanks. It does seem to be V-Ray again that’s causing this. I’ll contact Chaos support
VisualARQ needs to store information related to the plug-in on the 3DM. This information may contain user data like styles (wall, door, etc), settings, or plug-in data required by the plug-in to work.
If you execute a VisualARQ command like
vaWall, the plug-in will create a new wall style (if there are no wall styles in the document). Other operations, like working with Grasshopper Components or importing an IFC file will generate VisualARQ data that needs to be stored in the 3DM. Usually this information is about the 10% of the 3DM size.
If you want, you can run the command
vaPurge in order to erase all VisualARQ data from the active document.
If you think you never run any VisualARQ command on that document, then maybe there is a bug. So send me the document so I can check what information is in there.
Also, take into account that VisualARQ stores information about native Rhino objects, like section attributes, custom parameters, relations between them. Moreover, some geometry inside blocks is also replicated inside VisualARQ data to make sure VisualARQ objects can be recovered when the document is modified in a Rhino without VisualARQ.
If you work on documents with VisualARQ data, but you have Tibidabo and VisualARQ plugins blocked, VisualARQ cannot update its plugin data. For example, if you delete a bunch of Rhino objects, and VisualARQ is no loaded, VisualARQ data will still contain information related to those deleted objects. IMHO, in this situation, having VisualARQ blocked is not helping.
If you have problems with VisualARQ, please let me know. We will always try to make it better and fix any issues you have.
We have already been through this process, and it was supposed to be fixed.
Now the problem is back , adding over 80Mb to each file, which is just not acceptable.
I have un-installed VA and don’t plan to ever use it again.
I purged my file by saving my rhino file without plugin data and now, anything I export from it is nice and light again.
If VisualARQ is adding 80Mb to the file, it is because there is some VisualARQ data in the document.
You need to understand that Rhino (and not only Rhino, but any other application) plug-ins need to store information in the document in order to provide more features to the application they work on.
If you want, send me the document and I will check what VA information is in the file. Also, let me know what have you done in the document. Rhino templates has no Tibidabo/VA data, that’s for sure. And if Tibidabo and VA were locked, I don’t understand how VA data was in there…
Take into account that VA information will be exported/imported between documents (only if Tibidabo and VA are loaded), just like any other document information. VA styles or VA parameters are like Rhino layers or Rhino blocks, they are information, and information needs to be saved.
There could be a bug, or maybe this is not the behaviour you expect from our application.
I’ll be more than happy to help you with this issue. And if we could make changes in VisualARQ to improve your workflow, we’ll make them.
No one wants 80 MB of junk exported along if he exports a few curves, that just can’t be right.
My experience with VA is that it has been buggy, obnoxious and obtrusive.
Me and my team have spent more time reporting bugs/sending files, etc… than actually using it.
Now if you don’t mind, I need to get productive instead of fixing someone else’s botched work.
I would add another request that could be called “No sequential save”.
The thing is that, with the right click command recal, If after saving a huge file you have the silly idea of right-clicking (to re-focus on Rhino if you switched to another window for example), Rhino will run the “Save” command again, and re-save the identical file for absolutely nothing.
Put _Save in your “Never repeat” commands section. (Options>General)
Ahh thanks Mitch , thats’ where it was hidden. I had a vague memory of this.
It would make sense to have “Save” in there by default in my opinion…
Yeah, don’t know why it isn’t…
On the heap it is…