The Insanity God

That's certainly interesting... when debugging from the IDE it adds the folder it compiled into as an extra place to load mods from, perhaps this somehow affects the load order when it's not decided by dependencies.

To my understanding the Lang system is just a last entry wins system, meaning what matters is the load order.

Wait the modmaker puts stuff in game domain folder? I'm surprised I haven't seen this one before then.

For as far as I can see your alloy recipe works just fine even with that other mod (though you are lacking a language string for material-ancientgold) Your real problem lies elsewhere, namely in the combustibleProps that are required to exist and have a melting point that is reachable with existing fuel sources for it to show up as moldable, which disappears once you add "spearexpantion". The reason why this happens is because both your mod and "spearexpantion" put patches inside the game domain folder with the same name (meaning the files themselves end up overriding each other). This is why you never put anything inside the game domain folder unless absolutely necessary. Simply move the patch files from "assets/game/patches" into "assets/heavyforlonarmor/patches" and prefix the target file with "game:" (some already have this) and problem is solved.

And so should drinking I'd say... but here we are

I think that was just meant as a short form for "Game Mechanic Information" not an actual domain The issue is actually precisely that the domain was not specified... those language strings defined in the handbook config don't automatically get the domain added (they aren't even considered AssetLocations but just plain strings) so when it ends up looking for the code it actually ends up looking for "game:gamemechanicinfo-mushroomgrowing" On the other hand... the language file does automatically add the domain so it ends up searching in the wrong domain, simply prefixing this stuff with "craftsmanship:" should do the trick.

The base game "warmth" is purely about keeping yourself warm, there is no benefit to cooling as there are only penalties for being too cold and not for being too warm. Are you thinking of HiedrateOrDiedrate's cooling attribute, or some other mod by chance? This is how it is for all clothing but you could just change your `creativeinventory` into a `CreativeInventoryStacks` and set the attribute manually: "CreativeInventoryStacks": [ { "Tabs": [ "general", "items", "clothing" ], "Stacks": [ { "Code": "craftsmanship:blouse-{category}-{upperbody}-{color}", "Type": "Item", "Attributes": { "condition": 1 } } ] } ],

It's because of the attributes yes, the game automatically generally adds your domain as a default when loading an `AssetLocation` field... problem being that the attributes are not loaded as `AssetLocation` but as a `JsonObject` and then later read by other code which often does not do this, like in this case. You should be able to fix the error by prepending `craftsmanship:` to your `initialCode` and `resultCode`. (I don't have your `dough` itemtype so I can't test that)

Traders are entities and what you see in the creative inventory are not entities, you need to create your own `creature` item/variant (the vintage story equivalent of a spawn egg), see `survival\itemtypes\creature.json`

Actually should probably make this public or add a public add method. That way support can also be added the other way around (as in the other mod could register a method of their own to your mod if present)

