Voso wrote: ↑Sat 9 Nov 2019 12:51 AM
I read all the previous posts so maybe I need to quote the one I believe you're referencing?
NPCs, including pets, going through doors is for now still intended. It was the original behavior for OF. The part that's blocking it is that we still don't support terrain / world changes that affect the navigation mesh that's used for npc path finding as this nav mesh is statically generated upfront. This pathing issue is also the reason why we have tower razing / wall destruction disabled as it too would lead to unexpected npc behavior (aka hole in wall but pets / guards would path through the maybe closed door miles away instead of walking a step or two through the hole).
Line of sight already supports dynamic changes (e. g. doors opening / closing).
OK? This was the original behavior of OF, but we are now in NF. They have disabled terrain/world changes aka tower razing and wall destruction. I find that very interesting because both these items worked on live for many years. The devs are too busy working on QOL changes that harm PVE and RVR instead of squashing bugs so they disable features and state that pets pathing through doors is legit. We all have our own opinions. Game patches/updates would never happen if posts weren't written on the forum. Don't assume someone is complaining when they're stating facts.
You may have read it but apparently not understood it if you're claiming we deliberately disabled that feature to have the OF pet behavior.
Pathing is something that happens server side, just because it works on live (I guess pathing working on live is debatable in many cases and at least from the looks of it it got a lot worse over time, anyways, while ours is most certainly not perfect in any way there are fewer wtf moments) doesn't mean it's working on a freeshard which is a complete reimplementation of the server side of the game.
Pathfinding in general is a very performance and / or memory intensive operation, when the server is at about 50% cpu utilization around 20% is spent on path finding, the server itself without line of sight handling would take around 10GB of ram, with line of sight it's 25 and pathing itself is another 15GB. We're using a modified version of https://github.com/recastnavigation/recastnavigation living in a separate process, the way it works is that the individual zones (like emain, og) have been exported in a format that recast can itself transform into its own format, that's around 10GB, this then results in the static navigation mesh we use for the game.
The problem is now that things like tower razing / wall destruction or even door destruction require changes to this static navigation mesh, however, the naive / simple variant of just precalculating all possible states is not feasible as there are about 100 states possible for most NF keeps and there can be multiple keeps in a single zone and storing every single possibility for a given zone would hence be multiple terabyte just for that. It's also not really feasible to recalculate that on the fly as processing a single zone takes about a minute or two.
So the obvious alternative, which is also supported by recast, would to use tiles for the keeps and just replace those tiles, however, that's actually rather complicated and takes time, ideally spent in bigger chunks unlike most qol changes or bug fixes that usually at most require a couple hours at a time.
To put it in simpler terms:
The world is exported upfront and used as is, there is currently no way to change this export while the server is running, being able to change parts of it while the server is running is planned but will take time. Only and all of what is contained in this export affects the movement of npcs. Since we do at some point need npcs to walk through doors (when they are destroyed) they are just not inside this export. Since we do at some point not want npcs walk through wall parts that can be destroyed these walls are inside the export.