Erik

These are possible future updates. Freedom of Choice update: Micromanagement Gone update: Test of Time update: Mendelian inheritance update: Riders of Rohan update: Gold Rush update: World of Wolves update: Smithing rework update: Forging of the Rings update: Unlimited Power update: Steel age update (Dependency: Unlimited Power update): Valyrian steel update (Dependency: Smithing rework update, Forging of the Rings update, Steel age update): High ground update (Dependency: Unlimited Power update): Clockwork brain update (Dependency: Unlimited Power update): Worldgen Part 2: Give us oceans! update: Deep waters update (Dependency: Worldgen Part 2: Give us oceans! update): MS Untergang update (Dependency: Worldgen Part 2: Give us oceans! update): Finally Connected update: Combat Phase I update: Armor update (Dependency: Combat Phase I update): Combat Phase II update (Dependency: Combat Phase I update): Revenge of the Enemies update (Dependency: Combat Phase I update): Combat Phase III update (Dependency: Combat Phase II update): The Winds of Winter update: Living world update (Dependency: The Winds of Winter update): Breathing world update (Dependency: The Winds of Winter update): Winter is Coming update (Dependency: The Winds of Winter update): Environmental Hazards update (Dependency: The Winds of Winter update): Living Underground update: Beer n Barrels update (Dependency: Winter is Coming update): A Fine Taste update (Dependency: Beer n Barrels update): Effective food update (Dependency: A Fine Taste update): Secrets of the Alchemist update: Fancy Tree update: The Hunted update:

Some first impressions on this mod: First of, the amount of effort and work put into this mod is simply amazing, I feel like that needs to be mentioned, as I know from personal experiences, that making mods is very work intensive. What this mod does really good: Predators sleeping is something that is very cool and makes the game more fun, as wolves won't constantly attack you. It seems a little bugged at times (when the sleeping wolf attacks you and is always looking towards you) Dead animals are beautifully realized, with realistic skinning processes. Problems with this mod: The mod is not really intuitive and lacks documentation. There are a lot of things the player can knap right away, but most of this things are useless at the beginning and overwhelmed me a bit. I figured out quickly that the hand tools are supposed to be your first tools, however I haven't yet discovered how to create the materials for the rope that is required for the stone tools. The changes to wood (different log sizes) make inventory management really painful. VS's inventory is just not build for this type of stuff. There is a lot of "microcrafting" involved, i.e. crafting steps just to make things only used in other crafting steps, which can get a bit annoying and does cause more inventory problems. There are a lot of oddly specific wooden blocks for creating rooftops. While it enables making good looking roofs, it is not user friendly at all. How problems could be fixed: A simple solution for making the progression more streamlined, would be to remove stone tool heads and use the hand-versions in the crafting recipes instead. Or there could be only one "stone hand tool" which is used as an axe, knife and hammer at the same time (which is also somewhat realistic). More tooltips on things and documentation on this forum topic. Just stick with the normal wood logs, or at least allow players to turn the thinner variants into firewood. Maybe a bigger starting inventory or a weight based inventory (which sadly wouldn't be easy to implement). Less crafting steps. Fixing the rooftops isn't easy, it would probably require dynamic model selection or something in the line of the Carpenter's Blocks mod. Anyhow, these are just my subjective first impressions on the mod, feel free to ignore them if they don't fit your vision, this is your mod.

Do not forget steam engines. While they were invented much later than the other methods you mention, they were often used to provide mechanical and only much later to generate electricity.

