copygirl

You should be able to use the same code class for a custom item without overriding the item, usually. You placed your .json file into assets/game/itemtypes/... - in the same spot as the Vanilla asset is in? Regarding your suggestion, I believe I heard from Tyron that you can use wildcards to get that behavior. So instead of requiring "tool-axe" for example you'd use "too*-axe".

Can't do much about the bad error message - still something that needs to be improved. Remove the .json files one-by-one to find which one is causing it and share that (as a Gist, for example) and we can have a look at what the cause might be. As you can imagine it's difficult to debug an issue without the .json that causes it.

I somewhat agree, but on the other hand, blanket-banning something that could possibly open an interesting and deep discussion would be unfortunate. Tyron said we could just file it under "let's wait and see". If gameplay suggestions become unmanagable on the tracker, we can always take it back.

Hey everyone! I've suggested to @Tyron the possibility of using a public GitHub repository to track bugs and feature requests. He was so nice to give me the opportunity to create one and I already submitted a couple of issues myself. The upside over the forums is that it feels a little more leight-weight and focused, and some people, especially modders, might already have a GitHub account. Issues can be closed and re-opened, categorized, assigned to developers and milestones, even referenced to in other GitHub repositories. [ GitHub: anegostudios / VintageStory-Issues ] You're welcome to post: Report bugs, glitches, crashes Report performance issues Suggest gameplay additions and changes Suggest creative & server admin tools Suggest modding API additions & improvements Request documentation addition & clarification Questions & discussions, preferably on the topic of modding EDIT: As of recently, the team has decided the issue tracker should only be used for bugs, crashes and the like, not suggestions. This is due to the large amount of issues that have built up over time, which are hard to keep track of. Please use the other options available for suggestions. The developers are still looking at and happy to hear all your input! Feel free to open or move your issues there if you want, but you can also continue using the forums, Discord, or whichever way you preferred to so far. I might go as far as to mirror issues from the forums and Discord to the public issue tracker to have a single place for all our tracking needs, but - one thing after another. If you have any questions, suggestions or concerns, please let me know and I'll try to get back to you, if someone else doesn't already in the meantime

And with Vintage Story 1.5.2 coming about, it's also time to release another version of CarryCapacity: 0.2.4. This little update also comes with the ability to place carried blocks back down on any side of a solid block - not just the top.

Fill The Gaps seems to break Vanilla wooden slab recipes somehow..?

Released 0.2.3, which fixes a bug (only present in multiplayer?) when a player doesn't have an entity associated with them. Thanks to @heptagonrus for (indirectly) reporting the bug to me!

While I personally share this vision myself, I don't think it's a good approach. I doubt a "single disclaimer" on the site would be legal OR fair. The very least is a clear "I give Anego Studios the rights to distribute, modify and sell any content submitted through this form" checkbox or something along those lines. The last thing we want is drama over the ownership of content in the game. In some way, we will have this whenever a official mod repository is implemented, I would think. At least regarding the distribution portion. To some degree the "mod developer took too long to update the mod" issue will go away once we have a stable API with few to no breaking changes. Not to mention that, if the game developer likes a certain design idea, or perhaps had plans to implement it themselves, anyway, they shouldn't have to shy away from implementing the idea or concept themselves without using the mod's resources or code. Especially for something simple as a water sac. But for something that someone spent months if not years creating a custom experience, say Azanor's Thaumcraft or TerraFirmaCraft itself, you should be able to own what you made and decide over its use. Lastly, I made my response thinking more about modder to modder relationships, building a healthy, friendly and productive modding community around this game, rather than how things should work between the game developers and modders. I think they'll approach us, either as individuals or the entire community, if requests or questions come up from their side.

Heck, it doesn't have to be 50%. It could be 80%. The idea is to make the player aware of the lack of integrity through gameplay, actually requiring them to repair it before it breaks and disappears completely and instantly. I'm not a fan of warnings such as "you are hungry", "your equipment is about to break", ... That's not very immersive to me. Even if it's done in a non-intrusive way - It's the easy way out. Communicating wear and durability through gameplay elements, graphics and sounds is something I'd be after, personally. And.. I will be a little controversion here. But what says "you need to repair this" better than an item falling out of your backpack? Assuming of course - and this is the difficult part - that the player is guaranteed to notice and realize why there's suddenly an item on the ground. I don't have a good answer to that at this time. Knowing that a majority of players likely would be against this design choice, I'm okay with this likely not ending up in the Vanilla game.

