Brady_The

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

Probably your best bet to get attention on this matter would be to talk about it in the discord channel or by creating an issue. Especially the issues like the mentioned elk mistranslation seems to be serious enough to warrant escalating this. AI-supported translations are a problem. Your case is not the first one. All the elk related translations seem to have been "translated" by one guy. Another option would be to fix these things yourself. Everybody can partake in translating. It's a lot of work, but it doesn't have to be done all in one go. Focussing on the worst contenders could be the first move.

The easiest way would be to ask the mod author to add a config which allows you to enable or disable certain features. That could be a big ask, depending on the authors knowledge or interests. There's the chance that the mod already offers this option. However, that feature would most likely be mentioned on the mod page. The better way would be to create a server tweak mod, which specifically targets those blocks or items you don't want to be crafted. How you go about it, depends entirely on your goals. Do you want to disable the crafting? (Block/item still exists, could be acquired via creative mode/console commands) Do you want the block/item entirely gone? (No handbook entry, etc)

I am looking at the most current version of your mod that's available on the ModDB. I assume that you are touching at least partially the files with code, considering that your shape definitions differ from the usual way. Is it possible that something is manipulating textures in code as well? I assume that the texture definitions within the blocktypes have changed as well. Otherwise the overlays could potentially be messing with the in-game appearance. I only downloaded the assets you shared here and everything appears to look like it is supposed to look.

There's definitely expandedfoods, but this one is beast, changing a lot of things about cooking. You haven't mentioned pies, but this mod might interest you: https://mods.vintagestory.at/theartofpies There's also https://mods.vintagestory.at/sammiches.

Your logs don't show anything, mine do neither. Ingame everything looks like it should. It seems that the issue resolved itself. You could connect to the world in which the error appears and place down new slab, see if those are affected as well, but if these error blocks don't appear in any newly created worlds, it is pretty safe to assume that the issue are no longer.

If it happens in one world, but not in another one it could be indeed a caching or block registry issue. If that is the case, the issue is most likely restricted to this one (older?) test world. I would go ahead and compare the client-main and server-main logs for both of those worlds. They very likely contain a clue to the reason what the issue is. If you want you could also share your mod here. I could have a look and see if I encounter these problems too. Edit: Did you potentially do some work on the json files for these blocks after you placed some down? If you did, that might explain your issues, because placed blocks do not update automatically.

That's how you do it! I personally would go ahead and move all patches into the heavyforlonarmor domain. This happened once. It can happen again if somebody else is using ModMaker created patches to modify something you change too. All but the first three of your patches fit the ModMaker naming pattern. Edited https://wiki.vintagestory.at/Modding:JSON_Patching#File_Path_and_Name_Considerations to reflect current implementations.

If I remember correctly bowls and pots should be emptied when thrown into water.

Don't mind me, I am just an AI hallucinating things. The ModMaker doesn't do that, but it generates the same file names. So if people use the ModMaker and put patches into the game domain (because that's what you do if you refuse to go through the wiki tutorials to understand the finer details of modding VS) you'll get those results. Hm, I wonder if those domain issues are mentioned anywhere on the wiki. I might have to take a look.

I do believe that this is the build outline for the cementation furnace. You activate it by Shift + Right Click and deactivate it by Right Clicking the stone coffin.

Well, that solution was surprisingly (and might I add disappointingly) easy. This is btw an interesting side effect of the ModMaker. I can only assume that we will see more of this in the future.

I quite like the trim, but now that you mentioned and after another look, removing the canopy or replacing the dark with a lighter wood might already be enough of a change. As it currently stands the (porch) roof acts as a thick, dark border, minimising the size of the ground floor and making the whole issue worse by darkening the whole lower section.

I think the house looks pretty great. The first floor is a bit oppressive in size, overpowering the ground floor with its volume. Make the ground floor a bit taller and see how it changes the view.

Unfortunately you cannot at this time.

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.

Make sure that you are using the correct asset type and code, and that the asset is available.

What's most likely missing in your case is the correct command. "/giveitem" is for items. Blocks require the command "/giveblock". The next hurdle would be the correct asset code. The easiest way to obtain those would be via Creative Inventory. However, if you don't have any admin powers, the next best way would be to execute the command ".edi" in chat. This adds among other things, the page code of assets to their handbook pages. This gives you two information. Is it a block or an item. What is the asset code. With those you can now spawn the aged wooden bed (or any other asset). /giveblock bed-woodaged-head-north, followed by the quantity if you need more than one and the target, if you are not giving the bed to yourself. "/help" giveblock" in the ingame chat will help you with any optional parameters.

That looks correct. How did you ascertain that the drop is not working?

Drops are a bit different for entities. Those are handled on the server side. So you would have to address "/server/behaviors/9/dropsByType/*-normal/-" if, for example you would want to add drops to the normal drifter. Because you are patching a game file you don't need to add the game domain in front of asset codes.

You could do it in such a manner, however, it would have a huge downside. If you place the drifter file in "yourmod/assets/game/entities/lore" you would overwrite the Vanilla drifter. If the developers should ever decide to change the drifter, players using your mod would never experience those changes because the original file is overwritten. This could also cause problems with other mods modifying the drifter file. You want to patch the original file instead: https://wiki.vintagestory.at/index.php/Modding:JSON_Patching This way the original file is not replaced, but modified only in the areas you chose to address. You could utilise the ModMaker, which you can find in the installation directory, to create patches for you based on edited Vanilla files.

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

The scrambled eggs recipe works for me. Start a completely mod-free test world, switch to creative and test again. "/giveblock firepit-cold" lets you skip the firepit building part. If it works there, you have conformation that a non-cooking mod is apparently messing with cooking.

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.