as you can tell from the debug visuals, the AI I've made for my game has almost-working AI... except they always go straight to the corner and get stuck.
I have navigation set up on my tiles correctly, and my relevant movement code is down below (nav_node is the navigation agent on my enemy): 

                        nav_node.set_target_position(player.global_position)
			look_at(player.position)
			var current_location = global_transform.origin
			var next_location = nav_node.get_next_path_position()
			var new_velocity = position.direction_to(next_location).normalized() * spd
			move_and_collide(new_velocity)

please help, every tutorial I can find is either outdated or they do the exact same thing yet somehow don't have this issue. I've been at this for almost three days!

Have you tried increasing the agent avoidance radius slightly by a few pixels? I would also recommend tweaking your tilset navigation layer to see if that helps.

    Lethn the avoidance radius doesn't change things at all, I tried on both 0.1 and 1000000 and it did the same behavior on both. tileset navigation is a similar story: no matter how I tweak it, nothing changes, unless I make the purple tiles navigatable. then they run headfirst into them. the size and shape of the navigation polygon seems to be irrelevant!

      That's very unusual and if it's any consolation, there seems to be general frustration around Godot TileMaps when it comes to actually using them, I'm having quite a few annoyances with them myself and it keeps making me consider 3D, have to wonder if the maths would be better just using 3D sprites among other trickery but that seems silly for what I want to do. Most tutorials out there just show you how to use them in a simple side scroller fashion they don't explore mechanics like we're attempting.

      it's incredibly frustrating that with all these tools and improvements, it's only the people still using the old version that can fix something so game-breaking. I'm seriously considering quitting this engine entirely if I can't get this to work, because it means I can only ever make games in wide open spaces without any walls. the old way of doing it used get_simple_path which godot 4 doesn't have, and it has no equivalent, and trying to find out how to manually implement that has been like pulling teeth. no one wants to tell me anything other than the code I've already posted. the code that doesn't work! frankly if I wasn't trying to stay polite through all this frustration this post would have a lot more colorful language. it would literally be easier to code an entire pathfinding algo from scratch than to try and use these seventy bajillion tools that maybe five actually do what I want but there's no way to know which combination of on off switches and numbers will ACTUALLY DO THAT!

      and yes, this is a giant cry for help. it's hard to stay sane when one thing is taking up so much of your time and refusing to move. I feel like frickin' sisyphus rolling the boulder up the hill except it only ever rolls downhill.

      I'm trying to make some reeeee noise about the TileMaps myself in the hope that the back end devs will take a look at the stuff we're complaining about, for me it's the issue of how much of a pain in the arse interacting with individual tiles is and I completely understand where you're coming from. Ironically Godot was seen as the pinnacle of 2D game dev by most outsiders, now because of the focus on 3D ( Which is excellent by the way, I would recommend at least using Godot for your 3D projects ) I think the official documentation especially hasn't had chance to catch up with all the changes for 2D and I would not be shocked if even the tutorial makers are in the same boat as you and trying to figure everything out. I don't like the idea of having to rely on extremely hacky work arounds and code even by my standards to get this sort of thing working because it seems like Godot's TileMaps do have a lot of potential.

      I'll laugh and cry at the same time if I give up and make a 3D RTS within five seconds because I don't have to deal with the TileMap's incredibly fiddly code lol.

      I still hope someone comes in with a real answer at some point, but for the moment I've decided to just leave that alone and let the enemies sit still while I work on everything else.
      maybe by the time I finish the rest of it something will have changed for the better :p good luck with your problem as well, person who did their best to help

      • xyz replied to this.

        xyz I've already shown all the relevant code, everything else has nothing to do with pathing at all. I set up the navigation map by using navigation layers on the tiles. the purple ones have none at all, and the grey ones do. that's why they're trying to go around the purple ones and failing.

        also forgot to mention, turning off the wall collision half works. they're still glued to the walls and if I waggle them around enough I can pop them over the walls, but they can at least move.

        • xyz replied to this.

            xyz I did that, and it didn't help at all. a full square has the exact same effect as a half filled square, which has the same effect as a tiny square only in the middle. they completely ignore the shape and only look at if there's any navigation data on them at all.

            how would that even work with a tilemap anyway? make a brand new tile exactly identical to the other ground tiles then give them a custom navigationpoly and only use those tiles near the wall? that seems cumbersome even if it would actually work.

            • xyz replied to this.

                samuraidan Hard to give specific suggestion without seeing the setup. Perhaps make a minimal project that demonstrates the behavior and post it here.

                    samuraidan how would that even work with a tilemap anyway? make a brand new tile exactly identical to the other ground tiles then give them a custom navigationpoly and only use those tiles near the wall? that seems cumbersome even if it would actually work.

                    It can be fully automated via scripting.

                      xyz

                      simple-example-pathfinding-tiles.zip
                      4MB

                      this is the simplest possible project I can make that recreates the issue. as you can see when you play it, the AI dives head-first into the walls and makes no attempt whatsoever to go around them. the pathing does, but it's glued so tightly to the walls that they enemy can't follow it.

                      • xyz replied to this.

                          samuraidan
                          Ok. You should eliminate enemy collisions with walls completely. One way to do it would be as I suggested. Make all possible versions of floor tiles, all with same graphics but different polygon configuration depending on adjacent walls. The inset should be large enough so that enemies cannot touch walls at all. If you want to make it look even better use chamfered or rounded corners on those polygons and circular colliders on enemies. You'll probably need a separate collider for navigation, possibly a rather small one if you want enemies to pass through 1 tile wide corridors.

                          Once you test this on a small handmade map, you can make a script that will replace all vanilla floor tiles with clones that have proper nav polys in respect to adjacent wall configurations. Run this script once at startup and you're done.

                          You can automate further if you want to have various types of floor tiles without repeatedly doing the manual setup. Store nav polys separately, have all floor tiles on a separate layer and wall tiles on another layer and let the script assign proper nav polys to all floor tiles, again choosing the right nav poly depending on floor's surroundings, via TileMap::_tile_data_runtime_update()

                          However I'd personally opt for plain A* approach, without any nav polys. Simply get all floor tiles that are at wall corners and let their centers be the points fed into A*. Your script would need to figure out point connections but that's not hard to do on a tile map.

                            I'm going to have to try the Astar thing, cause if I turn off wall collisions they can occasionally pop through the walls wholesale like I mentioned earlier.
                            jeez, all that just to make enemies that can functionally path. no wonder every tutorial is set in a giant open outdoor area. anything more and it might be a three hour long video :p though it does feel like you're overcomplicating the answer for no reason, to be honest. I just want enemy that routes around wall not... everything you just said.

                            also, does the Astar2D node still exist in 4.0? the docs don't say it's gone and don't mention a rename either but I can't find it.
                            ^ never mind that part, I thought it was a node not something you had to add through code

                            • xyz replied to this.

                              samuraidan cause if I turn off wall collisions they can occasionally pop through the walls wholesale like I mentioned earlier.

                              They should not pop if they never touch a wall. Nav polys should keep them off. But yeah, A* would be easier to set up for this.

                              samuraidan though it does feel like you're overcomplicating the answer for no reason, to be honest. I just want enemy that routes around wall not... everything you just said.

                              It's far less complicated than it sounds.

                              However here's a caveat. If something looks smooth and simple on the outside, doesn't mean there's no substantial labor needed to make it so. People tend to forget there's an enormous difference in effort between playing a game and making it 🙂

                                  I don't think you meant for it to come across that way, but that last sentence sounded really condescending. especially when I've already been putting in a ton of effort and research for three days. please don't talk down to me like that.
                                  I don't really need it to be smooth, I just need it to work. and the reason they pop through the walls is that they all collide with each other to stop them from dogpiling into a single enemy, which pushes them past the walls and into the floor again. making the path on the floors narrower wouldn't stop that, I don't think.

                                  I'm currently looking into astargrid2D as an alternative but information is extremely scarce. the documentation and one youtube video is all I've found.

                                  I would also like to remind you that simple for you is not necessarily simple for me. I've had bad days before because I was struggling with something for a long time that people kept saying was easy, and it never made me feel better.

                                    samuraidan He's not, he's just being a programmer and general dev that doesn't appreciate how complicated pathfinding algorithms and other bits of work are because he looks at far more complex stuff every day and they always come across badly to noobs and others asking questions when they post like this LOL, I've caught them out and sometimes myself numerous times thinking like this. I might reach the point where I regard this type of thing as 'easy' but honestly I find working with 3D far better in Godot, the TileMaps seem to be a genuine pain for quite a few people, even the experienced ones.

                                    It seems like TileMaps are being misinterpreted a lot as how to use them and I think that the Godot 4 documentation is partially to blame because it's not clear enough on what can be done and what can't plus the proper methods to do various mechanics like click to move with obstacles and I regard that as incomplete. I think he is right though, if you're really determined a custom A* algorithm is probably the way to go and that's the conclusion I've come to, I'd rather just switch to low poly 3D myself though because ironically the maths is now easier on that for me and I know what I'm trying to do will work. I've experimented heavily with 3D pathfinding and it's a lot better.

                                    The problem is and I was thinking about this, the argument to be made on the opposite end is that really quite a lot of behaviour we expect from TileMaps like the navmesh for cells clearing when they have a NavmeshObstacle2D put over them should certainly be features in by default or have some easier way to access individual tiles without having to do a silly amount of code. At the very least back end devs come on, please let us have some kind of code to access the individual tiles in a less silly and hacky way than what I've had explained to me.

                                    It might seem really odd, but I've been thinking, especially since you're doing a top down shooter I guarantee you it will probably be easier doing everything in 3D. In fact something really odd I was considering was the idea of using 3D sprites and a bit of optical illusion trickery to deal with all of the collision problems, that might also be worth a revisit. You would simply have to make sure the 3D sprites were facing the right way up for your top down camera among other things, this might even be a way of dealing with this problem if rather ridiculous, think Doom sprites but on a different axis.

                                        I'm leaving this open since the tilemap issue never really got a best answer, but for now I've gone back to using a navigation region with a really wide berth away from the walls and turning off wall colliders for enemies. I'm gonna have to manually change the region every time I change the level, so I really hope tilemap nav layers work correctly sometime soon, but at least my enemies can actually function for now.

                                        Lethn I've been ignoring your 3D suggestion cause I already have so many 2D assets drawn, but that suggestion of using real 3D faking 2D with sprites is an interesting one that I might actually consider at some point.