Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Thanks for your submission and votes on this idea! We are evaluating where this request falls into our roadmap and will provide an update when we have made a decision.
This would be very helpful for many things, especially with the ability to show calculated parameters in tags. Key schedules are great for standardizing information, but often that information needs to be displayed outside a schedule.
Finish groups in apartment complexes
Occupancy types for rooms and areas (Assembly, /Occupant or /Unit text to a tag, etc.)
Adding the ability to include calculated values in tags feels like a near miss when we still do not have the ability to use shared parameters in key schedules.
I submitted this idea as well. Having the ability to use Shared Parameters in a Key Schedule is a must. Calculated Values to Tags is pretty useless without enabling this feature.
Adding my support for this one. Was excited to use a calculated value in a tag, for occupancy calculations, but without the ability to tie it to the occupancy load factors in my key schedule - no can do 😞 Thanks!
@Anonymous First of all the issue of what would happen if a shared parameter is defined in both a shared parameter and in a family only applies to all non-system families where you can add a formula. As with anything else being transferred, I'd see the project information as overruling any in the project. Ideally, when trying to add a shared parameter controlled by a formula in a family Revit would give you a warning that the shared parameter is defined elsewhere. It would then either:
Not allow the shared parameter to be added to the key schedule while controlled by a formula
(Preferred) Have additional warning dialogue text stating "If you continue _____ parameter will be overridden" After clicking "OK" it would allow the parameter to be added and would add an asterisk to the model name or highlight the parameter field in some way, with the hoover text "this parameter is being controlled by a key schedule". If the family is edited or put in another project without that key schedule it will revert to having the shared parameter be controlled by the formula
Only to give one example from a previous experience in case it helps Autodesk:
The goal was be to be able to control door Ironmongery visibility parameters on the door families (such as kick and push plate; lever, pull handle and/or push bar; euro lock, thumb turn or occupancy signage; WC and/or statutory signage, etc) through the Ironmongery Set (key) schedule, which could even be linked to an external excel file.
In the beginning it was ok to control it through door schedules but once the number of doors on the project surpassed the couple of thousands then it became a bit harder to handle it. I initially had the idea to create a few basic hardware sets inside the family with the ability to override it by instance if needed (see image), but then the number of sets started increasing rapidly and suddenly that approach was no longer enough.
I then considered creating dummy "yes/no" text parameters on the key schedule (only parameter type allowed) and then match the family parameters to them through dynamo, but it would became too messy down the road, ending up being a bigger problem than actually started with.
If we had the power to control more than "dummy" text parameters on a family through a key schedule, that would be powerful! Those specific parameters could then all be instance so to avoid conflicts, not a problem. But ideally type would override type and instance would override instance. It could work as sort of a "Global Parameters Set" with "sub-parameters" associated to it.
Or else to be able to have those "parameter sets" or key schedules inside the families to control a set of parameters at once would also be great and save huge time...
