CanPathTo function

[Rama]

@jip

I'll definitely look into it. Sounds like it can be used as a proper alternative to the CanPathTo function.

@maudlin27
Ah, thanks for the guidance! I will test this out later!

[maudlin27]

@jip I’m not sure it would just have been that as the results would change after waiting an amount of time but that time would vary from memory - eg sometimes I recall it mightve been 40s plus into the game that it started to be accurate. Then again it’s been several years since I last looked into it as it had massive performance issues as well (taking ages to calculate) which made it near-unusable for my purposes at the time regardless of its accuracy

[clyf]

@rama

I believe there's also a limit (for performance) on the amount of pathfinding that can be done any given tick. Completely speculative, but if you're spawning hundreds of units at once and giving them all simultaneous move orders the CanPathTo function might be timing out. If you haven't already, try cycling through the units that fail the check one at a time and doing it again.

[Rama]

@maudlin27 @Jip

Well, I just tried the new code maudlin27 shared with me, and it works perfect! Really, appreciate the contributions both of you make a lot! This makes things much simpler! I am going to have to get more familiarized with the abilities of Jip's navutility. Opens up some interesting possibilities.

[Jip]

@maudlin27 said in CanPathTo function:

@jip I’m not sure it would just have been that as the results would change after waiting an amount of time but that time would vary from memory - eg sometimes I recall it mightve been 40s plus into the game that it started to be accurate. Then again it’s been several years since I last looked into it as it had massive performance issues as well (taking ages to calculate) which made it near-unusable for my purposes at the time regardless of its accuracy

Engineers (including the (S)ACUs) are also set to be immobile while constructing.

[Jip]

@rama said in CanPathTo function:

@maudlin27 @Jip

Well, I just tried the new code maudlin27 shared with me, and it works perfect! Really, appreciate the contributions both of you make a lot! This makes things much simpler! I am going to have to get more familiarized with the abilities of Jip's navutility. Opens up some interesting possibilities.

The module navutils.lua exists to create a consistent interface for other developers that want to use the navigational mesh. There's also debug tooling that allows you to visualize the output of some of the functions. You can find them through the hotkeys menu:

The highlighted hotkey is the main view for the navigational mesh. You can visualize the navigational mesh itself through the window it creates. It makes it easier to understand some of the utility functions.

You're actively discouraged to directly interface with the navigational mesh itself. That involves any function and / or data that directly originates from navgenerator.lua by importing it in your code.

How the navigational mesh works is still a work in progress. The interface of the navigational mesh itself can therefore change. As long as you make use of navutils.lua then you can be fairly certain that the interface remains stable.

If you'd like more functionality then feel free to discuss that with me. A lot of the functions that exist now in navutils.lua originate from requests by AI developers, specifically by Relent0r the author of RNGAI

[Rama]

@Jip

I was trying to improve the Rift Spawn point generator for maps that have difficult navigation areas. But looks like Rifts are still hitting in unpathable areas. I tried adding a NavUtils.CanPathTo test as a secondary to make sure path was valid. While this script worked in testing with bots (Rift Nukes would launch at start of game), it appeared to not work with actual players online (Rift Nukes never launched). No errors in logs related to the script.

This was the code snippet:

-startPos = Random location chosen as spawn point for Rift
-endPos = Randomly chosen Player start position
-StartAmphibious = NavUtils.GetLabel('Amphibious', startPos) --Where units are coming from
-EndAmphibious = NavUtils.GetLabel('Amphibious', {randX, terrainAttitude, randZ}) --Where units are trying to reach
01 if StartAmphibious == EndAmphibious then
02 local AccurateTest = NavUtils.CanPathTo('Amphibious', startPos, endPos)
03 if AccurateTest == true then --If Path is true then Position is added as possible Rift spawn point.
04 newPos = { randX, terrainAttitude, randZ, type = "VECTOR3" }
05 table.insert(validRiftPositions.positions, newPos)
06 end
07 end

Sorry on the ugly code snippet, I don't know how to add in the nice looking snippets.

I've since reverted the code in the latest release, AI Wave Survival v260. The prior version, v259, has the script that only appeared to work with bots.

[Jip]

Did you generate the navigational mesh? If it is not generated, then it won't work. Make sure to call the generate function in NavUtils.lua at the start of the map script

[Rama]

