Giter VIP home page Giter VIP logo

Comments (14)

NoxyNixie avatar NoxyNixie commented on June 26, 2024

The tile degradation setting never did anything other than what its description says:
Over time slowly degrades floor tiles that block tree growth until the trees can grow there again.

The only tiles right now that block tree growth are player build tiles. Trees can grow on sand (though less likely) and other ground tiles so this degradation setting never touched those tiles.

Most generated ground tiles have a fertility value. This value is used to calculate how far and how quickly trees spread. It is by default balanced around more fertile looking land allowing more trees to grow while deserts tend to have less growth and might even slowly reduce forest densities.

If I make forest spread more fertile ground to the less fertile ground this will counter all the balancing I did to make the spreading not ridiculous. If everything turns fertile over time your entire world will be so full of trees you will actually start noticing it impacting performance.

Now I could potentially make fertility spreading a thing but I'm not sure if I should. the consequences could be dramatic especially if its enabled on very large maps.

I'm not sure if I should change the description to clarify what seems already clear to me nor would I really know how to explain what is already explained while keeping it short and simple. I've already put too much information in some of the setting descriptions.

from noxys_trees.

BloodyRain2k avatar BloodyRain2k commented on June 26, 2024

I guess the description is indeed clear enough when the player knows that tiles automatically means player tiles.
I didn't know that as I only knew what tiles were, not that there doesn't seem to be any that can exist by other means.

But now I got a different question: can a setting be added to make trees keep a distance to tiles too?
For me they keep growing into my roads because they only keep their distance to entities afaik.

from noxys_trees.

NoxyNixie avatar NoxyNixie commented on June 26, 2024

Trees shouldn't actually be growing on road tiles. If they are, can you make a screenshot of them actually being fully on a road tile (when they grow on the edges of placed tiles it can seem as if they grow on them but technically they'd be next to those tiles).

If you disable tile degradation no tree will be able to spread onto placed tiles.

Making it so that trees keep their distance to player placed tiles (like they do with entities) is going to be very resource intense. Essentially tiles do not have an owner associated with them like entities do and there are far more tiles than entities in a specified area therefor the area scan (which on its own is already the most resource intense operation) cannot be filtered as much and becomes very expensive.

I have yet to look into some of the newer filtering options in some of the latest releases of Factorio but I suspect this won't actually change anything with regards to tiles. So at this time I can not say that I will implement this feature.

from noxys_trees.

BloodyRain2k avatar BloodyRain2k commented on June 26, 2024

when they grow on the edges of placed tiles it can seem as if they grow on them but technically they'd be next to those tiles

That's what I actually meant. As far as the scan for tiles, can't they scan the nearby tiles in a small radius on 'spawn'? It's not like they should have to despawn when the tiles gets placed near them.
Either they get removed by the placer or not.

But they just shouldn't pop up so close to tiles that they look like they're on it.

from noxys_trees.

slippycheeze avatar slippycheeze commented on June 26, 2024

@BloodyRain2k just to check, are you using a mod which reduces the collision box for things -- especially "Squeeze Through"? If so, that is a good candidate for why trees grow in inappropriate places, because the tiny tiny collision box ends up making them put in places they visually don't fit.

from noxys_trees.

BloodyRain2k avatar BloodyRain2k commented on June 26, 2024

Great guess, I am actually using that because there are tons of places you should be able to fit through but can't without that mod.
I'll see if I can add a setting to it to exclude trees and see if that changes something.

from noxys_trees.

NoxyNixie avatar NoxyNixie commented on June 26, 2024

That's what I actually meant. As far as the scan for tiles, can't they scan the nearby tiles in a small radius on 'spawn'?

Owh it is definitely possible, I never said it wasn't possible however it would impact performance more than you'd initially think.

The following small section of code:

Noxys_Trees/control.lua

Lines 635 to 659 in 6c06191

