So I thought that the cases block looked a bit weird with boolean inputs so I tried editing it making look like reporter inputs using a read only number input block and then I noticed 2 things.
So I want both of these missing features to be added.
Hi, welcome to the forum!
I can't really see a use case for variadic read-only dropdown input slots. Writeable ones, maybe, but if you can only make a limited number of choices, what's the point of making a lot of them?
Unevaluated-ness could apply to any input type, yes. We might get around to that eventually, but since you can put any type expression into an Any slot, it's just a cosmetic issue, rather than a real limitation. (But I want that too, for the Streams library! I want a version of IN FRONT OF whose second input slot looks like a list but is unevaluated.)
But for the specific situation you started with, we have a better solution in mind. I'm not promising we'll do it soon, but the idea is to be able to group a bunch of consecutive input slots and/or title texts and make the entire group variadic. So you could have an input group
else if (Boolean) then (script)
and make that variadic. The effect inside the procedure is that the two sub-inputs would generate same-length lists of inputs when called. Designing a good visual representation for that will probably be harder than actually implementing it; anyway, that's where it's stuck right now.
A use for read only in multiple inputs is in a block like this:
[scratchblocks] (+ go + through + path + ((points...)::motion) + in + ((secs # = 10)::motion) + secs::stack motion)::hat control//Glide to is a custom block I once made. for each ((object)::list)in(points){ gilde((secs)/([length v]of(points)::list))secs to(object)::motion}::list loop [/scratchblocks]
I don't understand; which input is read-only? I guess you must mean POINTS, but it's not a pulldown menu.
This is what the block should look like:
[scratchblocks] go through path[ v]@delInput@addInput in (10) secs::motion [/scratchblocks]
Points is the read only input.Interesting .... so what would the dropdown menu offer?
I'd have thought a block like this to move thru a set of points would want the input to be a variable and not fixed?
It would offer the objects.
I think I've got you ...this request is to avoid having to drop another reporter into each slot?
Ok… I didnʼt think of that. It will still be nice for this suggestion to be added though.
I see, the use case is that you want to control the order in which sprites are visited. But you can do it this way only for a fixed number of sprites. (Even though the variadic input will give you however many slots you want, when you program a call to your block, you have to choose which sprites you want explicitly.) I'd be more inclined to write the block so that it takes a list of sprites as input, then you can build the list programmatically.
So do you want 2 separate blocks?
[scratchblocks] go through path ⌸ in(10)secs::motion [/scratchblocks]
and[scratchblocks] (list of objects[ v]@delInput@addInput::list) [/scratchblocks]
Red halo over the arrows; "input list"
This feature allows it to happen both ways
Yeah, okay, now I understand what it is you want.
No promises, but eventually we'll do an overhaul of input types...
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.