Remove Torches, I'm Serious

[Libervurto]

I was playing earlier and couldn't find any coal. I went into a cave assuming I would find some fairly quickly but no. I dug deeper and deeper, it got darker and darker but still there was no coal. I could barely see anything but I had enough wood and cobble to make a furnace and smelt some of the iron I'd picked up. I used the furnaces as a light source for a while until I found some flint and crafted a flint and steel; this is when not having any torches actually became fun. Placing down some wood and starting a fire to illuminate my work space felt very natural and pleasing.

Yes I really found diamonds before coal!

Torches that burn indefinitely ruined survival Minecraft because it is so easy to make areas completely safe forever. Just because Minetest doesn't have mobs by default (and I assume it will do in future anyway) doesn't make the situation any better. Torches, in their current incarnation at leat, make the world feel dead and fake. Real fires are great not just because setting them up and lighting them is cathartic but because things can also go wrong, a fire can get out of hand and spread. This encourages some extra thought, care and planning, adding to the gameplay experience.

I understand that many players groan at the idea of having to maintain the areas they colonize but isn't that largely what survival is about? I feel like that sort of maintenance is far more engaging than the chore of constantly worrying about a hunger bar.

So why not try playing without torches for a while and see if you find it as compelling as I did?

Fire would need some tweaking in a few ways before torches could be removed.
[*] Fires need to burn for a reliable length of time. In my torchless adventure some of my fires lasted almost a minute while others only a few seconds. Some randomness is welcome but no more than 10%. DETAILS: I'm not familiar with how fire works in code but if it relies on an RNG test every few ticks then how about giving blocks a new "combustion" parameter that stores how burned up the block is in levels 0-15, then every successful RNG test will move it on to the next "combustion" level?
[*] Fires need to burn for longer. Having to restock a fire every 30 seconds is impractical. Around 5 minutes would be adequate. Perhaps we could build up a larger fire that would burn for 10, 20 or even 30 minutes?
[*] Blackening of textures as they burn would be a nice visual aid to let you know when your fire is reaching the end of its life. This effect could also look like soot when applied to non-flammable materials, like stone.
[*] A new model for intentional wood fires would be nice.
[*] New item idea: Ashes. Fully combusted wood turns into ashes. Ashes are a good fertilizer so they could be mixed into soil to improve the growth rate of plants. Lye is extracted from ashes, lye is used in soapmaking, curing some foods, and identifying mushrooms. So lots of potential uses for ashes if these things interest devs/modders.

[kaadmy]

Ashes and scorched wood would indeed be a neat addition, but changing the texture on a node is unfortunately quite costly in Minetest.
Torches decaying, and weak torches in my subgame already decay over time :)

[duane]

Add some goblins to your game. Not only will they steal torches, they'll mine out your constructions unless you watch them closely. And in some of my mods, they start fires on their own.

[Byakuren]

I don't think maintaining your light adds to the gameplay. Survival games don't necessarily have to be simulations, and when they aren't, adding easy repetitive actions that you have to do makes the experience worse. The solution would be to make mob spawning not light based, and maybe add some separate mechanic that makes it more expensive to keep mobs from spawning. There could also be some kind of incentive provided to not keep everything lit, though I'm not sure what that would be.

[SegFault22]

If we can manage to make a form of the game where nodes are filled with materials in varying volume, it will be trivial to implement fire properly, as we can just slowly degrade the combustible content of a node when it is on fire, until there is none left. Also, such a system would have room for reasonable smoke and CO2 and the like, and much more beyond just this.

However, until then I believe it would be better to make some kind of lighting system which consumes fuel over time, so it is predictable and doesn't last constantly. We could make, for example, a lantern, where all furnace fuel items can be burned to produce light and burn much slower than in the furnace. It would convert itself to a light-producing node just as a furnace, and back to a "normal" node as well.

To replace lanterns with something more persistent, some kind of light-producing ore could be added which is not common and only occurs deep underground - torches or other embodiments furnished with such a material, would never run out, but they would be considerably more expensive than fire torches; it wouldn't be practical to light your mines with them, but it would be practical to light your house/base with them.

