The Insanity God

Hmm how interesting, it seems that when you have a comment in an array it actually is read as an item in the array (of ValueType "comment") and because the game is manually grabbing each entry and trying to parse it to a GridRecipe, it ends up failing and crashes. As someone who likes to put down comments this is good to know.

You sure? I comment out stuff in my files (including recipes) all the time during development and I never noticed any issue with that. Was under the impression that comments are ignored by Newtonsoft.JSON (the library responsible for parsing JSON)

There is no such thing as "game:pressedmash-cranberry-dry", should be "game:pressedmash-cranberry". The Dry/Wet is decided by the presence of a "juiceableLitresLeft" attribute on the ItemStack. I'm not sure if inverted attribute requirements on recipes is a thing with pure JSON though (as in have it only allow items that don't have that attribute).

Hmm your packaged zip works just fine for me, I tested on windows 10 with 1.21.6 and 1.21.5 (just to make sure) without any other mods. So unless you are running some other mod with a conflict while testing then I honestly don't know what's causing this. This specific error message should only appear when it's trying to create a pit kiln

It's because the "drops" you defined are invalid "type" should be "block" not "blockfence" (type is purely to distinguish between "block" and "item") hence it's crashing, but you can just remove this entirely as BlockFence already has custom logic for dropping the correct variant and in doing so completely ignores the drops defined in the JSON file.

It's crashing because you have a "-" in the "code" field, this symbol is used as a separator for the variants defined in the variant group. In the case of BlockFence it has logic for always dropping the free (no snow cover) and ew (orientation) variant, this however is crashing because it's thinking that your base code is "lattice" and not "lattice-fence". (this custom dropping logic also means that the "drops" defined in the JSON are ignored btw) You also have an unrelated issue in your variant groups: You are adding [ "oak" ] and also everything in "game:block/wood" which already contains oak, meaning it will attempt to create the oak variant twice. (This is not fatal but will give an ugly error log)

