Minetest_game: Stone hoes are as efficient as diamond hoes

[HybridDog]

Currently the only difference in efficiency between the hoes are their amount of uses, please correct me if l'm wrong.
So players use the stone hoes because they're the cheapest ones and the lower amount of uses is negligible.
The other hoes are only used in creative mode or by players who don't know the difference between them yet, aren't they?

The soil could get different quality, it either
is more fine or it
was dug to a controlled depth (if compost is beneath the soil, one shouldn't dig too deep).

The second one doesn't make much sense in minetest, so it's enough to store the fineness.
Imagine every time a hoe is used, it halves the amount of big dirt chunks:
n: amount of uses, f: fineness, sv: start value (of fineness)
f(n) = sv * 0.5^n
= sv * exp(ln(0.5)*n) = sv * exp(-ln(2)*n)
Since it doesn't halve it but third or whatsoever, each tool can get a value fining_strength > 0
f(n) = sv * exp(-fining_strength * n)

The fineness of soil can be stored as 16 bit float in param1 and param2 because they aren't used currently, correct me if l'm wrong.
The bigger the value is, the more the soil is gritty.
Hoes can of course be used more times on a soil node to make it more fine (but it works worse and worse until the change is so small that due to 16 bit limit nothing happens)
Plants can get thresholds to make their grow speed individually depend on the fineness.
And the fineness is denoted as tilling.

Another solution:

A hoe_use_interval could be added, if the player uses a hoe, they needs to wait until they has gathered enough strength to plough again.

[paramat]

A hoe_use_interval could be added, if the player uses a hoe, they needs to wait until they has gathered enough strength to plough again

:-1: Makes no sense.

I feel durability is enough justification for multiple-material hoes.

[MarkuBu]

Would makes more sense if there is a difference in grow time and/or harvest amount. But this would be difficult to implement

[Wuzzy2]

Tools already have full_punch_interval. Just out of curiosity, would it be possible for tools to detect whether a tool is used when this time is over or not?
Like, if you punch with the tool before the full_punch_inteval is over, the tool acts differently or does nothing at all.

[MarkuBu]

A diamond picaxe is faster than a stone picaxe. Why not make a diamond hoe faster than a stone hoe?

[paramat]

Would makes more sense if there is a difference in grow time and/or harvest amount.

That would make no sense.

I don't think it can be faster as it is simply acting on a node.
Originally we had no hoes made from precious materials, but these were added for consistency.
Durability is enough difference, going further with this is a little ridiculous.

[MarkuBu]

That would make no sense.

Would totally makes sense. Better quality tools make better soil, where crops can grow better/faster.

Each other tool differs in two things. Durability and action. Except the hoe. Diamond sword makes more damage than a stone sword, diamond picaxe is faster than stone picaxe (plus can dig more nodes)

I know that this would make a little bit more work, but I will make a suggestion. We could define 3 types of farming soil with different quality. Wood and stone hoe produces low quality soil, iron and bronze produces normal soil and mese and diamond produces high quality soil.

they can differ in grow time and/or crop yield. For example on low quality soil you can only harvest one wheat, on normal soil you can harvest one or two, on high quality soil you can harvest always two wheat

Edit: there are actually three differences. Swords differ in durability, attack speed and damage, picaxes differ in durability, speed and diggable nodes.

[paramat]

Better quality tools make better soil

Sorry yes that's reasonable. Implementing faster grow times or higher yield is i feel too complex though.

[MarkuBu]

Maybe an idea for farming redo, @tenplus1 ?

[Ferk]

I don't think it would be too complex to check the soil metadata in farming.grow_plant. But I'm not sure if it's worth it to do the additional get_meta for each plant.

I think it would be more interesting instead if there were special plants growing in soils that only high tier hoes can produce (say.. sand soil, gravel soil, etc). But better in a mod since MTG doesn't have that much use for plants other than decoration or bread anyway.

[MarkuBu]

@Ferk that would be an additional use of better soil, but I aggree that it wouldn't make sense in MTG with two crops

[Ferk]

@MarkuBu the thing is that different soil nodes for different plants to grow wouldn't require any metadata check and it would be straightforward to implement. It doesn't require any change to farming.

Soil that makes plants grow faster would require the get_meta so it won't work in the farming mod for MTG. In that case you would really need some other farming mod to collaborate and it would only be compatible with the plants using that mod.

[DonBatman]

@HybridDog - I like the idea! I would call it till or tilling instead of fineness though. If this can be done without breaking mods it would make farming much better. Plants could grow faster on better tilled dirt or give more on harvest. A lot could be done.

[C1ffisme]

@paramat

I feel durability is enough justification for multiple-material hoes.

Not really. Nobody ever builds a diamond hoe or even a steel hoe, since stone works at the same pace and is far cheaper. Even one stone hoe lasts long enough for you to build a farm to supply your own food needs. (And since food isn't really needed unless you take damage, technically you don't even need a hoe at all. Even if you do take damage, dying isn't that consequential unless you live about a mile from your spawnpoint.)

I'm against making hoes slower, though. Farming is a non-essential in this game, and making it tiresome to do is just going to make people not want to do it.

[DonBatman]

@C1ffisme - I agree that farming is non-essential accept for when you add mods. Minetest is made for mods. When you have the hunger mod and mobs_redo then food is very important. This is why having the hoes have better progression is a good idea imho.

[paramat]

Thus is why we had no fancy hoes for a long time, they had no advantage.

[HybridDog]

Okay i'm not so opposed to the concept but am concerned about complexity, please keep this simple.

float numbers are simple, param1 and param2 can be used:

-- hidden number, 10 bit significand, 6 bit exponent, both unsigned
function tofloat(z)
    assert(0 < z and z <= 1, "[farming] tofloat: " .. z .. " ∉ ]0; 1]")

    if z == 1 then
        -- calculating this every time is not requisite
        return 128, 0
    end

    local e = math.floor(math.log(z) / math.log(2)) + 1
    local m = math.floor(z * 2^(10 - e))
    local mtop = math.floor(m * 0.25)
    return mtop, m * 64 - mtop * 256 + math.min(1 - e, 63)
end

function fromfloat(param1, param2)
    if param1 == 128
    and param2 == 0 then
        -- see above
        return 1
    end

    local mbot = math.floor(param2 * 2^-6)
    return (param1 * 4 + mbot) * 2^(mbot * 64 - 9 - param2)
end

[paramat]

Your suggestion is not simple, i was thinking use param2 values of 1 to 6 corresponding to the hoe material used, then adjust grow time on that. The ideas in this thread are getting disproportionately complex.

[HybridDog]

Your suggestion is not simple, i was thinking use param2 values of 1 to 6 corresponding to the hoe material used

it just looks messy because you can't use shift operators in lua,
values of 1 to 6 corresponding to the hoe material used don't make sense because you can make the soil more fine if you use some hoe more times

[MarkuBu]

You can use shift since Lua 5.3. Sadly LuaJIT is still 5.1

And making the soil finer by using the soil several times makes sense in real life, but I think it is too much reality in a game.

As I suggested 3 would be enough, but paramats idea is OK as well

[HybridDog]

And making the soil finer by using the soil several times makes sense in real life, but I think it is too much reality in a game.

You could watch people playing cookie clicker on soil.
In my experience you feel kind of embarrassed and accountable when you are aware that people perform such actions because you wrote the code to make them do so.

[MarkuBu]

But the diamond hoe looses a lot of it's advantage. You can get the same result with a stone hoe, it just takes longer and may need (a lot) more hoes.

The idea of this issue is to create a need to craft better hoes. So as I understand your suggestion you can get the same result with any hoe, it just takes longer. If the difference is to small no one will make diamond hoes. And to large differences will be ridiculous. I know that there are ppl out there who will punch the hell out of each node with a wooden hoe just to get the best soil

Not to mention how you want to make a floating point value visible for the player how good his soil is. I still go with 3 different soil levels. There you can make distinguishable textures

[paramat]

We can't start supporting multiple uses of hoes, players just want to use a hoe once and that's how it currently works. This is overkill.

[HybridDog]

And to large differences will be ridiculous.

It makes a difference if you use some stick you found in the forest instead of a proper steel tool.

players just want to use a hoe once and that's how it currently works.

The hoe only needs to be used once, but if you hoe more times, the dirt becomes less gritty and the plants grow faster. If you have big fields you usually don't care how fast your plants (actually only seeds) grow because it takes time to farm the grown ones and full grown plants don't get better in time.

Edit: l hope l'm not blocking something…

[Ferk]

float numbers are simple

Not really. I don't think using a float is justified, you don't need dynamic precision for something like this.

[numberZero]

@HybridDog there is no space for a float: param1 is used for light level, so only 8-bit param2 is free.

I’m for several (3) soil levels as different node types. They don’t need to affect anything in the base game but should be available to mods (just as gold has little use in MTG but not in mods) so that different plants may have different requirements. Or you can make standard plants have different grow speed depending on soil level, if that’s not too complex (note that no metadata is needed).

Moreover, high-tier hoes may be usable on something other than dirt, as @Ferk suggested. But that’s nice for mods, MTG seems to have no use for that.

And one additional notice: IRL soil is not reusable, you need to till it each year AFAIK. Add that to MT (e.g. using plant’s on_dig) and you will get more use for a good hoe) (that can still be automated with pipeworks and mesecons)

P.S. Really I would prefer hoes to work similar to other manual tools, but that requires major client change.

[HybridDog]

As far as l know the soil node is not paramtype "light", the light bank is calculated and stored separately in memory.

[paramat]

Yeah, but param2 is the one to use as it's the one used for special purposes.

[Wuzzy2]

Can this issue be closed? It seems unlikely anyone will implement this, also many don't want the proposed changes in the first place.

[paramat]

:-1: The idea is reasonable for ultra-realism but i prefer to keep things simple and just have the difference being number of uses. Taking into account the quality of the blade on soil quality is i feel overly-anal attention to detail that doesn't belong in MT. I'm opposed. I'd rather use param2 for soil furrow rotation.

[HybridDog]

The topic is the uselessness of high quality hoes. The proposed changes are just an example of a way to fix the problem.

[MarkuBu]

I would propose to change the number of uses. Reduce uses for wood and stone dramatically and increase the diamond hoe, so stone becomes unattractive.

Another idea is to remove the drop of seeds when harvest grass by hand. You need to use a hoe instead which seems legit. And the better the tool the higher the drop chance

[paramat]

So players use the stone hoes because they're the cheapest ones and the lower amount of uses is negligible.

Yes there can be more difference in uses, anyone want to make a PR? This is the obvious simple solution.

[paramat]

Bump, more uses PR anyone? Very easy so i'm not going to do it.

[C1ffisme]

@paramat I don't think more uses is an advantage when it comes to hoes. Unless you have a mod that requires tons and tons of a certain crop, most of the time you'll usually only plant a small farm that won't even break a stone hoe. (You might not even break a wooden hoe if all you plant is cotton. So maybe this situation can be improved by adding hunger?)

[HybridDog]

You could make certain plants require certain soil flags. You can store 8 bit in param2, so you could make each tool change different flags (e.g. wood: 1, stone: 2, steel: 1,2,3, diamond: 3,4) and seed placing require specific flags (e.g. wheat seed: 2,3, cotton seed: 1). It's a simple solution and gives hoes individual benefits.

[paramat]

Makes no sense, a hoe is a hoe independent of material, it's also still over-complex, and we are thinking of making soil facedir so the furrows can be rotated on create.
The uses idea is suggested because it's simple and so acceptable, we could reduce the uses of non-diamond hoes instead.

[numberZero]

Why can’t just hoes work like other tools? That is, requiring some time to use, depending on the level. I understand that it is implemented in a different way, but guys, we even have CSM now, why can’t we make such little change? That does worth implementing, not only for hoes but for all non-standard tools, like a drill or a crystal shovel.

[HybridDog]

requiring some time to use

numberZero, you could easily save the time when using a hoe in the item metadata.

[numberZero]

@HybridDog that’s terrible. You must see you hoe, just like you see you mine. A hidden delay may only make you angry.

[paramat]

Hoeing time dependent on level could be good.

[HybridDog]

@numberZero l agree, there were changes recently which allow colourizing the inventory item, so maybe it's possible to darken the item until it's useable again.

[numberZero]

What a dirty hack... And still unreliable.

So, as I said, its work should look as of a native tool like a pick,
an axe, etc. If core change is needed for that, let it be so, just
describe the API it should support; that should not be too hard
to implement. Just remember that hoes aren’t the only tools that may
need that; there are drills, lasers, crystal shovel, etc. And food =)