Then, it would probably make sense to remove torches, or make them last as long as 1/4 the time of a piece of coal in the lantern, degenerating when that runs out (or turning into a "burnt stick", having a charred end where the fire used to be, and only useful as scrap - replacing the stick with an iron rod could make it re-usable by adding more coal, but why do that when you can just make a lantern?)

It would also be preferable, not for realism but rather for reason, to require some source of fire to light torches and furnaces. Flint & steel don't require some sort of tinder in order to start fire, so it isn't realistic - but it is reasonable that you need it to make fire, because making fire requires a method of delivering energy sufficiently magnified to start the process, even if that method is magic/energy-manipulation.

[MineYoshi]

Coal made of wood!

About all those tecnical aspects: I have a question, will the "CO2" and "Smoke" be done in C++ or Lua? I have that question but i don't know... Also, this of the "Smoke" will be hardcoded? Or it'll be justly a mod?

[SegFault22]

About all those tecnical aspects: I have a question, will the "CO2" and "Smoke" be done in C++ or Lua? I have that question but i don't know... Also, this of the "Smoke" will be hardcoded? Or it'll be justly a mod?

Well, first it would require a total overhaul of the existing system (most likely a fork, because it is substantially different), for this to even make sense. You know how we can have nodeboxes of pretty much any shape? Well, imagine that now all nodes entirely consist of nodeboxes of any possible shape, each node can contain more than one, and they can fit together seamlessly - for example, a node that is half dirt and half sand. For simplicity, only one node would exist, being an empty placeholder for "volumes" of "material", where materials are registered similarly to how we register nodes now, except with a few more parameters. In the dirt/sand example, you would have one volume of the node consisting of dirt, and another consisting of sand - you can subtract mass from the dirt part, without directly affecting the sand (except it may fall by gravity, if there's sand above where the dirt is removed, but that's kinda complicated).

Then, all nodes made of wood can take any shape, and we can subtract mass from them (shrink them), convert some of the mass to a different solid material (charring, ashes) or even a gaseous material (CO2). The difference between the solid materials and gaseous materials, is that gaseous materials don't have a definite density or shape, so they can spread out and fill whatever empty space is available, or even mix with other gases. So when you light a wood node on fire, it immediately starts converting wood matter into char and some amount of CO2 and heat, which then converts to some amount of ashes and a lot more CO2 and heat. In order for fire to make sense, though, there will need to be some way to keep up with the distribution of heat in nodes (it's hottest where the fire is), and keep up with heat dissipation by conduction (if the fire goes out, it starts to cool off, embers stop glowing).

That way, using flint and steel on the top of a wood node raises a small part of it to far beyond the combustion temperature (of wood), which then catches on fire and starts converting to char, ashes and CO2. Since the CO2 is extremely hot when it is generated in the fire, if gives off light and turns opaque-looking from the light output, because it is above the (universal) incandescence temperature; and hot gases flow upward, so we get realistic-looking flames without having to directly animate anything.

However, this would basically turn the game into a "reality simulator", if we go too far and make everything look as close to the real-world as possible (which is not too difficult with the system I described) - we should be careful to keep stuff like flint and steel OP enough, for example you don't need to catch a tiny spark in some charcloth to start a fire, instead the flint and steel basically places a considerable ball of incandescent plasma-air wherever you right-click with it, instantly igniting combustible materials. And, we can have materials which don't exist in the periodic system, such as mese and adamantium - and tools would still be insanely fast compared to the real world, but instead of seeing a node crack-up until it disappears, chunks of volume of the material you are pointing at get removed from a node until there isn't any more of it in the node, and this happens fast enough that the total dig-time for a node full of dirt is the same as it was before when digging a dirt node in the "old system".

