Do we have a way to tell the pathfinder this area is a no go?

[smoth]

Not using the stupid speed maps. Not using a Lua hack like teleport a unit back. I want to tell the pathfinder avoid here

[Silentwings]

Afaik "stupid speed maps" (=typemaps?) are the only way.

[zwzsg]

I have not found any that works.

[smoth]

Type maps fail because they are based on spring's magical assignment of classes and cannot be touched by Lua(or can they?)

[enetheru]

I would also like this.

[gajop]

Would be nice to have more control over the blocking map via Lua.

[qray]

Not saying that this is the solution you're looking for, just for completeness:

For my space maps with voidground , I played around and tested a lot terrain types with 0 speed (for all unit classes) and regarding pathfinding it works very well. Only units that get pushed or thrown there are stuck then, which IMHO is a big downside of this method in many use cases. Requires then Lua to solve this...

And

Type maps ... cannot be touched by Lua(or can they?)

https://springrts.com/wiki/Lua_SyncedCtrl#TerrainTypes

[Google_Frog]

Do you want units to be completely unable to enter an area or do you just need the pathfinder to treat it as impassible?

[smoth]

Pathfinder. Units getting bumped thrown etc are a separate issue that I can to some degree control.

[Kloot]

https://springrts.com/wiki/Lua_PathFinder#PathNodeCosts

[smoth]

DUDE! KLOOT! Awesome!!

[gajop]

How is this used? It's confusing, I can only make guesses..

Here's one:

Code: Select all

-- initialize a path grid (what are the defaults costs, is it even a grid, what should be the values?)
Path.InitPathNodeCostsArray(0, 1024, 1024)
-- use it
Path.SetPathNodeCosts(0)
-- set cost based on grid positions (example position)
local x, z = 5, 12 
local cost = 80
Path.SetPathNodeCost(0, x * 1024 + z, 80) -- is this how array position is calculated? 
-- set cost based on map positions
-- convert mapPosX, mapPosZ to x, z based on grid resolution and then use the above?

[Kloot]

As the wiki says, overlay cost values are additive which already implies what their default is (0).

The overlay grids are stored in row-major order, so you want z * numNodesX + x to transform grid coordinates (x, z) to the corresponding array index.

Converting from map to grid coordinates should be obvious: downsample them by the map:grid size ratio unless you set numNodes{X,Z} equal to mapSize{X,Z} in both dimensions.

note: it's useless to supply cost grids larger than the heightmap.

[gajop]

Cool, thanks.
I think these are clear now - I'll update the wiki when I test this.

Just to confirm - it's not possible to have a separate cost grid for different units, unitdefs, or movedefs?
That is, there can be only one cost grid for all units?
The reason I ask this is because we may want to use this to make certain units avoid certain areas of the map that are hazardous to them, but still allow other units to walk there. Unit AI is an option, but this is basically a pathfinding issue.

Another thing - does the cost grid override the heightmap-generated values or is it additive to it?
How do we update it?

PS: I'm of the opinion that Path.SetPathNodeCost should provide a slightly different interface:

Code: Select all

Path.SetPathNodeCost(number arrayID, number x, number z, number cost) -> boolean success 

It feels more intuitive and works similar to Path.GetPathNodeCost.

[Kloot]

An active grid will affect all units. Separate per-movedef grids would be possible, the others aren't (the PFS has no concept of units or unitdefs).

Costs are additive only.

To update, just call SetPathNodeCost again and any newly calculated paths will take the changes into account (if they visit the modified nodes).

NB: at present, only the default PFS can use these overlays.