Spring RTS Engine

I would be happy to hear how unit movement could be fixed gameside. However, afaik it hasn't been touched for ages.

My biggest issue with pathfinder is how units always go to the most optimal route. Do we have control over that? where they can go, I will go in a straight line despite how much this terrain might slow me? because units can go way off course in order to maintain their time to arrival/speed(not sure which is the metric). This sometimes results in units doing dumb stuff like going into an enemy base. I am ok with obstacle avoidance but when you have a unit making all these twists and turns to avoid hills it can be problematic.


is there a way to address this? or is my description of the problem behavior unclear?

That's what I meant with that poem...

well, what ultimately happens, and this has always been the case, on maps with narrow valleys, you end up with the units all crowded in the valley. I know most people play with flat maps but I always experimented in the past and would often have all my units trying to funnel through a valley when they all could potentially have just gone straight through just a bit slower as some of them would have been on the hillsides. Instead i have to do several formation move orders to fight this.

smoth wrote:My biggest issue with pathfinder is how units always go to the most optimal route. Do we have control over that? where they can go, I will go in a straight line despite how much this terrain might slow me? because units can go way off course in order to maintain their time to arrival/speed(not sure which is the metric). This sometimes results in units doing dumb stuff like going into an enemy base. I am ok with obstacle avoidance but when you have a unit making all these twists and turns to avoid hills it can be problematic.


is there a way to address this? or is my description of the problem behavior unclear?

Purpose of heatmapping

so as pretty as things like:

or


I had to give up on them because the little hills and bumps resulted in units funneling through their optimal areas. Even in GRTS which had WAAY more forgiving slope tolerances.

Heatmappying was removed IIRC
*edit* also does heat mapping do anything to allow a unit to NOT predictably route it's self to the most OBVIOUS Chokepoints?

smoth wrote: My biggest issue with pathfinder is how units always go to the most optimal route. Do we have control over that? where they can go, I will go in a straight line despite how much this terrain might slow me? because units can go way off course in order to maintain their time to arrival/speed(not sure which is the metric).

The metric is cumulative cost incurred from terrain affecting unit speed via the (movedef) slope- and depth-modifiers.

Depending on those modifiers, even a short path across a steep mountain ridge can be seen as a more costly route than one taking the long way around through a nice flat valley, so if you want a unit to follow a straight line regardless of terrain, you need to change them such that slope and depth do not count as penalties. The flipside of this is that units will not slow down when going uphill or through water.

FLOZi wrote: Purpose of heatmapping

No.

I only read first line, thought he was talking about ALL units taking optimal line and getting stuck on each other

Kloot wrote:so if you want a unit to follow a straight line regardless of terrain, you need to change them such that slope and depth do not count as penalties. The flipside of this is that units will not slow down when going uphill or through water.

