Jump to content

Kulze

Vintarian
  • Posts

    9
  • Joined

  • Last visited

Everything posted by Kulze

  1. Yes, there is no need to expand the shelf-life further then it already is. I more meant a immersive integration. Hence keeping the long-lasting aspect existing, maybe increasing the absolute end-result a bit while reducing the result if not the whole range of steps is done. We already cure but salt is a mess to access currently which makes it very untenable to achieve, and salt is not a resource that's hard to acquire in reality if you know what to do. The major reason it was worth so much historically was majorly in africa since water access there is limited. In Europe salt access was initially water evaporization and later salt mines. Still valuable since labor intensive and otherwise only available in miniscule amounts but sufficing for personal usage at least. It also created the word 'salary' hence from the roman word 'salarium' where soldiers were paid in salt (or the value of salt in comparison, we don't know fully) for providing their service. The other parts though are missing, and salt alone doesn't provide such a massive boost to let food last longer. My recommendation hence is reducing the effect of salt substantially, creating a reliable production method through water evaporization (be it fireplace and pot or leaving it exposed in the sun to 'dry' bowls and get a very small amount this way) and adding a official method of smoking since we also now have the beehive kiln which provides a very similar mechanic as what could be used to build a smoking chamber. So my recommendation is having dry-curing from salt available with massive amounts of salt usage but no further process needed or being possible. A alternative option for dry curing with significantly less salt usage (rubbing rather then submerging) for a far less inferior preservation but allowing follow-up methods like dry-storage for mild dehydration which needs actively looking out to not forget it already. Then the smoking process which does need a distinct built setup and large investment in effort. Leading to the best preservation effect possible though. Also wet curing would be a possible solution then for shorter-term preservation which does provide a caloric boost though at the cost of having significantly reduced shelf-life and higher effort needed. Salt is underutilized in the game currently with only halite as a source, but then massive amounts, making it a 'either I have all or none' situation. I simply think that a more gradual system which enforces supply and demand necessities is a viable approach here, making halite a long-lasting source but with a limit and evaporation created miniscule amounts available as a early-game method. Immersion and variety without removing gameplay meaning.
  2. The mod 'Bricklayers' does include a top-tier system for more variety of pottery. I can heavily recommend it. It's good enough to make me wish it to be future vanilla content for most of it. High variety in decorative elements and high variety in needed materials which reduces abundance of some materials quite a lot.
  3. The issue with the primitive Survival mod is that for some eldritch reason I cannot follow it has... well.. eldritch content included in it. Didn't know we had that stuff in primitive times! A vanilla inclusion of meat preservation outside of salt would be highly enjoyed though, actually the 'proper preservation' methodology overall would be fantastic! Meaning a mixture of salt (extractable from the seawater and as a mineral optimally) together with sodium nitrate (curing salt) as well as smoking and drying. Medieval style original cured meats lasted several years after all, in comparison it's absolutely untenable to keep meat long-lasting in the game sadly, you're mandated to live off of husbandry rather then hunting. Actually it would provide a great option to make bush meat into a proper food source, allowing it to be treated and gaining caloric value for it, which would allow it to stay a viable long-term source without setting up husbandry, increasing the potential playstyles without removing the early-game struggles of feeding yourself. I imagine a well-designed immersive option for making long-lasting food is the following: - Curing meat in salt. - Storing it in a root-cellar/pantry to allow the curing process to take place instead of rot. - Followed by smoking it in a smoking chamber, using wood chips/sawdust which could be created as a side-effect of cutting planks with the saw. - Drying it while making sure it's not exposed to rain. Each step improving the lifespan of the meat a bit further. I could imagine the need for meat hooks where individual pieces have to be hanged onto, the process being a lengthy one (in-game day+) where the process is based on how long the smoldering wood is kept 'lit', hence providing smoke and with it the lignines inside the wood.
  4. Ah, that was a bit misunderstood then, but it's a great point to make! We gotta differ between 'mods' and between 'core integration' here. Obviously mods shouldn't be monetized, they're a community service, not a paid position after all. And it's been proven time and time again that free monetization leads to mass-flooding of low quality content. It's a whole different can of worms to open up to make something like this actually functional and reliable, it's obviously not worth it to even suggest as neither are the resources here nor would be the reward reliable for anyone involved. What I talked about was 'core integration'. A modder has the intellectual rights on their created content. Sure, it can only be used in combination with the base product, but the work itself is their intellectual property as it's adding on top of a existing product and hence separate. Hence should the modder allow to have it integrated in the base game on the premise of their code rather then Anego working on a similar design from scratch then the option to allow a 'reward' of some kind should be open. And given a creator has the right to set their own terms of what value their work has it should also be in the hands of the creator to set it accordingly. It's Anego's choice to take the offer or not simply. Example: - Creator makes a mod which provides a functional trading system outside of the auction house, a in-game one. It includes a lot of models, UIs, scripts. Tons of work. - Upon release to the community - a normal mod in the moddb - there's 2 hidden checkboxes and a textbox which only the creator and Anego are able to see. One is 'I'm allowing Anego to use this code for usage in their game and adjusting it freely' and the second is reliant on the first stating 'I'm offering the code free of charge and voiding my rights of intellectual property to Anego'. The free option. The textbox is only relevant when the second box isn't ticked and states 'This is my expected remuneration for providing this the rights to use this code' and allows to input what exactly they would want for it. They can state whatever... and Anego can choose to agree to whatever... or start extra efforts to message the mod creator through that system to make up a alternative deal. It's simply a extra option to allow usage of code without legal issues, because no matter which country if you set the conditions for usage and receive the according remuneration you've rescinded the rights to have any further say about what happens to it related to the game. That's what you get rewarded for after all. One further option is the classic 'open-source' integration model. Basically all that happens is that people have the ability to see the code and can make more in-depth changes to it while Anego still retains rights of intellectual property to it. Hence we got a official branch and changes to the game according to whatever any user wants, the peak culmination of a modding community. A great example on how it works is 'Cataclysm: Dark Days Ahead' actually. A core lead which retains ownership and decides on the direction and a community which can make merge requests to the core game. Mandated code structures to even pass a preemptive check for viability to reduce workload of the company and full choice for the company to use or not use said code going forward. The majority of merger requests commonly done in this case are bugfixes, optimizations and gradual miniscule improvements. And in the game example I made it led to that game being the biggest, most comprehensive and complex game of that type which has ever been seen, with a update speed of commonly 1 successful merger a day median, often more. Most people know the open-source style from Linux where the code foundation is freeware. In our case the code foundation isn't freeware though and hence any type of fork does still provide revenue back to the company or is simply included as a mod. Full development control stays with the company but since people want to have the best possible experience available it leads to a overall superior product over time... agreeing or not agreeing with the development direction. Exactly, modular setups are a necessity basically. Core gameplay can still be adjusted even from input of individuals... but risk is not present this way. And any large-scale not 100% tested aspect is a top-layer mod which can or cannot be integrated into core gradually, or be used as a simple 'extra' in the form of buildings blocks to create your own experience. The current mod setup we have is already supporting that greatly. Workload itself is also adaptable this way to not be overwhelming as it allows removing overhauled systems without major issues while also keeping the possibility for players to keep using the old style in many cases. A big win in terms of player agency. The risks are clear as well, choice paralysis and the necessity for a user-friendly way of adding/removing aspects through a simple but comprehensive way of setting up their game experience. It hence creates work on other areas which usually don't need any work. But the upsides are also quite clear as described above.
  5. Well, the whole system is not quite fleshed out, especially the temporal storms are... problematic. It's clear what's intended, and to a degree it does it actually well. As a beginner the portal storms are a panic moment... until you start to learn how to deal with them at which time they become a pure bother. The same can be said for the rift spawn, both in terms of spawn conditions and frequency. It's 'not quite there' yet, though what exactly it needs is also beyond me. It's design-wise one of the most problematic ones for sure, extremely hard to find the golden middle ground to achieve what is supposed to be achieved but not making it either mundane or simply tedious. As for the bowthorns ans shivers? They were the best additions to the game has had in terms of danger. Normal drifters can be entirely trivialized with a spear, the only danger being the thrown stones and narrow or non-flat areas. Inside of caves they do exactly what they're supposed to do, which is making your life hell and making spelunking extremely risky at the chance of providing serious rewards as translocators and ruins provide a hefty amount of power to the player. As for handling them, the stability mechanic is actually fairly fleshed out, the only things I would love to see is options to improve stability levels permanently as to not have situations where a started build is temporaly stable on one edge only to realize that you're actually at the edge of a temporal unstable surface area. The same with the underground as even significant terraforming which removes large amounts of material and hence causing the player to reach low z levels leads to some... wonky situations. Despite daylight enemies spawn in such deep holes, something which in my opinion shouldn't happen as you're providing direct surface access. But besides that the system is fairly well designed actually for a placeholder one which will likely need substantial changes as the content depth increases even further.
  6. Well, to be fair most of the issues can be circumvented with a opt-in option to allow devs to make use of the mod content to directly fold it into the game or adjust it according to needs, basically creating a form of a 'fork' of it. Simpy described you provide your mod in the mod database and when you do you not only get a baseline document to agree to ensuring the terms are clear but it would also allow to choose if it's free of charge - for those simply wanting to improve the game - or with a custom box to allow describing the expected return of whatever kind. It's then up to the devs to decide if they're willing to do it or not as any weird or outrageous ones can simply be ignored. I imagine the most common would be credits being given, and the baseline that the moment you allow it to be used you loose any form of rights related to returns outside of the initially stated one had you provided them.
  7. Well, that's the thing though... for copper, bismuth/tin bronze or iron it absolutely makes sense to think this way. But what about meteoric iron, black bronze or steel tools as example? Meteoric iron is a fairly limited material, black bronze as well and steel is a hefty time investment to make. Saving up on those is commonly worthwhile. So while niche it definitely has a place, and a very good one as well. You might throw away the materials available in abundance... but keep those and use the inventory space despite it not being 'efficient'. There definitely exists a way to handle that! I would say that 'reforging' can definitely be included in a proper gameplay loop there. Material after all doesn't shear off uniformerly. A hammer head might deform... the handle might break/wear down and even without keeping it completely realistic in terms of material loss (the gameplay loop is to be upheld after all) one thing immediately coming to mind is material purity here. This is a form of mechanic which is introduced in some games already, albeit often unintentionally as a simple 'improvement' mechanic. Metal gets more pure as it's reheated and reforged, removing leftover impurities. Also the grain structure becomes more uniform and hence strenghtened against abrasive treatment. One way to integrate it reasonably would be to reduce the starting durability of tools a bit but instead add the reforging option to not only repair tools but also by adding new material which has been sheared away and the re-heating causing it to become more durable for usage. Hence the favorite top end iron pickaxe used and having gone through several repairs would a bit more durable compared to a 'freshly forged' pickaxe as example. This could improve gameplay loop in several ways actually. For one it allows individual players which struggle with early resource acquisition to reduce the usage of materials a bit, hence reducing the difficulty between stone-age with solely knapping and traversing with your first tools into the copper age a little bit, it's the biggest difficulty spike in the game currently anyway. And secondly it allows to include a baseline reforging option from the get-go. Hence re-heating material, reducing the amount available with the need to add a bit 'fresh' material for the upside of getting a higher max durability out of it. More initial cost for a more comfortable experience simply. I can imagine especially in MP environments this could provide a great upside with any form of trading. Low quality tools versus high quality tools. True, but we gotta see it in the form of a gameplay mechanic. Games aren't perfectly realistic for a reason. Imagine having build a nice little 'village' for yourself with dedicated places for butchery, and inn, a living space, a tannery and so on... all lighted up nicely, with some street lamps. And then you gotta replace those candles over and over and over. That's pure tedium. Nice for a 'realistic' playthrough with several people in MP but a horrible experience for anyone playing SP. The effect doesn't need to be extreme, the whole thing seems more about immersion then functionality after all, and Vintage Story is top-tier when it comes to immersion purposes. It's where it shines after all. There is a reason many people love mods like Bricklayers which builds upon those already immersive mechanics further. Besides mods like Quarry mod which reduces the hassle. One thing I've always found a bit odd for example is the inconvenient way we have to currently quarry for stone blocks. A usage for metal coming to mind right away here would be stonecutting tools. Hence low durability tools which are specifically designed to cut stone into prepared shapes before using a hammer&chisel onto it. Chisels have absolutely insane durability currently as the need it since we adjust whole blocks at once, which have a significant amount of 'voxels' in them after all. One option playing into it right away would be to introduce the ability to not needing to mine under exposed blocks, instead being able to saw it off. Optimally with prepared shapes too. Slabs, pillars, strips, cylinders... that stuff. Simply shapes which make progressing from there substantially easier, allowing chisel durability to be reduced. That alone in combination with the aforementioned reforging mechanics in some form would allow more targeted processing at the cost of storage complexity... or keeping up the ongoing method which means easier storage and less variety but more waste of metal in total. Hence the reforging would counteract reduction of metal usage by re-introducing it in a different form even without significantly extra use-cases for them (like rails, steam machinery or the likes). Also one showcase of a use-case which is in vanilla missing for the time being is 'Cartwright's Caravan'. A similar implementation for transportation in the form of simple hand-drawn carts which could only be reliably moved over roads (getting a severe speed debuff on any off-road block hence) would allow a relatively 'easy' next step for content implementation anyway as it solves several issues at once. For one the metal usage to reduce abundance. Providing a reliable need to actually create long-distance roads, even without creating buildings. Improving long-distance transportation without being reliant on fixed position teleportation entirely.
  8. There currently us no resistance modifier of any kind so you're good to go with that. Also I like the idea of using the raw stone as a building material in this way without being forced to go through the usual quarry method in the game. The only thing to look out for in terms of chiseling is that taking too much material away (which is a bit wonky on the exact limit) can cause it to become a 'non solid' block. This is important for things like enclosed rooms to keep temperature warmer in the winter or to impede waterflow and/or rain. I've yet to find out the exact detail as to when and why this happens exactly, but you can enforce it by making a hole into a side of a block and for example allow water to flow through, similar to a grate or even making it look like a sort of faucet this way. The water flowing out will take up the normal amount of space though, it takes a bit of fiddling aorund to design around this. Another property which happens with chiseled blocks is in relation to dirt. Currently dirt doesn't recover into dirt that has grass (at least the green top-texture) growing on it if made into a chisel-block. Something which I would greatly enjoy to have happening in the future as it would allow detailed landscaping with smooth hills.
  9. Chiseling in VS is amazing, the foundation of it is such a powerful and delightful tool in itself! Though when it comes to repeating tasks for it the system obviously starts to struggle, doing 100 fences in a row is - mildly spoken - tedious. For that QP's Chisel Mod exists, which is by now kinda a 'must have' mod for any playthrough with anyone wanting to use it on any large scale in the game, so that's fine. What I want to suggest though is a addition to allow repeating multi-block designs, so here goes: What if we had a system similar to clayforming/smithing attached to chiseling? The way I imagine it is a method of blueprinting basically. A measuring tool which is to be put at all 8 corners of any design-piece to create said blueprint, optimally with the option to save it as a nameable file (for re-use in new worlds). To built it somewhere else afterwards you have to use those measuring tools again but with the function of creating something, providing a overview with the sizes available and like all other things starting with the bottom left corner. Optimally when opening designs it'll also show a preview of what is picked to allow actually using the right one (a miniaturized visualization in some way maybe?) Going a bit further this can also include a option to exchange specific materials or simply use the 'default' design. Hence a granite statue becoming a sandstone statue instead, with a choice for every materials included to exchange it with something else. As for the building part itself that would be similar to clayforming. Adding it from the ground up layer by layer similar to the method of adding voxels with the chisel itself. This could also include sizeable structures with full blocks included, hence instead of making one add the individual voxels for the next material it instead would ask for the full block to be added in position. This way people would be able to not only keep their creations between servers or worlds, having the option to re-create them without having to fully memorize them (or use developer tools to copy/paste) but also to iterate on already finished designs. A well outfitted chiseled home which can get a version upgrade with more intricate and beautiful designs rather then 'loosing' it whenever a sever shuts down or a old world simply isn't fitting for whatever reason to be kept into a new version. I hope this is a interesting idea and would definitely love to see that in the far future! After all that would be quite the sizeable design to make I imagine.
      • 1
      • Amazing!
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.