i'm pretty sure the only major changes to input groups were that the variable associated with the group in the custom block now reports a list of lists instead of a 1d list. but i do not know if the ([slots V] of block (()@addInput) was changed from 1d to 2d lists (it now reports a 2d list but it may have done that from the beginning).
Alright, I took a look, and you're right, it was changed, and the input groups weren't working.
I've just now updated the block to now work with input groups.
please add snap blocks to snap converter
What do you mean by that?
so you can drag the picture of the blocks made by snapblocks and drag them into snap
So snapblocks to snap.
I do want to create something like that, but I've been putting it off because I'm not sure how to detect variadic inputs vs regular inputs. Plus, the new input groups would also be pretty hard to detect, unless I have some special syntax for grouping inputs together, but who knows how many people are actually going to use that?
I want to do it, and many blocks can be translated easily, unfortunately variadic inputs are really the culprit for my procrastination.
well, custom blocks wouldnt work at all unless you have a definition for them written, so maybe the extra syntax is in the definition block?
Custom blocks are easy, since I can literally just give them an empty definition, unless you define the block in the same snapblocks script (which snapblocks already detects), so that's not an issue. The only issue is detecting which inputs are in variadic inputs, and it's just gotten harder with separators, expand text, collapse text, and input groups.
but i mean for the script where you put the definition of the custom block, there could be syntax in the hat block
Yes, I could use that, however that's not a solution to blocks without a definition hat, and I don't want you to have to include a custom block definition in order to convert to snapblocks.
oh.
1: 10.2.1 was released, can we have the blocks
2: the rest of this post
welp, i forgot about it for a while but just remembered and did it in five minutes, but in a different way:
you can 
, or like this:
but you would probably want this, which is what snapblocks uses:
→lol::rgb(199,255,207) → lol :: rgb(199,255,207)
O just took a look at this, and I didn't think about getting the xml of the block, then parsing the xml to get the color. That's actually a pretty cool thing.
I'm going to use this idea, but taking a look at your code and @tethrarxitet's code, I'm probably going to create my own, seeing as how both don't take into account primitive categories, and @tethrarxitet's assumes that the 8th quote is always the category color you want, which is probably not always the case.
I have an idea for a better script, one that instead grabs all the custom category colors, as well as trying to get the categories of the blocks in the xml, that way it can work for any snap xml, not just 1 block xml that is a custom category. This may seem more complicated and unnecessary, however I'd rather have redundancy that will guarantee that there are no errors, and work for any block.
I believe that it is always the case for custom categories, but I created my block specifically so that normal blocks return an empty string (but maybe mine doesnt work correctly, i forgot to test it).
what do you mean by
Well, what would happen if you put in multiple blocks? If the first one isn't a custom category, but the second is, the block will report the wrong category color (though that can be fixed by just only taking the first block instead).
but doesnt your snapblocks converter go through one block at a time?
Yeah
so wouldnt this block be added when deciding the ending of the snapblocks block after ::? if not, how were you planning to add category colors?
I'm going to add a similar block, just parsed the way I prefer.