Pathfinding, question to devs

[Masure]

Considering the mess around pathfinding, why on earth did the code was not reverted ? I know reverting is not trivial when code is not modular enough. But for god sake, such crappy pathfinding behaviour (compared to what we had) makes me wonder why.

Please tell us.

Thanks

[Forboding Angel]

What we had was fucking awful. Of course people like you will distort it to make it sound like it was gods gift to pathfinders, but those of us who have delt with it enough remember what it was like. Fuck that.

BA should adapt smoth's movedef stuff so that the pathing info in the unitdefs in BA can be fixed.

[SinbadEV]

the new pathing code is much more dynamic and modular then the old code (apparently) so it will be much easier to move beyond the problems existing in the previous system and move ahead then to revert (apparently).

Reverting major re-factors are not easy (apparently).

You can always set up your own spring server and host games using a pre-re-factor engine version (in fact I think ZK-Lobby allows this on the current server... apparently)

[Masure]

@forb

So you explain that new pathfinding features needed by non BA mods led to regression until unitdef are properly updated. So with unitdef update regression will be gone and pathfinding as good as before (in BA) ?

[SinbadEV]

@forb

So you explain that new pathfinding features needed by non BA mods led to regression until unitdef are properly updated. So with unitdef update regression will be gone and pathfinding as good as before (in BA) ?

more like, pathing was broken but worked "OK" for most mods, pathing was fixed (a bit) but only if you fixed your movedefs, other mods and games changed their movedefs so they work but BA hasn't done so (apparently).

[Masure]

the new pathing code is much more dynamic and modular then the old code (apparently) so it will be much easier to move beyond the problems existing in the previous system and move ahead then to revert (apparently).

Reverting major re-factors are not easy (apparently).

You can always set up your own spring server and host games using a pre-re-factor engine version (in fact I think ZK-Lobby allows this on the current server... apparently)

You're not dev and there are a lot of "apparently" that don't help me to understand. I also could have explained many thing with "apparently".

Your last sentence also sounds like a troll.

[Masure]

@forb

So you explain that new pathfinding features needed by non BA mods led to regression until unitdef are properly updated. So with unitdef update regression will be gone and pathfinding as good as before (in BA) ?

more like, pathing was broken but worked "OK" for most mods, pathing was fixed (a bit) but only if you fixed your movedefs, other mods and games changed their movedefs so they work but BA hasn't done so (apparently).

No offense but I think you lack accuracy in your explanation and I'd wish more concerned people try to answer.

[SinbadEV]

the new pathing code is much more dynamic and modular then the old code (apparently) so it will be much easier to move beyond the problems existing in the previous system and move ahead then to revert (apparently).

Reverting major re-factors are not easy (apparently).

You can always set up your own spring server and host games using a pre-re-factor engine version (in fact I think ZK-Lobby allows this on the current server... apparently)

You're not dev and there are a lot of "apparently" that don't help me to understand. I also could have explained many thing with "apparently".

Your last sentence also sounds like a troll.

I wasn't trying to draw out negative reaction so by my definition it is not trolling... also, technically, the information I provided in it is valid and would resolve the issue you are having.

My main point is that the "pathing issue' has been discussed ad nauseam and when someone comes in and just whines about it in a fresh development thread it makes me defensive of the guys who put so much work into engine development and that all the other advancements they have made along with what you are calling a "regression" would likely have to be reverted and re-commited/tested in order to do what you are presenting as "simply reverting".

[SinbadEV]

@forb

So you explain that new pathfinding features needed by non BA mods led to regression until unitdef are properly updated. So with unitdef update regression will be gone and pathfinding as good as before (in BA) ?

more like, pathing was broken but worked "OK" for most mods, pathing was fixed (a bit) but only if you fixed your movedefs, other mods and games changed their movedefs so they work but BA hasn't done so (apparently).

No offense but I think you lack accuracy in your explanation and I'd wish more concerned people try to answer.

That is your prerogative and I wish you luck in your future endeavours.

[smoth]

No offense but I think you lack accuracy in your explanation and I'd wish more concerned people try to answer.

I'll try and clarify as to calm this down.

Ba and many other spring projects were not doing their part to check that they did the unit and movedefs correctly. Things like: footprintx, footprintz can be conflicting in the unit def. if this happens, the unit pathing is screwed up.

here is the short version of what happens.

at load the movedef classes are used in the pathing calculation, this is what the unit thinks it can go over/through.

In game the unit def is what the unit actually can do.

- say a unit thinks it is larger than it is, it will avoid areas you know it can pass through.

- say a unit thinks it is smaller than it is, it will get stuck frequently because it thinks it can pass around it.

I recently wrote some code to help check the unit defs against movedefs but ba uses a .tdf for it's movedefs so it needs to convert before it can benefit from my code. Meaning all conflicts have to be checked manually. This leaves lots of room for errors.

does that help explain what he was saying?

[TheFatController]

