Our Story:
A large retailer, with nearly 8 years experience with Revit. A family library of nearly 2,000 custom components. Custom-written database applications that read & write from Revit.
One single parameter brings the whole lot crashing down.
The culprit is the 'FINISH' Parameter in the CASEWORK family. It seems that Revit is hardcoded to only allow a TEXT field for 'Finish' in the Casework category.
This is a problem for us, as we use the Parameter 'Finish' as a MATERIAL type - as one would logically expect!
We want to use the Casework category, but we cannot assign a 'Finish' as we do for every other object as the data type is wrong - Revit says "NO. You must use a TEXT field for 'Finish' in Casework. NO SOUP FOR YOU!"
The 'Finish' Parameter cannot be edited in the Casework category - not in the family editor, not in the the RFT file. In fact we can't even edit the RFT file, which was how we got around this in the past.
So now that we have updated to 2013 we are screwed, and I have to decide which one of two dead whales I have to kick down a 7 mile beach (yes, an operation that is long, hard, messy and something I really would rather not do)
Do we:
1. rewrite ALL of our families to have a different parameter, leaving a rogue 'Finish' parameter to cause confusion? (I'll have to go buy something like a $2,500 plugin to edit families en masse - I don't what to hand-edit 2,000 files), oh, and I will also have to spend a big chunk of budget rewriting all the databases to use the new parameter, or write a 'shim' to translate database keys - kludgy, horrid, difficult to document & maintain - just yet more overhead.
2. Ignore the CASEWORK category, put all of our CASEWORK in GENERIC MODELS and have to embarrasingly explain why to all our BIM partners? The shame of having Archicad guys laugh at me - "You can't change a default parameter? BWAHAHAHAHA!"
I used to know of some sneaky, undocumented ways of editing RFT parameters to 'clear out the junk' so you could have nice clean custom families with correct parameters and NO 'rogue' unused parameters; but such methods no longer work (to explain - we have just upgraded from Revit 2009 (!) to 2013...)
Revit now demands that we have a 'Finish' Parameter in Casework that is a TEXT field, and won't accept any persuasion otherwise.
Does anyone know of a way to get Revit to allow a 'default' parameter to be changed?
Remember this is not a system parameter, this is 'just' an family parameter - and one that in most of the content that comes with Revit OOTB actually use the same way we do - as a MATERIAL type. Having a parameter in the 'Material & Finishes' group set to be a TEXT parameter, ignoring the entire MATERIAL system is just a bit... DAFT!
There is something I don't understand about your situation. You say that you guys have been dealing with Revit families for 8 years. Has the casework template ever been different? I doubt it, since those templates tend to stay the same year after year. If the Finish parameter was Text, you knew it was Text since eight years ago. Why from the beginning, you did not create your own "Finish_material" parameter as material? Or why is this an issue now after 8 years of working with the default Finish as text? You say that it is because of the upgrade to 2013. I don't understand that part.
There's a new add-in on the exchange site that does everything that that $2500 program does and more for only 10% of the price. Check it out! Parameter Manager or something.
I don't have the time to test and verify this at the moment, but try changing the extension on your family template (.rft) to .rfa, then open it, make the changes you want (may need to delete the Finish parameter and create a new one in order to change the formatting to Text), save it, then change the extension back to .rft.
No, the Finish parameter cannot be modified nor deleted, and if you start a family with another template and change it to Casework, the parameter shows up again....
Yes Ross, this is what we had done in the past, and it worked as long as you didn't later change the category.
You used to have the nice little workaround that you could rename a template to RFA, make the edits you wanted, then resave as RFT.
That ability seems to have been removed - there is now some hard restriction on doing that.
I really can't understand the hard restrictions with regards to template parameters. Revit won't break as far as I can tell if a door family doesn't have a 'Rough Width' parameter, especially when that parameter might not even be used. So what is the logical reason for making such parameters undeletable?
Sure I can understand the basis for having templates set up a certain way, but FORCING end users to retain a whole bunch of parameters that might not be used is very strange. AutoCAD doesn't FORCE you to have 7 undeletable layers in every block, and it would be a right pain if it did - but that is in effect what Revit does!
More parameters = more confusion for end users. We are trying to reduce the number of parameters to reduce confusion, and are left with a scattering of parameters that can't be deleted.
If there was a good reason why they are undeleteable then I would feel better because I could give users a reason why all our doors have a Rough Width parameter, but I can't think of any good reasons.
BTW I had a look at the 'Parameter Manager' mentioned, - presumably this is Sumex Parameter Manager?
Nice looking app, but unfortunately no help - it only edits Shared Parameters.
@Alfredo_Medina wrote:No, the Finish parameter cannot be modified nor deleted, and if you start a family with another template and change it to Casework, the parameter shows up again....
Oh well, back to the drawing board, I suppose. I imagine there's some reason that particular parameters are hard-coded, although for the life of me I can figure out what it is.
Well, crap.
Sorry to hear that you've used only family parameters for all of those families of yours. That'll make editing them all fun in the future when more stuff like this arises.
We use a fairly exhaustive set of Shared Parameters.
My issue with the Finish parameter is that in the past we were able to remove it by the undocumented ability to edit an RFT.
We can no longer do this, as the method to remove such a parameter is now blocked. So now we have a 'Finish' parameter appearing in Casework only, that must be documented as not to be used, and additional QA time spent ensuring that users don't enter materials in that parameter - annoying as it is now the FIRST parameter that appears in the 'Materials' group - we cannot even move it to another group to hide it!
The fact that we had removed the parameter in the past leaves us with a problem now - yes, you can say this is not Revit's problem, we removed the parameter... BUT there is the issue that we are left in the situation due to what seem to be arbitrary decisions on Autodesk's part.
Why is 'Finish' a protected parameter in Casework, but NOWHERE ELSE?
Why is it suddenly important to remove the ability to edit RFTs?
Why does Revit change customised Shared Parameters arbitrarily without informing you?
Did you know that Revit will rename YOUR Shared Parameters without informing you? No? Neither did I until I found out by accident!
The use of parameters in Revit appears to follow some strict rules that are rooted in the historic paradigm of 'NO CUSTOMISATION' in Revit - No UI changes, No function changes. The 'new' paradigm of allowing customisation is admirable and very welcome, but we are still left with little 'landmines' like this - you can edit everything else BUT YOU CAN'T EDIT THE ALMIGHTY 'FINISH' OR "ROUGH WIDTH' PARAMETER! (with apologies to Hunter Kressel - Google him)
If there is some great and powerful an functionality that the 'Finish' parameter enables - maybe it contains the piece of code that makes the TAB key work - then sure, leave it as it is. But I am willing to bet that there isn't anything 'magic' about the 'Finish' parameter - or the 'Rough Width' parameter either.
If I understand correctly, you used to have a template of the Casework category, made in a previous version of Revit, which you had been able to edit to remove the Finish parameter. What happens when you open the same old template in 2013?
Open old template in 2013 - The 'Finish' parameter is automatically created as a TEXT parameter.
Any EXISITING parameter named 'Finish' (INCLUDING Shared Parameters!) is automatically RENAMED to 'FINISH1'. Of course this breaks Shared Parameters and mayhem ensues.
Any attempt to insert a FAMILY created in previous versions with the 'Finish' parameter removed results in the 'Finish' Parameter being added.
Any attempt to insert a FAMILY with an existing parameter called 'Finish' that is NOT a TEXT field results in a failed insert - 'Cannot create parameter - load cancelled' or error message to that effect.
I have since unpacked the RTF/RFA format to see if the structure was something simple like XML that I could tweak, but no, it's some form of encoding, and I don't have access to disassembly tools here! The file format is interesting however, and does contain some form of XML / text fileds which give me some clues as to how people are writing apps that find things like Revit Version Numbers from families. I notice that all the templates that ship OOTB with Revit 2013 still claim to be made by the BETA vesrion in February 2012 by the way...
Why some of this data could not be exposed in a 'MANAGER'S MODE' of Revit is a bit beyond me, and yes I am aware of the older versions debug mode - it would make some of the aspects of managing a BIM system MUCH easier! Perhaps a command-line switch to activate 'BIM MANAGER / CAT HERDER MODE'?
I try to do ...
- Change Family Category by Generic model, then modify parameter names, then change family category by original.
OK?!
This "FINISH" parameter is hardcoded into doors also. I am trying to help our users distinguish the difference between Door Finish and Frame Finish.
In our office Door Material and Door Finish are both Type Parameters and Frame Material / Frame Finish are both Instance Parameters. Now when a user selects a door in the project, they will see this under the instance properties: (this is maddening). I feel your pain about the casework parameter.