local r = config.minimum_distance_between_tree / noxy_trees.fertility[tile.name]
if surface.count_entities_filtered{area = {{newpos[1] - r, newpos[2] - r}, {newpos[1] + r, newpos[2] + r}}, type = "tree"} > 0 then
return
end
local rp = config.minimum_distance_to_player_entities
if rp > 0 then
for _, force in pairs(game.forces) do
if #force.players > 0 then
if surface.count_entities_filtered{area = {{newpos[1] - rp, newpos[2] - rp}, {newpos[1] + rp, newpos[2] + rp}}, force = force} > 0 then
return
end
end
end
end
local er = config.minimum_distance_to_enemies
if surface.count_entities_filtered{area = {{newpos[1] - er, newpos[2] - er}, {newpos[1] + er, newpos[2] + er}}, type = "unit-spawner", force = "enemy"} > 0 or
surface.count_entities_filtered{area = {{newpos[1] - er, newpos[2] - er}, {newpos[1] + er, newpos[2] + er}}, type = "turret", force = "enemy"} > 0 then
return
end
local ur = config.minimum_distance_to_uranium
if surface.count_entities_filtered{area = {{newpos[1] - ur, newpos[2] - ur}, {newpos[1] + ur, newpos[2] + ur}}, type = "resource", name = "uranium-ore"} > 0 then
return
end
surface.create_entity{name = parent.name, position = newpos}
global.spawnedcount = global.spawnedcount + 1

determines if a spawn attempt fails or succeeds. These checks are written in such a way that they are as performance friendly as possible and mostly follow the fail fast principle. Meaning that the first checks are usually the least performance intense.

In the code section above this is checking to see if trees aren't growing too close to trees. By default the radius here is 0.8 (less than a single tile) and conversely covers a tiny area. However this acts on entities and also on specific entities (type = "tree"). which makes it perform reasonably fast in comparison to the other checks.

All of these checks act on entities and are filtered in some way or another that make it perform reasonably fast. However this section of code is still the slowest of the entire mod. The reason is that this section is called many times and needs to happen really fast to not be noticeable.

As you may know Factorio works in a tick rate of 60 ticks per second which gives the entire game roughly 16ms to perform a single game cycle. By default the tree spreading logic is only executed once per second (or once every 60 ticks) and is highly split up between many ticks (if you enable debug mode in my mod you'll see its report a statistic called Chunk Cycle. Depending on how large your world is it can take quite some time to perform a single chunk cycle which is essentially cycling over all your world chunks. So this mod splits up the work load over many ticks to make it nearly unnoticeable that the mod is doing anything. However most of the intense calculations in my mod happen still in a single tick when trees are being grown. If this action takes too long people will notice a stutter roughly every second. Since the entire game only has 16ms and the game has to divide that into rendering, game and scripts (other mods included); The time I can spend doing calculations is very limited in a single tick. Which brings me to why I don't think I will implement a check for tiles.

First of as mentioned before tiles are quite a bit different from entities and they don't really come with a "type" I can filter with making it so I'd need to filter it myself or provide a reasonably large list to the filter function (which means a transition from lua objects to C objects which is kinda slow proposition).

Another and probably even worse approach is to manually check the tiles around the tile I'm checking to place the tree on. This would multiple the call to get_tile by 9 with a radius of 1 or less than 1. This specific function creates a new lua object which is a fairly expensive operation and to be avoided as much as possible (one of the reason why I'm using the count_*_filtered variants of the filter functions since it does not create a list of Lua objects). On top of that I would still need to check the tiles against a reasonably large list! Also if you'd want a radius that is larger than 1 tile ... the amount of work grows exponentially.

You have to keep in mind that this small filter section is called many times in a single tick when the tree growing happens. Thus any performance impact is exponentially noticeable.

But they just shouldn't pop up so close to tiles that they look like they're on it.

I can implement the feature but I will disable it by default and there will be a warning about its performance impact.

@BloodyRain2k just to check, are you using a mod which reduces the collision box for things -- especially "Squeeze Through"? If so, that is a good candidate for why trees grow in inappropriate places, because the tiny tiny collision box ends up making them put in places they visually don't fit.

