Brady_The

The old "allowed/skipVariants" format you are using only allows one {variable} per ingredient. The second in your recipe is effectively ignored.
Switching to the new format for Grid Recipe Crafting introduced in 1.21.0 should get rid of these errors.
{ "ingredientPattern": "F,L", "width": 1, "height": 2, "ingredients": { "F": { "type": "item", "code": "framesaw-*", "isTool": true, "toolDurabilityCost": 8 }, "L": { "type": "block", "code": "woodstain:staineddebarkedlog-{color}-{logtype}-ud" } }, "allowedVariants": { "color": [ "black", "blue", "brown", "gray", "green", "orange", "pink", "purple", "red", "white", "yellow" ], "logtype": [ "acacia", "aged", "baldcypress", "birch", "ebony", "kapok", "larch", "maple", "oak", "pine", "purpleheart", "redwood", "veryaged", "walnut" ] }, "output": { "type": "block", "code": "woodstained-{color}-{logtype}-stain", "quantity": 16 } }

Somebody prepared a template for this case: https://mods.vintagestory.at/templateformusicadditions
Starting with this will make it a bit easier. Download and unzip the file. Follow the instructions till "Navigate to ...".
Now you write "replace some files". If you really just want to replace a couple of files, it'll be much easier to not use the subfolder as done in the template, but to overwrite the default Vanilla music files. This is rather crude, but is much easier than writing a patch that surgical removes some music tracks from the musicconfig.json file (which essentially contains the playlist).
In this case navigate to the installation folder of Vintage Story -> assets -> survival -> music, write down the names of the music files you want to replace, add your music files straight into the music folder of the Music Pack Template (not the subfolder) and name them accordingly. In the example below I would replace the original daylight.ogg file with my own custom one.
After you have done this with all the tracks you want to replace, skip to the last step of the template guide and follow it. Unless you are not interested in sharing the mod - zipping the files just makes the sharing easier. The game doesn't require zip files to recognise mods.
If you want to replace all music files, you can essentially follow the template guide, with the small addition of changing a little detail in your "musicconfig.json". Replace the word addmerge with replace. This will overwrite the original musicconfig (or playlist), instead of just adding to the end of it.
If you do not want to replace any music, but rather just add to the Vanilla playlist you can follow the whole template guide step by step.
If you have any questions, feel free to ask them either here or in the mod page - the latter would help the author to improve the template, but either is fine to me.
In case you are asking yourself, why the Vanilla music is contained in a "survival" folder but your music files are in a "game" folder - good question and eyes. That's because "game" on the mod side acts like an all-encompassing stand-in for all folders in the Vintage Story directory.

If you are playing 1.22 you most likely ate a mushroom with psychedelic properties.

3332_yQ4dxcBCkXR54rLUd2m2.mp4

/entity remove e[type=trader*, range=x]
in which x is the range measured in blocks with the player as the centre.
"range" should be optional but I prefer to keep it in to be a bit more precise in targeting.

I can't help you with Blender, but for VSMC I have this link to a 5-part-tutorial by ThenthArchitect:
There's also this VSMC Community Edition which comes with a lot of quality of life changes and additions: https://github.com/Pure-Winter-hue/vsmodelcreator/tree/pw-vsmc-hard-winter-edition

Whoops, I completely misunderstood your problem.
You seem to be right about your assumption regarding the planting being handled in ItemCattailRoot. https://github.com/anegostudios/vssurvivalmod/blob/2fdc2c37e5bbe1c92ce1314fe0b3e7c1576d42eb/Item/ItemCattailRoots.cs#L11
It should be fairly easy (well, at least I imagine it to be) to add your item via harmony patch, but for that you need at least some coding experience.

"isFood": true in the root of the recipe will prevent the conversion into a dirty pot.

You have to be a bit more specific. About what step(s) are you exactly talking about?
There's the option to add team members to a mod, including team members with edit rights, so you could release updates on the original page.
Alternatively there's also the option to transfer ownerships of a mod in its settings on the ModDB. That would give you full control over the mod page.
Of course that would have to be done by the original owner.

https://mods.vintagestory.at/pauseonstart might do what you want.

Technically there is "transitionableProps", but that's fairly limited in scope. In your specific case you would need code which would check if certain items are in the vicinity of the blocks you want to change.

That's a nice looking slab.
I am afraid that you are stuck in Vanilla, but QP's Chisel Tools comes with a hand wedge tools that does exactly what you are looking for. Depending on where you want to have your slab positioned you want to use the move mode afterwards.

If you used the texture reference "base" in your shape file instead of "copper" it'd work.
Solution: Replace
"textures": {"base": { "base": "game:block/metal/ingot/copper"}, } with
"textures": { "copper": { "base": "game:block/metal/ingot/copper" }, } Edit: KDLynch's "all" solution would work in this case too, because you are only referencing one texture in your shape.

The "fired" variantgroup requires to be called "materialtype".
https://github.com/anegostudios/vssurvivalmod/blob/84c80e85f36e31d3b6454021da0fbbba4cba71a3/BlockEntity/BEToolMold.cs#L37

Due to the way the large trough works, only one side of it does accept inputs via chutes. Check if you chose the correct one.

Replace textureByType with texturesByType. texture supports one texture, textures more. The game is trying to find "base" but only finds "string".

