[Mod] Farming Redo [1.23] [farming]

[TenPlus1]

Thanks jp, lemmie check out the code and textures and will get back to you :)

[jp]

PM incoming in your inbox for the code & textures...

[Inocudom]

TenPlus1,

I submitted a new pumpkin model for farming_plus (the PilzAdam's one), but unfortunately it was rejected. I don't know what can I do with it, and I don't want to post a new fork just for a new pumpkin.

So, if you like it, I can give it to you for your mod...

VanessaE doesn't like it either?

[TenPlus1]

Thanks ruberwardy...

update: jack o lantern can now be turned on/off... also, jp's round jack o lantern is on Xanadu server...

[HeroOfTheWinds]

Something I came across while adapting the latest version for use with SkyTest...

This mod has no support for flat maps. Many of the plants only grow above a certain height, so on a flat map (however pointless that can be) there are many missing plants. I don't know if it pays to fix it, but I just thought I should report it anyway. :)

[TenPlus1]

HeroOfTheWinds: the mapgen.lua has limits within to make certain plants grow at specific heights like in real life but are easily removed...

[GingerHunter797]

Another amazing mod! Thanks! :D

[mgl]

I wanted to add the food from the new blueberry plant to BlockMen's Better Hud mod but noticed that some of the already existing hunger values don't match between Farming Redo and Hud. Bread and carrot at least. So I'm asking for them instead (from the "hunger.lua" file of Hud on Xanadu for example).

I also noticed that most of the food from Mobs Redo doesn't exist on Hud either. Once again, Xanadu's "hunger.lua" could help.

[TenPlus1]

on farming redo and mobs redo forum threads you will find the hunger.lua values for all items within the mods...

[mgl]

on farming redo and mobs redo forum threads you will find the hunger.lua values for all items within the mods...

I read some, but I thought they were outdated and confusing. Your bread is worth 4 hearts without Hud but 6 food with. The carrots 3 and 4...

[TenPlus1]

Remember food goes up to 15 points (5 hidden) so I take that into account, easily changed though to make it same...

[mintpick]

Hello there. I enjoyed playing around with your mods. Dropped here for a quick bugreport: player can eat meals even with full health points.

[TenPlus1]

mintpick: sadly that's a bug with the minetest engine itself, although if you use the Better HUD mod which adds hunger to the game, it will not let you eat when you are full :)

viewtopic.php?id=6342

[mintpick]

mintpick: sadly that's a bug with the minetest engine itself, although if you use the Better HUD mod which adds hunger to the game, it will not let you eat when you are full :)

viewtopic.php?id=6342

Good, thank you for pointer.

[freakedenough]

is it possible to combine farming_redo with ethereal for natural spawning?

[TenPlus1]

Ethereal mod is already compatible with Farming Redo and will spawn new plants into newly generated areas of map...

[prestidigitator]

Submitted a pull request for enhancing plant growth to occur even when the map block is unloaded and ABMs aren't running. This works by marking the last time an update was evaluated in the node's metadata, and using a statistical model (Poisson distribution) and day/night light levels to determine how many stages to grow the plant since the last ABM execution.

Should be good for single-player and for large servers where players have to house themselves in remote corners and nobody is around most of the time. They won't have to sit around watching the plants grow, and can either log out (so long as the server is still running; uses game time not wallclock time) or be off doing other interesting things like mining and exploring.

[Kilarin]

This works by marking the last time an update was evaluated in the node's metadata, and using a statistical model (Poisson distribution) and day/night light levels to determine how many stages to grow the plant since the last ABM execution.

Oooo! I've been thinking about doing something like this. I really hope it gets pulled!

[TenPlus1]

Prestidigitator, thank you so much for the routine to grow plants while the player is out and about doing other things, normally it would be a great idea and I'd include it in farming redo but I have a few problems that bother me... First is that players farming indoors or underground wouldn't have their plants grow until it's daylight outside, and secondly it seems to lag my test server quite a bit when you have a decent sized farm (and times that by how many players are on the server)... So a big thank you for coding this feature but I will not be including it YET until it's viable for most players and servers...

[prestidigitator]

...players farming indoors or underground wouldn't have their plants grow until it's daylight outside...

Not quite true. What the logic does is test:

1. Whether there is a day and night cycle at all (whether or not time is frozen by setting time_speed to 0). If there isn't, it just uses the current light level as returned by minetest.get_node_light(pos) and, if this falls in the min, max light range, the total elapsed time since the last run.
2. The light level at midnight as reported by minetest.get_node_light(pos, 0) and at noon as reported by minetest.get_node_light(0.5). These DO factor in the light generated by other nodes (e.g. torches and stuff), and then add the light the sun would contribute at those times (if any). I tested this pretty thoroughly using the luacmd mod.
3. Whether the nighttime (midnight) light falls within the min, max range given, and whether the daytime (noon) light does. If both fall within the given limits, it just uses the straight elapsed time. If neither do, there's no growth at all. If one or the other does, it calculates the amount of night or day that has elapsed since the last run, as appropriate.

The only difference between that and true dynamic lighting measured by minetest.get_node_light(pos) every time an ABM runs is in the last hour or so before sunup and the first hour or so after sundown. Otherwise it's the same, whether or not you are in a cave or exposed to the sky or have torches or whatever.

it seems to lag my test server quite a bit when you have a decent sized farm (and times that by how many players are on the server)...

Hmm. Okay. I'll do a bit of performance testing and see about optimizing and enhancing a bit. It might work just to decrease the frequency of the ABM some more, since truly it doesn't matter how much it runs (except that plant nodes will only actually be replaced when it does run).

[prestidigitator]

Okay, so I found a defect, which accessed a nil value and potentially even caused crashes. It's now been fixed.

I also added profiling code. All you have to do is uncomment one line of code and it will periodically report timing statistics for the ABM (every 400 runs or the run that occurs at least 100 seconds after the previous report). I also tested by using this same profiling logic in the existing ABM logic on the master branch.

I used this in a 16x16 (256 node) field of wheat under various conditions (the whole lifecycle during daylight, night time with just planted, partly grown, and mostly grown plants, and daytime after leaving and returning back to the area after a long enough time to cause full or almost full growth). The results I got were interesting. The new (poisson-based) code is pretty steady under almost all conditions (average 23µs per ABM, with a standard deviation of 3µs). The standard code is indeed faster (average 10µs, with a standard deviation of 1.6µs) at night, under all nighttime conditions. During the day, throughout the normal growth cycle of the plants, the standard code is about the same (average 26µs with a standard deviation of 9µs) as the poisson-based code.

The interesting case is when returning to an unloaded region of the map. At that point the new poisson-based code slows down a bit (average 40µs with a standard deviation of 11µs) as it catches up, but then it basically quits since all the plants have matured to where they don't run ABMs anymore. So it might cause a little lag generated as players enter regions that have a lot of plants that were growing and are now mature, and then it'll cause less lag than the existing ABM (since the existing one will still be running to mature the plants).

In all, it seems my original guess of running the ABM on 2/3 as many nodes seems (coincidentally) about right. It'll be reasonably close at night, actually save time during the day, and only produce a small slowdown for a brief moment when visiting a region that had a lot of pending growth. I also believe I can optimize the calculation of the poisson distribution for exactly that condition of many pending updates, since when lambda is large (say, greater than 2) it's probably reasonable to round it to the nearest 0.5 or 1. That should lend itself nicely to a table-based lookup. I'll give that a try and see how much it helps the slow case.

EDIT: Wanted to add that I'm NOT running a build with LuaJIT enabled, but I suspect that LuaJIT would make the poisson calculation faster, if anything....

[prestidigitator]

So I find this interesting. I optimized the heck out of the Poisson distribution calculation, and found that it didn't really change anything in terms of how stable the ABM execution time was. What's more, the circumstances under which it was taking a long time didn't quite make sense either (e.g. it often took longer the more mature the plants were, and calculation of the Poisson distribution should take LESS time in that case since the maximum number of potential growth stages is less).

So I did some more detailed profiling, and it looks like it is the time it takes to access a node's metadata that can vary like crazy. For example, the ABM execution time can go from 20µs to 45µs while the Poisson calculation stays under 2µs and the entire growth stages calculation remains under 5µs. That's pretty bad news for using metadata in ABMs in general, unfortunately, so I guess it had better only be done for nodes that are relatively rare (since I find it unlikely the engine will be optimized in this regard). I'm pondering a better in-memory caching approach that might, for example, use metadata ONCE to allow elapsed-time updates to a whole area (e.g. a 80x80x80 map block).

[TenPlus1]

That's something I found also, reading metadata and overall object information can slow down mods quite substancially, even checking if an available mod is installed causes slowdown... I try to cater for this when optimizing all of my mods...

[prestidigitator]

So I've done some research and experimentation, and I think plant growth might actually be much better handled by node timers than ABMs! This might still require some simple analysis of how much day/night has passed, but it actually means you could just pick a random lifespan (or length of growth stage) and then calculate the number of stages very easily based on the number of timer periods that have elapsed, and grow plants at exactly the right times! This is even persisted automatically when the map block is stored, and even large numbers of timers are handled quite efficiently in the C++ engine code. It also means no slow or clumsy metadata fields; the engine deals with timer values "natively." Forget the Poisson distribution; I'm thinking a normal distribution (bell curve) for lifespan, calculated when the node is first created, and then a simple timer! (EDIT: Actually, I may have to take that back slightly for the very stupid reason that there seems to be no access to the actual timeout value from a timer callback; ONLY the elapsed time! Need an engine pull request for that one, I think; it's about a 5-line change, not counting documentation.)

The only downside is that a timer might have to be added to the node definition(s), rather than just a group. Can possibly do this automatically with an override though. (In fact, a rare ABM might still be useful just to make absolutely sure that "growing" node types are properly detected.)

[prestidigitator]

Well, I'm coming to the conclusion that it's just impossible to profile things in Minetest. I'm actually computing less in the timer than was being done in the ABM (e.g. using a table to cache stages instead of parsing the node name each time), and it's 50% slower (the actual code being executed within the callback, that is). Every once in a while the amount of time just soars through the roof and doesn't come down again, even with an incredibly consistent test scenario. I'll think I've optimized enough because I'll get a streak of good times, but then suddenly it'll just crawl again and not recover.

Short story: timers behave exactly like metadata access did, though that makes absolutely no sense. Maybe the best option is just to provide a simple boolean configuration option, which uses the simple behavior by default. If a little more execution time every now and then is acceptable for a given server, it might be worth the extra functionality. If a server is already dragging its feet, it might not be worth it.

[Kilarin]

Possible suggestion:
Getting a nodes meta data is slow. SO, when you enter a new region, all of the nodes grabbing meta data at once creates lag.
WHAT IF, each time the ABM runs, it checks random number, and if that number is, say, 1 in 5 (or whatever works out in testing) THEN it grabs the meta data to see if its been out for a long time and updates for missing growth. If not, updates the last time field in the meta data.

That way, when the player walks into a new area, you wont' have every single plant pulling meta data at once, but, after a few minutes, they should have all discovered that they are overdue and updated their growth?

[Nubm]

I'd love to see a mod pack of farming and mobs redo with a diffculty setting. :p
IMO the plants give so much food, they should grow much slower. My small fields support me forever and an army of pets as well. Great mod nonetheless!

Btw, what did you use for the signs in the image? Are they just textures or is it a mod to put in items (i think MC has those)?

[prestidigitator]

Possible suggestion:
Getting a nodes meta data is slow. SO, when you enter a new region, all of the nodes grabbing meta data at once creates lag.
WHAT IF, each time the ABM runs, it checks random number, and if that number is, say, 1 in 5 (or whatever works out in testing) THEN it grabs the meta data to see if its been out for a long time and updates for missing growth. If not, updates the last time field in the meta data.

That way, when the player walks into a new area, you wont' have every single plant pulling meta data at once, but, after a few minutes, they should have all discovered that they are overdue and updated their growth?

Well, that's just it. I'm not using metadata anymore. I'm using node timers, which tell us how much time has elapsed since the time they were set (or last executed if repeated). And the logic they run is very, very close to the logic that the original code did in the ABM. However, that same logic takes on average 50% longer (per execution) to execute for some reason, and—the bigger problem—is erratic, unlike the original ABM. And the amount of time it takes per run of the timer shows about the same characteristics as when I used the method of accessing metadata within the ABM. Same slowdown; same lack of predictability.

Yes, the original idea was that if the use of metadata was slower, it could simply be done less often. However, the slowdown doesn't seem to be bounded. If a normal ABM took a steady 20µs per run and the metadata access resulted in a steady 30µs per run, I'd just say run it 2/3 as often and everything's good. But what happens is, for example, the old code takes 20µs per run and the new code takes 30µs per run sometimes, and 70µs to 100µs per run at other times, without any good explanation as to why (e.g. if I profile the Poisson calculation it takes a steady 5µs, so the extra 30µs isn't coming from there....). I thought the metadata access was a good "why." Turns out not. Heck, I thought the fact that I had to call minetest.get_node() twice from a timer because it isn't passed the node table as a parameter like an ABM action is was a good "why." But then I used a closure to store the node name so I wouldn't have to call minetest.get_node() again just to get the name, and it didn't solve anything. If the "why" would just show up, I'd be happy; I could design a solution to avoid it. But the damned thing keeps playing hide-and-seek.

[ronnietucker]

Is it possible to have this mod spawn items on a map created before the mod was installed?

Thanks!

[Don]

If its a map chunk that you want to regent do
/deleteblocks here.

This will regenerate the chunk and plants should grow.
Do not do it in areas that have thing built.