On Sun, Apr 30, 2017 at 02:05:34AM -0700, you wrote:

@numberZero l agree, there were changes recently which allow colourizing the inventory item, so maybe it's possible to darken the item until it's useable again.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest_game/issues/1252#issuecomment-298220588

[HybridDog]

If core change is needed for that, let it be so

You could add a removal_prediction field to tools. Then you can make it behave like digging the dirt with other tools.

[Ferk]

The problem here is that currently there are 3 completely incompatible ways to handle the behavior of an item when it's being swung.. and 2 of them are hardcoded:

• digging: hardcoded (though parametrized) behavior in the engine, triggered when a node is hit.
• damaging: hardcoded (though parametrized) behavior in the engine, triggered when an entity is hit.
• using: lua-defined behavior, triggered whenever there's an on_use callback in the tool, overriding both the 2 above behaviors.

This means any item that adds an "on_use" becomes incompatible with being used as a weapon or as a digging tool. And the behaviors that are special for digging/damaging (eg: holding the mouse on the item or the weakening cooldown of weapons when damaging, together with the cooldown animation), are unusable from Lua.

Imho, both damaging and digging are just particular cases for using a tool. So I think on_use should not make it impossible to dig/damage, instead it should just customize the way and manner of the action. This would make possible special tools and weapons with special actions that actually feel like tools and weapons when swung.

