Taehl wrote:call a function which gets a list of all trees in the map
There is not, to my knowledge, any provided function that can do that. That is essentially what the onchunkgenerated event function is doing for us, adding trees in new chunks (base trees don't reproduce so no need to recheck them) to our own table in the glob table (the only table that is saved and loaded when the player's game is).
The reason you have to do it in chunks is because Lua is quite slow relative to the C++ code (that most other things, pollution, energy use, etc. are done in), ~9x times slower according to
this (note: that factor can change depending on the exact comparison test used, feel free to Google some yourself, though Lua will always be slower to run due to overhead in the language, but those overheads also make it nice to work in
). This leads to a drop in updates per second (UPS), and thus frames per second (FPS) as well, when you try to do too much
at any one time, regardless of how often those times occur. If it takes 1/3 of a second (20 ticks) to run through the entire list, and that time will grow as you explore more of the map, trying to do all of it in one tick (even if it is only every minute) forces "everything" else to wait on it, and logically leads to 19 ticks of lag on that tick. Splitting the work into a "reasonable" amount (that can be found through testing) every tick means that it can be finished within that tick and not cause any lag, it still takes approximately the same amount of time for the work to be done, but the work is 'un-noticeably' spread out over that time frame since it's not trying to get it all done at once.
As for 'updating' the tree list, it's quick to remove entries and can be done during that tick. Optimizing the tree list so that chunks are of a reasonable size (more than 10 tree but less than, say, 500, just an arbitrary number) would only make sense after x seconds since it's actually pretty uncommon for trees to die, and in the base game trees are never added. That can be done in ontick by checking if event.tick % 60 * x == 0 (ie, that the current tick is some multiple of the number of seconds you want to wait) and if so then calling the function which optimizes the list (theoretically that list could become so large that you'd want to spread that work out as well, but it'd just be the same principle at work). Of course, trees growing leads to another
possible point, most obviously with the Treefarm mod, since it does grow trees, and so you'd need the code to recall findentitiesfiltered to see when more have grown, BUT that call is also relatively slow since the C++ has to first find all of the entities in that area, filter them, and then pass them back to Lua, so you wouldn't want to call it for areas that don't have a treefarm in them (you can detect when they are built with onbuiltentity and onrobotbuiltentity). You'd probably want to make 'special' areas that are, perhaps, checked more frequently using findentitiesfiltered (separate list, just storing the area to check instead of the trees theirselves?). But, perhaps the time that those trees live is so small and inconsequential that it wouldn't be worth actually considering them as 'special' and instead simply ignoring them would be easier?
Taehl wrote:That is, indeed, less than easy
It's not particularly
difficult, but it requires some thought as to the "best" way to implement it.
P.S. If anyone happens to notice that something is incorrect then please correct me, but I believe everything I said there makes sense
