OXCE (OpenXcom Extended) main thread

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

[Yankes]

Only the last two screenshots are a bug in Bresenham. The rest is a different pathfinding problem. Problem between walking and running.
They cost the same. At least from what I can tell. Same TU usage for all tiles, only the path is different.

This whole discussion was started because there was difference in cost, most glaring difference was fix and rest that differ become canonical version. This mean some specific moves cost different than before. And this in theory could cause that game choose different paths, and this is assumption I start this discussion.

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

And you show diff to old that its now irrelevant because cost could change it. If you show two paths from NEW version that prove game chose unoptimal path then this discussion will follow differently.

Yesterday I downloaded your save (what point was to set ironman in it??) and check what parths are generated, and in some cases game choose unopitmal ones. This look more like problem with A*.
I attached example of this bug, this on its own is enough to prove that somting is wrong with pathfanding, only difference was where I click not what version of game I was using or what move type I used. This was prof I was asking.

This mean you are correct that something is wrong with it.

btw thank you for detailed testing it.

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

It should produce different paths, different cost mean different paths, of corse as `run < walk` they should be very close to each other but rounding could make some paths better and other worse by +/-1 especially if there are tie in some variants.

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.

move of this code should not change any thing, it probably expose bug that already exist in it (aside of case where I did some very stupid error that cause all of this), and your detailed checking find it after it was exposed.

[BlackStaff]

Two small questions, please!

I use OXCE 7.5.3 + UNEXCOM. Like other packages, you have to add one or more pilots in the planes. Ok!
But when this plane is shot down, the name of the pilot does not go in the "Memorial of the missing"!
Is it possible to modify this fact?

I had "translated" on the site an information like that following an interception by a "HunterKiller", one could recover all or part of the crew of our shot down plane...
Did I "translate" correctly and is it active in OXCE ?

Thank you!

[Fomka]

I had "translated" on the site an information like that following an interception by a "HunterKiller", one could recover all or part of the crew of our shot down plane...

You have translated correctly. I have one occasion in X-Com Files mod for OXCE when a pilot was recovered automatically after his aircraft was destroyed. Just check BASES -> BASE INFORMATION -> TRANSFERS. Your pilot may be there, arriving at your base in about 96 hours.

And you should start a new thread for this question.

[pedroterzero]

Hi Meridian,

I hope I'm posting this in the right place -- I am trying to cross compile both OXCE and FtA from Linux using your instructions, but it seems I am probably doing something wrong. Can you point me in the right direction, or by any chance, does it fail for you in the same way currently? To clarify, I've tried this for both OXCE and FtA and neither are successful.

This is what is, I think, the relevant bit from the logs (I've also attached the full build logs for both OXCE/FtA below):

Code: [Select]

[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/State.cpp.obj
[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Surface.cpp.obj
[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/SurfaceSet.cpp.obj
[ 41%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Timer.cpp.obj
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Unicode.cpp.obj
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Engine/Zoom.cpp.obj
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Geoscape/AlienBaseState.cpp.obj
/app/src/Engine/Unicode.cpp: In function 'bool OpenXcom::Unicode::naturalCompare(const string&, const string&)':
/app/src/Engine/Unicode.cpp:607:100: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'WinStrCmp' {aka 'int (*)(const wchar_t*, const wchar_t*)'} [-Wcast-function-type]
  WinStrCmp pWinStrCmp = (WinStrCmp)GetProcAddress(GetModuleHandleA("shlwapi.dll"), "StrCmpLogicalW");
                                                                                                    ^
[ 42%] Building CXX object src/CMakeFiles/openxcom.dir/Geoscape/AllocatePsiTrainingState.cpp.obj
In file included from /app/src/Engine/Zoom.cpp:51:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:217:1: error: redefinition of 'unsigned int __get_cpuid_max(unsigned int, unsigned int*)'
 __get_cpuid_max (unsigned int __ext, unsigned int *__sig)
 ^~~~~~~~~~~~~~~
In file included from /opt/mxe/usr/x86_64-w64-mingw32.static/include/intrin.h:70,
                 from /app/src/Engine/Zoom.cpp:46:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:217:1: note: 'unsigned int __get_cpuid_max(unsigned int, unsigned int*)' previously defined here
 __get_cpuid_max (unsigned int __ext, unsigned int *__sig)
 ^~~~~~~~~~~~~~~
In file included from /app/src/Engine/Zoom.cpp:51:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:272:1: error: redefinition of 'int __get_cpuid(unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)'
 __get_cpuid (unsigned int __leaf,
 ^~~~~~~~~~~
In file included from /opt/mxe/usr/x86_64-w64-mingw32.static/include/intrin.h:70,
                 from /app/src/Engine/Zoom.cpp:46:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:272:1: note: 'int __get_cpuid(unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)' previously defined here
 __get_cpuid (unsigned int __leaf,
 ^~~~~~~~~~~
In file included from /app/src/Engine/Zoom.cpp:51:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:289:1: error: redefinition of 'int __get_cpuid_count(unsigned int, unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)'
 __get_cpuid_count (unsigned int __leaf, unsigned int __subleaf,
 ^~~~~~~~~~~~~~~~~
In file included from /opt/mxe/usr/x86_64-w64-mingw32.static/include/intrin.h:70,
                 from /app/src/Engine/Zoom.cpp:46:
/opt/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/8.4.0/include/cpuid.h:289:1: note: 'int __get_cpuid_count(unsigned int, unsigned int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)' previously defined here
 __get_cpuid_count (unsigned int __leaf, unsigned int __subleaf,
 ^~~~~~~~~~~~~~~~~
make[2]: *** [src/CMakeFiles/openxcom.dir/build.make:2462: src/CMakeFiles/openxcom.dir/Engine/Zoom.cpp.obj] Error 1
make[2]: *** Waiting for unfinished jobs....