- Jul 07, 2016
- Jul 05, 2016
-
-
paramat authored
Preserve overlapping registrations of large and small clusters below y = -64 but now extend the small clusters up to y = 0 (the previous highest iron ore level) in a similar to way to coal
-
paramat authored
Each ore's rarity is equal to that occuring below y= -1024
-
paramat authored
Re-order registrations Add and improve comments Change sand blob ymax to 0 as sand does not always rise above 0 Remove dirt blobs from sandstone as it is unsuitable for many sandstone biomes and ugly in stony sandstone desert Change ymax of first iron region to 0
-
tenplus1 authored
- Placing liquid inside a protected area no longer returns an empty bucket - Remove on_place function, tidy up code, return proper itemstack - Shorten code (changes from HybridDog/patch-35)
-
- Jul 03, 2016
-
-
tenplus1 authored
- Global functions sethome.set(name, pos) , sethome.get(name) and sethome.go(name) - Tidy: trim coords to one decimal place and write to table and output table in one go. - Add error checking - Add t4im's homepos loader
-
- Jul 01, 2016
- Jun 27, 2016
- Jun 26, 2016
- Jun 25, 2016
-
-
paramat authored
-
- Jun 22, 2016
- Jun 21, 2016
-
-
Yutao Yuan authored
Previously waterlily has misaligned top and bottom textures and looks different when viewed from below. This also hides the flower in bottom texture.
-
Auke Kok authored
Allows for more properties to be passed through. Somewhat simplifies the code as well.
-
- Jun 18, 2016
-
-
cd2 authored
This doubles the fall height without damage to 11 nodes.
-
Auke Kok authored
Allow many crafted nodes to be rotated in any way possible. These blocks all have slab and stair versions, which can create awkward patterns if placed together. By allowing these to be rotated players can create new patterns and appearances that were not before possible. Since this wasn't possible before, there won't be any effect to existing builds, as param2 should always be '0'. The current screwdriver mod also refuses to rotate and alter param2, so this is safe to enable from now on. Personally, since these are all *crafted* nodes to begin with, it should be apparent that they can be rotated to begin with, but I can see people may disagree from a simplicity perspective. It also may affect param2 usage that other mods rely on, although I'm not aware of any mods that do this.
-
- Jun 15, 2016
-
-
paramat authored
Symbols used in search caused the game to hang with a grey screen, for example searching for 'diamond;ingot'
-
paramat authored
Lowering the top surface to be level with the boat top somehow causes the boat to fall through world if underwater. Revert to previous position that is needed for correct behaviour
-
Auke Kok authored
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.
-
- Jun 05, 2016
-
-
paramat authored
-
- Jun 04, 2016
- May 30, 2016
- May 28, 2016
-
-
paramat authored
Make rotatable with 'paramtype2 = facedir'
-
Auke Kok authored
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.
-
- May 25, 2016
-
-
Auke Kok authored
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.
-
Auke Kok authored
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.
-
- May 23, 2016