You can probably see why it would be best to put this into a fork, instead of the default game - such as the immense complexity involved in programming "all of this", how it is almost entirely different from the existing node system and would make the game look and feel a lot different (while it would still be a voxel game, though), and the insane quantity of processing resources needed just to run the server end of this system (rendering it all on the client side, especially the part where volume is quickly subtracted from a node as you "dig" at it, would be an extreme load poossibly requiring several high-end GPU cards just to get a considerable framerate). It would probably be safe to say that it will be many years before this is even possible, even if all of the programming were finished already.

So, until then, the existing fire system seems effective - if we really want char and ashes and CO2, we could create (in the C++ part of the engine) a special texture effect for combustible nodes, where the texture slowly turns black as it burns, and when it is completely black it starts to turn gray, until finally replacing the node with a small layer of ashes, also releasing a CO2/smoke node every so often (which looks like smoke, being somewhat transparent but gray in color), which would float up and linger around (when two CO2 nodes become stacked upside-down on a ceiling, the one closest to the ceiling moves to the side to allow the one under it to move up) - or, instead of the moving nodes method, CO2/smoke could be a fluid with "negative viscosity", which the engine handles differently by making it flow up instead of down (like this stuff from some other place) - so a source node is placed above every fire, and when the fire goes out, the source node degenerates and the "flowing smoke" clears away like flowing water when the source is removed.

It is always best to keep the combustion products from being hard-coded into the C++ part, because someone may want to modify how CO2 works or change its properties, or make different combustion product gases which behave similarly, but are produced by special materials.

Also, players should not be able to breathe in smoke, just like they can not breathe in water, but we may have to implement that differently because smoke has a density similar to air, not water, and you can technically breathe it, unlike water.

[Libervurto]

I don't think maintaining your light adds to the gameplay. Survival games don't necessarily have to be simulations…

I don't want it to be a simulation either. I am not asking for fires that burn out for lighting because it is realistic, only because it is fun to light fires and it adds to atmosphere and gameplay. When I am exploring I want to feel like an explorer, this means it should not be so easy to colonize areas, and lighting is a big part of that. More permanent lighting should come later in the game and at a bigger cost to resources (oil/gas lanterns and electric lighting).

Well, first it would require a total overhaul of the existing system…

I find it fun to talk about these kind of elaborate systems but it all sounds a bit too complicated. I love it when there is any mechanic that acts like cellular automata (nodes interacting with each other) but I don't see much enjoyment for the player for all this hard work in this case.

However, I really like the idea of a gaseous node! It could act like water but flowing upwards. We could have a generic "fluid" node type with a density value, if the density is lower than air the fluid floats like smoke, higher density sinks like water.

[MineYoshi]

About all those tecnical aspects: I have a question, will the "CO2" and "Smoke" be done in C++ or Lua? I have that question but i don't know... Also, this of the "Smoke" will be hardcoded? Or it'll be justly a mod?

Well, first it would require a total overhaul of the existing system (most likely a fork, because it is substantially different), for this to even make sense. You know how we can have nodeboxes of pretty much any shape? Well, imagine that now all nodes entirely consist of nodeboxes of any possible shape, each node can contain more than one, and they can fit together seamlessly - for example, a node that is half dirt and half sand. For simplicity, only one node would exist, being an empty placeholder for "volumes" of "material", where materials are registered similarly to how we register nodes now, except with a few more parameters. In the dirt/sand example, you would have one volume of the node consisting of dirt, and another consisting of sand - you can subtract mass from the dirt part, without directly affecting the sand (except it may fall by gravity, if there's sand above where the dirt is removed, but that's kinda complicated).

Then, all nodes made of wood can take any shape, and we can subtract mass from them (shrink them), convert some of the mass to a different solid material (charring, ashes) or even a gaseous material (CO2). The difference between the solid materials and gaseous materials, is that gaseous materials don't have a definite density or shape, so they can spread out and fill whatever empty space is available, or even mix with other gases. So when you light a wood node on fire, it immediately starts converting wood matter into char and some amount of CO2 and heat, which then converts to some amount of ashes and a lot more CO2 and heat. In order for fire to make sense, though, there will need to be some way to keep up with the distribution of heat in nodes (it's hottest where the fire is), and keep up with heat dissipation by conduction (if the fire goes out, it starts to cool off, embers stop glowing).

