Sort of a random extra here - would it be weird to have Gooey in-game for JS? @Florian has prepared the neato GooeysQuests module complete with basic interaction and a placeholder dungeon generation piece. Could Gooey also help guide the player, sort of a more personalized version of the help system?
Other things to consider adding in when time/energy is available:
WildAnimals for the deer (I've asked @glasz for injured/dying animations) and inclusion of resources from said deer into various recipes
The computer system from @Marcin Sciesinski as a high-end automation option, there is even the Fluid integration module and the possibility to use a moving computer as a harvester of sorts
Herbalism / Alchemy when @xtariq finishes extracting it from WoodAndStone. Maybe a standalone Cooking module too (yum, roast venison!)
Maybe Genome sometime after that for plant breeding. Make your own blueberry variants!
Minimap that could be enabled if you craft some mapping gadget - I think @msteiger fixed some of the odd cases where it goes black, if not all?
Rails when we can get @SkySom to poke at it a little more. Just the small trains / minecarts for actual mining or carting around of resources. A tank cart would be nice if you're crafting away from a water source yet need water (I hauled a few buckets up a hill Saturday even for some minimal stuff!)
Also as a maybe bug report I think I was having to 'e' click twice to open some things. Unsure if that was just me or just a multiplayer thing.
Somebody needs to make a cow, sheep, or a goat so we can have milk and a process to turn it into cheese. Got the cheese wheel!
Chisel - shaping already placed stone type blocks.
The Problem:
In minecraft, sculpting a mountain into a statue is common, but empty, as theres no real reason to do it because building the statue from scratch is faster. As it were, its easier to build David from loose stones then sculpting him out of marble.
In minecraft - ores drop ores, sand drops sand, stone drops cobble (one easy smelt from stone), dirt to dirt, and so one. Scupting from a mountain isnt unique than building from scratch.
However, in minecraft beta before beta 1.8, there was one type of block that was impressive to build/have. Ice (and diamond and redstone ore). Before enchanting, ice could not be obtained legitmentally. So the only way to build from it was - be in a biome where water freezes to ice, and make molds to free into ice. A long and annoying proccess. Or, if you don't live in a cold biome, push an iceblock ALL THE WAY HOME, via pistons. Thus, ice was pretty impressive. However minecraft didn't really have a special use for ice, althought it was impressive, and hard, it was not useful.
This would be achieved by - the power of the pick. unlike minecraft, you could make the pick much easier to break objects, then to achieve them.
In minecraft breaking stone with a pick results in cobble, not stone.
However you only need to smelt cobble to stone, so not much work. Building and breaking is almost the same in terms of work. you can smelt massive amounts of cobble easily, so building a statue from scratch instead of sculpting is still easier. You'd make the tech/craft tree in a way that its hard to obtain the natural blocks a mountain/natural world is made of. In this case, natural blocks would be so hard/expensive to even obtain, crafting shaped ones would be even more so. It would be cheaper,faster,easier to cut (via chisel)/sculpt already existing blocks into shapes. Thus sculpting is backed by an actual game mechanic, not just imagining mount rushmore. From here we could put some kind of value/mechanics of having something made of natural blocks. For example, a nuclear bunker is best when encased in actual stone. However this doesn't put any value in the fact that you didn't place the blocks/the blocks are there since natural generation.
The best I have been able think of for this, block placing date (like filesystem file creation date). Thus blockers placed naturally by the terrain generator will be the oldest possible, which you can do what ever with. (special properties, like perhaps make them harder. In this case, carving a statue out of a mountain (instead of building it up out of natural blocks) will be harder/more solid/sturdier. This will have additional intresting uses, for example, ancient ruins will be harder to destroy vs your home made of the same material. Thus you can have structures the player is more inclined to go through, then try to bruteforce/break through.
It could also be used as a primative anti-grief. While yours and jimmy joes house are both made of the same wood, you've been there much longer, so your wood is settled in/harder (vs his fresh, or newly placed shifty wood. Or whatever) . You're harder to destroy/grief. The longer your stuff exists on the server, the harder it is to remove. (albiet, probably for only some blocks)
I suppose block placed date would also be useful when accessed raw.
However there are some problems with this, storing that directly in block data would be very, very expensive. So thered have to be some kinda of external database accessed when things destroy/place blocks. However, thats implementation details.
the changingBlocks library has also be recommended, but that also deals with a problem of expense.
The best usage will probably end up beaing to choose only certain blocks to age.
I think I finally get one angle of your thinking that wasn't clear to me: cobble vs regular stone. Thus carving a mountain (existing stone) vs building a statue (just "cheat" by baking cobble back into stone identical to a regular mountain and place those blocks).
Still, while you could make a whole system for that you don't really need to. Just force said "natural stone" to break into something else when broken and leave no crafting path to get it. IMHO allowing placed blocks to age individually is overkill and not necessarily realistic since any serious aging would likely take years or even eons. Also, stuff that ages tends to get weaker anyway, so that doesn't really help make older structures more grief-resistant. Plants etc are naturally a different case (growth systems in limited quantity)
If you did want to simulate, say, the ruin of a city over time then you would probably want to do that at the simulation layer, not block layer. Keep track at the chunk or even the potential sector layer. Have an age counter on the city entity, stored at the sector level, so it'll be alive even when no players are near and no chunks are loaded. If the city becomes abandoned via some game logic process then start ticking age every in-game day, week, month, or whatever. Change the area as you see fit, keeping in mind you may simply be changing entity data, some of which may get queued to hit the next chunk load (you may or may not want to change actual block data on disk - it could be cheaper to just wait and see if a player ever visits a city and as the chunks are loading then replace the blocks with aged or ruined versions)
But then that piece would probably fit better in Cities / DynamicCities rather than within JS
This is semi-related to JS. As I couldn't find a thread for the ThroughoutTheAges (TTA) gameplay module, I decided to post this here.
I talked with @Cervator today following my recent updates to CopperAndBronze (CaB) and Smithing. I was asking whether I should move the Copper and Tin (and future) Ores from CaB to Smithing for a near-future module (i.e. EquipmentSmithing), and we ended up talking about how WoodAndStone (WaS) and CaB may not make sense anymore in terms of scoping. Due to moving systems away from those modules into discrete systems ones (such as Alchemy, Cooking, Smithing, etc.), WaS and CaB are becoming more obsolete in a sense. But, they still have some valuable content in there (like items and recipes) that are not part of the systems modules.
In short, we need to reorganize/rename the modules under the WorkstationCrafting or NeoTTA family (see attached screenshot below) to make more sense scope-wise as well as sensible dependency chaining. After all, we want the systems modules to be usable by other modules that don't intend to be survival-focused like NeoTTA.
(Arrow indicates dependency relationship. For example, Potions depends on AlterationEffects.)
From what I was thinking, I see the primarily systems modules (Cooking, Alchemy, etc.) to be on the top, then the Age modules (WaS, CaB etc.) in the middle, and finally the gameplay template modules (e.g., TTA) to be on the bottom.