I am starting to understand. (Maybe.) (I am a bit slow...)
What I do not understand are the UV mappings in normal-copper.json. I assume you mapped the cubes according to the texture resolution? Or how did you work within the VSMC to get the correct view you presented?
Just one example. The element lid in the shape file you provided contains the following uv mapping for the cardinal directions. Those are for the default size of 16x16:
"north": { "texture": "#texture", "uv": [ 0.0, 0.0, 5.0, 1.0 ], "autoUv": false }, "east": { "texture": "#texture", "uv": [ 0.0, 0.0, 5.0, 1.0 ], "autoUv": false }, "south": { "texture": "#texture", "uv": [ 0.0, 0.0, 5.0, 1.0 ], "autoUv": false }, "west": { "texture": "#texture", "uv": [ 0.0, 0.0, 5.0, 1.0 ], "autoUv": false }, Now, if you want to to use a texture with the resolution of 32x32 (double the size) those mappings double too:
"north": { "texture": "#texture", "uv": [ 0.0, 0.0, 10.0, 2.0 ], "autoUv": false }, "east": { "texture": "#texture", "uv": [ 0.0, 0.0, 10.0, 2.0 ], "autoUv": false }, "south": { "texture": "#texture", "uv": [ 0.0, 0.0, 10.0, 2.0 ], "autoUv": false }, "west": { "texture": "#texture", "uv": [ 0.0, 0.0, 10.0, 2.0 ], "autoUv": false }, The same would apply for 64x64 textures:
"north": { "texture": "#texture", "uv": [ 0.0, 0.0, 20.0, 4.0 ], "autoUv": false }, "east": { "texture": "#texture", "uv": [ 0.0, 0.0, 20.0, 4.0 ], "autoUv": false }, "south": { "texture": "#texture", "uv": [ 0.0, 0.0, 20.0, 4.0 ], "autoUv": false }, "west": { "texture": "#texture", "uv": [ 0.0, 0.0, 20.0, 4.0 ], "autoUv": false }, I am not much of a theoretician. I prefer a more hands-on approach, so I'll attach the files I had a go with. These files still probably need some cleaning.
As you can see in the hotbar there are some texture issues, which could be related to the texture resolution.
I hope I am not completely on the wrong path here. I am not a huge VSMC expert. Nor am I apparently able to understand your problem correctly. 😆
normal-copper_32.json normal-copper_64.json

Game translation: https://crowdin.com/project/vintage-story-game - you just need an account
Wiki translation: https://discord.com/channels/302152934249070593/420476226420080670 - create account and ask Aki for edit permissions

Alright, now we are getting somewhere. Where is the patch file located? It should be in "craftsmanship\assets\craftsmanship\patches". Sub-folders in the patches folder are okay.
Also, test it without any extra mods to make sure that it is not some other mod messing with the drifter file.

According to the comments this mod doesn't work any more.
I wouldn't count on an update any time soon: https://mods.vintagestory.at/reignited#cmt-22612

That's Compatibility Lib's moment to shine.
I am currently rewriting the article, because it is a bit archaic. Here's a sneak preview: https://wiki.vintagestory.at/BradyThe/Sandbox (It's still a work in progress, but hopefully explains the inner workings of the Comp Lib already a bit better.)
How I would go about it depends a bit on the structure of the other mod and your goals.
Remove recipes from the other mod: Easy. I would probably use Mod-dependent json-patches (JSON Patches in my rewrite) to disable them.
Combine/replace item: Easy - medium: There are one or two solutions to this.
Overwrite the 3rd-party item with the Comp Lib. Put all properties of both items (the 3rd-party and yours - combine) into this file. Disable your item via patch. Add recipes into the compatibility folder using the item code of the overwrite. Disable the 3rd-party item with a patch, add any properties of the 3rd-party item you want in yours (combine) to your item by patch. Example setup (I quickly frankensteined an existing test setup, pay no regard to any domain or other inconsistencies):
I hope all of this isn't too theoretical only making sense in my mind. If you have any questions, shoot them.

The VTML code could be counting towards the character limit per site.
I'd do some testing with and without the code and see if there's a difference. There most likely will be. Then I would report my findings on https://github.com/anegostudios/VintageStory-Issues/issues. The devs most likely didn't think that VTML would be that heavily used. That should be an easy enough fix on their end, though.

That depends what you mean with grouping. You can consolidate blocks/items in the ingredients section in the handbook.
"attributes": { "handbook": { "groupBy": ["seashell-{type}-*"] } } You cannot condense the handbook entries too many ways. You can filter out variants of assets, showing for example only north-orientated assets
"creativeinventory": { "general": [ "*-north" ] } Technically you can "excludeByType" assets, but that'll remove the handbook entries completely (which doesn't make them uncraftable btw).
"attributes": { "handbook": { "excludeByType": { "*-eidolon": true, "*-erel": true, "*-seamonster": true, "*-thunderlord": true } } } But that's about it.

Usually dependencies are listed in the mod description.
Admittedly it's bit hidden on the mod in question, but it's there.

Ah, now I understand your problem. It has been a while for me. Yep, you have to save the page first. That page will be in Draft mode, so people won't have access to it. You've got all the time in the world to fill out all the details.