That is what I feared, I was playing with that before but I had hoped in my dated knowledge that something was added to allow us to more or less ignore slopes or at the very least allow a fudge value for certain ranges as long as they exclude the non-passable(nothing should ever see this as an available zone for travel

Maybe have a config var that would ignore all paths that are $VALUE times longer from the closest one available?

If I make a mutator fixing unit movement in xta for vehicles and bots (as a poc), will you promise to give it 10 solid games of testing? If so I'll do it, and I think I can please the majotiy of players. Maybe not the vast majority, but a majority nonetheless.

Kloot wrote:Obviously the lack of complaints is due to there being no players left because, as we all know, Spring is dying.

Quick question, how much money each month is required for you to quit your job and work on spring full time?

(Do not split this into it's own thread abma, it's just a fast question.)

Forboding Angel wrote:Why don't you simply fix unit movement? That would be much more simple. Your unit movement is so cruddy, it's no wonder that the pathfinder struggles with it.

if by that you mean giving higher slope tolerances to vehicles, i agree. I did that in my game too.

@mario, kloot is a pretty advanced coder meaning that if he codes for a living, he could be doing anywhere from 50 - 90k usd easily. Per month that would come out to $4,166.667 at the lowest end of the spectrum.

@Raaar, Higher slope tolerances can help a lot, yes. That wasn't my first objective though. That said, you can raise a lot of tolerances surprisingly significantly and help pathfinding while not noticeably affecting gameplay (In most cases).

Kloot wrote:

smoth wrote: My biggest issue with pathfinder is how units always go to the most optimal route. Do we have control over that? where they can go, I will go in a straight line despite how much this terrain might slow me? because units can go way off course in order to maintain their time to arrival/speed(not sure which is the metric).

The metric is cumulative cost incurred from terrain affecting unit speed via the (movedef) slope- and depth-modifiers.

Depending on those modifiers, even a short path across a steep mountain ridge can be seen as a more costly route than one taking the long way around through a nice flat valley, so if you want a unit to follow a straight line regardless of terrain, you need to change them such that slope and depth do not count as penalties. The flipside of this is that units will not slow down when going uphill or through water.

FLOZi wrote: Purpose of heatmapping

No.

It sounds like smoth wants to split the slope and depth modifers into two values. One value would be used by the pathfinder to find a path and the other would be used to make units slow down when on hills or water. Then he could set the pathfinder-related value such that the pathfinder does not incur any extra cost when looking steep pathable terrain. He would retain the slowdown on hills behaviour by not changing the speed modifier value.

These values would also let people find a middle ground where units avoid very steep terrain but still move in fairly straight lines over hills.

Jools wrote:I think units getting stuck in factories may be fixed in the latest development build of engine, but I can't say, we haven't tested it enough with real games . In 98.0 it happens frequently, once per game per player I would say.

The most common complaint isn't that pathfinding is stupid, it does its task quite well. But on some maps units are instructed to go into "red" terrain and get stuck.

it has certainly improved if you compare with engine 94 or 95. I tested it on the map Epic with giving constructors complex orders, and after 96.0 it works better. But it's still not as good as it was in say engine 0.78 or so. Maybe that had other problems or maybe we only remember the good stuff. Ultimately my memory is subjective.

I tried to grep this year's demos for the string _98 in the name and for "pathfinding" in content. 16 hits out of 905 demos. Not so many complaints. It's nice that zk uses the latest engine, but how many real games does zk have with the engines 94, 95, 96 and 98? I only ask that so I can know how much data there is to back up that hypothesis.

Units getting stuck in factories is fixed in dev engine. You may have to modify your yardmaps a bit though.

Could you provide examples of maps and units that get stuck on "red" terrain? Also is "red" unpathable or just very steep?

Why does is matter how many games ZK has with 94,95,96 and 98? Which hypothesis is being tested? It seems pointless to try to find when you think the pathfinding was broken before testing my claim that it works in dev.

Look into turn speed inertia. That was added some time in the past few years and iirc the defaults can make path finding feel quite bad.

Google_Frog wrote:
Units getting stuck in factories is fixed in dev engine. You may have to modify your yardmaps a bit though.

Ahaa, that's something I haven't heard. Modify how?

Google_Frog wrote: Could you provide examples of maps and units that get stuck on "red" terrain? Also is "red" unpathable or just very steep?

It's very common. Basically any map except a flat map. I'll take a screenshot next time it happens.

Google_Frog wrote:It sounds like smoth wants to split the slope and depth modifers into two values. One value would be used by the pathfinder to find a path and the other would be used to make units slow down when on hills or water. Then he could set the pathfinder-related value such that the pathfinder does not incur any extra cost when looking steep pathable terrain. He would retain the slowdown on hills behaviour by not changing the speed modifier value.

These values would also let people find a middle ground where units avoid very steep terrain but still move in fairly straight lines over hills.

kinda, if we could have something like "optifudge"(I don't care what you want to call it). As in, as long as the slope is passible, ## degrees variation would been within reason for a unit to path through. I want a tollerance, I am not sure how to explain it. Flat distance is a bad idea because that would potentially result in units going to places they cannot path through.

Given the following topography:


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..

I thought I understood what you wanted but with this skiing example I no longer do.
I assumed you wanted units to sometimes still take steep but shorter distance instead of longer but flat distances. Now it seems you want to change pathing for multiple units (flocking/flow), something like this: https://youtu.be/Hc6kng5A8lQ?t=148

These are different problems.

That is what I want. Not flocking, just assume all skiers were give a move order from the top of the hill

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