aliens

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

Online Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 2968
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1140 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: 233
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1141 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: 7955
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1142 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.

Online Yankes

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

Offline Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 7955
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1144 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: 233
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1145 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 #1146 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

Offline Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 7955
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1147 on: July 07, 2022, 12:16:48 pm »
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):

Hi,

I don't have this setup locally anymore, I'd need to install everything again...

But we have this setup on the build farm (maintained by Stoddard) running fine for some years now.

The build farm is also building FtA, most likely using the same setup (https://lxnt.wtf/oxem/#/FTA), but Stoddard or Finnik should confirm.

Offline Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 7955
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1148 on: July 07, 2022, 12:18:07 pm »
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

Should be fixed in v7.5.19

See also: https://openxcom.org/forum/index.php/topic,10541.msg147434.html#msg147434

Offline Rangerh

  • Colonel
  • ****
  • Posts: 114
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1149 on: July 08, 2022, 08:32:58 pm »
A question about the "sickBayAbsoluteBonus" and "sickBayRelativeBonus"

On a game with the 40k/Rosigma  i have some troops with extreme recovery time a bit too often (that's because 40k/Rosigma troops have a lot of HP so they endure a lot more wounds ingame).
So i checked https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom)#Base_Facilities

Found that those sickbay could be interesting to work around the problem. So i added

sickBayAbsoluteBonus: 0.0
sickBayRelativeBonus: 10.0

To the STR_ACCESS_LIFT entry (that is found in terrain_40k.rul file from the 40k mod folder) , as it's the basic facility that every underground base will have from the start.
According to the ufopedia website entry , this should means the building provide a healing bonus of 10% by day, so it should mean my troops would all be healed in a maximum of 10 days.

But after more testing, it is not the case, the recovery time is going at a normal rate (i mean the same as if i had not added the sickbay entries)
To test more, i increased sickBayRelativeBonus: 10.0 to  50.0 , so any wounded unit should be healed at max in 2 days if i understand the ufopedia website explaination.
But again after testing ingame, i see the soldiers only recovering at a normal rate (after several days the high wounded still have a high recovery time).

Any idea at what am i doing wrong ?

« Last Edit: July 08, 2022, 08:36:31 pm by Rangerh »

Offline Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 7955
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1150 on: July 09, 2022, 02:09:47 am »
it works fine for me... you have a syntax error (or equivalent) somewhere

Offline Rangerh

  • Colonel
  • ****
  • Posts: 114
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1151 on: July 09, 2022, 11:31:52 am »
Does not seem to be a syntax error
Code: [Select]
facilities:
  - type: STR_ACCESS_LIFT
    spriteShape: 2
    spriteFacility: 17
    lift: true
    provideBaseFunc: [BASE]
    buildCost: 300000
    buildTime: 1
    monthlyCost: 4000
    sickbayAbsoluteBonus: 0.0
    sickbayRelativeBonus: 50.0
    mapName: XBASE_00

I even added the sickbay lines to the living quarters in case but still the troops are healing at a normal rate.
Code: [Select]
  - type: STR_LIVING_QUARTERS
    requiresBaseFunc: [BASE]
    spriteShape: 1
    spriteFacility: 18
    buildCost: 400000
    buildTime: 16
    monthlyCost: 10000
    sickbayAbsoluteBonus: 0.0
    sickbayRelativeBonus: 50.0
    personnel: 50
    mapName: XBASE_01

I really don't understand why this is, i searched in case buildings were also defined somewhere else in the 40k and Rosigma folders, but no it's only in this terrain_40k.rul file from the 40k mod folder (there's no building definition in the Rosigma mod folder itself)
So i'm completely clueless at why it does not work.

Then i went to the codex (the ufopedia name for the 40k mod) and gave a look to the living quarter debug and default and noticed maybe why things are not working :

and it's the same for the access lift
Huh ?  the modification seems correct in the terrain_40k.rul but ingame it does not take them in account ?

Offline Rangerh

  • Colonel
  • ****
  • Posts: 114
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1152 on: July 09, 2022, 03:13:00 pm »
Ok, i went with a different approach, adding a "Medical Unit" facility as a submod instead of editing the facilities from 40k/Rosigma

So i have in my user\mods\ folder , one that is named "HealUP"
Inside of it i have metadata.yml
Code: [Select]
#
# metadata.yaml for Heal UP for 40k

name: "Heal UP for 40k"
version: 1.0
description: "Provide an early basic medical facitily."
author: OpenXcom

master: "40k"

I have a HealUP.rul (with intentional very low building time and very high sickbayRelativeBonus for easier testing)
Code: [Select]
facilities:
  - type: STR_EARLY_TREAT
    spriteShape: 1
    spriteFacility: 18
    buildCost: 400000
    buildTime: 1
    monthlyCost: 10000
    sickbayAbsoluteBonus: 0.0
    sickbayRelativeBonus: 50.0
    maxAllowedPerBase: 1
    mapName: XBASE_01

ufopaedia:
  - delete: STR_EARLY_TREAT
  - id: STR_EARLY_TREAT #facility
    type_id: 16
    section: STR_BASE_FACILITIES
    image_id: 01.SPK
    text: STR_EARLY_TREAT_UFOPEDIA

a Language sub folder that has the  en-US.yml
Code: [Select]
en-US:
STR_EARLY_TREAT: "Medical Unit"
STR_EARLY_TREAT_UFOPEDIA: "{NEWLINE} Provides some basic medical assistance to the base personel."

Then i enabled the mod with 40/Rosigma.
Ingame the submod works as i can build a new facility named "Medical Unit"
Spoiler:

It has codex entry
Spoiler:

But if i go to the Info then enable DEBUG and DEFAULT, it does not take in account that this building has sickbayRelativeBonus: 50.0 (i even tried other value, and even some reasonnable ones)
Spoiler:

I was wondering maybe the ufopedia/codex simply does not display the correct value but still the game apply them ?
So i checked with my high HP high wounded units, like "Vaitai Trasea" that for my save is at 60 days of recovering
Spoiler:

Then i let 4 or 5 days going, according to sickbayRelativeBonus: 50.0 , it means the trooper should be healed in max 2 days, but it is not the case, as after several days, this guy is at 55 days of recovering
Spoiler:

So at that point i'm really completely puzzled as to why it's not working, as the log does not show any error , any help please ?

« Last Edit: July 09, 2022, 03:14:52 pm by Rangerh »

Offline Delian

  • Colonel
  • ****
  • Posts: 233
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1153 on: July 09, 2022, 03:20:19 pm »
Maybe because it's "sickBay" and not "sickbay".

Offline Rangerh

  • Colonel
  • ****
  • Posts: 114
    • View Profile
Re: OXCE (OpenXcom Extended) main thread
« Reply #1154 on: July 09, 2022, 04:35:42 pm »
THANK YOU !

Can't believe it was such a basic mistake, but correcting "b" into "B" worked !
Thank you a lot, not understanding why it was not working was maddening .