Author Topic: Brutal-OXCE 9.1.4  (Read 54920 times)

Offline Abyss

  • Colonel
  • ****
  • Posts: 355
    • View Profile
Re: Brutal-OXCE 8.0.0
« Reply #120 on: December 31, 2023, 07:29:52 pm »
I never done so, but this particular year really want to wish this particular thread all-prosper and break the limits! To Xilmi: thank you for everything you've done so far. We really appreciate your input! Have a best 2024!

Offline Alpha Centauri Bear

  • Colonel
  • ****
  • Posts: 466
    • View Profile
Re: Brutal-OXCE 8.0.0
« Reply #121 on: December 31, 2023, 11:13:34 pm »
Joining the holiday celebration.
I had a real fun rediscovering this game and BAI in particular. Wish everybody prosperous enough life to have time for beloved games!

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 641
    • View Profile
Re: Brutal-OXCE 8.0.0
« Reply #122 on: January 01, 2024, 09:01:05 pm »
There's a bug in 8.0.1 that makes it very very likely to crash when you end a mission. It happens both when you finish it or choose save and abandon game. The save does not corrupt though.

It also randomly crashes during enemy turns so I had to revert to 7.13.1. It was crashing constantly so it is not really playable.
Damn. That's horrible to hear.  :'(

So now it's not only that I have to redo the merge and hope to not break the hangars again but also look for the reason or even reasons of a crashes.

Do you happen to have savegame(s) from just before crashing? It could potentially be related to going from 32 to 64 bit. But could also have other reasons. I had some weird issues related to pathfinding-destructor.

Offline donk

  • Sergeant
  • **
  • Posts: 37
    • View Profile
Re: Brutal-OXCE 8.0.0
« Reply #123 on: January 01, 2024, 11:47:24 pm »
Damn. That's horrible to hear.  :'(

So now it's not only that I have to redo the merge and hope to not break the hangars again but also look for the reason or even reasons of a crashes.

Do you happen to have savegame(s) from just before crashing? It could potentially be related to going from 32 to 64 bit. But could also have other reasons. I had some weird issues related to pathfinding-destructor.
No it's gone since I reverted. But it should have happened to you for sure so it might be something else.

The only way I could finish a mission was to save and let it crash, then reload and finish it on the same turn. If I passed a turn and finished a mission it would crash again.

The only difference in settings from previous version was that I enabled the new base stats. I also play on lvl 3 ironman and I have some XCF sub mods if you think that matters.

The random crash in the enemy turn was when projectiles were flying so it might be related to the path finding. I did not play long enough to see if it crashed in my turn.

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 641
    • View Profile
Re: Brutal-OXCE 8.0.1
« Reply #124 on: January 02, 2024, 12:26:19 am »
I guess I'll just have to play-test a lot including actually finishing missions in a real game and not just Mission-generator-missions and try to see if it happens for me too.
If it doesn't, I'll make a 32- and a 64 bit-version of 8.0.2 so you can see whether this makes a difference for you.

Saw the crash happen in a private stream from someone else.

Noteable was: He was playing with Ironman and it happened when he was doing Save&Exit. It also happened during a Terror mission. So possible necessary conditions are: Ironman and/or a neutral faction existing.

So this is the direction I'll investigate tomorrow for reproducing it.
« Last Edit: January 02, 2024, 02:25:59 am by Xilmi »

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 641
    • View Profile
Re: Brutal-OXCE 8.0.0
« Reply #125 on: January 02, 2024, 12:13:05 pm »
A thought that struck me: how does Brutal AI handle the situation when an enemy is given at least two weapons, and the better one suffers from the two-handed penalty? Or they both do? Or they get something like four handguns with different stats/ammo? How do they choose? Do they choose? And, most importantly, how do they avoid the two-handed penalty manage to use two-handed-only weapons in this situation, if at all? Something like a rocket launcher, an axe and a pistol all at the same time.
The way "multiple weapons" are handled via the AI-API is not really fleshed out. Most likely because the vanilla-AI can't do that at all. They just determine their "main-hand-weapon" and then go ahead using it. The main-hand-weapon is determined by looking at the right and left hand. If there's a weapon in each it'll pick the one that requires fewer TUs for a basic attack. Additional weapons are ignored. That's how, for example the Lobsters in TFTD don't know they have a melee-attack and the little saucer-terrorist in TFTD don't know they have a ranged-attack.
Even with the grenade-usage, the AI doesn't actually change the slot the grenade is in. It just pays the TUs it would cost to move it to the hands ontop of the priming+throwing-cost.

Brutal-AI isn't limited like that. It iterates through all weapons and all fire-modes a unit has and picks the one that it thinks has the best damage per TU, which dynamically can alter by the enemies's armor and distance.

However, the API doesn't switch weapons. There is a "BattleAction"-object which has a weapon-pointer and an action-type, which the AI populates. There are no checks whether that weapon is in a hand. It just uses it from whereever it is.  I actually don't know whether the 2-h-penalty is applied if there's 2 items in hands.

Changing how it works would require some modification of the AI too. It would have to take all that stuff into consideration that it currently doesn't. It definitely seems to have been designed around units who have exactly one weapon. So the behavior for units that deviate from that is not properly handled or even defined.

Offline Alpha Centauri Bear

  • Colonel
  • ****
  • Posts: 466
    • View Profile
Re: Brutal-OXCE 8.0.1
« Reply #126 on: January 02, 2024, 06:13:05 pm »
Request for different arrow color for "last spotted enemy location".
I see that you use different colors already but they are very similar: bright yellow and darkish yellow. Even if I can distinguish them by staring into screen it would be nicer to have completely distinct colors to not strain my eyes. Any other but yellow would do.
😀

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 641
    • View Profile
Re: Brutal-OXCE 8.0.1
« Reply #127 on: January 02, 2024, 06:33:41 pm »
Could anyone else reproduce the crash and has a save from shortly before?
I've been trying to catch a crash for an hour now and it simply doesn't happen on my side. :\

Maybe it was related to something in OXCE 7.10.1 and it is fixed since I updated to OXCE 7.10.3. I'll check the notes if something like that could be the case. Really doesn't look like it. None of the commits mention fixing anything.

Oh, and trying to run XCF fails because of a change in OXCE 7.10.3 actually. :o

Edit: Okay, I had the crash happen now. Once. And it wasn't reproducible from the auto-save the turn before. It happened after losing a mission in XCF that lasted roughly 10 turns.

The crash happened at a very odd place. At the destructor of Pathfinding::~Pathfinding() or respectively deep in some dlls that run after that.

I don't have an idea what I could change to fix it or how to test potential fixes. The main-issue being how much I struggled with reproducing it even just once. If it would happen all the time, it would be much easier.

So I guess I'll go back to 32 Bit and we just play a lot and if it doesn't happen again, we assume that it's related to that.

If it still happens, it could be related to the code that determines whether a spotter should be used, which uses path-finding. But I don't really get why it would crash at the end of the mission then.
« Last Edit: January 02, 2024, 08:28:15 pm by Xilmi »

Offline Abyss

  • Colonel
  • ****
  • Posts: 355
    • View Profile
Re: Brutal-OXCE 8.0.1
« Reply #128 on: January 03, 2024, 06:49:28 pm »
Could anyone else reproduce the crash and has a save from shortly before?
I've been trying to catch a crash for an hour now and it simply doesn't happen on my side. :\
Hi!
I can confirm the game crashes when you press save&abandon the mission when playing Ironman. The game crashes to windows. But should leave to main menu. The issue may overlay with what donk has described.
The save is attached.

Actually, I also want to complain on BAI, which in 8.0.1 has only one aggressiveness adjustment. And when set to "baseline" it is not competitive at all. Enemies all lurk, doing only 30% of possible damage. And I still cannot switch it to "baseline + modder-set", because ruleset numbers for VAI are not good (actually, very bad) for BAI.

The suggestion was to make BAI consider ruleset aggressiveness as multiplicator, rather than surplus. So, 0.5 aggressiveness will make unit more cautious, while 4.0 will make it rush like devil. Then, I can run around the ruleset numbers and make tuned unit-aggressiveness submod for XCF.
It also can be very purposeful to look at current formula of the aggressiveness-related weights. 

The advanced suggestion is to make BAI consider a range of aggressiveness as multiplicator.
For example, RUL file can contain diapason (like, aggressiveness: 1,0/1,8 - for min and max), from which BAI can randomly pick and assign aggro for each given unit on map. That can make some interesting results. Of course, this unit.RUL mod will be used for BAI solely, excluding VAI gameplay.

This also can be under additional +number in settings, no need to replace options for aggressiveness, that are already there.
 
« Last Edit: January 03, 2024, 07:11:29 pm by Abyss »

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 641
    • View Profile
Re: Brutal-OXCE 8.0.1
« Reply #129 on: January 03, 2024, 08:02:39 pm »
I can confirm the game crashes when you press save&abandon the mission when playing Ironman. The game crashes to windows. But should leave to main menu. The issue may overlay with what donk has described.
The save is attached.
I could reproduce it once myself. With 8.0.2 I now provided a 32-bit-version again. Unfortunately the issue was not reproducible enough to do good testing or be confident that it's a 64-bit-issue. I do, however think it's quite likely it is. So it would be nice if the people for who it crashed frequently in 8.0.1 could try whether the crashes stop with the Win32-variant.

Actually, I also want to complain on BAI, which in 8.0.1 has only one aggressiveness adjustment. And when set to "baseline" it is not competitive at all. Enemies all lurk, doing only 30% of possible damage.
This sounds odd. They should be competitive regardless of aggressiveness. I do a lot of playtesting and when I play 14 Soldiers with regular guns, a grenade and a smoke against a Large Scout with lowest tech Sectoids I get a close battle. The cases where higher aggressiveness made it harder were the ones where the Aliens spawned right outside of the Skyranger. For this case the spotter-logic works in the sense that they are willing to expend the TUs of one of theirs to spot people inside and shoot inside.

For determining competetitiveness I also usually use benchmark-scenarios to make it as comparable as possible. Missions with vastly varying team-compositions are not helpful for comparative testing. So can you confirm that you have indeed tested with the same starting-save or very similar conditions when you found a reduction of damage to only 30% of "possible damage". Or how did you determine what amount of damage is possible?

Enemies should attack when they can. Whether they reserve TUs for hiding after attacking or keep attacking until they can't anymore is determined by the quality of available cover.

The idea of the introduction of the spotter-logic is to create a situational logic that determines when a unit should actually push rather then using some sort of non-situational value for that. The overall tactical idea is that all units push towards the location that is closest while still providing the most safety and then inviestigate the situation via peeking until it looks most opportune to ambush the enemy.

Note that there was a bug which is fixed in 8.0.2:
"Fixed an issue with the spotter-determining-code that caused the spotter to think their friends would always have enough weapon-range."

This caused units to think they should be spotters when becoming one wasn't a viable option, making them walk into reaction-fire without their allies being capable of providing significant assistance.

And I still cannot switch it to "baseline + modder-set", because ruleset numbers for VAI are not good (actually, very bad) for BAI.

The suggestion was to make BAI consider ruleset aggressiveness as multiplicator, rather than surplus. So, 0.5 aggressiveness will make unit more cautious, while 4.0 will make it rush like devil. Then, I can run around the ruleset numbers and make tuned unit-aggressiveness submod for XCF.
It also can be very purposeful to look at current formula of the aggressiveness-related weights. 

The advanced suggestion is to make BAI consider a range of aggressiveness as multiplicator.
For example, RUL file can contain diapason (like, aggressiveness: 1,0/1,8 - for min and max), from which BAI can randomly pick and assign aggro for each given unit on map. That can make some interesting results. Of course, this unit.RUL mod will be used for BAI solely, excluding VAI gameplay.

This also can be under additional +number in settings, no need to replace options for aggressiveness, that are already there.
A min- and max-floating-point number for absolute aggressiveness in the rul-file would probably be the best solution when it comes to handing control to the modder. The idea of a variable multiplier was more for experimentally determining suitable values but not nice for the player who didn't know what to set it to. Alternatively there could also be fixed multiplier to the values from the rul-files that allows a much bigger range without the need to change the structure. For example with a multiplier of 0.1 and valid values from 1-100 or so there also would be a lot of variety. But this would of course lack the advantages of having a separate min- and max-value.

Offline Abyss

  • Colonel
  • ****
  • Posts: 355
    • View Profile
Re: Brutal-OXCE 8.0.1
« Reply #130 on: January 03, 2024, 08:46:31 pm »
So can you confirm that you have indeed tested with the same starting-save or very similar conditions when you found a reduction of damage to only 30% of "possible damage". Or how did you determine what amount of damage is possible?
Yeah, I can. This previous savefile I attached is the mission that I tried multiple times with various aggro settings. The 7.13.1 where I set recommended 1/2 "baseline" + modder-set squashed my units in 10 turns, just because every enemy attacked simultaneously, minotaurs rushed with macro-flamers and axes (actually, I love how BAI prefers macro-flamers instead of melee option). Also, BAI thrown more grenades. I was lacking ifrepower and had to decide whether I should fire or reserve TU's for incoming enemies. None would help, because it's map with 50 enemies.
 
The one in 8.0.1, where I had chosen only baseline, I had it easily won. Even so it was pushing first 2-3 of turns, the battle changed fast towards reaction fire and killing of small waves of some attacking guys, while others were hiding inside the buildings on the map edges (away from actual combat area). Thus, overall enemy push was noticeable, but quite dealable.
The panic spiral of enemies started soon after, so past turn 12 the game became one-side beating.

I am sure that in some scenarios 0-1 aggressiveness is definitely purposeful. But clearly not in case of battles vs x3 enemies (of same power), where rushing strategy for AI is better. 

Quote
This caused units to think they should be spotters when becoming one wasn't a viable option, making them walk into reaction-fire without their allies being capable of providing significant assistance.
Well, that mission was pain in the ass (I dealt it 4 times, lost badly 3 times and easily won on 4th). It usually spawns in mountains/open field, but now spawned in close urban area. That is why sniper-rifle loadout was wrong. I clearly don't wan't to play it again to check.

The thing angered me was when BAI in two turns thrown 5 units through the same door, which had exit tile in reaction-sight of my snipers. That was enough to get that something goes wrong with decision making.

Quote
For example with a multiplier of 0.1 and valid values from 1-100 or so there also would be a lot of variety.
Well, the 4 for max aggressiveness is arbitrary number to which everyone got used to. And it was introduced by you.
I think simpler is better. So, if you chose this over min-max range, no trouble. 
 
The question is: should every unit on the map be of same picked aggression, or statistically different by min-max.
Theoretically, if same, then missions overall will feel different, which is good.
If min-max in same battle, then bunch of attackers, bunch of lurkers and so on. Which will result in force split. Which, in its turn, will lead to lose of competitive power. In theory. I don't know what will happen during real gameplay, given all these advances in BAI decision making. 

Quote
for experimentally determining suitable values but not nice for the player who didn't know what to set it to
Yep. I am going to make a submod, so players don't have to do anything.
I'll do it right ahead after getting the understanding of actual/final decision weights.   
So that would be great to chat on them and/or look at formulas, if you share the lines where to look at and how to understand them.

But then, approach should be verified, at least not drastically changed every new version.

UPD don't take my whining about "AI is too easy" and "AI is too strong" as bipolar disorder.
I am looking for balance that kicks my ass, but yet is possible to beat:)
« Last Edit: January 03, 2024, 09:20:26 pm by Abyss »

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 641
    • View Profile
Re: Brutal-OXCE 8.0.2
« Reply #131 on: January 03, 2024, 11:57:23 pm »
Bad news:

8.0.2 also can crash in deconstructor of Pathfinding. Apparently regardless of whether Win32 or x64 is being used. I was playing all evening 5 missions no problem. 6th mission crash at the end when _battleGame and subsequently _pathfinding are deleted.

The good news is that once I find the actual cause, I can go back to 64 bit. The bad news is that I still need to find it. What I changed was that I now also call getReachableBy for friendly units in order to determine whether a unit that checks whether it becomes a spotter would get support or not.

But the functionalty works and it doesn't crash where it's used. Only when the mission ends, which is the part I don't understand. :\

I also don't really just want to remove this feature that I considered a big enough step to warrant a new major-version. Especially not without understanding how that can cause an issue like that.

Online Yankes

  • Commander
  • *****
  • Posts: 3309
    • View Profile
Re: Brutal-OXCE 8.0.2
« Reply #132 on: January 04, 2024, 12:07:58 am »
Simply some code indirectly access it. There is lot of processing after mission end. And of of function doing something else call your function.
Like there is function that do A, B and C, where A and B is needed for mission end but C that is not needed require checking patfinding.

Beside you you not have debugger that stop when crash happens? you should have function backtrack of crash site and see from where
this code is called.

Some times fix is simply add `if` in strategic position, there is lot "fix" like this already in OXC and OXCE (I prefer less hacky solution but some times it impossible).

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 641
    • View Profile
Re: Brutal-OXCE 8.0.2
« Reply #133 on: January 04, 2024, 02:05:11 am »
Beside you you not have debugger that stop when crash happens? you should have function backtrack of crash site and see from where
this code is called.
Well, the last code inside of non-external libraries when the crash happened was inside of SavedBattleGame::~SavedBattleGame() at the call of "delete _pathfinding".

I just put out an 8.0.3, in which I simply made the deconstructor of SavedBattleGame empty. This fixed the crash for me.

The most common reason for crashes is dereferencing null-pointers. That's very easy to find and fix with the MSVS-debugger. This kind of issue here was a bit special though.

I noticed that other deconstructors, like Pathfinding, for example, also don't contain any code. I haven't kept up with how C++ changed over the years. My assumption is that manually deleting stuff inside of deconstructors isn't really necessary with modern compilers.

And since making a false claim is the best way to learn something on the internet because it will trigger someone to come out and correct me, I'll just claim that this is the case and therefore just deleting the contents of the destructor was the right way to fix the issue.

Offline donk

  • Sergeant
  • **
  • Posts: 37
    • View Profile
Re: Brutal-OXCE 8.0.3
« Reply #134 on: January 04, 2024, 03:32:55 am »
I've tested 8.0.2 32 and 64 bit today. No crashes and 64 bit is noticeable faster. Good shit.