Spring RTS Engine

Hi,
Yep. this pathfinding is not good sometimes. I played 3-4 games (XTA) yesterday and "pathfind" fails over 10 times. 5% of your gaming time is going that you check possibly pathfails.

Many times cons go to inside factory. This is very annoying. You can lose game because of this.
https://dl.dropboxusercontent.com/u/440 ... n00089.png

Sometimes units can't go out from factory. Small units too and without nano's too.
https://dl.dropboxusercontent.com/u/440 ... n00078.png

This fatass blocking my way
https://dl.dropboxusercontent.com/u/440 ... 00081b.png

Two units. Very simple move order (one click).. both get stuck. This pathfind sometimes really sucks!
https://dl.dropboxusercontent.com/u/440 ... n00091.png

Note: I only play XTA. So mayby those problems are only problems of this mod (not engine). TECHA players have not so much pathfind problems.. but yes..they play lots of flat maps. (Blue Fields etc)

Does anyone have effective values for

https://springrts.com/wiki/Movedefs.lua#Heat_Tags

and

https://springrts.com/wiki/Movedefs.lua#speedModMults

Should they be used in conjunction or separately?

There's also an (undocumented) set of tags for 'flow mapping', not mentioned in changelog or commit log. What is the purpose of flowMapping & flowMod?

Silentwings wrote:If you don't have thousands of units, did you try qtpfs? It handles clumping well, iirc.

How do I know if I am. Using it?

It's a game option. XTA has it as a modoption but almost nobody uses it.

Edit: game option = mod rule.

With e.g. http://imolarpg.dyndns.org/trac/balates ... es.lua#L34. By default the other PFS is used.

smoth wrote:This happens over long distances:
Red = unpathable, too steep whatever
green = area that we can go
blue = the way the units will follow the topography.
black people = units


Overtime everything more or less ends in a big line..

This is most likely caused by the resolution of the pathfinding as units will chose the same path. This will happen even on ralative small (1000 elmos or so)distances and even at long ranges at on completely flat maps at least in S44. I tested moving peewees in a line in XTA 9.745 and they would maintain their formation when moving straight horizontally or vertically. However when moving diagonally they would form up along the same lines.



Map Flat-map. Spring 98.

It is all very peculiar to me. I don't understand why they pile up.

smoth wrote:It is all very peculiar to me. I don't understand why they pile up.

Because long distance pathing is broken down into one or a few paths(the blue lines) rather than individual paths for all the units. When several units converge on the same paths they block eachother and form a line.

Edit:I should add that pathing is octogonal. The pathing is only use 8 directions to navigate at all but the shortest distances.

You could certainly hack it.. by doing a pathable area side test along that one line and squeeze and re-stretch the formation.

The grouping for pathing though is a good thing.. hating on that, is basically hating on good performance.

The 'bunching up' is what I was referring to when i said it is what heatmapping was for, also avoidmobilesonpath. But I can't yet find good values for them in s44, and I don't know if they should not be used in conjunction

I spent a week trying every reasonable possible value with all those tags, trying to get anything resembling coherent behavior and failed rather miserably.

The only thing more useless than not using those tags and values, is using them.

The behavior breaks down into two categories... Non-derpy (and completely standard behavior)/100% Derpfest (Yo dawg, I HERD U LIEK CIRCLES!)

So good luck, you're going to need it.

Forboding Angel wrote: The only thing more useless than not using those tags and values, is using them.

I like that quote, it's like something Oscar Wilde would have said. Very witty indeed.

And there is only one thing worse than being witty, and that's not being witty!

zoggop wrote:i remember when i was writing a config for shard, i wrote a periodic check if the unit had indeed left the factory. if not, i had it try another move order in another direction. much what players do, except they swear more.

This was such a faff, in NTai I tried to get around this by issuing a move command as soon as the unit can be given commands to move immediatley south of the factory ( all factories faced south ), but that had the same issue. I tried forcing the AI to give special spacing values to factories to force a navigable area, which worked, but it also caused other issues with building placement, which caused a lot of complaints, and crippled the AI on some maps.

A possible solution I'd hoped for but thought extremely unlikely for practical reasons would be for a factories yardmap to include a buffer of navigable area surrounding the structure, with perhaps more around the exit. I never asked for this though, as it would piss off players, and you wouldn't be able to place factories immediately next to each other, e.g. arm kbot facs etc

I did get a placement algorithm that fixed it all working in the end, but it took too much cpu

I'd suggest looking at delauney triangulations and voronoi diagrams for high level path planning

Since we were talking about pathfinding, is there any way to disable it or in any way control pathing calculations?
I'm making a map editor and I don't need Spring to recalculate pathing (or at least, not as much as it does).

You can set pathFinderUpdateRate here: https://springrts.com/wiki/Modrules.lua#system

I think no. But it might be worth making one. Equally people editing maps might want to try units on them while they go. I always do, of course not in nearly as convenient a way as your code would allow.

Jools wrote:You can set pathFinderUpdateRate here: https://springrts.com/wiki/Modrules.lua#system

Thanks

Silentwings wrote:I think no. But it might be worth making one. Equally people editing maps might want to try units on them while they go. I always do, of course not in nearly as convenient a way as your code would allow.

Right. I was hoping I could control it dynamically since I don't need it triggering while I'm modifying the terrain, only after it's done. I'm actually not sure how much of a performance hit it is yet. The delay I'm seeing might be in heightmap display taking time to update and any other slowdowns are also possibly the result of my code.

Since my response was disputed, I should add that I didn't test it, but I don't see why it wouldn't work.

You can probably find out what is taking the time with /debug.