OXCE (OpenXcom Extended) main thread

[Yankes]

For now Meridian said that for now leave it as is.
https://github.com/Yankes/OpenXcom/commit/66d70f0ca7dd751e7c34cf296aaa0fe5d1f6839f
there some potential changes I plan to add in future.

[Delian]

Ok, I tested it and running diagonally now costs 4 tu as before. Thanks.

While testing, I found another change, unrelated, but still I think it's problematic.
Pathfinding in version 7.5.16 is worse than in 7.5.3

.sav file piratez v.M5.2

[Yankes]

I do not plan change it if whole path only differ by 1TU, at some point you need accept new behavior.

[Delian]

What about 3TU? So you're saying that bad pathfinding isn't an issue?

Edit: I should note that running and walking produces two different paths. Walking produces the same path as before (like in 7.5.3, a better path), but running produces a different, less-optimal path, so maybe the issue is there somewhere.

[Yankes]

Paths spend more than 50TU, 3TU diff is 6%, if it was 20TU or more then I could worry and consider this bug.

Simply as there is new way calculate cost there could be +/- 1 difference in some cases. And simply old paths now cost more because of this and game choose other.

[Delian]

I don't think you understand. The A-Star algorithm, Dijkstra etc., these are supposed to be optimal path algorithms. It means that they always produce the shortest/optimal path from point A to point B. There is no "only 6% difference". Either they find the shortest path, or they don't. And if they don't, it means they're broken/bugged/incorrectly implemented.

I spent an hour looking at the code, but I couldn't find what change caused the bug...
So for now, the best I can help is with providing a better save file and a few more screenshots.

[Delian]

3 screenshots:
- Walking from point A to point B. It finds the optimal path.
- Running from point A to point B. In version 7.5.3 it finds the optimal path.
- Running from point A to point B. In version 7.5.16 it doesn't find the optimal path.

[Delian]

3 screenshots:
- Walking from point A to point B. It finds the optimal path.
- Running from point A to point B. In version 7.5.3 it finds the optimal path.
- Running from point A to point B. In version 7.5.16 it doesn't find the optimal path. 15TU difference.

[Delian]

3 screenshots:
- Walking from point A to point B. It finds the optimal path.
- Running from point A to point B. In version 7.5.3 it finds the optimal path.
- Running from point A to point B. In version 7.5.16 it doesn't find the optimal path. Somewhat wobbly...

[Delian]

2 screenshots. Neither walking, nor running finds the optimal path. However, these two paths are NOT a bug in OXCE. This is an older bug that's also present in OXC. This bug is due to the fact that Bresenham Line is used before A-Star algorithm (A-Star never runs). The fix would be to run both Bresenham and A-Star, and only use Bresenham if both paths cost the same.

[Yankes]

I don't think you understand. The A-Star algorithm, Dijkstra etc., these are supposed to be optimal path algorithms. It means that they always produce the shortest/optimal path from point A to point B. There is no "only 6% difference". Either they find the shortest path, or they don't. And if they don't, it means they're broken/bugged/incorrectly implemented.

I spent an hour looking at the code, but I couldn't find what change caused the bug...
So for now, the best I can help is with providing a better save file and a few more screenshots.

And you do not understand what I mean.
I changed cost calculation that in some cases have different cost, this is base data that is used by Pathfinding.
If you change data then you change output. Paths from old version could cost more now and algorithms skip them for better ones.
You should at least prove that old paths are still best in new version.

Only case I will examine is one when you show difference of 15TU as this is lot bigger that it should be.

Beside if this is bug in Bresenham vs A-Star then its it will be probably up to Meridian if we keep this or change as this could affect gameplay (user probably more expect straight line move than some random moves around to save TU, this could be deadly if unit side step cover)

[Rangerh]

Question about the AI in OXCE.

Playing recently the 40K mod + Rosigma , but i don't think the mod modify the built-in AI.

I am starting to notice very often the AI is having a very strange very bad behaviour : it will try its best to maintain a long distance between the overall location of my troops and their own.
I mean at mission start there are AI troops spawning over the maps , i start to move from my entrance points.
And from there i notice that the AI troops that hadn't been killed have all moved toward the edges of the map, closer to the edge each time i progress to their direction.
So in the end they're out of my range and i am out of theirs, but they don't try to move to their attack range, they just randomly move around -while- staying all the time out of their or my weapon range.

I checked if by mistake i had enabled "Sneaky AI" as what i observe correspond exactly to what the "Sneaky AI" description is, but no, that setting is set to NO.

But still in every battle i have i observe the same AI behaviour (out of the kamikaze "leroy jenkins" type of enemies of course, at least this part of the AI do its job) everytime, the AI will progressively move toward the edge of the map while i am advancing, and never ever try to get in its own weapon range to attack me (or if i don't move toward them none will every shoot anymore).

Is there any way to get the AI trying to actually fight or is "Sneaky AI" wrongly enabled despite it is set to NO ?

[Yankes]

Hard to say, this could be combination of factors that cause this, like they do not run away but "patrol".

[Rangerh]

They seem to have some kind of patrol behaviour still, but they seems to always stop if they approach a certain distance to my troops and turn back. They always seem to maintain that distance , that happens to be right out of their weapon range so they never open fire.

It's been several battles now i have noticed this odd AI behaviour , the only AI that actually fight are the ones that are spawned not too far from my troops or that even if retreating are still in some kind of weapon range (as they're in range of my weapons and i'm in range of theirs), but once those enemies are cleared (and once every civilians are dead too), if i move i see the away AI enemies doing the retreat and "stay away" patrol dance forever after that. 

I'll have to replay some vanilla xcom again to see if the behaviour is indeed an OXCE problem or if there's something else at play in the 40k+Rosigma combination.

[Delian]

Beside if this is bug in Bresenham vs A-Star

Only the last two screenshots are a bug in Bresenham. The rest is a different pathfinding problem. Problem between walking and running.

Paths from old version could cost more now and algorithms skip them for better ones.

They cost the same. At least from what I can tell. Same TU usage for all tiles, only the path is different.

You should at least prove that old paths are still best in new version.

Sorry, what? You can easily see the best path on the screenshots, can't you?

I changed cost calculation that in some cases have different cost, this is base data that is used by Pathfinding.

I did look at those changes, but I think they were minor, and they also don't explain why walking and running produce two different paths. Logically the two paths should always be the same...

My best guess is that... when you moved the running cost multiplication from Pathfinding::previewPath() to Pathfinding::getTUCost(), it somehow caused the bug. But I can't confirm this or tell why.