Great guess, I am actually using that because there are tons of places you should be able to fit through but can't without that mod.

The collision boxes of trees is completely irrelevant with regards to tiles. The only place in my code where collision boxes actually come into play is with this line. However in this case the trees can be placed on most tiles anyway especially those tiles we'd want to prevent them from being placed on (or near).

Playing with the mod "Squeeze Through" or any other that changes collision boxes has pretty much no effect on the actual placement of trees aside from where a tree can't actually go (water, out of world tiles, etc).

from noxys_trees.

BloodyRain2k avatar BloodyRain2k commented on June 26, 2024

First of as mentioned before tiles are quite a bit different from entities and they don't really come with a "type" I can filter with making it so I'd need to filter it myself or provide a reasonably large list to the filter function which means a transition from lua objects to C objects which is kinda slow proposition.

Ok, that's indeed bad. Have you tried to talk to one of the devs about this?
Because I think that something like trees spreading slowly is something that simply has to be in the game. It makes the game more alive, and me less anxious about the fact that without it, any tree that's lost will be lost forever.

I can implement the feature but I will disable it by default and there will be a warning about its performance impact.

That would be much appreciated.

from noxys_trees.

NoxyNixie avatar NoxyNixie commented on June 26, 2024

Ok, that's indeed bad. Have you tried to talk to one of the devs about this?

Nope and probably not going to either as what they provide in their API is already quite good. The problems of performance are simply a result of how the game works and I won't ask them to completely alter their game design to make tree spreading more performance friendly.

Because I think that something like trees spreading slowly is something that simply has to be in the game.

If you consider what type of game Factorio actually is then tree spreading is quite far out of the scope of the game and its intended design. So in my opinion it shouldn't be in the base game. Fortunately Factorio has a very good mod API and allows many things that are beyond the scope of the game ;)

from noxys_trees.

NoxyNixie avatar NoxyNixie commented on June 26, 2024

Alright the setting has been implemented along with some extra stuff: e6fc008 and released as 0.2.2.

from noxys_trees.

BloodyRain2k avatar BloodyRain2k commented on June 26, 2024

Thanks for adding it, I'm already testing the limits with it and for my hardware I can run it at 2 ticks between updates with it updating 1 chunk while the degradeable distance is set to 1.5 and it's still smooth.

But I have the feeling this tree isn't convinced of the settings I'm using:
image

And yes I've made sure that this isn't one from before the update. I've paved that road just after it for testing this because it makes the best place to keep an eye on the spawning behaviour of the trees.

from noxys_trees.

BloodyRain2k avatar BloodyRain2k commented on June 26, 2024

So I've been continuing to test things and I keep encountering cases where the trees simply don't care how close they grow to entities or tiles.
image

In the top middle there's one (close to the blue signal) having it's roots over the rail, and in the bottom middle there's one half growing on the rail.

Do I have any settings wrong? Or is it because I have such a fast update rate?
Which I btw simply have for testing and benchmarking reasons.

Edit: I also hate these guys because their graphic is way out of their box. And I can't even filter them for deconstruction planners : (
image

from noxys_trees.

slippycheeze avatar slippycheeze commented on June 26, 2024

Playing with the mod "Squeeze Through" or any other that changes collision boxes has pretty much no effect on the actual placement of trees aside from where a tree can't actually go (water, out of world tiles, etc).

Interesting. It certainly caused the same sort of effect for me with "Fish and Wildlife" mod, which is where I discovered that "Squeeze Through" triggered the problem, and the same feature in "Picker Tweaks" didn't.

Sorry if I derailed this with a wrong guess at a possible cause. Thanks for your patience.

from noxys_trees.

NoxyNixie avatar NoxyNixie commented on June 26, 2024

I made a change (released as 0.3.1) that may alleviate some if not all of the trees "spawn" on-top of player build entities (or ghosts). What I think is going on is that some trees die due to pollution but then resurrect again when the pollution goes away. However when dying their location isn't exactly the same is the original tree due to the dead trees having weird hitboxes.

from noxys_trees.

Related Issues (4)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.