Author Topic: OXCE (OpenXcom Extended) main thread  (Read 291229 times)

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 2838
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1140 on: June 26, 2022, 02:23:54 pm »
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.

Offline BlackStaff

  • Colonel
  • ****
  • Posts: 319
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1141 on: June 28, 2022, 01:06:40 pm »
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!

Offline Fomka

  • Colonel
  • ****
  • Posts: 133
    • View Profile
    • Email
Re: OXCE (OpenXcom Extended) main thread
« Reply #1142 on: June 28, 2022, 04:14:03 pm »
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.

Offline pedroterzero

  • Sergeant
  • **
  • Posts: 28
    • View Profile
    • Email
Re: OXCE (OpenXcom Extended) main thread
« Reply #1143 on: June 29, 2022, 01:35:43 am »
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....
« Last Edit: June 29, 2022, 01:36:41 pm by pedroterzero »

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 2838
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1144 on: June 29, 2022, 03:06:54 am »
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.
After fixing this bug answer that algorithm correct find "fastest" path, trick was that cost had weight based of distance to target that for running or when your reduce cost of move it become screw too much and will miss real fastest path.

Offline Delian

  • Colonel
  • ****
  • Posts: 228
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1145 on: June 29, 2022, 10:52:12 am »
Ok, let me test...

...the 1st and 3rd cases were fixed. The 2nd case (with 15 TU difference) still fails to find fastest path.

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 2838
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1146 on: June 29, 2022, 11:50:12 am »
This probably stay as is, if straight path exist then it will be choose even if cost more, this is manly for control, when you want move unit precisely.

As this is part of UIX this will require Meridian blessing to change it.

Offline Delian

  • Colonel
  • ****
  • Posts: 228
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1147 on: June 29, 2022, 01:25:07 pm »
As this is part of UIX this will require Meridian blessing to change it.

I've attached another screenshot. Can you confirm that the path that's used in this screenshot uses Bresenham? I think here it uses A*...

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 2838
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1148 on: June 29, 2022, 01:33:10 pm »
Yes, it should use it there. You can test it by move starting point that it could not make "line path" then it will choose more effective one.

Offline Delian

  • Colonel
  • ****
  • Posts: 228
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1149 on: June 29, 2022, 02:47:37 pm »
Ok, yeah, it does use Bresenham.

But you know, Bresenham isn't used for "precision and control". It's used mainly in cases of diagonal flying, so that you get a zig-zag path instead of two long lines (one straight and one diagonal). If I wanted precise control, then I'd just move a unit 1-2 tiles at a time. But yeah, when multiple optimal paths exist, Bresenham line is preferred. But if Bresenham is not the optimal path, then it should not be used.

It's kinda funny because the code in Bresenham is like.. if (... tuCost == lastTUCost ...), basically, to check if bresenham is optimal path, the function only checks if there were any changes in movement cost from one tile to the next, so if you're running on expensive terrain (tall grass / wheat fields) the whole time, it won't notice any changes. But if it detects changes in the cost, then Bresenham will say "I'm not optimal path, don't use me". I've attached a screenshot where you can see that a straight line exists, but because there's one cheaper tile in between, it detects this change in cost and then A* is used instead.

Anyway, yeah, since that's an OXC bug, it's up to Meridian to decide what to do with it.

Offline Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 7722
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1150 on: July 04, 2022, 07:27:44 pm »
I think you could've done the same for energy
const auto energyCost = (cost.EnergyPercent - 1 + costDiv / 2) / costDiv;

For now Meridian said that for now leave it as is.

I have tested the compatibility with this earlier TFTD-compatibility fix: https://github.com/MeridianOXC/OpenXcom/commit/ff3ac8d8ada2a838bf525df2caf2dab78adac9f6

As far as I can say, it works well.

So, from my side, we can change also the Energy formula to be the same as the new TU formula.

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 2838
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1151 on: July 04, 2022, 07:43:17 pm »
Ok

Offline Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 7722
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1152 on: July 05, 2022, 04:15:32 pm »
Anyway, yeah, since that's an OXC bug, it's up to Meridian to decide what to do with it.

There is no right or wrong answer here, so I'll just share my opinion.

The original game doesn't find the optimal path either.
Without any hard evidence, I'd guess that it was a deliberate design decision... to provide players with more natural paths instead of the cheaper ones (at all costs).
(Optimal path algorithms were already well known in the 1990's and they were not too memory- or cpu-intensive.)

It's kinda funny because the code in Bresenham is like.. if (... tuCost == lastTUCost ...), basically, to check if bresenham is optimal path, the function only checks if there were any changes in movement cost from one tile to the next, so if you're running on expensive terrain (tall grass / wheat fields) the whole time, it won't notice any changes. But if it detects changes in the cost, then Bresenham will say "I'm not optimal path, don't use me". I've attached a screenshot where you can see that a straight line exists, but because there's one cheaper tile in between, it detects this change in cost and then A* is used instead.

This was definitely a deliberate decision from OXC devs.

OXC changed (I am intentionally not using the word "improved") the pathfinding algorithm to produce more TU-optimal paths.
But in a decent number of cases, TU-optimal paths differ from natural paths, which irritates a lot of people (including myself), and so the compromise you described above was made to produce more natural paths again (although not as many as the original game).

One example for all: when you start your very first mission and tell your very first rookie to go down the Skyranger ramp:
1/ the original game will take the straight natural path (as everybody would expect I hope)
2/ openxcom will take a funny, unrealistic path involving a jump down from the ramp... that both looks bad and in reality should cost a lot more than just walking down the ramp

(Let me just repeat that... the very first command you issue as an xcom commander on a battlefield, is executed differently in openxcom than most of us would expect. I can only guess how much this bothered OXC devs and how painful the compromise must have been. I definitely don't envy them.)

I personally prefer natural paths, which give me more precision-control as Yankes said, without too much hassle.
And they look better too.
That's why if I could choose how to fix this issue, I'd revert back to the original algorithms from 1994 and not use openxcom algorithms.

But breaking compatibility with openxcom would cause me more trouble (from all the nitpickers around) than it's worth... so at the end, I will compromise too and not do anything.

Offline Delian

  • Colonel
  • ****
  • Posts: 228
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1153 on: July 05, 2022, 10:46:23 pm »
Thank you for the explanation. It's ok then.

The bug in bresenham can be worked around by players because it's easy to see if you're walking on expensive terrain or not. So for people (myself included) who prefer TU-optimal paths over straight paths, it shouldn't be much of an issue.

As far as the original pathfinding goes, I think back then pathfinding algorithms weren't as good as they are today, and that was the main reason for the straight paths. Perhaps OXC devs saw this, and that's why they chose to use an improved one instead. I can't say what is or isn't expected, or what l looks good/bad, but in reality, walking down a ramp should cost less than walking up the ramp hehe~
« Last Edit: July 05, 2022, 11:06:37 pm by Delian »

Offline Valerra

  • Squaddie
  • *
  • Posts: 6
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1154 on: July 06, 2022, 06:12:06 am »
I got this error on loading OXCE 7.53
"Error for 'ALIEN_PSI_WEAPON': Wrong index 36 for sound set BATTLE.CAT"

and many more similar errors in log file.

What's wrong?

maybe the reason is i don't have any sound device. OXCE 7.3 version is Ok