The on_use currently returns the Itemstack object. Since Lua can return multiple values, there could be a second return value that, if present, would indicate that dig/damage should take place, and maybe provide some options dynamically.

EDIT: Ok.. sorry, I just noticed that the after_use callback might as well be used to replace on_use for tools that are not to override digging, even though it doesn't apply for damaging (I think there's an issue already open for that, though) nor is it dynamic (yet that makes it more lag-friendly).
This means that after_use would already make this work, though a removal_prediction would make it look better, like HybridDog suggested.

[numberZero]

It can’t be just a return value. The network delay is unavoidable, so it would lag this way. Not to say that some servers are, er, “a bit laggy.” So, some client-side code is needed as well.

Nevertheless, server-side code is often necessary too for overall reliability and to prevent cheating.

On Mon, May 01, 2017 at 02:53:57AM -0700, Fernando Carmona Varo wrote:

The problem here is that currently, there are 3 completelly separate ways to handle the behavior of an item when it's being swong:

• digging: hardcoded (though parametrized) behavior in the engine, triggered when a node is hit.
• damaging: hardcoded (though parametrized) behavior in the engine, triggered when am entity is hit.
• use: lua-defined behavior, triggered whenever there's an on_use callback in the tool, overriding both the 2 above behaviors.

This means any item that adds an "on_use" becomes incompatible with being used as a weapon or as a digging tool. And the behaviors that are special for digging/damaging (eg: holding the mouse on the item or the weakening cooldown of weapons when damaging, together with the cooldown animation), are unusable from Lua.