Engineering in Vintage Story Split of the mechanical energy system and the mechanical computing system. This is one of the most important things, because both systems try to archive very different things which would benefit from very different mechanics. The energy system cares about rotation speed, torque and maybe inertia, which are useless in a computational system, which that needs binary states, like the direction of rotation. Other than that, splitting the two would also make performance optimization easier, allowing for bigger and better machines. Furthermore the split is also helpful on a game design side, as it emphasizes the split of functionality very well. Material split for mechanical energy and computing system. To make the split more evident for the player, I suggest using different materials for the energy and the computing system: Wood for energy and brass for computing. The energy system should pose interesting problems for the player. It is very important that using mechanical energy needs to pose engineering problems for the player to solve. Otherwise, mechanical energy would be a pretty dull cosmetic addition. As mechanical energy is compromised of at least two variables, being speed and torque, converting and balancing these could present an interesting engineering challenge. Fluctuating energy output on certain generators could make automatic gearbox-adjusting a new and interesting engineering challenge, when certain energy consumers need a specific minimum or maximum value of one of the two variables to function or change behaviour when receiving different values. Mechanical computing should be based around the geneva drive. The geneva drive is a gear mechanism that turns constant rotation into intermittent rotary motion. It is used in mechanical clocks and therefore allows for the very cool name of "clockwork engineering" to be used for mechanical computing. As mechanical computing is driven by a clock, it further emulates real electrical computing. Geneva drive could be operated at different speeds using different speed of mechanical energy to provide different clockwork tick speeds. The torque provided to the geneva drive could limit the number of components driven by it, not working at all when the torque provided is too low. Gear rotation direction as a binary unit for clockwork engineering. Unlike redstone, clockwork engineering shouldn't violate the conservation of energy completely, so the on-off state can't be efficiently used for binary computing, without making clockwork computers huge. Therefore gear rotation should be used as the primary binary unit, as inverting it is as easy as placing two gears next to each other. Mechanical sensors should be present to provide single clockwork ticks. As clockwork circuits only operate when ticking, they would need to check constantly for changes at sensors. This would add a lot of unnecessary computation efforts, which could result in bad performance, as well as making simple tasks much more complex. To oppose this, mechanical sensors should be able to provide single clockwork ticks. The sensors shouldn't produce power out of nothing, so there should always be some mechanical explanation for a tick, like an entity detector being a piston that pushes down and therefore produces a mechanical signal turned into a clockwork tick. Torque as a variable sensor output. The sensors could also output different values of torque, depending on the measured thing, i.e. a heavy entity, item or block would provide a higher torque for the tick. This would play further into the realisms side and could also have some practical uses, like clockwork circuits being so large, that they only activate when the sensor provides a certain torque. To make systems like this possible, a clockwork resistor block, which adds addition torque requirements to the clockwork circuit, would be useful. Furthermore, to make sensors actually useful for processing weak signals, geneva drives may have a mode to activate for a tick, when they get ticked. This allows having a weak signal with a weak torque triggering a geneva drive to provide a single tick with a torque based on the torque input by mechanical energy. Any mechanical (automation) block should have a very general and simple functionality. General means is that a block should always have more than one application. Simple means that single blocks should only be able to solve very small and simple problems, bigger more specialized problems should be solved by combining simple functionalities of the single blocks in interesting ways. After all, engineering should always be a puzzle for players to solve and not a solution they get after grinding materials. This should apply to all aspects of engineering (automation, mechanical computing, mechanical power) in Vintage Story, never providing players with a simple "Automatic farm"-block. Simple functionality also has the side effect of making blocks easier to understand.

I edited the poll, to reflect the feedback.

I don't think the frequency and direct detection go well with each other, as direct detection would only be useful with much rarer veins and frequency detection with much more common clusters. If you can dig down everywhere and expect to find ores 70% of the time, there is no real purpose in using direct prospecting. If you won't find more than two veins in an area, there is no real use in frequency prospecting. The methods of ore generation have different problems for the player to solve. With larger rare veins, the player needs to find the vein. With common small clusters, the player can easily find clusters, but might wan't to know where the most clusters for what metal are. You're right. But I wouldn't say they are separate issues, I think that they are tied together, where only one option of prospecting makes sense for one option of ore generation.

I'm really unsatisfied with the current mining experience. It's basically like minecraft, where there's little patches of ore everywhere and mining infrastructure is useless. Prospecting only tells you, if a chunk has many ores or few, which isn't overly useful, since the most useful ores are also the most common. I would rather prefer a Terrafirmacraft like approach, with better prospecting (Prospecting in TFC is very difficult to get into). Veins would ideally be generated like the Reasonable Realism mod (very long, thin veins). Prospecting should tell you if there are ores beneath in a certain radius (like 6 block diameter). If there is a ore block somewhere directly beneath the prospected block, the player should be notified. So prospecting would be a search on the surface, with clear results. I added a poll to this post, I would be very happy, if you could fill in your opinion.