Yes, I have NavUtilis.lua imported at start. It is also used to test if players can be reached by Amphibious units only, and will change the land units to Amphibious/Hover units only. That script works fine, and I redid the Rift Spawn Points script with it.

I checked the map the issue was occurring on, thinking there might be a small pathable route, but the areas were completely isolated.

[Jip]

Can you give me more context, such as the source code of the mod and the map (Rifts?)? Then I can investigate for you

[Rama]

@jip

Below are two replays, both using v259 of AI Wave Survival, which used the above Code snippet to spawn the Rifts. The Rifts are a newer addition to the mod. Immediately after build time ends, and then again every few minutes, the AI will launch a Rift Nuke (an EMP nuke) that will land near the players. The nuke, on detonation, will create a Rift Orb. The Orbs are used as spawn points for additional waves of units.

The Rift Script runs at the start of the game, testing random locations near players to see if Amphibious units can path to the player's start locations. If the script finds the units can, it will add the location to a list of possible positions Rift Nukes will be launched at.

The code is in the following directory:
\mods\AI Wave Survival\hook\lua\AI\AIBehaviors.lua

For v259:
Function name is CreateRiftSpawnPoints() on line 8864.
All the functions below that, to line 9272, are part of the Rift Nukes/Orb/Waves scripts.

1st Replay with v259, with Human players, I though I had corrected a potential bug in v258 that broke the Rift Script, as I had not added a "if huBrain and not huBrain:IsDefeated() then" check. First Rift Nuke should be launched immediately after Build Time ends, but no Rift Nukes are ever fired the entire match.
Replay: #21288851

2nd Replay with v259, with bots only, to test if Rift Nukes would work. Rift Nuke launches as it is supposed to, at end of Build Time, and another 4 minutes later (they should come every 4 minutes, increasing to every 2 minutes later in the game).
Replay: #21289283

And a final Replay with v257. This was the game where I noticed Rift Nukes were landing on mountains that were not pathable to the players, causing spawned units to get stuck, and is why I added the above Code Snippet. I have reverted v260 to this code, meaning Rifts function in latest version, but may hit in areas that are not pathable.
Replay: #21277826

[Jip]

It works with bots because the average bot generates the navigational mesh. It doesn't exist by default. You'll need to generate it before using it. See also this snippet. In the first replay (21288851) the navigational mesh was not generated.

To generate it, add it to your simInit.lua hook like so:

local parentBeginSession = BeginSession

function BeginSession()

        import("/lua/sim/navutils.lua").Generate() -- <-- needs to be called before everything else that may rely on it

	ScenarioInfo.Options.Victory = "domination" 
	  -- dun break anything!
     parentBeginSession();
	 
	
	 LOG("Trying to init survival")

	--local aiBrain = GetArmyBrain("Army_9")
	local behaviors = import('/mods/AI Wave Survival/hook/lua/ai/AIBehaviors.lua')	

     --behaviors.STRfour()
	 --LOG(" behaviors.STRfour called")
	
	 ForkThread(behaviors.InitSurvival)
	  LOG(" behaviors.InitSurvival called")
	   -- run our own bit of the sim!
  
	 LOG("init survival")
	
end

[Rama]

Oh, good to know! Yeah, I always test with bots first. Didn't know the navigation mesh didn't generate if no bots in the game. I assume once I add this, I won't need to add the additional code snippet to double check pathing? Is this test sufficient? Or do you think I should include the CanPathTo test? Don't know which function is more accurate/faster.

-StartAmphibious = NavUtils.GetLabel('Amphibious', startPos) --Where units are coming from
-EndAmphibious = NavUtils.GetLabel('Amphibious', {randX, terrainAttitude, randZ}) --Where units are trying to reach
01 if StartAmphibious == EndAmphibious then

[Jip]

I would just use CanPathTo, the definition can be found on Github. It does what you would do manually. Specifically, if the function returns false (can't path) then the last argument tells you why it returns false. You can use that in your code to understand your other options as what to do next.

[Jip]

@Rama In general - it may be worth your time to familiarize yourself with the functions that are available to you through navutils.lua. They can really help you get around (quite literally, heh) certain problems

[Rama]

@jip

I have been looking through the navutils.lua at all the functions. Using the PathToWithThreatThreshold() could make for much more responsive waves.