To make a better spawn for my crabs, I’m using that _radiant.sim.topology.are_connected() to find a location where they can spawn and then go to a trap.
But using it as _radiant.sim.topology.are_connected(trap, crab_spawn) , where the trap argument is the trap entity just placed and crab_spawn is a point3 location randomly chosen, returns true even when the tested position is deep in a hole with no ladders, or up in a cliff.
Example, crab trap at the bottom and crab spawned at a not reachable position
That function is indeed confusing. The topology service is eventually consistent, but isn’t guaranteed to always be up to date. If the topology service hasn’t calculated that area yet, are_connected() will return true (and start a task to calculate that area), but are_strictly_connected() will return false. Also it accepts a bunch of different argument combos, but the way it does (entity, entity) is based on adjacency, while (entity, something else) is on the single point entity location.
When I used the wrong arguments, the error message display a list of possible valid arguments. As you said there many different arguments, entity, point3, region.
I used (Entity, Point3). A few of those variations accepted a third, int, value. I tried using that without much success. Can you explain what it does?
The strict had two variations, (point3, region3, int) and (point3,point3,int)
I tried using two locations and 0 as the third arg, but it always returned false, even in flat ground.
The int argument is to select different artificial navgrids and non-zero values are only used for building planning. I’m not familiar with that code, but Chris might be able to elaborate there.
For the strict version, if it’s an area that has not had topology queries run on it yet, it will always return false, just like the non-strict will return true. You can subscribe to topology updates and retry it later (see wait_until_reachable.lua).