redram

That wouldn't fix the issue. Players always want all their food, at least in times when decay matters. Decay is a mechanic that tries to keep food relevant as a limited resource, and drives the player to use other game mechanics like cooking and preserving. It's not to force players to 'count their calories' and throw out food they don't think they'll need in the next few days. When you're running around looking for a place to settle in the early game, you're fighting decay, you want every scrap, but it's a race against time, and composting isn't even relevant. I think the only way to fix this issue of a half-life system might be to have all containers (and the players inventory) have a special 'output' slot that they cannot put anything into. That slot would basically be reserved just for rot. Might even only show up if the container has food, otherwise it's hidden. However that single slot would need to be able to accept an entire inventory of rot, otherwise you're back to the same problem. That or there would need to be able to be a dynamic number of these output slots. As many as required. And theoretically they could dynamically place the rot back into the regular chest slots, once slots open up due to the entire stack decaying. That would be more helpful if not for the infinity issue, of course. If chests auto-combined stacks as they rotted, that would help a lot though, I think.

Nothing prevents a tier vs tier system from having other factors like speed reductions or damage type specific reductions. That can still be based on the actual type of armor, rather than material. As far as basic reductions go there's always going to be a statistically superior one, even in your scheme.

The heightmap in my example is primarily for establishing oceans-mountain-river relationships, and giving rivers direction. It would - for the reason you mention - need to be limited in it's max height. Perhaps to 80% of world height or something. And it would be a uniform smooth slope, unless occasional jumps for waterfalls were necessary/possible. The landform heights would essentially be added on top. That would hopefully leave room at the 'top' for mountain-like stuff to happen. So your chunk map might have an elevation of 160 at one chunk, but then the landform noise on top is what adds the interesting detail, perhaps adding up to 50 additional blocks of variation in height. That's be total 210 blocks at the example point (160+50). Even at the max chunk map height of 200 (for a 250 world height), 50 in variation would be safe (though not allow for trees, so there'd perhaps need to be a 'tree line' elevation). It'd take some consideration and condition, but I think it's doable. This would probably have an effect on the max continent size you'd want. If sea level is 110 and the max elevation of the chunk map is 200, then you've got 90 height gain max from ocean to mountains. 90x32 gives about 2900 individual blocks of 'run', if elevation decrease by 1 at every chunk. So a max continental 'diameter' of about 5800 blocks. Which is a lot, but far short of 32k. Which may be alright though; it'd allow for large oceans and bays and lakes internal to the continental box of 32k square, which would help break things up so the 32k box is not as obvious. Of course if there could be areas where the elevation doesn't decrease at every chunk, that'd help extend the width of the continent. The chunk column stuff would be great of course, but I imagine would be an incredible amount of engine overhaul?

Also I think your active item slot has to be empty (bare hand)

Ya I don't really see the point of an eyeball planet either. And I agree that east-west wrapping is just fine. No need for north-south. My biggest beef is the lack of oceans - I try not to harp on it too much, but given the topic this seems like a place for it. I don't see oceans as wasted space at all, but as a good boundary. To me, the world gen as it is is overwhelming. The world is infinite in all directions, effectively. So I cannot 'finish' exploring in any direction. This is an exhausting notion, and aggravating because it means that in any given direction I could maybe explore just a bit farther and find that one great ruin, or better landform. The world is infinite, and yet without order, it becomes to me - in a macro sense - chaotic and potentially the same in all directions. I think this is not optimal. When I was in my last year of high school, I took an 'architecture class, which was basically really just meant to be learning the drafting software. The teacher mainly taught physical education, so he knew nothing about the software, so he basically just told us 'make whatever you want'. He gave us a project without boundaries, and the result of having no boundaries means that you have no basis in which to anchor. Projects were dull and pedestrian. It was high school of course. But still, what I realized later in my college courses is that boundaries and unique conditions are what make projects interesting. They're what defines them and gives them character. I think the same is true of world generation. I think that having oceans would add good boundaries to the game. A player can reach an ocean, and then 'check off' that direction in their mind, and focus in another direction. Rather than constantly forever having the choice at any given moment to continue in a direction endlessly, or switch directions, knowing that that direction is endless as well. A player can establish in their mind a 'map' of their home. A map with boundaries. I think it is easier for a player to 'take ownership' of an area when it has well defined boundaries, as opposed to being just a part of an endless fabric. Moreover, I think that having oceans would allow us to have mountain ranges that make sense, and with mountains and oceans, you can have rivers and valleys. I think the verisimilitude of the world would be greatly advanced by this. I can't claim to know much at all about world gen, but from perusing online discussions it does seem like you need a defined 'continental areas to get this sort of thing. So I support this general arrangement, along the lines of what Tony says. Though specifically I would suggest 32,768 block square. Which is 1024 chunks. This allows a chunk-level bitmap to govern heights across the entire region, as well as mapping oceans, land, and mountains. I think that's all you need to then start drawing rivers on that ~1mb image. Once the rivers are drawn, the 'normal' world-gen then takes place around them, but is always (or at least mostly) 'stapled' to the rivers. This way you don't have to worry about nonsensical elevation changes, because the rivers govern the elevation in their chunks. From what I've read, it's doable, it's just a matter of how much area you want in your zone. A 32k square is a lot of space - much more than TFC2 had for each 'island', and I think you could create a great diversity of landforms in that area. Anything from archipelagos to Continents. As long as each zone is guarantee to have *some* land, I think you could avoid the vast ocean deserts of TFC. Moreover, you could start to organize the minerals. You could have the top sedimentary layer tend to be thicker the closer you get to the ocean. So if a player wants coal or other sediementary resources, perhaps explore more towards the ocean. If you want ores found in igneous/metamorphic, head inland towards the mountains perhaps. If you want to settle in a swamp, then the coasts will be your better bet. If you want a mountain home, and you start on a coast, then you could know to head perpendicular to that coast, or perhaps follow a river inland. So ya, that's my dream in terms of world gen.

I'm late to this discussion, since this was posted the day we left for 2 week vacation. But my belated 2 cents is that having armors whose damage reductions operate in different ways is probably going to be confusing, mainly, possibly also hard to balance. If you did have 3 types of reduction in the game, I think it'd be better if they were consistent across armors, rather than each armor only using 1 of the 3. It would look like a consistent system. 3 different things could read as indecisiveness, or incompleteness. I of course have a preference for the 'tier vs tier' notion I touched on in this post, but that's for a different topic. As for the rest I generally agree. Keep the number of 'active' armor slots small (gauntlets and boots and such can still be there for decorative or accessorial purposes), armor could affect other things like combat speed or number of container slots, etc. A lot depends on the overall goals of the system.

General may have been better, but for simple questions like this, Discord is an even better option. Much more frequented. Regarding your original question, I *think* that whatever mods are in the mod folder, and checked in the mod manager, will be used? I'm not sure on that though. But for the peaceful mod it would be relatively easy to test. It's a mod that doesn't add any blocks, so I really don't think you have anything to lose by just trying it.

No oceans in the game right now, and it's not clear if there will be. As I recall, Saraty found oceans in TFC (the minecraft mod that inspired VS) to be a 'waste of space'. And there were some pretty bad huge endless oceans it's true. Personally I don't think that makes any and all oceans bad. I think oceans would actually be good, and I think they'd be necessary to have 'realistic' rivers, which I think would be extremely good to have. But in any case, that's sort of the state of things at the moment.

I think all the other animals we currently have are either able to be domesticed, or in the case of wolves, their pups will probably be how you get dogs. My guess would be that this is probably intended for wild animals that won't have any domestication purpose, like foxes. But that's just my guess.

Combat in VS is about like MC I think, minus the shield and armor, which aren't implemented yet. As for how it ends up, there's been a lot of suggestions regarding that. I don't think it's set in stone yet. Your biggest worry is wolves, because they can kill you in two hits. So you need to have your head on a swivel in temperate forests. Pillaring up is an easy way to deal with them though. Once you have iron sword, things become much better. The grind is not that bad - tech right now tops out at iron tools, there's no machinery or other fancy uses yet. The sticking point can be bronze. A lot of people seem to have a rough time finding cassiterite. Though you can also do bismuth/zinc for bronze. Mainly just learn to use a propick. If you try to find bronze components just randomly caving, you'll probably have a hard time. The grind right now is significantly less than it was in TFC, in my opinion.

Since we just had a devlog icebox, I thought I'd drop some ideas about how ice box and storage might work. I would hope that ice boxes would require ice to function, and, hopefully ice storage is in itself a mechanic. I don't know if there is a feel for 'when' in the tech tree ice boxes should be thing, but it's a factor to consider when designing the recipe and process. ICE HARVESTING For ice harvesting, presumably lake water will freeze in winter. This could be simply mined via a pick of course. irl ice saws were used, so the saw itself would be another possibility, or even an ice-specific saw, though that would probably be a bit much. The process could be drawn out (hence making ice box refrigeration more significant) by making the harvesting of each block - in raw block form - perhaps require a right-click-hold harvest method, like harvesting a corpse. This would allow it to take a quite awhile. The block could still be straight broken with a pick, fast, but then you get nothing (or ice chunks, but they can't be stored long-term) ICE STORAGE Once harvested, an individual block could be highly encumbering, slowing the player immensely. Making it very attractive to have a cart of some kind to move the ice. I would further suggest the stack size in player inventory be limited to 1, and hotbar only, if not offhand slot only, but that's kind of getting into the inventory discussion. Suffice to say, I'd like to see ice blocks be not easy to move in quantity. Even more interesting would be if a block could be placed, and then 'pushed' by the player in-world causing it to slide along in real space. This might be faster than carrying by hand, but cannot climb at all. Only go down. If a block falls more than 1 block, it shatters into nothing. This would allow the player to have a subterranean ice house, and just slide the blocks in. Once in the ice house, the player needs to properly store them. Once temperature is above freezing, the blocks should melt pretty fast, UNLESS they are bordered on all 6 sides by either another ice block, or a hay block. This would give use to hay blocks. If bordered on all sides by ice blocks, the block does not melt at all. This makes high volume storage better than thin layers. If bordered by some hay blocks, then the ice will melt. The more hay blocks the faster. I don't know if this would potentially cause tick lag though. To remove a block, the player removes a hay bale, an pulls out a block of ice. Harvested ice blocks would need to be different from natural ones, so the stored ones don't require the saw to remove. The player then replaces the hay bale. The whole blocks is still hard to move though, so at that point the player can perhaps break the ice block into chunks, for easy transport. Since chunks can't be stored long-term the same way as blocks, the player should only break up ice blocks as they need them. ICE BOX The actual food storage would happen in the ice box. I think the ice box should be a 2 block tall assemblage, like the bloomery. One half is for the ice, the other for the food. Storage should be less than a normal chest by a column maybe. The construction could be very simple (2 chests plus some straw bales) but presumably this will be one of the best food storages in the game, so I'd instead go for something more involved. For one, metal lining. So several sheets of metal. Copper, bronze, or even stainless, depending on the desired tech gating (Yes I know stainless is a very modern metal, but given the chromium and such it's clearly being angled for). Galvanized steel would also be a possibility. The insulation material I would suggest as perhaps wool or some other animal hair, or perhaps alternatively cork, if cork trees were a thing. Mineral wool could also be used - interestingly it is drawn from slag, so might tie in with the metal refining mechanic. Even the wood case (if one is required) could perhaps be made of milled lumber, requiring a sawmill (so not just regular planks). A combination of metal sheets, insulation material, and milled lumber would I think make it a pretty involved item to make. How often the player needs to stock the ice would need to be carefully balanced. Too often and they won't be practical, too little and they'll be OP. Offhand I would think the ice should last 2-3 days at minimum, so that the player doesn't absolutely have to be on time every day. But possibly longer yet even, if you want to allow some slack for the player to go exploring for several days. But then again, maybe they need to construct an automated ice delivery system to deal with long absences? Anyway, that's my initial thoughts. Make ice boxes expensive, possibly higher tier, and make ice not trivial to harvest and store.

At this moment they don't do anything, and you cannot break them. However, it sounds like soon they will be functional. Don't know if that means we'll be able to move them or not.

Yes, patches of sand and gravel appear in all biomes, so that you should be able to find something to pan anywhere.

Just fyi, because it wasn't clear to me if you know about it already, but there is a cooking pot in the game that allows you to make soup, stew, and porridge. I think this feature came in after Stroam's suggestion. This system will be expanded upon over time, to be sure. But it's pretty labor intensive for each new system, so it's slow going.

You'll need a bronze anvil. There is no iron anvil in the game yet. I don't think the hammer type matters.