rezecib Posted September 26, 2017 Share Posted September 26, 2017 This may not be the best place to put this, but I've been updating Geometric Placement to play better with the new structures. However, the way that they are implemented with placeTestFn makes it very difficult to incorporate them. For the Tar Extractor, placeTestFn is responsible for both checking for nearby tar slicks and then also repositioning the provided inst onto it. This is problematic because the repositioning is "silent"-- by calling the function you can't tell if it's been repositioned or not (except by seeing whether it returned true for whether the build position was valid, but the other users of this function also use this). For the fish farm, placeTestFn is doing two things: Hiding some animation symbols Doing its own separate check for nearby structures within 5 range The hiding animation symbols part is problematic because I would like to be able to run these checks for my grid points as well, and these don't have these animation symbols. The separate check part just seems unnecessary-- why doesn't it simply use the recipe's min_spacing parameter? There would be a small functional difference (it would also be blocked by non-structures), but it would be much cleaner. (and a side note about min_spacing, that "finalling hack" for chests in components/builder could be rolled into the recipe too; the code around that hack could also be improved by precomputing min_rad*min_rad instead of doing it every iteration). Perhaps it would be better to have the tar extractor use a "findValidPlace" function which explicitly returns the valid position or nil if none is found. The fish farm's placeTestFn's code could all be moved elsewhere (e.g. a postinit function parameter for MakePlacer for the anims, and then using min_spacing), making it unnecessary. This would allow me to disable the grid when "findValidPlace" is populated, which makes sense because there's only going to be one nearby place, but still have a grid for fish farms, for which it makes sense to show the possible valid locations. Edit: So I guess the reason it isn't using min_spacing is because aquatic recipes actually ignore it in favor of their isShore, nearShore, tooClose check. This check actually has some pretty strange behavior and would benefit from being rewritten. I see that it looks like the intent was for ballphin palaces to not be buildable near land, but because the check is just checking various points around the edge of a square, certain islands allow placing ballphin palaces by shore (screenshot attached). Perhaps a better approach would be to precompute shore distances for all tiles in the world? For simplicity this could be done with Manhattan distance in at worst O(n^2) time by first checking each tile to see if it's shore, and then doing a recursive crawl outwards and assigning the minimum of the current distance for that tile and the current recursive depth. Alternatively, this kind of square check works fine as long as it's not checking distances over 4 (as this could allow it to miss inner tiles), and would work almost perfectly for distances up to maybe 12 or so. But the current 100 (25 tile!) distance for ballphin palaces doesn't make any sense with this method. Rather than adding this new function for basically doing the same min_spacing check, perhaps aquatic recipes should just do both the shore check and the normal collision check? I marked in red the points I believe it is checking to see if they are water for the tooClose predicate. Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.
Please be aware that the content of this thread may be outdated and no longer applicable.