Allow water to turn cobble slab and stairs to turn into mossy versions.
There is no crafting recipe for mossy stairs and mossy slabs, the
stair/slab API has been modified to allow for a recipeitem that
is `nil`, which will omit adding a crafting recipe for these two
items. The API documentation is updated.
The slabs and stairs will turn mossy when water is adjacent, just like
cobblestone. You can either farm mossy versions by placing them in
water for a while, then collecting them, or run water over your craft.
Enable ignition of tnt, gunpowder and permanent
flame above coalblock using flint and steel
Override coalblock to remove flame above when dug
Add depends.txt for default mod
Mese texture is a classic-mese-yellow version
of celeron55's texture used in MTv0.4.0
Add missing texture credits for mese crystal
and mese crystal fragment
Because the fire nodes are not removed 100% when there are
no more burnable nodes nearby, they can potentially stay around
for very, very long times, leading to ABM trains every 5 seconds
for no good reason (only 1 in 16 will be removed every interval).
A much better method to remove fire nodes is to remove them by
timer, and give removal a 100% chance if no flammable nodes are
adjacent. This makes fire cleanup a lot faster and more natural,
and will reduce the amount of ABM hits making fire overall more
responsive.
We also remove the 1 in 4 chance and fold the removal of flammable
nodes into the ABM chance.
There's some low hanging fruit cleanups in here as well.
Each sapling is given a single node timer that is between
2 and 4 days of game play time (40-80 minutes). If you walk out
of the zone, and come back later, the tree will always grow
to full if the timer has elapsed.
Because trees.lua is all functions, it needs to be parsed before
nodes.lua, since that references some of its functions. Hence,
change the order of parsing here. Otherwise saplings would not
grow to full.
This PR requires @minetest/minetest#3677
Farming and plant growth has traditionally in minetest been
implemented using ABM's. These ABM's periodically tick and cause
plants to grow. The way these ABM's work has several side effects
that can be considered harmful.
Not to mention a comprehensive list of downsides here, but ABM's
are chance-dependent. That results in the chance that some nodes
potentially never get processed by the ABM action, and others get
processed always. One can easily find this effect by planting a large
field of crops, and seeing that some nodes are fully grown really
fast, and some just won't make it to fully grown status even after
hours or play time.
One could solve the problem by making the ABM's slower, and giving them
a 100% of action, but this would cause the entire field to grow a step
instantly at ABM intervals, and is both ugly, and a large number of
node updates that needs to be sent out to each client. Very un-ideal.
With NodeTimers though, each node will see a separate node timer event,
and they will likely not coalesce. This means that we can stop relying
on chance to distribute plant growth, and assign a single timer event
to grow the plant to the next phase. Due to the timer implementation,
we won't ever miss a growth event, and we can re-scehdule them until
the plant has reached full size.
Previously, plants would attempt to grow every 9 seconds, with a
chance of 1/20. This means typically, a plant would need 9*20 seconds
to grow 1 phase, and since there are 8 steps, a typical plant growth
would require 9*20*8 ABM node events. (spread out over 9*8 ABM actual
underlying events per block, roughly).
because plants are likely not growing to full for a very long time
due to statistics working against it (5% of the crops take 20x longer
than the median to grow to full, we'd be seeing ABMs fire possibly
up to 9*20*8*20 with a 95% confidence interval (the actual math
is likely off, but the scale should be correct). That's incredibly
wasteful. We'd reach those conditions easily with 20 plant nodes.
Now, after we convert to NodeTimers, each plant node will see exactly
8 NodeTimer events, and no more. This scales lineairly per plant.
I've tuned the growth rate of crops to be mature in just under 3
whole days. That's about 1hr of game time. Previously, about half
the crops would grow to full in under 2 days, but many plants would
still not be mature by the end of day 3. This is more consistent.
An additional problem in the farming mod was that the final fully-grown
plant was also included in the ABM, causing infinite more ABM's even
after the entire field had grown to completion.
Now, we're left with the problem that none of the pre-existing plants
have actual node timers started on them, and we do not want a new ABM
to fix this issue, since that would be wasteful. Fortunately, there
is now an LBM concept, and we can use it to assure that NodeTimers
on crop nodes are properly started, and only have to do the actual
conversion once per block, ever.
We want to provide a fairly similar growth rate after this conversion
and as such I've resorted to modelling some statistical data. For this
I created a virtual 32x32 crop field with 9 steps (8 transitions)
as is the default wheat crop. We then apply a step where 1 in 20
plants in the field grows a step (randomly chosen) and count the
number of steps needed to get to 25%, 50, 75% and 95% grown.
The resulting data looks as follows:
25% - ~120 steps * 9 sec / abm = 1080s
50% - ~152 steps = 1368s
75% - ~194 steps = 1746s
95% - ~255 steps = 2295s
Next, we want to create a model where the chance that a crop grows
is 100% every node timer. Since there will only be 8 steps ever,
we want the slowest crops to grow in intervals of ~ 2300 / 8 seconds
and the fastest 1/4 of crops to grow 1080 / 8 seconds intervals.
We can roughly compare this to a normal distribution with a median
of 1400 with a stddev of ~350 (thick fingering this one here).
The rest is a bit of thick-fingering to get similar growth rates,
taking into account that ABM's fire regularly so if they're missed
it's fairly painless, but our timers are going to be 1-2 minutes
apart at minimum. I calculate the timer should be around 150s
median, and experimented with several jitter ranges.
Eventually I settled for now on [80,200] with a redo of [40,80],
meaning that each growth step at minimum takes (80 to 200) seconds,
and if a negative growth condition was found (darkness, soil not
wet, etc), then the growth step is retried every (40 to 80) seconds.
The end result is a growth period from seed to full in ~ 2.25
minetest days. This is a little bit shorter than the current
growth rate but the chances you'll miss timer ticks is a bit
larger, so in normal gameplay it should be fairly comparable.
A side effect is that fields grow to full yield fairly quickly
after crops make it to mature growth, and no crops are mature
a very long time before the majority grows to full. The spread
and view over a growing field is also fairly even, there's no
large updates with plenty of nodes. Just a node here or there
every second or so in large fields.
Ultimately, we get rid of ABM rollercoasters that cause tens of
node updates every 9 seconds. This will help multiplayer servers
likely a lot.
Standing on a boat makes you appear to "hover" over it since this
collision box is way too high. Lower it so that it's low enough
to look normal when walking on top of a boat
Removed unnecessary inventory textures
The drinking glass inventory texture now differs from
the node texture to be more clearly a drinking glass
Smaller textures to reduce size as nodes
This pull adds a new global variable called creative.formspec_add
that will allow mods to add to the creative inventory screen
without the need to fork the mod altogether. Simple solution
that works already for inventory_plus' BACK button
This uses a vmanip to count adjacent tnt nodes and explodes them
all at once, using an inverse square law to recalculate the radius.
The maximum explosion becomes 125 nodes of tnt yielding a radius of
15 nodes, which does not break my machine and makes it return
in under a second.
This makes both bigger explosions and less stability issues.
The drop code has been simplified and now drops at all times a
reasonable amount of drops, never blanketing the area with drops,
even at the larges explosion level.
Particles are scaled up according to explosion size as well - a
bigger explosion will show bigger particles.
To scale the tnt:boom particle, we move it to the _effects() function.
Introduces an `on_blast(luaobj, damage)` callback that mods can attach
to an entity def. The function will get called with the damage that
TNT would make.
The function should return three values:
bool do_damage, bool do_knockback, table drops
do_damage allows the mod to tell the TNT code to perform damage on
the entity for the mod. The mod code should not do anything with
the entity HP. The entity should not be immortal. If false, then
the entity will not be damaged by the TNT mod.
do_knockback allows the mod to tell the TNT mod to perform an
entity knockback effect. If false, no knockback effect is applied
to the entity.
the drops table is a list of items to drop. It may be nil. E.g. {
"wool:red" }.
I've documented both on_blast() API methods in game_api.txt. It is
a better place than lua_api.txt.
Any second explosion near a first TNT explosion will punch all
entities found nearby, including item drops. This causes the
item pickup code to think the item was picked up, but by
a `nil` player, thus removing the item.
We query for the immortal entity group, and if the item is in
the immortal group, do not punch the item.
We reuse the tnt:boom texture for a particle that is added by the
on_construct() of tnt:boom, and has a short expiry time (0.2sec).
It is 3 nodes larged, centered on the explosion.
We then make tnt:boom airlike so it doesn't have a texture, and it's
the thing that emits lots of light (we could even make it exist a
bit longer).
The nice thing about particles is that the client is less susceptible
to lag and will always remove them as fast as possible, so this makes
the visual more constant and responsive.
The effect is similar, and the reduction in particles is a small
boost in responsiveness.
To compensate, I've lowered the spawner time and expiration length
as well.
We add a +/- 0.5 random value to the velocity vector of
ejecting nodes.
I've spotted a lot of nodes going exactly straight up if blowing
up sand above TNT. The extra variation looks less artificial.
We apply punch damage to mobs caught in the blast radius, as
this code previously only hurt players.
We "move" players back 1 node if they're caught in the blast, and
slightly up. We can't "eject" players due to missing API code to
support that, unfortunately.
Adds a minor helper function that allows efficient retrieval of
several inventories from a node inventory. We use this helper to
quickly retrieve the items in chests, vessel shelves, book shelves
and furnaces, and return these with the nodes itself to the TNT caller.
The TNT caller then performs the entity physics, and we don't need
to do anything else.
We disable TNT doing anything with bones.
We expose a bug in the code that drops the items - metadata was lost
entirely. This patch corrects that by properly copying the metadata
and creating the drops list inclusive metadata.
This changes how dirt blocks turn to dirt_with -grass, -dry_grass
or -snow.
Previously, dirt that was sunlit would turn to dirt_with_grass no
matter what, but this happened without any context, so you could
get green patches of dirt_with_grass in the middle of a savannah or
even desert.
Dirt no longer turns to covered dirt unless it's within 1 node from
another dirt_with_grass or dirt_with_dry_grass or dirt_with_snow.
This makes dirt_with_grass "growback" a lot slower, since it now only
happens on the edges, but it retains the context nicely now.
If there is any dirt with a grass or dry grass plant, or snow on top,
and enough light, we'll convert it sporadically to dirt_with_grass
or dirt_with_dry_grass or dirt_with_snow.
This allows us to plant grass of our choice in a large dirt patch,
or in a region where otherwise that type of grass is not present.
This used to be done by 2 abms, but I've combined them in to a single
ABM that is ordered to run with maximum efficiency, solving for the
most common outcome first before attempting more complex checks.