I didn't mean the player wouldn't be able to understand the concept, I just think it would add a lot of tedium to the inventory management. Players would have to constantly move items around their inventory, to make everything fit although the idea behind the weight mechanic was to make inventory management less relevant. Tools have durability is mainly implemented to slow the players progression, to keep him from cutting down whole forests and mining mountains. It also serves as a way to balance the amount of resources the player has, so the player has actually some reason go mine ores throughout the whole game. Replacing tools is also very easy, you even can carry multiple tools with you. I don't expect the player to carry multiple backpacks in your system. When your backpack breaks it just drops to the ground? What happens to your items inside it? How can you repair it if you can't pick it up? I also imagine the breaking of a backpack taking a lot of the players time, as he is severely limited without one. If I understand you correctly, there is a weight limit for containers, but it doesn't limit you from exceeding the limit, instead durability is used when the limit is exceeded. I would suggest the weight limit to be limiting the items that you can carry, instead of having durability involved. That would also be easier for players to understand.

Well, this system would probably also work well with weight, but it's more of a framework for the gui than for gameplay. Introducing weight may be a good idea, because it helps to keep inventory management very simple, but it requires different controls for the gui and the quickbar would require to only be virtual, with no items actually being stored there. Only introduce weight or volume, as introducing both would make inventory management really difficult again. Bag durability is a bad idea, only serves being tedious.

Well, I guess I learned something new. The current system, as far as I know, is not moddable in any way, which really is a shame. Color coding would indeed be something nice. I thought of action slots, because I thought, the inventory system needed some standardization to be moddable. Action slots are an easy way for modders to expand the functionality of the inventory, like adding new types if armor. The moddability using action slots could be so easy, as modders could remove the option for multiple backpacks by just editing the json files. Implementing the system wouldn't be 'as hard', as the game already has some form of a html/css-like GUI system (It's only mentioned in one of the first news posts), it would "only" require some major refactoring.

The problem with the current system is the implementation on the four pouch slots: Other than carrying four backpacks being absurd, the player doesn't know, which item is stored inside which pouch. Having the pouches placed next to the quickbar is an odd design decision, as it ruins symmetry and has no real practical use, other than obstructing the players view. What the modding api currently lacks is the ability to create GUIs with inventory slots. The proposed system wouldn't only allow for easy creation of new GUIs, it would also allow for easy modification of existing GUIs. For example: A mod that adds capes could simply add a new type and add an action slot of that type to the players inventory via coding or json patching. Multiple mods can add multiple things to the same GUI without compatibility issues.