This depends on how you do it, as long as you make sure to only access the code from the other mod when it is actually present then it will work just fine. Keep in mind however that this doesn't always behave as you might expect when looking at the uncompiled code, variables for instance are always declared at the start of the method when compiled, so doing this would fail if the mod is not present: public void DoStuff(ICoreAPI api) { if(api.ModLoader.IsModEnabled("ModB")) { var modBModSystem = api.ModLoader.GetModSystem<ModBModSystem>(); modBModSystem.PerformAction(); } } But if you extracted the content of the `if` statement to a new method then it would work. In your scenario you would probably want to make create a collection of delegates and only register the method for each different mod if they are present, which would look roughly like this: //Returns wether the provider is able to provide water and how much water was provided public delegate bool WaterProviderDelegate(ICoreAPI api, BlockPos pos, Block block, BlockEntity blockEntity, int requestedAmount, out int waterRetrieved); public class SprinklerModSystem : ModSystem { internal static readonly HashSet<WaterProviderDelegate> WaterProviders = []; public override void Start(ICoreAPI api) { if (api.ModLoader.IsModEnabled("hydrateordiedrate")) { WaterProviders.Add(WaterProvider_HoD); } } private static bool WaterProvider_HoD(ICoreAPI api, BlockPos pos, Block block, BlockEntity blockEntity, int requestedAmount, out int waterRetrieved) { waterRetrieved = 0; if (blockEntity is BlockEntityPipe) { if (FluidSearch.TryFindWellSpring(api.World, pos, out var foundWellSpring, maxVisited: 4096)) { int delta = foundWellSpring.TryChangeVolume(-requestedAmount); waterRetrieved = -delta; } return true; } return false; } public override void Dispose() { base.Dispose(); WaterProviders.Clear(); } } public class BlockEntitySprinkler : BlockEntity { public int WaterCapacity { get; protected set; } = 1000; public int CurrentWaterAmount { get; set; } = 0; public override void ToTreeAttributes(ITreeAttribute tree) { base.ToTreeAttributes(tree); tree.SetInt("currentWaterAmount", CurrentWaterAmount); } public override void FromTreeAttributes(ITreeAttribute tree, IWorldAccessor worldAccessForResolve) { base.FromTreeAttributes(tree, worldAccessForResolve); CurrentWaterAmount = tree.GetInt("currentWaterAmount", 0); } public override void Initialize(ICoreAPI api) { base.Initialize(api); if (api.Side != EnumAppSide.Server) return; RegisterGameTickListener(OnServerTick, 1000); } private void OnServerTick(float timePassedInMs) { CollectWaterFromProviders(); //Actually do something with the water } public void CollectWaterFromProviders() { if (SprinklerModSystem.WaterProviders.Count == 0) return; int remainingCapicity = WaterCapacity - CurrentWaterAmount; if (remainingCapicity <= 0) return; var downPos = Pos.DownCopy(); var block = Api.World.BlockAccessor.GetBlock(downPos); var blockEntity = Api.World.BlockAccessor.GetBlockEntity(downPos); foreach (var provider in SprinklerModSystem.WaterProviders) { if (provider(Api, downPos, block, blockEntity, remainingCapicity, out int waterCollected)) { CurrentWaterAmount += waterCollected; break; } } } }

They are not identical, the code is different. The code of the crashing version has a `-` in it, which is a big no no as it this symbol is used to separate variants. This means that whenever the game attempts to do any kind of logic for looking up variants it will think that your base code is "cabinet" (because it discards everything after the first variant separator) which generally results in it being unable to find the block or item. The method that is crashing does exactly that: `CodeWithVariant` attempts to take your code and replace the "side" variant with the value "east" (if present) but in the process it removes the `-1` and thus becomes unable to find it.

@Mrflaxe `BlockEntityChisel` is indeed the class you want but it's in `VSSurvivalMod.dll` not `VintageStoryLib.dll`.

As @Diff said, it's not an actual field but just a getter/setter method hence you cannot accept it using `___fieldname` as this is only a thing for fields. You'd have to either accept `___typeAttributes` and interface with it manually or use reflection: var pregnancyDays = Traverse.Create(__instance).Property<float>("PregnancyDays").Value; (I assume the utility method mentioned is referring to the `Traverse` class)

@joe saw They actually aren't hard coded, you can define them in the Block Attributes to override the default.

@AmethystZhou I haven't used it myself before so I don't have much in depth knowledge but it uses Dana's AttributeRenderingLibrary so would recommend reading their wiki and maybe looking into other mods using it. wiki: https://github.com/Craluminum-Mods/AttributeRenderingLibrary/wiki/Attributes-(ItemShapeTexturesFromAttributes)#name

@Micah Holmes Well the fence classes are designed to select the variant that would connect the correct sides (I assume this is what you mean with rotation) and you just removed that altogether so makes sense that rotation doesn't work anymore... This is only relevant for stuff with the "BlockGenericTypedContainer" class (or a class inheriting it). Other blocks would generally use "HorizontalOrientable" (or "OmniRotatable") behavior but this won't work very well for fences as it has more then just rotations (it has different variants for connecting multiple sides after all)

You just changed your block class to ' BlockFenceStackAware' which requires a different kind of setup, like a "wall" texture and "-top" shapes. See `Vintagestory\assets\survival\blocktypes\stone\drystonefence-free.json` for example.

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" } ]