Spring RTS Engine

Kloot wrote: And just as a reminder: what unit movement was like <= 0.82.7), what it is like now (83.0 - 91.0) and where it will be going (>= 92.0).

The last two seem really great.

tzaeru wrote:

Kloot wrote: And just as a reminder: what unit movement was like <= 0.82.7), what it is like now (83.0 - 91.0) and where it will be going (>= 92.0).

The last two seem really great.

yeah, O_O at the bulldog avoidance, that shit cray

Kloot wrote:

FLOZi wrote:kloot, is there at all a selection of 'optimal settings' you'd recommend for path-finding, including things such as footprint sizes, heat map values etc?

Or alternately pitfalls to avoid e.g. footprint sizes that are radically different to movetype sizes

Certain combinations of parameters are better than others, yes. I might do a writeup about them and how they interact with each other, but the constant nagging about pathing being "terribad" isn't making me run faster.

Who's willing to chip in, guys?

That last one with the weaving flashes legitimately made me WOW out loud. I can't think of another game/engine with pathfinding that good.

The Yak wrote:That last one with the weaving flashes legitimately made me WOW out loud. I can't think of another game/engine with pathfinding that good.

I've seen better pathfinding in academic demos, but yeah, game engine's in general don't tend to utilize what is really available in the field.

Looks awesome by the way Kloot!

Academic demos are excessively optimized for general cases. They handle edge cases pretty badly.

That pathing for 92 is actually amazing. Are there any caveats/issues that mean it won't be an easy implementation?

I wouldn't put too much value on these movement videos since it's not really a scenario that happens ingame. Not saying it'll be bad without trying of course, but... The old pathfinder was ok yet on this one thing it fails as shown on the vids. Hopefully it'll be surpassing that now, when will 92 be released approx?

2) brakerate values were interpreted "liberally", units stopped _much_ faster than they were supposed to

What to multiply brakerate by to get it back to what it used to be?

On the contrary, "this one thing" (units crossing each other's paths) happens *all the time* ingame and how well an engine handles it is a major factor in whether large-scale games feel playable or unplayable.

And while the vids may show "artificially neat" (although 450 armflash crashing frontally is anything but) scenarios, you could *never* get good interaction on the level of such huge groups if it worked badly on the level of individual units.

You might also try doing this in 91.0 for some relevant shits and giggles.

What to multiply brakerate by to get it back to what it used to be?

10 (note that the values have already been changed in BA, though not by that amount)

The problem with tracking pathfinding improvements or regression bugs is that we lack (high level)* test cases showing stuff that didn't work in the previous version but work now, and vice versa.

I feel that if we had that, we could have a clearer picture of whether it's going to fix or break stuff people care about.

Would having mission-like mods (basically a mutator of sort) that would contain one or more of these tests work for you? They would be using a self-contained script.txt with either spring or spring-headless and produce output in the form: "Test x SUCCESS" or "Test x FAIL".

The idea is that these tests would be created not just by the core Spring devs, but also by the community devs or even end users, using GUI "programming".

In the past month I was too busy finishing my masters (and GW2 ), and it will take me a couple of more days to finish it, but then I'll be able to work a bit on my editor for a week or two, so I should have some concrete example of that.

*(high level) - most notably stuff such as "ships getting stuck on the shore of certain water maps" or "tanks getting in steep holes they can't get out of"

These *high level* tests sound like actual games. We might as well put it to the ultimate test rather than put efforts into loads of clever smaller tests.

LEDZ wrote:These *high level* tests sound like actual games. We might as well put it to the ultimate test rather than put efforts into loads of clever smaller tests.

Or just come up with a list of test cases that people should check with each new build... no need to develop anything beyond a rigorous test plan.

Kloot wrote:

What to multiply brakerate by to get it back to what it used to be?

10 (note that the values have already been changed in BA, though not by that amount)

Does this apply to acceleration as well?

What is exactly QTPFS?
Will it fix this http://zero-k.info/Forum/Thread/3432 ?

KingRaptor wrote: Does this apply to acceleration as well?

Nope.

BlueTemplar wrote:Will it fix this http://zero-k.info/Forum/Thread/3432 ?

Unfortunately there is no pathfinder (not even QTPFS) in existence yet that can magically fix user errors. Or maybe gadget errors in this case, because ZK's slope visualization code (which I assume is what made you think your ramp would be passable) does not always match what the engine considers passable slopes:

http://kloot.darkstars.co.uk/ZKRampTooSteep.png (demo)
http://kloot.darkstars.co.uk/ZKRampPassable.png (my test with a longer ramp)

Those red "inf" values mean the top part of your ramp is actually too steep for an armcom, so the pathfinder does exactly what it should by returning paths *around* the center mountain.

Um, what I see is that the pathfinder considers that there is NO ramp. My ramp is straight, why would the bottom be passable, but not the top?

BlueTemplar wrote:My ramp is straight

Is it? AFAICS ramps get built in multiple sections, each of which could have subtly different slopes only visible to the engine. However, if you can reproduce this in a SP testgame with nothing else going on (which I wasn't able to), I'll take a closer look.

Yes, especially since IIRC this ramp is built to allow even vehicles to pass (as the ramp widget indicates by it's color when drawing the ramp). I had built a ramp first that would be good enough for kbots, but my com wouldn't go up there, so I tried making a "vehicle" ramp.

Look also at how for your ramp, the ramp sides are red-colored, while for mine they aren't.

That was not my point. Your ramp's top section is raised *separately* from and before the bottom, which may or may not be important for the reasons stated above. And like I said:

myself wrote:if you can reproduce this in a SP testgame ... I'll take a closer look

For some reason I only seem to have this problem in MP games...