The inventory in VS is very unfinished, so I got a small idea on how to expand it. First, I'll introduce a new property for blocks and items: The type. Types are just categories for items and blocks, a type can be attached to any item or block via json. Custom types can only added by code mods, using an IType interface. Some types can also require additional data in the json file to fully work. Possible types: Backfit (for backpacks and the like), Helmet, Chestplate, Tool, Weapon, Pouch, Ore, Ground, Flower, Food,... Now, I'll introduce the item slot types: Normal slot: A absolutely normal slot, every item fits in. Filtered slots: These slots only fit items and blocks of a specific type. They render as a black slot with the type image in it. The type image is defined in the types code. Action slots: Action slots are type slots with the ability to utilize the item inside the slot. The handling of the item is described in the onEquip, onEquipped and onUnequip functions of the corresponding type (in the class that implemented IType), using properties defined in the items json file. Action slots look like filtered slots, but have a bar next to them and are surrounded by an inventory box. Custom slots: Can be added using mods to add special functionality to inventories, like the inventory of a furnace. They can be created by inheriting from the abstract CustomSlot class. Their appearance can also be defined using coding. Technically speaking, all slots implement the IInventoryElement interface and all inherit form the CustomSlot class An example for an action slot: Backfit type action slot. Used for backpacks and barrels: When the player puts a backpack in the slot, the action slot "expands" and adds new slots to the inventory, some of them even being action slots: When the backpack is pulled out of the action slot, it keeps the items stored inside the item, making swapping out backpacks easy. Armor is also using the action slots to be equipped. Now that we have covered slots, we will quickly cover my vision for a moddable inventory system. An inventory is defined via json. The inventory has a size (width, height in % of screen). There are multiple elements that can be fit inside an inventory, notably slots, filtered slots, action slots, custom slots, other inventories and other inventory elements. There are three types of inventories: static, floating and custom inventories. Inside static inventories the elements are statically fit using coordinates in percentages of the inventory. Floating inventories have the elements inside positioning oneself by order, like floating in css. Floating inventories also have a scrollbar, when the elements inside would not fit the width and height of the inventory. Custom inventories are often dynamically inserted into inventories, using action slots. They can also be defined in json or generated by code, the coded approach being more common, like in the case of the backpack. Custom inventories are also either static or floating. An inventory that is not inside another inventory is the window object. Custom inventory elements, like progress bar or buttons can be defined by implementing the IInventoryElement interface. The coding of inventory handling should be very reminiscent of Javascript DOM scripting, having to append objects, getting objects by class or id and so forth. Inventories in the survival mod should be stored in json files as mach as possible, to warrant maximum modding compatibility. I know there is some html/css like system in place for GUIs right now, but right now it isn't moddable, and I thought of this as one way to solve this. Implementing these changes would obviously be a massive, but worthwhile, undertaking, as it is basically a rewrite of most of the GUI system, things like shift-click behavior on items have to be entirely rewritten etc. This was a very technical description of a easily moddable system, and while my "how to design it code-wise"-suggestions might not work so well, the basic premise of a floating player inventory with action slots is what should definitely be implemented somehow.

I think the game has a long way to go to be called "finished", I would judge the current content to be 30% of the way. The main problem now is, that a lot of systems feel unfinished: Smithing needs a big rework, hopefully promoting player skill. Iron production needs to be finished, there needs to be an iron bloom that is worked. Knapping/pottery is a very annoying task, I would like the recipes to have a smaller grid with bigger tiles. Farming could use more diverse crops, maybe fruit trees (see Growthcraft). Food and health balancing needed, maybe introduction of stamina. Underground/cave rework (cave biomes, deeper = dangerous) The bag/inventory system needs to be reworked/rebalanced. Animals and mobs need an AI and behavior rework, right now everything is a monster that wants to kill you. Combat is the worst, I will probably post a more streamlined overhaul suggestion soon. The current ore/prospecting system feels kinda useless, finding tin is really hard. Would love to see something like in Reasonable Realism. Connected textures are desperately needed, I can't stand the look of redwood trees anymore. Now to missing/needed features for release: Steel age. Leather working. Animal husbandry. Mechanical power system. Mechanical computing system. Minecart/railroad system. Mechanical automation tools. Alchemy and herbology systems. Cooking and nutrition systems. Armor system. Seasons and weathers. Oceans and drowning. A tutorial and an TMI/NEI/JEI of some sort. And this was just the survival mode content I think the game needs. Some things that you also planned: More story content, maybe dungeons, should only be released at 1.0, to contemplate spoiling the story before release. Villages and npcs. I feel like a basic system like in minecraft would be very disappointing, so I would push this behind the release in a big update. And here are some things the game may not need imo: Player stats/attributes, they usually promote grinding and systems that require no player skill. More streamlining, the audience for this game isn't stupid and wants something that is more than a pretty minecraft clone.

There will be NPC's and Monsters in the game, and the game has Multiplayer. Combat is an essential part of the game, so weapons are too. The sword has historically been one of the most useful weapons and should therefore stay included in the game. At least in multiplayer, a sword is required.

A small mod that adds one new block with special properties to the game: The scaffolding! Features: -Climbable -Vertical deployment -Breaking the bottom scaffolding will result in all scaffoldings above breaking too! ScaffoldingMod.zip

My opinion on death punishment: Gravestone, no item despawning. Makes death dangerous, but not frustrating.