If a backpack has wear / durability, why only have one source of damage? Why can't they take damage from walking, from being full, from getting attacked? For the record when I think of backpacks in this way I don't think of how they're implemented currently, but rather in a way similar to Wearable Backpacks, where they're implemented as a wearable "armor" piece (replacing the chestplate slot) and block you can pick up and place. If they were implemented in TFC they'd probably take up the back slot, though. When this was brought up in Discord, I suggested the downside of wearable inventory to only come into affect after an extended time of wearing them without taking care of keeping it in good shape. So for example, after 4 hours of playing, you'd lose 1 slot, after 2 more, another one, then another one the next hour, then 30 minutes, 15 minutes, ... I'm imagining this with a single backpack wearable the player would have equipped with more slots instead of the current 4 backpacks one can have with 6 slots each. The process of wear could be shown on the inventory slots, so you'd have an easy and clearly communicated way to see this.

Adding to this list: UNLICENSE: Like CC0, shows intend that you want to release the work as public domain. It's shorter, however it's not as legally sound. That hasn't much to say, as we as modders would be unlikely sueing each other anyway. In fact, I believe MIT wasn't challenged in court yet either, so the same is true for it, and it's widely popular. So I would argue it's really about showing intention rather than being enforcable legally. No license: To work on and release a mod, you don't need to use an open source license, or any license at all. By default, even if you don't put a "Copyright © <name> <year>" notice anywhere, you retain all (copy)rights to your code and nobody is allowed to use it. It's still possible to release the source code to your mod as well, for people to learn and copy "insubstantial" portions of code. This is called "Visible Source" as opposed to "Open Source" by the way. Custom license: It's silly, but you can put together your own license text outlining what you want people to be able to do with your code and assets. Mixed: On the topic of the distinction between code and assets, you can release your code as open source but, for example, keep all rights to your textures. This can be noted in your license file before the actual license text. I personally use Unlicense and have used MIT in the past, and those are the ones I would recommend, myself. However, it would be important to note why it makes sense to use an open source license for your mod in the first case, and what it means. By licensing your mod under an open source license, other people are allowed to: Copy parts of your code for use in their own mods. Substantial portions of code require retaining the original license in some form, such as in a comment at the beginning of a code file, or as a text file in a folder. Public domain licenses don't require keeping the license. Redistribute the entirety of your code elsewhere, or create their own modified version of your mod (a "fork"), and release those those modified versions, as well. Through creating a fork, people can contribute changes they make back to your mod. Or, since the changes will most likely be under the same license, you could just use them the same way they can copy, modify and redistribute your mod. Technically, people can sell and profit from your mod unless you use a non-commercial type license, such as hosting it on a website with ads (9minecraft, anyone?). I wouldn't worry though, as I doubt anyone would willingly use these sites, with an official mod repository likely being supported at some point. Not all licenses are compatible. Especially if you decide to go with a same-attribution style license or your own. This is why I prefer the more simple licenses that don't have any "special" clauses and are easy to read and understand. When entering a name along with the copyright notice in your license, pseudonyms are fine to use, and recommended if you don't want to show your real name. There might be a slight upside with using your real name if you can use this modding project as part of a portfolio when you want to apply as a programmer, game designer / developer somewhere, or similar. Theoretically, unless the license somehow doesn't permit it (CC-BY-SA would do this), the Vintage Story team could take your mod and integrate it into the base game. I doubt they'd do this without approaching you, and they'd probably safe themselves of any potential legal trouble by requiring you to sign a little waiver that gives them the rights to use what you created, anyway. But I suppose it's still an important point to make. Don't worry too much about licenses right away if you can't decide. If you don't have a license, you can add it at any time. Once you've choosen a license, you can still at any time change the license if you'd like. Though in that case, do keep in mind that, technically, any version that still had the old license will stay under that license. This becomes a bit more difficult once multiple people work on a project, because then, everyone has a say in it as they own parts of it, so you all have to agree. This can be avoided having constributors sign a Contributor License Agreement (CLA). I think it's important to note that ideas are not copyright-able. Even if your mod is closed source, as long as someone does not steal any of your code or assets, and simply reimplement this idea or concept from scratch, they have the right to do so. You may claim the person "stealing" your idea is a meanybutt, but that's just, like, your opinion, man. Let's keep in mind that we're modding a game in our free time for our enjoyment, and we should be striving to collaborate and create something better than a single person or even a talented team of people can do. Let's allow each other to learn from, re-use and improve each others' creations without being too constricted by concepts of ownership in our virtual hobby. We're still in early stages of modding, so we don't have an official or unofficial mod repository yet and neither do modpacks exist. Heck, we don't even have any significant amount of mods that have been released yet, so requirements and recommendations will most likely change in the future. This thread hopefully will still be a good starting point regarding licenses for anyone joining our adventure of modding Vintage Story! ♥