Imho, there should be a generalized way to handle this. I think it would be good if, for example, the return value of on_use could determine whether a damaging or a digging effect should take place, and let the on_use provide the parameters grammatically, instead of using fixed values from the definition that cannot be made dynamic from a mod.

This would open the possibility for custom digging tools, custom weapons, etc. that actually do something special and not just another variation in damage/speed.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/minetest/minetest_game/issues/1252#issuecomment-298313077

[paramat]

I suggest someone makes the number of uses of hoes rise faster with material, to make the valuable ones more attractive to use, this is the simple solution to this.

[InfiniteOtter]

I would love it if a hoe would also harvest. If the hoe automatically harvested ripe crops of the same type that adjoin, then there would be an advantage to diamond. One swing, nine grain harvested. Much better than the wood hoe that only harvests one grain at a time.

[paramat]

I think the problem here is actually the mistake of adding 6 tiers of tools for a non-primary tool, which has long been seen as ridiculous. I suggest we can solve this stated issue and simplify by removing bronze, mese and diamond hoes. I can imagine some rare situations where stone may not be easily available so i would consider wood, stone and steel to be a good minimum.

We can deprecate a tool by only removing its recipe, tools in existence will get used up, then we can remove the entire code in a future release.
The number of uses of these 3 tiers could be tuned.

These are only hoes and don't justify large amounts of dev time, we should be simplifying and the complex ideas above are not justified. Let's not make another mistake of making hoes even more complex, they need to be simplified.

[paramat]

PR #2103

[paramat]

2103 merged.