The last two seem really great.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).

Moderator: Moderators
The last two seem really great.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).
yeah, O_O at the bulldog avoidance, that shit craytzaeru wrote:The last two seem really great.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).
Kloot wrote: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.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
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.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.
What to multiply brakerate by to get it back to what it used to be?2) brakerate values were interpreted "liberally", units stopped _much_ faster than they were supposed to
10 (note that the values have already been changed in BA, though not by that amount)What to multiply brakerate by to get it back to what it used to be?
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.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.
Does this apply to acceleration as well?Kloot wrote:10 (note that the values have already been changed in BA, though not by that amount)What to multiply brakerate by to get it back to what it used to be?
Nope.KingRaptor wrote: Does this apply to acceleration as well?
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:BlueTemplar wrote:Will it fix this http://zero-k.info/Forum/Thread/3432 ?
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.BlueTemplar wrote:My ramp is straight
myself wrote:if you can reproduce this in a SP testgame ... I'll take a closer look