I recently wrote some code to help check the unit defs against movedefs but ba uses a .tdf for it's movedefs so it needs to convert before it can benefit from my code. Meaning all conflicts have to be checked manually. This leaves lots of room for errors.

I have the output of this code, fixed all of the instances where a units footprint was bigger than its movedefs in BA in 7.20 but there's still a few things to fix but there's nothing major that should mess up pathfinding and the mismatches mostly affected Sea and T3.

t1 vehicles and kbots were never affected by this.

[Masure]

No offense but I think you lack accuracy in your explanation and I'd wish more concerned people try to answer.

I'll try and clarify as to calm this down.

Ba and many other spring projects were not doing their part to check that they did the unit and movedefs correctly. Things like: footprintx, footprintz can be conflicting in the unit def. if this happens, the unit pathing is screwed up.

here is the short version of what happens.

at load the movedef classes are used in the pathing calculation, this is what the unit thinks it can go over/through.

In game the unit def is what the unit actually can do.

- say a unit thinks it is larger than it is, it will avoid areas you know it can pass through.

- say a unit thinks it is smaller than it is, it will get stuck frequently because it thinks it can pass around it.

I recently wrote some code to help check the unit defs against movedefs but ba uses a .tdf for it's movedefs so it needs to convert before it can benefit from my code. Meaning all conflicts have to be checked manually. This leaves lots of room for errors.

does that help explain what he was saying?

You clearly explained that movedef values interact with pathfinding. Thanks !

But I have a few more questions :

- do previous pathfinding was incorrect as it dealed with bad values (BA ones) and still gave "good" results ?
- I found movedef specs both in LUA and TDF format. Is such a simple translation required ?

[CLASS0]
{
Name=KBOT1;
FootprintX=1;
FootprintZ=1;
MaxWaterDepth=15;
MaxSlope=36;
CrushStrength=5;
}

local moveDefs = {
KBOT1 = {
footprintx = 1,
footprintz = 1,
maxwaterdepth = 15,
maxslope = 36,
crushstrength = 5
}
}

- would corrected moveinfo values give as good results as before ?

[smoth]

- do previous pathfinding was incorrect as it dealed with bad values (BA ones) and still gave "good" results ?

previous pathing probably had a lot of expensive hacks to cover when the movedef and unit def conflicted. That is my guess. The current pathing is pretty decent but has issues where units are concerned. There are things like moving through dense woods that was impossible in the past(>1 year ago when I tried it). It really wasn't better persay I think this newer one is less forgiving but that is my perspective and not code based fact. I don't want to bullshit you here.

- I found movedef specs both in LUA and TDF format. Is such a simple translation required ?

to use the movedef check stuff I put up, yes, all that is required is a simple update on the part of ba. it will auto correct the conflicts forcing the movedef data on then unit. Which may result in undesired effects such as a unit suddenly having a larger or smaller footprint or different crushstrength. Which is why the infolog.txt will have a pile of warnings(you can ignore the warnings about the movedefs classes just worry about the unitdefs classes) waiting for you so you can make the discretionary changes which require a human being. your conversion looks correct btw.


I find that it is as good as before wrt to pathing around objects. I find unit to unit interaction to be different but I cannot say better or worse. I am not happy that units get stuck behind each other but I remember that happening in the past also. We still have the same issues of units forming a single file line and getting stuck behind a slower moving one .

[Forboding Angel]

I imagine that the main issues were with units over 2x2 footprint size. Also, as a point to note, it's ok to re-enable heatmapping again (make sure you test first before releasing with it re-enabled). Use the movedef heatmapping tags to control it and you can get some pretty fine tuned pathing behavior. It still isn't perfect, but it's 100% better than the old pathfinder already in the fact that you can actually configure it.

@masure, I'm not going ot bother to explain it to you as you wouldn't understand it anyway, but let me jsut say, your beef should be with the developer/maintainer of whatever game you're bitching about. In BA's case that would be TFC who has obviously put some effort into BA's move stuffage.

Coming here and just spouting off about something like this just makes you look dumb.

[AF]

Thats not true at all, the old pathfinder was massively better than the changes and the borkedness it caused, see here, this is the pathfinder at its 'height' before the change that broke everything:





Oh wait....

[AF]

And for lulz

[Otherside]

forb spouting the same shit over and over when the pathfinder is obviously borked makes you look like a douche.

no one is claiming that the old pathfinder was the greatest thing ever but at least it was functional and isn't prone to the retardedness of the current pathfinder.

The pathfinder has obvious problems apart from the stuff you have been mentioning.

Felony 1.

[AF]

*cough* AFs last 2 posts *cough cough*

The pathfinder was always broken, and so have numerous attributes of BAs movement, inherited from a stubborn caydr who refused to accept his setup was broken when mappers initially brought the subject up.

Cost of Reverting is huge
Cost of fixing is nowhere near as huge
Neither will result in perfect pathfinding anyway

[smoth]

The pathfinder has obvious problems apart from the stuff you have been mentioning.

Well then, enlighten all of us.

[Peet]

<images that do not actually represent pathfinding issues>