Contextual “Get Geometry” lacks the option for simple Line objects
If one could flag only “Line” in the filter, selecting a curved curve should be discarded/impossible.
Contextual “Get Line” is a different thing, because it prompts the user to pick 2 points.
Default value: how?
Setting “At least=0” should let one to bypass entering a value, letting the script execute anyway.
I tried with feeding the contextual component with a value or using a value if the user returns a “null”, but it simply abort the execution of the player completely.
Presets.
Anything you enter in that window will be ignored if is different from this format:
You can’t use strings.
And this is quite dumb as, even using this format, will result in this:
@AndyPayne can you look into this?
There is a way to have default value? (for when the user skip a “get …” step. See my first post.)
Presets simply do not work properly. Get Integer and Get Number:
You enter some preset values
Then confirm and reenter that menu and presets are changed to
but then even if you change them to something like
is useless, because once you execute the player you get this:
and the 20,30,40 values/strings are nowhere to be seen.
With Get String it is similar:
once executed:
simple number strings are ignored (and cause other fishy problems in the presets list).
Generally presets do not work nicely.
anything past the “=” is totally ignored, and we can’t have a nice control over it.
I would expect something like:
value_used_in_the_code = “option description shown in the command bar”
or vice-versa.
A simple:
3 = “Triangle”
4 = “Square”
5 = “Pentagon”
or
“Triangle” = 3
“Square” = 4
“Pentagon” = 5
is impossible with any of the Get number/integer/string.
Thank you for bringing this up. When I first started working on this feature I wanted to try to reuse as much as possible. The editor that comes up when you edit the list for the Value List is pretty close to what we needed, so I looked there. However, as you pointed out, David has added some additional parsing functions when you edit the list so that it knows how to handle things specifically for the Value List editor. Obviously, these parsing functions are not necessarily needed for the Presets dialog in the contextual component… and I think that’s where some of the frustration is occurring. However, that isn’t to say some parsing isn’t necessary. You see the presets that are defined in the contextual components show up as command options in the command line, and there are some constraints as to what are valid option values. Below are some of the constraints.
Command option names can not contain any whitespace (spaces)
Command option names can have numbers, they just can’t begin with a number
Command option names can not contain any special characters
So, you see there are some rules that have to be followed. I think the best solution is to rework the Presets dialog box to create a completely new editor that implements our own constraint logic specific to command options. However, I’m not 100% sure if this will be available for Rhino 7. Most of our efforts are now focused on Rhino 8 and new features typically target that release. I will discuss this internally and create a YT item for this issue.
Lastly, you mentioned that there’s still a bug with the auto-saving being triggered when modifying parameter values. This has been fixed and will be available in the Rhino 7.29 release.
Thank you for the prompt assistance.
I’m ok with some “grammar rules” needed for the command option names.
But my point was that command options names simply do not work. At all.
Anything past the “=” character is completely ignored, not used.
Get Integer and Get Number will show all your presets values with a “a=”, “b=”, “c=” etc… you have no control over that.
… if I really wanted that, I would wrote:
10 = “a”
20 = “b”
etc…
The only way to have it sort of working is to use Get String (which still ignore anything past “=”) but at least give a clean Command option, and then I can later parse that text inside the definition and “translate” it to my wanted value.
:\
I’m doing GH courses here and then and grasshopper player is one of the most exiting feature from the students eye. You can build rhino commands/functions without programming knowledge!
Just finished a course a couple of weeks ago, and my students re-reported this bug to me…
Yes, I’m aware that the current preset editor isn’t ideal and doesn’t really work the way you want it to. Again, the reason I made it say “a=”, “b=”, “c=” was because I didn’t want people to have to deal with learning the command line constraints so I “auto-assigned” option names for them… Perhaps this was incorrect As I said, I’m aware of the current limitations and this will probably need some time to re-work. But thank you for bringing this to our attention.
As I said, I’m aware of the current limitations and this will probably need some time to re-work. But thank you for bringing this to our attention.