That way, using flint and steel on the top of a wood node raises a small part of it to far beyond the combustion temperature (of wood), which then catches on fire and starts converting to char, ashes and CO2. Since the CO2 is extremely hot when it is generated in the fire, if gives off light and turns opaque-looking from the light output, because it is above the (universal) incandescence temperature; and hot gases flow upward, so we get realistic-looking flames without having to directly animate anything.

However, this would basically turn the game into a "reality simulator", if we go too far and make everything look as close to the real-world as possible (which is not too difficult with the system I described) - we should be careful to keep stuff like flint and steel OP enough, for example you don't need to catch a tiny spark in some charcloth to start a fire, instead the flint and steel basically places a considerable ball of incandescent plasma-air wherever you right-click with it, instantly igniting combustible materials. And, we can have materials which don't exist in the periodic system, such as mese and adamantium - and tools would still be insanely fast compared to the real world, but instead of seeing a node crack-up until it disappears, chunks of volume of the material you are pointing at get removed from a node until there isn't any more of it in the node, and this happens fast enough that the total dig-time for a node full of dirt is the same as it was before when digging a dirt node in the "old system".

You can probably see why it would be best to put this into a fork, instead of the default game - such as the immense complexity involved in programming "all of this", how it is almost entirely different from the existing node system and would make the game look and feel a lot different (while it would still be a voxel game, though), and the insane quantity of processing resources needed just to run the server end of this system (rendering it all on the client side, especially the part where volume is quickly subtracted from a node as you "dig" at it, would be an extreme load poossibly requiring several high-end GPU cards just to get a considerable framerate). It would probably be safe to say that it will be many years before this is even possible, even if all of the programming were finished already.

So, until then, the existing fire system seems effective - if we really want char and ashes and CO2, we could create (in the C++ part of the engine) a special texture effect for combustible nodes, where the texture slowly turns black as it burns, and when it is completely black it starts to turn gray, until finally replacing the node with a small layer of ashes, also releasing a CO2/smoke node every so often (which looks like smoke, being somewhat transparent but gray in color), which would float up and linger around (when two CO2 nodes become stacked upside-down on a ceiling, the one closest to the ceiling moves to the side to allow the one under it to move up) - or, instead of the moving nodes method, CO2/smoke could be a fluid with "negative viscosity", which the engine handles differently by making it flow up instead of down (like this stuff from some other place) - so a source node is placed above every fire, and when the fire goes out, the source node degenerates and the "flowing smoke" clears away like flowing water when the source is removed.

It is always best to keep the combustion products from being hard-coded into the C++ part, because someone may want to modify how CO2 works or change its properties, or make different combustion product gases which behave similarly, but are produced by special materials.

Also, players should not be able to breathe in smoke, just like they can not breathe in water, but we may have to implement that differently because smoke has a density similar to air, not water, and you can technically breathe it, unlike water.

First, ya' need to remember that this good idea can become a very laggy game...
Second, if the mapgen sometimes explode my little AMD Athlon x64, i think that generating the map in those "little n' cute" blocks (or also called "mass") will make the game unplayable... If sometimes both games ("MineCraft" and Minetest) have lag due to mapgen, this becomes a pretty crazy idea for my Hardware...
Also if the map is generated by "chunks" and technically there is "mass" in every block, with different materials, maybe in one "block"... I don't know how exactly big could be this "chunks" and also it can become laggy...
But if you decide to justly choose the normal mapgen, and make every block become mass, then it couldn't be that bad...

[SegFault22]

