Discussion Suggestion More pathfinding options for MobileParty

[Space_Pot8to]

Allow modders to modify the variables to whatever pathfinding algorithm is used in the engine. In particular I want to use this for MobileParty's on the campaign map. That way we can make parties do things like be unable to travel across enemy-controlled settlements, bridges, or other territory. For example take this town.
It sits on a river crossing. What I can do is set the faces that cover the town to a specific id or maybe cost. What I want to do is then be able to do is during the campaign decide for each party whether that id acts as a wall in the pathfinding algorithm or not. So do something like add a field to MobileParty called FaceIdsToAvoid or FaceCostsToAvoid or both that we can assign to, and then consider these fields in pathfinding. Having the option to do this can make things like controlling chokepoints (bridges, fords, isthmuses, mountain passes, etc.) actually important.

I think something like what I describe is already done for Agents with Agent.SetAgentExcludeStateForFaceGroupId, so the infrastructure is already in place for missions, it just needs to be made to work for MobileParties. Another way to achieve this is to make the navigation mesh accessible to modders, and we can maybe implement our own pathfinding, but doing so would probably be wildly inefficient, so better to have it done in the engine.

 

[NPC99]

I agree it would be great to implement choke points for mountain passes or gates in walls (i.e Great wall of China or Hadrian's wall or GOT wall or Mordor's Black Gate). A new terrain type with each individual face referenced to a specific town or castle that are impassible to any faction at war with the faction controlling that settlement. Effectively allowing choke points to change sides when their related settlement changes hands, following a siege etc.

 

[sh1ny4]

Would love this too

 

[FoozleMcDoozle]

definitely would be nice to have something like this

 

[Terco_Viejo]

I agree it would be great to implement choke points for mountain passes or gates in walls (i.e Great wall of China or Hadrian's wall or GOT wall or Mordor's Black Gate). A new terrain type with each individual face referenced to a specific town or castle that are impassible to any faction at war with the faction controlling that settlement. Effectively allowing choke points to change sides when their related settlement changes hands, following a siege etc.

Absolutely

Could you keep an eye on this please @Dejan ?.

 

[Snorri]

bump

 

[aigle_360]

I tested this feature on the campaign map. However, I don't think it fully matches the requirement.

I noticed as from v1.2.X that the method called "GetPathBetweenAIFaces" from the "MapScene" class has a new parameter called "excludedFaceIds".

Instinctively, I would assume that by giving the id of a navmesh face, it would ignore the face from the pathfinding algorithm as the argument's name suggests.
So, for testing purposes, I created the following Harmony patch which allows the exclusion of hardcoded FaceIds for all parties.
Note that the tests are conducted on the v1.2.9.34019 build.

    [HarmonyPatch]
    public static class DynamicNavmeshPatch
    {
        [HarmonyPrefix]
        [HarmonyPatch(typeof(MapScene), "GetPathBetweenAIFaces")]
        public static bool Prefix(object[] __args)
        {
            // excludedFaceIds argument is the 7th argument and is null by default
            if (__args.Length == 7 && __args[6] == null)
            {
                // var excludedFaceIds = new[] { 4447 }; // FaceId of the bridge near Amithatys
                var excludedFaceIds = new[] { 6 }; // FaceGroupId --> Fording terrain type
                __args[6] = excludedFaceIds;
            }
            return true;
        }
    }

We can naturally test this out with a bridge. We can use the one near Amitatys as lots of different parties come through there.

The following screenshot shows the FaceId of the relevant navmesh faces:

We can notice that the light blue navmesh face corresponds to the bridge which FaceId has the 4447 value. It also has the Fording terrain type.
So if we include the value 4447 in the excludedFaceIds argument, parties should not be able to cross over the bridge. However, this is not the case.

As a second test, we can try the value 6 which corresponds to the Fording terrain type. Technically, the value comes from the FaceGroupId (PathFaceRecord class)
As a result, parties do not cross the bridge. In fact, it excludes all navmesh faces with the Fording terrain type. In other words, bridges can not be crossed.

Here is a short video showcasing this behaviour:



In conclusion, I think that FaceIds should be the one to be excluded rather than the FaceIdGroup. Maybe both can be supported ?
Currently, a unique terrain type value has to be added for each strategic chokepoint in order to be managed individually.
If I have tens of different chokepoints, it becomes very tedious to manage. On top of that, the navigation mesh needs to be modified via the modding tools.

It's also not possible to disable random navmesh faces on the fly. There are use cases for this. For instance, dynamically creating new settlements in unforeseen areas or implementing random events such as floods. With the current system, these all have to be pre-defined which limits the experience of an advanced sandbox.

Anyway, that's my opinion on the matter and I hope some of you found this enlighting. I do hope this will looked at.

 

[Piconi]

In conclusion, I think that FaceIds should be the one to be excluded rather than the FaceIdGroup. Maybe both can be supported ?
Currently, a unique terrain type value has to be added for each strategic chokepoint in order to be managed individually.
If I have tens of different chokepoints, it becomes very tedious to manage. On top of that, the navigation mesh needs to be modified via the modding tools.

It's also not possible to disable random navmesh faces on the fly. There are use cases for this. For instance, dynamically creating new settlements in unforeseen areas or implementing random events such as floods. With the current system, these all have to be pre-defined which limits the experience of an advanced sandbox.

Thanks for the feedback, we will discuss this.

 

[NPC99]

Thanks for the feedback, we will discuss this.

What’s needed is a faceidgroup that is only passable to parties not at war with the faction owning the nearest town/castle (by distance to the face in question) as that would dynamically change as that settlement changed hands or peace was declared. This would allow the same Face ID number to be used across a campaign map for all choke points or zones of control. Each instance would only require an accompanying town/castle. More importantly it wouldn’t require coding - allowing sceners to implement chokepoints as required.