It actually does work (I tested it) but you can't place it by aiming at the stick pile because the hitbox is not a full block, you'd have to aim at a wall above it. Once you change the hitbox to end up as a full block you can place it just fine normally: [ { "op": "add", "path": "/class", "value": "ItemFirewood", //Only firewood is valid for charcoal pit (hard coded requirement) "file": "game:itemtypes/resource/stick.json", "side": "Server" }, { "op": "addmerge", //Has to be addmerge to prevent deleting other attributes "path": "/attributes", "value": { "firepitConstructable": true }, "file": "game:itemtypes/resource/stick.json", "side": "Server" }, { "op": "addmerge", "path": "/behaviors/0/properties", // need to select the first behavior through "/0" "value": { "stackingCapacity": 32, "bulkTransferQuantity": 8, "burnHoursPerItem": 0.1, //Change hitbox and scale so it ends up as a full block allowing you to place stuff by aiming at it rather then a wall above / next to it. "collisionBox": { "x1": 0, "y1": 0, "z1": 0, "x2": 1, "y2": 0.25, "z2": 1 }, "cbScaleYByLayer": 0.125, "upSolid": true // this is required to make it so you can put a firepit ontop of it and stack it more then 1 high }, "file": "game:itemtypes/resource/stick.json", "side": "Server" } ]

The efficiency is used to calculate the conversion to charcoal yes, idk if it's a 1 to 1 ratio though. (note: GetFireWoodQuantity collects the efficiency of the actual item, in this case sticks) NatFloat is a vintage story data type for generating random numbers https://wiki.vintagestory.at/Modding:NatFloat

You have this invisible face because by default the game will try to cull any faces that are not visible (because they are touching a neighboring block) and your model does not cover the faces. You'd want to change the sideopaue and probably also sidesolid in the blocktype json file: "sidesolid": { "all": false }, "sideopaque": { "all": false }, As for not being able to place a block in the center position, well.. that makes sense as there already is a block there (your tent block that is). If using code you could probably use a BlockEntity or the Fluid Layer to somewhat make the space usable but it won't be easy.

The attribute patch should be "addmerge" to prevent deleting other attributes The behavior properties path is incorrect should have a number indicating which item in the behavior list to edit, so "/behaviors/0/properties" for the first behavior (the game is made in a 0 indexed language so we start at 0) The behavior properties should also change "upSolid" to true, because otherwise you cannot place a campfire on it (which is required for a charcoal pit) All in all this would be the minimum changes you'd need for it to work: [ { "op": "add", "path": "/class", "value": "ItemFirewood", //Only firewood is valid for charcoal pit (hard coded requirement) "file": "game:itemtypes/resource/stick.json", "side": "Server" }, { "op": "addmerge", //Has to be addmerge to prevent deleting other attributes "path": "/attributes", "value": { "firepitConstructable": true }, "file": "game:itemtypes/resource/stick.json", "side": "Server" }, { "op": "addmerge", "path": "/behaviors/0/properties", // need to select the first behavior through "/0" "value": { "stackingCapacity": 32, "bulkTransferQuantity": 8, "burnHoursPerItem": 0.1, "upSolid": true // this is required to make it so you can put a firepit ontop of it and stack it more then 1 high }, "file": "game:itemtypes/resource/stick.json", "side": "Server" } ] Though you will likely also want to change the stacking model and it's ratio's (default one will look weird) and possibly also change the "efficiency" attribute (NatFloat) to change the conversion ratio to charcoal.

Well I mean it's not really a limitation for code mods, but yeah still quite a lot of this stuff that needs to be refactored to be less hard coded.

No the shape is fine, from the looks of it `ItemShield` has a lot of logic for rendering shields through attributes. The "construction" variant group states are used in a hard coded ways so a lot of the logic in `ItemShield` is not working because your item does not have one of the expected [ "crude", "woodmetal", "woodmetalleather", "metal", "blackguard" ] states variantgroups: [ { code: "construction", states: [ "scutum" ] } ], Relevant code: https://github.com/anegostudios/vssurvivalmod/blob/84c80e85f36e31d3b6454021da0fbbba4cba71a3/Item/ItemShield.cs#L53

the command you are thinking of is ".tfedit" (used while holding the item to bring up an interface for live editing these position transforms)

I normally just check the actual game files, but in this case it's a bit hard because the thing you are trying to patch is a value that's patched in. The `%appdata%\Vintagestory\assets\survival\blocktypes\soil\soil.json` file already contains 1 behavior (index 0, because the language is 0 indexed) and then a patch later adds the unstable behavior so I would assume it's at least index 1.

I can't help but notice the following: Your patch is a text file and not a json file. It's also missing comma's in between the different patches. The index is wrong on some of them (soil would be index 1 I believe not 0), you'd also have to ensure it runs after the base game patch (not sure if that's even a thing for patches but you could try dependson in the patches) I'll be honest though... this kinda thing is a lot easier and less prone to break with game updates and other mods when done from code.

So remember how earlier I said "this is normally done either through a BlockEntity with custom logic for it or through variants" well the `GenericTypedContainer` would be one of the base game BlockEntities with rotation logic... meaning you now have 2 rotation systems trying to interfere with each other. I know the base game chest also has this but in their case it's to provide legacy support (you can only place down the `east` variant now and it fully uses the BlockEntity rotation) the reason why the textures don't work is because `GenericTypedContainer` is designed for creating variants through attributes instead of the standard variants system and to achieve this they altered the way textures are defined. { "code": "workbench", "class": "BlockGenericTypedContainer", "entityclass": "GenericTypedContainer", "behaviors": [ { "name": "Lockable" }, { "name": "Container" }, { "name": "BoatableGenericTypedContainer" } ], "creativeinventory": { "general": [ "workbench" ], "decorative": [ "workbench" ] }, "attributes": { "inventoryClassName": "chest", "defaultType": "normal-generic", "types": [ "normal-generic" ], "handbook": { "groupBy": [ "workbench" ] }, "rotatatableInterval": { "normal-generic": "22.5degnot45deg" }, "storageType": { "normal-generic": 189 }, "retrieveOnly": { "normal-generic": false }, "shape": { "normal-generic": "workbench" }, "typedOpenSound": { "normal-generic": "game:sounds/block/largechestopen" }, "typedCloseSound": { "normal-generic": "game:sounds/block/largechestclose" }, "variantByGroup": "side", "variantByGroupInventory": null }, "shapeInventory": { "base": "workbench", "rotateY": 270 }, //Texture identifiers are prefixed with the type "textures": { "normal-generic-top": { "base": "game:block/wood/workbench/top" }, "normal-generic-bottom": { "base": "game:block/wood/workbench/bottom" }, "normal-generic-fdoor": { "base": "game:block/wood/workbench/bottom" }, "normal-generic-back": { "base": "game:block/wood/workbench/back" }, "normal-generic-sideleft": { "base": "game:block/wood/workbench/left" }, "normal-generic-sideright": { "base": "game:block/wood/workbench/right" } }, "replaceable": 500, "resistance": 1.5, "lightAbsorption": 99, "sidesolid": { "all": false }, "sideopaque": { "all": false }, "heldTpIdleAnimation": "holdbothhandslarge", "heldRightReadyAnimation": "heldblockready", "heldTpUseAnimation": "twohandplaceblock", "tpHandTransform": { "translation": { "x": -1.23, "y": -0.91, "z": -0.8 }, "rotation": { "x": -2, "y": 25, "z": -78 }, "scale": 0.4 } }

You'd need code for this. but should be fairly straight forward as the game triggers an event whenever this happens. (from `ItemSlotCraftingOutput` class)

If you want it to be rotatable with a wrench then you need to add the "WrenchOrientable" behavior: { code: "workbench", behaviors: [ {name: "HorizontalOrientable"}, { name: "WrenchOrientable", properties: { basecode: "yourmoddomain:workbench" } } ], variantgroups: [ { code:"side", loadFromProperties: "game:abstract/horizontalorientation" } ], creativeinventory: { "general": ["workbench-north"], "decorative": ["workbench-north"] }, shapeByType: { "*-north": { base: "workbench", rotateY:0 }, "*-east": { base: "workbench", rotateY:270 }, "*-south": { base: "workbench", rotateY:180 }, "*-west": { base: "workbench", rotateY:90 } }, replaceable: 500, resistance: 1.5, lightAbsorption: 99, sidesolid: { all: false }, sideopaque: { all: false }, textures: { "top": { base: "game:block/wood/workbench/top" }, "bottom": { base: "game:block/wood/workbench/bottom" }, "fdoor": { base: "game:block/wood/workbench/bottom" }, "back": { base: "game:block/wood/workbench/back" }, "sideleft": { base: "game:block/wood/workbench/left" }, "sideright": { base: "game:block/wood/workbench/right" } }, heldTpIdleAnimation: "holdbothhandslarge", heldRightReadyAnimation: "heldblockready", heldTpUseAnimation: "twohandplaceblock", tpHandTransform: { translation: { x: -1.23, y: -0.91, z: -0.8 }, rotation: { x: -2, y: 25, z: -78 }, scale: 0.4 } } note: the content of "basecode" doesn't actually matter it just needs to be unique. (the game uses it as a key/identifier to group the blocks by)

Huh, maybe this kinda patch just somehow doesn't work when run client side and because you added the "side" line it now enforces the patch happen during client side logic (instead of happening earlier) it stopped working It's case insensitive, in the code It's actually capitalized so if it wasn't then lowercase would likely fail

The game uses `IntArrayAttribute` for this, would look like this: ITreeAttribute treeAttribute = new TreeAttribute(); int[] myIntArray = [1, 2, 3, 4]; treeAttribute["myIntArray"] = new IntArrayAttribute(myIntArray);

It's bleeding through the sides because you didn't define `sidesolid` and `sideopaque` and you can't rotate it because you didn't add any logic for rotation... this is normally done either through a BlockEntity with custom logic for it or through variants (the latter means it creates a separate block for each orientation) So you'd end up with something like this: { "code": "workbench", "class": "Block", "maxstacksize": 64, "variantgroups": [ { "code": "type", "states": [ "fired" ] }, //Add the extra orientations { "code": "side", "loadFromProperties": "game:abstract/horizontalorientation" } ], //Add behavior to handle logic for selecting the correct orientation to place "behaviors": [ { "name": "HorizontalOrientable" } ], "attributes": { "mapColorCode": "settlement" }, "shape": { "base": "workbench", //Set orientation on shape for each orientation variant "rotateYByType": { "*-north": 180, "*-east": 90, "*-south": 0, "*-west": 270 } }, //drawtype: "Cube", "blockmaterial": "Soil", "creativeinventory": { "general": [ "*-fired-north" ], "decorative": [ "*-fired-north" ] }, "replaceable": 700, "resistance": 3, "lightAbsorption": 99, // Must declare textures so they get added to the block texture atlas "textures": { "back": { "base": "game:block/wood/workbench/back" }, "sideleft": { "base": "game:block/wood/workbench/left" }, "sideright": { "base": "game:block/wood/workbench/right" }, "bottom": { "base": "game:block/wood/workbench/bottom" }, "top": { "base": "game:block/wood/workbench/top" }, "fdoor": { "base": "game:block/wood/workbench/bottom" } }, "drops": [ { "type": "block", "code": "workbench-fired-north", "quantity": { "avg": 0.85, "var": 0 } } ], "sounds": { "place": "game:block/dirt", "break": "game:block/dirt", "hit": "game:block/dirt" }, //These should be defined to prevent it from assuming the sides are solid and thereby not render the sides of blocks next to it. (aka the bleeding through) "sidesolid": { "all": false }, "sideopaque": { "all": false }, "fertility": 3, "heldTpIdleAnimation": "holdbothhandslarge", "heldRightReadyAnimation": "heldblockready", "heldTpUseAnimation": "twohandplaceblock", "tpHandTransform": { "translation": { "x": -1.23, "y": -0.91, "z": -0.8 }, "rotation": { "x": -2, "y": 25, "z": -78 }, "scale": 0.4 } }

Essentially the same way as you'd do in the ModInfo, though if the mod is already marked as client side then this will only enforce that the patch happens during the client side code and not during the server side code when possible. [ { "file": "game:blocktypes/stone/cobble/cobbleslab.json", "op": "replace", "path": "/textures", "value": { "horizontals": { "base": "block/stone/cobblestoneslab/{rock}" }, "up": { "base": "block/stone/cobblestoneslabtop/{rock}*" }, "down": { "base": "block/stone/cobblestone/{rock}*" } }, "side": "Client" } ]

The `Side` should be set to `Client` inside the modinfo.json (and possibly also in the patch itself) and well if the server is using fairplay guardian (mod for restricting client mods on a server) you might need to get it whitelisted

I think you might have understood, but I'm not entirely sure so I'll give my take anyway: The error is actually unrelated to the grid recipe it's crashing because of the combustible props: In the case of your "storagevessel-ashforest-raw" this will resolve into "storagevessel-ashforest-fired", but your file for fired vessels does not have a "ashforest" variant: As a result, when you open up the handbook page and it tries to display that it can smelt into "storagevessel-ashforest-fired" it crashes because it doesn't exist.

You might want to try Rubberbandaid (https://mods.vintagestory.at/show/mod/28325) and see if that helps. Vanilla has an issue where if too many player attributes are updated at the same time it can seems like you are lagging/glitching/rubberbanding but it's actually just due to some hard coded limit which when surpassed triggers a full resync of attributes including position. If you are using mods you can hit this limit especially easily as merely taking damage alone already gets you halfway to that hard coded limit.