First, ya' need to remember that this good idea can become a very laggy game...
Second, if the mapgen sometimes explode my little AMD Athlon x64, i think that generating the map in those "little n' cute" blocks (or also called "mass") will make the game unplayable... If sometimes both games ("MineCraft" and Minetest) have lag due to mapgen, this becomes a pretty crazy idea for my Hardware...
Also if the map is generated by "chunks" and technically there is "mass" in every block, with different materials, maybe in one "block"... I don't know how exactly big could be this "chunks" and also it can become laggy...
But if you decide to justly choose the normal mapgen, and make every block become mass, then it couldn't be that bad...

It is reasonable that we would not see this system implemented, or anything like it, until times when the "regular" capacity of RAM chips averages to several terabytes apiece (probably with a new serial interface), capacity of common hard drives (or their replacement) is some hundreds of terabytes, common processor speed is in the terahertz range, common number of processor cores reaches 64 or more, and common network speed is in the range of dozens of gigabytes per second. We may even need 128-bit processor architecture, to process twice as much data each cycle (of course we wouldn't need it to address more memory, because a 64-bit processor can address about 1.84*10^16 bytes (~16 exabytes).

[MineYoshi]

First, ya' need to remember that this good idea can become a very laggy game...
Second, if the mapgen sometimes explode my little AMD Athlon x64, i think that generating the map in those "little n' cute" blocks (or also called "mass") will make the game unplayable... If sometimes both games ("MineCraft" and Minetest) have lag due to mapgen, this becomes a pretty crazy idea for my Hardware...
Also if the map is generated by "chunks" and technically there is "mass" in every block, with different materials, maybe in one "block"... I don't know how exactly big could be this "chunks" and also it can become laggy...
But if you decide to justly choose the normal mapgen, and make every block become mass, then it couldn't be that bad...

It is reasonable that we would not see this system implemented, or anything like it, until times when the "regular" capacity of RAM chips averages to several terabytes apiece (probably with a new serial interface), capacity of common hard drives (or their replacement) is some hundreds of terabytes, common processor speed is in the terahertz range, common number of processor cores reaches 64 or more, and common network speed is in the range of dozens of gigabytes per second. We may even need 128-bit processor architecture, to process twice as much data each cycle (of course we wouldn't need it to address more memory, because a 64-bit processor can address about 1.84*10^16 bytes (~16 exabytes).

Ask somebody that if you can use a bit a supercomputer. Some universities sometimes have really powerful ones. Those computers are the only one who can run Windows 10 without any lag, but i guess that only will be for a day, then the 12 PM updates will make it get sick...
Or justly try the same but in a way that don't be so laggy, likely trying to divide a block in 4 pieces, and try to test that as mass. Don't start by the big, start by the little, so everything becomes easier to understand, and when you do a really powerful game you know better how everything works.

[SegFault22]

Ask somebody that if you can use a bit a supercomputer. Some universities sometimes have really powerful ones. Those computers are the only one who can run Windows 10 without any lag, but i guess that only will be for a day, then the 12 PM updates will make it get sick...
Or justly try the same but in a way that don't be so laggy, likely trying to divide a block in 4 pieces, and try to test that as mass. Don't start by the big, start by the little, so everything becomes easier to understand, and when you do a really powerful game you know better how everything works.

A sufficiently large PS3 cluster could probably make this work well, but it would still have some amount of latency from communicating between separate units. Most supercomputers are built as a cluster of several units - instead of one unit, with all of the processor cores on one chip, and having all of the RAM closely connected. It probably wouldn't lag from trying to process too much information and falling behind the processing schedule (as would a standard desktop PC) - rather it would lag somewhat from the time taken to encode/decode information at the network controllers, and send/receive it through the ethernet connections, which isn't too significant.

However, the client would have to be powerful enough to handle rendering the new type of nodes and predicting their movement/changes (placing stuff, breaking stuff, water and other fluids flowing or being absorbed by plants,...) before the information gets back from the server. Either the client and the server would both have to run on the supercomputer, or a specialized unit would be needed for the client - having some 8 graphics cards, 4 processor slots, 16 RAM chips of the highest available capacity, latest chipsets from AMD, all solid capacitors, and a power supply unit that probably wouldn't fit into a shoe box, and possibly requiring a high-current power connection such as that which is provided for clothes-drying machines.

It would be best to start with a maximum of only a few vertices per side, and limit the numbers for the quantity of a material in each volume to something like 16, until the system is perfected, then increase the maximum vertices per side to 64, and maximum quantity of a material in each volume to 1024 or so (1024 would fill the whole node, but when there's more than one volume of material present, each consists of less than that). We would still have to figure out how the shape of a volume or material is determined when more is being added, but that could depend on what the material is (makes pile-like formations if it is uncovered dirt, sand, or gravel; flows around until its surface is flat if it is water or lava; expands outwards and upwards if it is part of a tree that is growing,...) so there is still plenty to work on before it even becomes feasible to start work on such a monstrous program.

Alternatively to doing all of that work manually and creating such a monstrous system, we could go resurrect some stuff from Upvoid, of which the development was canceled a while back due to lack of sufficient funding; the developers say they may allow other developers to use their engine's code for free as long as they don't use it for commercial purposes, and it has most of the features that are desired for the kind of game I thought of - but may require some work to implement a dynamic gases system, plant growth, fluid absorption into porous materials (requiring a porosity system that can be used to set how much space within a material is not occupied by that material, and free to be filled by air or liquids and possibly already filled with air or liquids depending on where it is generated), multiplayer interface, and so on - but then it would likely be too much different from Minetest to call it a fork or even like Minetest, especially since it wouldn't be originally based on the minetest engine at all (possibly with the exception of the game menu).

Maybe we should just forget about this until it becomes viable, and find some other way to remove torches reasonably (lantern which burns fuel like a furnace to produce light but said fuel lasting much longer, maybe?) or implement a more reasonable way to produce lighting (the lantern) while keeping torches, but nerf them so that they require one whole stick apiece to make (less like minecraft), their brightness decreases over time as they reduce burning due to running out of stuff to burn, and when they are done all that is left is a "torch stub" (half of a stick) that has to be recycled with that composting mod (possibly modified so that instead of dirt, it produces some material that is more rich in nutrients - possibly persuading an overhaul of how plants grow in soil, such that they remove nutrients in order to grow, and below a certain level the node transforms into a lesser node that has the same nutrient value, but takes longer for plants to remove nutrients, until finally "dirt dust" is reached, which has no nutrient value. Plants would have a chance to "request" nutrients from the soil, said soil having a chance to remove one from its nutrient value and make the plant grow one stage, and the chance that the soil will do that depends on what kind it is - compost is best, rich dirt is slightly lower, fertile dirt is somewhat lower, dirt is significantly lower, depleted dirt is much lower, and dust dirt doesn't do anything when the plant tries to take nutrients so nothing grows in it)

Is this too much?

[azekill_DIABLO]

Add some goblins to your game. Not only will they steal torches, they'll mine out your constructions unless you watch them closely. And in some of my mods, they start fires on their own.

Stop breakin world with your goblins.

[duane]

Stop breakin world with your goblins.

Goblinz Rulz!

[MineYoshi]

Maybe we should just forget about this until it becomes viable, and find some other way to remove torches reasonably (lantern which burns fuel like a furnace to produce light but said fuel lasting much longer, maybe?) or implement a more reasonable way to produce lighting (the lantern) while keeping torches, but nerf them so that they require one whole stick apiece to make (less like minecraft), their brightness decreases over time as they reduce burning due to running out of stuff to burn, and when they are done all that is left is a "torch stub" (half of a stick) that has to be recycled with that composting mod (possibly modified so that instead of dirt, it produces some material that is more rich in nutrients - possibly persuading an overhaul of how plants grow in soil, such that they remove nutrients in order to grow, and below a certain level the node transforms into a lesser node that has the same nutrient value, but takes longer for plants to remove nutrients, until finally "dirt dust" is reached, which has no nutrient value. Plants would have a chance to "request" nutrients from the soil, said soil having a chance to remove one from its nutrient value and make the plant grow one stage, and the chance that the soil will do that depends on what kind it is - compost is best, rich dirt is slightly lower, fertile dirt is somewhat lower, dirt is significantly lower, depleted dirt is much lower, and dust dirt doesn't do anything when the plant tries to take nutrients so nothing grows in it)

Is this too much?

I think that justly a computer can do all the math, but try to emulate a "reality" is something out of the range...
That idea of the plants is good, i should admit...

[SegFault22]

I think that justly a computer can do all the math, but try to emulate a "reality" is something out of the range...
That idea of the plants is good, i should admit...

It may be possible to implement a plant growth system like that already. However, the plant node would have to check the "tier" and "nutrient level" of the soil it is planted on, before it can decide what is the chance to grow if at all.

In order to prevent nutrient "dupe" farming (where someone picks up all of their soil when it gets depleted enough but doesn't downgrade to a lower tier, and crafts it several times with some other mod to produce the same soil node with a reset nutrient value), the "tier" will be considered as having the sum of the maximum nutrient levels (or upgrade-point nutrient levels) of all previous tiers, and when it is created by crafting it has 0 "extra" nutrient level (it degrades to the previous tier of soil giving it an almost full nutrient level, as soon as something grows on it).

So "depleted dirt" or just "sand" is tier 0, has 0 nutrient value and never turns into the next tier without being crafted with something; "Dusty Dirt" is tier 1, upgrades when it gets to 16 orso nutrient value and has 0 by default when it is crafted or created by upgrading; "Dirt" is tier 2, upgrades when it gets 64 orso nutrient value, and has a defualt of 0; "Rich Dirt" is tier 3 and upgrades when it gets 256 orso nutrient value, has a default of 0; and so on.

If for example, crafting "dirt" from a "compressed dirt" storage-block gives it a full "extra" nutrient value, you could grow crops on it until it is nearly 0 nutrient value, then craft it back into a compressed dirt and back (or just dig it up, since node metadata isn't preserved into the itemstack when it is broken and turned into said itemstack), it will have full nutrient value again and the process can start again, giving the farmer an excess of crop products without consuming any total nutrient value between "cycles" of breaking/placing the dirt. So we would set it up the other way.

It may also be interesting if the chance for a crop growing every so often is determined by the "total nutrient value" of the soil node, which is the sum of the maximum/upgrade-point nutrient levels of all previous tiers plus the current "extra" nutrient level - the chance would be much lower in regular dirt, than it is in richer dirt.

Having said all of that, it may become obvious that this system alone would create a problem - the total "nutrients" available in the world is always decreasing, since food is destroyed when it is eaten (let's not bother in this department) and the only way to get nutrients would be to get it from soil that is already generated in the world. To prevent this being an issue, we can implement a system by which the farmer can produce more new nutrients to go in the soil, and a way for the nutrients to be distributed into the soil. But this will be somewhat more complicated, and requires some very skillful Lua-fu in order to implement.

Currently I am thinking that you would use stuff like crop leftover stalks/stems/leaves and any wood/tree material (or any organic matter, for that matter) in a composting system, wherein all of that stuff is gradually (and passively) processed into a "raw" nutrient material, that is then placed on or nearby soil nodes - these "nutrient blocks" start with a full nutrient value, which is slowly transferred to nearby soil nodes (that can accept it), and gets slightly slower as the nutrient value decreases - until it is 0, when the node is removed (unless it is made by mixing the finished compost with a "binder" material, in which case the binder is left behind. But the important part, where nutrients actually "come in" to the process, is some system similar to making finished compost, except it takes stone/gravel instead of organic matter, and produces lichens and moss, which are then composted as organic matter. That way, you can use all of that extra cobblestone from your mines as a source for nutrients for your farm, instead of just destroying it by whatever means or leaving it sitting around.

Again, there is that problem where the node metadata is not preserved in the itemstack which a node becomes when it is broken, so there are two possible options to prevent the nutrient dupe there: cause the nutrient nodes to crop nothing or an "empty" form when broken and their nutrient level is less than what they start with when placed, or create several node definitions for every possible nutrient level, and don't store the node's nutrient level as metadata. Both of these are not preferable, but the latter would preserve the nutrient level. It may be possible to save the metadata when the node becomes an itemstack and transfer it back when it is placed, but that may end up being hacky and could act unpredictably when you attempt to put two of the same node-item with different metadata into the same stack (since they are both the same item registry entry, they should stack together - however I'm not sure if the item metadata is checked before the stacks are combined. If item metadata is handled properly, then this is not an issue and we can make all nodes with nutrient metadata drop an item with the corresponding metadata when broken, and restore said metadata when they are placed)

We could also add minerals such as "Niter", "Lignite/Bituminous Peat" and others, as well as items like "Ashes", which can be used to "amplify" the process of converting stone to organic matter.

But, what does this have to do with removing Torches?

Well, some of the concepts from this could be used to design a "lantern" or other "burning node" which produces light and consumes fuel - you could have the lantern or whatever be given a "fuel" value, which is decremented by one every so often to keep the light going, and incremented when you input a fuel item such as coal (the increment would be related to the burn time of the fuel in a regular furnace, except the fuel would burn significantly longer in the lantern). Its GUI would consist of a single input slot and a "fire meter" like the furnace, and maybe an output slot for ashes if those are to be added as well.

This would replace torches in a sensible manner, and prevents you having to make a fire that lasts for some random time - you would be able to discern how long the lantern is lit, based on how much fuel you put in it. This could be complicated to implement in some areas, such as the conversion of fuel to the internal "burn time" value (properly handle someone putting in a whole stack of coal blocks, possibly by limiting the fuel value to some maximum number, and if the next fuel item would push the fuel value past that number, it is not consumed and added to the fuel value until there is enough "room" for the value to be at or below the limit when that happens).

It may also be a good idea to limit the maximum stack size for the fuel slot, since lanterns are small, and for balance - but this may be impossible. Again, I am not sure - if this is possible, that would be great, and so many other things would be possible by limiting a slot's maximum stack size (machine upgrade items which overclock the machines, increase energy storage or voltage/potential level - they may be quite OP or break the game, if for example the overclocker decreases the working time by half for each one and you put in a stack of 99, or if the "transformer" upgrade doubles the voltage/potential level of a power storage node and you put in a stack of 99, or the storage upgrade adds some static value to the energy storage, and you put in a stack of 99. Sure, we could just set the maximum stack size of the upgrades to 4 or something, but that would also make it difficult to carry enough upgrades for all 36 of your factory machines, which is not preferable)

[Nathan.S]

My more_fire mod makes torches burn out, and adds lanterns that need to be filled with oil. Might b something you want to look at.

[Pyros]

Both sides of this debate have good points.
Refueling torches seems... shall we say boring?
And yet infinite torches seems weird. (Especially when fire is finite)
Fireplaces seem more like a later-in-the-game sort of thing.
However, I'd cast my vote for keeping torches but making fires burn longer.

[TumeniNodes]

what about using on/off with right click function for torches?
Or right click off... and then right click with flint&steel to light them?

[jordan4ibanez]

This is a bad idea

[TenPlus1]

Would this help: viewtopic.php?f=9&t=15721

[Me Me and Me]

.... and then right click with flint&steel to light them?

I've wondered why torches are crafted with nothing that makes fire, like flint, but only with coal & sticks.

[TumeniNodes]

.... and then right click with flint&steel to light them?

I've wondered why torches are crafted with nothing that makes fire, like flint, but only with coal & sticks.

right...
or a bucket of pitch to dip them into so they light ; )

and what could you make pitch from? pine sap and coal dust... or something like that?

I wonder if anyone has made taps with a mallet to extract sap from trees like the pine and maple trees?

[ABJ]

We could just have furnaces as light sources.

[azekill_DIABLO]

no why not mese block :D the player would need to end the game to have some light. lol. furnaces. impossible.