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.