Hi
Why when I give a name to the program but in the output of indefinite items is added to the end of the name?
This is annoying at the construction output.
What you said isn’t entirely correct, @Mohammad.hakim.a . The display_name property of the object is set to be the exact same as the _name input and this is intended to be a human-readable way to identify the object you have made. However, all honeybee objects also have a unique identifier, which follows the object though the simulation engines and is what’s used by the rest of the software to uniquely identify the object.
You raise a good point, which is that, if we are going to expose something on the Grasshopper GUI, it should be the display name instead of the identifier so we may update the behavior in your screenshot soon.
I’ll also offer one other option, which is really only suitable when you are building definitions solely for you own machine (you never intend to share them) or you have some means generating your own IDs that are unique enough to avoid ID conflicts with other users and other machines. You can use the “HB Set Identifier” component to manually override the ID that is assigned to any object:
Set_Unique_ID.gh (9.7 KB)
Just bear in mind that you are playing with fire when you use this component and you really need to be sure that your _id is unique in order to avoid issues ID collisions.
1 Like
@chris In general, you are right. As seen in the attachment, the entered name and the displayed name were the same in the previous version, but not in the new version. This made it easy for us to write the input name in a panel and use the algorithm anywhere, and by changing it, everything was easily connected. But in the new version, we must connect from the output to any part of the algorithm that we need, and the role of the name is practically diminished.
Name.gh (109.4 KB)
Is it wrong to use a name like this? Doesn’t that make it easy?
Just use the “HB Set Identifier” if you need to hard-assign the ID of any object (whether it’s a schedule, construction, room, etc.).
And I would recommend choosing and ID that has a lower risk of colliding with IDs on other people’s machines.
“OCCUPANCYSCH-SCH1” might be a perfectly unique ID for a schedule in a single IDF but, if this is the ID of a schedule in a user_library that you plan to reuse over and over again, then chances are high that you’ll eventually encounter an ID collision. For example, if you share your library with someone else and they have a schedule with the same ID.
1 Like