@TimeBender25 It's actually specifically moving the wildcard "*" entry in the array, not the entire array as "path/to/array/*" implies. The reason for moving the "*" entry to a temp path is because of the "*"'s value taking precedence as the first valid match for anything. If you just append "*-obsidian" to a list, which adds it after the "*" value, the "*" will be the first valid entry the game sees and it'll ignore the "*-obsidian". So a makeshift "insert" operation that respects variable length arrays (since we don't know if the index of "*" will always match the vanilla index when other mods may modify the same array) is to simply move it out of the way, append what we want to insert before it, and then move it back to the end so "*" acts as the final fallback value as intended.

For example, with just appending, we end up with an array like ["*-flint", "*-copper", "*", "*-obsidian"], which gives "*" precedence over "*-obsidian", so the value of "*-obsidian" is never used. With moving and appending, we get ["*-flint", "*-copper", *-obsidian", "*"] which is what we want for wildcard matching to work properly. The JSON patching page on the wiki has a section explaining move operations with this use case as an example, and probably explains it better than I have.

Also I used the official VS Model Creator for the models, but they're really just modified vanilla models because I didn't want to stray too far from the vanilla style when making variants of existing items. I just swapped some textures and added/changed the blades/tool heads. If you wanted to do something similar, you might be better off using the VS addon for Blockbench or for Blender. Working with rotated cubes to make the serrated blades was kind of a pain due to the weird separation VSMC makes between object position and object origin when dealing with rotations and translations. That could just be a "me" problem though since this was also my first time using VSMC for anything significant. I'm far more familiar with Blender, but I was just too lazy to try finding the Blender addon for VS that I've heard about in the past.

If you're wondering why the textures are both defined in the model files and by "texturesByType" patches, it's because the VSMC doesn't put namespaces in paths, and putting the models into "obsidiancraft/shapes/whatever" implies the "obsidiancraft:" namespace when the texture paths should be in the "game:" namespace since they're all vanilla textures. So I had to use patching to fix it without having to manually add "game:" to each texture path in the model JSON file every time I re-exported them from VSMC.

I was peeking through the mod to try and understand Patching better, and I noticed you would move everyting in a path out to a temp path, add your own thing, then move everything back into the path. Rather than just appending your thing to that path in a single step. I was wondering why you did that, is there a reason for it? Is it required to make it work, is it just because it being at the Top is easier, or is ther some other reason I don't have reference for?

Also, how did you make the models? Is there a program for it, do you have to do it the hard way by making the JSON manually, or something in the middle?

@WolfWarrior

You're welcome! Also thank you for clarifying. I do understand why some people would prefer a more vanilla-like balance. I actually debated about it quite a bit during development because I like the idea of keeping my mods mostly balanced around their vanilla counterparts so they feel like improvements to the game rather than completely standalone features, but I've also never really like how vanilla obsidian is basically just flint but 10% better. I did briefly consider having a config option for switching between vanilla and realistic balancing, but I'm not sure how to even set up config options for a mod, and it seemed like a gross overcomplication of an otherwise simple mod. Especially for the initial release only being arrows, saws, and macuahuitl.

Good luck with your mod! Let me know if you need any more help with the patching system.

Chromarict

also I want to say that, I have no qualms with your balancing. it makes sense from a realism standpoint. I wanted to change the balance to be more game-like. so I have no suggestions I think your balance is valid and good for what you want to achieve.

you are so helpful!!!

thank you so much!

@WolfWarrior

Patching is actually pretty easy once you figure out the weird quirks with it. The worst part really is just figuring the correct path value to specify sometimes. I originally decided to implement these with patching because it felt like complete overkill to manually re-implement the entire game:blade class for a single weapon, as well as fully reimplementing the arrows and tools, when I could just add them via the variant system that's already available. Plus from a compatibility standpoint it works great, because it just works out of the box with mods like Toolsmith without a compatibility patch (although balance is a bit off due to how Toolsmith automatically calculates sharpness values).

You could always open up "patches/itemtypes/tool/spear.json" and "blade.json" to see how I implemented the patches, and just copy what I did to add obsidian variants for your flint variants and overwite the obsidian stats. For mod-specific compatibility patching, assuming your mod's modid is "vanillaarmory", you would put compatibility stuff for my mod into "assets/vanillaarmory/compatibility/obsidiancraft". You can put all the JSON patch entries into one file if you want, but for the sake of organization I prefer to have one patch file for each file I'm patching, matching the folder structure of what I'm patching so I can more easily find the original file if I need to reference it. So for example, I would make a "...../obsidiancraft/patches/itemtypes/tool/spear.json" file, and put all the spear patches in there. As long as you add "dependsOn": [ { "modid": "obsidiancraft" }] to each patch entry, they'll load after my mod to ensure they overwrite the values correctly.

Here's a quick example patch file to add the flint tepoztopilli as an allowed variant, set the textures to apply to the model for flint tepoztopilli, and change the damage on both obsidian and flint variants:

Hopefully that makes the patching system and my attempt at explaining it more clear. I had a lot of trouble figuring it out early on with just the wiki as a reference, but its a great tool once you finally get it. Once you get the basic framework written, it's as simple as a bunch of copying and pasting and changing the path and value entries. You'd also need to do recipes for the flint versions, but instead of using patching you could just copy "assets/obsidiancraft/recipes/grid/tools/spear.json" and "blade.json" to "assets/vanillaarmory/compatibility/obsidiancraft/recipes/" and swap the obsidian values to flint.

If you still would prefer not to go the patching route, I'm fine with you using the models as long as you mention somewhere that I made them. Also I'm not opposed to making balance changes directly in my mod if you have any suggestions. It's definitely hard trying to find a balance between making them realistically high damage and fragile, but still enjoyable to use for how rare they can be. I do think the durability might be a little too high, but I also don't want to make them too fragile because its not fun having weapons break in two hits like the vanilla scrap weapons.

Chromarict

i do want to change up the stats quite a bit (basically every stat) so it'll be easier for me to just use your models. especially since i suck at patching... but yeah I do need to write a compatibility patch to avoid duplicate items. and I'll have to figure out how to do that since I didn't realize you added the weapons via patch.

@WolfWarrior I'm open to the idea. Did you want to use JSON compatibility patching to modify my mod when its loaded alongside yours, or just use the models and completely reimplement the weapons yourself? Personally, I'd say patching is the better route since 90% of the work is already done, and it'll avoid the issue of duplicate weapons with different stats if both mods are installed. Internally, the item codes are game:spear-tepoztopilli-obsidian and game:blade-macuahuitl-obsidian, so you'd basically just need to make a JSON patch that adds *-flint versions to their respective allowedVariants fields and add all the flint-specific properties.

can I add your tepoztoplli and macuahuitl to my vanilla armory? I love these items and the models you made fit right in with the vanilla game. I just have some different ideas as to the balance and also want to add flint variations to expand stone age armories in an accessable way.

I think it is a good addition to all those who find obsidian for the first time and believe that it will be a special material as in Minecraft, finding obsidian in VS is usually disappointing, because it has no deferrence with any other stone ...

MACUAHUITL !!!!!!!!!!
tepoztopilli when ?

@SoggyGravel I think the current 90 durability is very low compared to copper scythes having 450. If you're cutting "optimally" in perfect 3x3 grass groupings it'll break in just 10 swings. A max of 90 dry grass for an entire obsidian scythe seems fragile enough to me when the vanilla obsidian knife gets a relatively huge 160 durability (for comparison, copper knives get 300).

That being said, I'm not opposed to making some balance changes, but I was trying to keep these roughly in line with the vanilla obsidian tools, which consistently have higher durability and strength than stone tools, without surpassing copper. I know that might not be realistic, but then that begs the question of whether I should just make my mod inconsistent with vanilla, or if I should patch the vanilla obsidian items as well to make them more consistent with how obsidian is expected to be strong but less durable.

i think a scythe should be very low durability. a scythe irl would be brittle 

@Mollycoddle Thanks for the suggestions for Toolsmith. I wasn't exactly sure how to balance a custom patch for it since I don't normally use it, and the defaults Toolsmith gave seemed decent enough for a stone tool. It does make sense to shorten the durability and boost the sharpness though, so I'll work on a patch for it. Also I was just thinking about adding a scythe while I was playing earlier, so I'm definitely adding that in the next update.

Love macuahuitls, one thing that should be adjusted in a patch for Toolsmith is that handles and such for obsidian tools often last a lot longer than the blades. The head durability should be a lot shorter while the sharpness is higher. It's only a quirk of culture and economics that had Europe and Middle East (mostly) abandon lithic technology, the Americas kept it going because it was just so economical. A skilled obsidian knapper in an urban setting with good logistics could make a lot of macuahuitl blades very very quickly, and they could be 'changed out' when broken very easily too, making them very good logistically for armies.

Another thing; could you add an obsidian scythe/sickle for cutting grass and so forth? Vintage Story actually really departs from reality when it comes to making scythes out of copper and bronze, because they are really shit for that! Even in Europe, the use of flint for scythes and threshing tools remained until well into the Middle Ages.

@LivCi I just tried it out and apparently it is full compatible with Toolsmith without need for patching. The obsidian saws have about a third of the sharpness and durability of copper saws (135 vs 375 max sharpness and 450 vs 1250 head durability). Crafting saws in-hand or the crafting grid with the new handles and bindings from Toolsmith also works perfectly as far as I can tell.

@QueerCoded Thanks for letting me know, I'll work on fixing that today. I completely forgot to test it in real multiplayer since I usually play singleplayer, and wrongly assumed it just worked since it worked with the internal server the game runs for singleplayer.

@LivCi I've never used Toolsmith, but based on my quick skim of the modpage I'm certain my mod will need a patch to use the fancier features in it. Since that mod adds new handles and grips and things, I'd need to patch in new recipes, tool variants, etc. That being said, you could probably still use this mod alongside it without conflict since it has its own recipes, unless Toolsmith completely changes the underlying game systems for how tools work. I'll test it out and let you know if there are any problems.

Cool items! However you've marked the mod as server side which means models are broken on client side for the sawblade and Macuahuitl when the mod is installed on a server

Is this mod compatible with Toolsmith?