Released 0.2.2, which now has an interaction delay circle wheel thingamabob as well as sounds when equipping and unequipping blocks.

I might consider it. Though an issue with a video is that it's likely resources will become outdated and text is easier to update. Preparing and re-recording a video multiple times until I'm happy takes considerably more effort, and I'm not entirely sure how valuable it'd be. Also considering I'd be doing this on Linux and don't have a Windows install around, I wouldn't be able to show some Windows-specific bits. Though, based on your feedback I added another section to the readme: General VS Code suggestions and Cheat Sheet

I updated the mod to version 0.2.0, making it a little bit more usable. Changes are: Added a delay to picking up and placing down blocks (can vary per block). You now need to hold right click for half a second to pick up a chest (0.2s for basket). Fixed rotation and rendering misbehaving. Block is placed upon death.

On one hand, the game is certainly polished enough to be "worth more" but I'm not sure there's ever a good middle. There's bad games that are more expensive, there's good games that are cheap. I would certainly pay more, but people who've not heard of the game could dismiss it because of it. Keeping the price low would lower the barrier of entry, would allow people to buy the game for friends easily to join in. Minecraft's likely benefited from its price early on, and only raised it after it reached a decent popularity. So I'm a little torn on this. A way to mediate one of the issues would be to offer a discounted price for buying the games multiple times for friends (and yourself). Then again I almost feel like by keeping the price low you might show more commitment to improving the game and attracting more players, rather than cashing out early. edit: With @Stroam chiming in as well I guess my vote will be for don't raise it, but obviously with a big "not yet". Thanks for laying out some of the data for Minecraft's rise to popularity and when the price was raised!

CarryCapacity is no longer being developed. Please use the lovely CarryOn instead, which is a continuation of this mod. CarryCapacity is a mod which allows picking up blocks and carrying them in your hands and on your back. This was made possible with the help of the awesome @Tyron providing some code samples with the official example mods. You can pick up chests, baskets, crates, barrels, planters, vessels and anvils by sneaking and holding right click with empty hands - that includes your offhand slot! This will prevent you from sprinting, and depending on what you're carrying, slow your walk speed down further. Placing them back down again is done by sneaking and holding right click on a block. Chests, baskets, barrels and vessels can also be worn on your back. To put what you're holding in your hands onto your back, sneak and hold right click in the air - without aiming at a block, otherwise you would just place it back down. Similarly, it can also be taken off again. Worn like this, baskets won't slow you down, but everything else will. [ VSModDB ] [ GitHub Releases ] Source code and more in-depth information is available on GitHub as well.

Speed limits for heavy armor might be viable if you have alternate methods of transportation, like horse-drawn carriage, trains, boats, ... where the lower walk or run speed doesn't matter. If the game eventually gets some Smart Moving like abilities - charge jumping, grabbing onto ledges, climbing, dangling from certain ceilings, crawling through 1 block large holes, ... - this could be another thing you could take away from players wearing heavy armor. The game could be full of decisions such as "do I want more protection, or stay agile?". Doing this would also mean that heavy armor can actually make you feel really powerful, because it can be balanced in such a way that most conventional attacks have little to no effect, and you wouldn't have to worry standing in the middle of a horde of drifters and take a bit of an ineffective beating, not worrying about trying to avoid attacks or anything.

Hello everyone! I'm a big fan of VS Code. I've used it to dabble into C# coding, doing web development, creating Minecraft mods, and now also creating mods for Vintage Story! I created this repository to walk people through how to set up a new project on their own and explains things on the way. It describes how to use .NET 5 / .NET Core to build mods in a cross-platform friendly way. GitHub: copygirl/howto-example-mod Any feedback is appreciated, especially if you're using VS Code or this setup in particular, but feel free to also talk or ask about VS Code in general.

I'm not entirely sure I understand the "head bobbing" part but I actually very much like stairs working the way the do right now - it feels much more like I'm actually walking up stairs instead of just magically "teleporting" up half a block the instant you hit the side of a block like in Minecraft. Do you wish for climbing stairs to be smoother visually with less camera jerking or also faster?

Also, if you happen to run in windowed mode, I've read that fullscreen runs a lot faster.