Brutal-OXCE 9.1.4

[kelltozet]

In a case like this isn't it even smarter for the AI to force the player to be more active and prolong the mission?

Sometimes, it's actually pretty smart for AI to play the defensive role. Especially since Brutal AI is so good at finding cover.
But is it always fun for the player to play on the offensive side? Well, for some people, it might be. But personally, I like a more balanced approach.

There should still be the option to set the Aggressiveness of the enemy-AI to "Inherit aggressiveness". But in a situation like on the screenshot above I'm not sure how much this will do.

I tried tweaking the aggression levels of units in the .rul files, but I didn't notice much difference between 1 and 8.
Maybe the effect of the aggression parameter should be bigger.

Another problem is that the enemy does not use numerical superiority when acting defensively.
Here is my current mission in the screenshots (1.png 2.png).
My squad is made up of 9 good quality fighters
The enemy has about 8 dogs, 25 low tier infantrymen and 2 machine-gun armored cars.

On my first turn, I take out a couple of guys in the open field.
Then the enemy takes up positions in the houses.
I'm just storming through houses 1, 2, and 3. Meanwhile, all the other enemies are sitting in their homes and not fighting.
Sometimes the thy can find a nice spot by the window, but usually they just wait.

So, the mission ends up turning into little skirmishes where the quality of my soldiers isn't balanced by the amount of enemies.
If the enemy were actively moving towards houses 1, 2, and 3 during my assault, I'd have to figure out how to respond to that.

I could probably bring back the forced-modes. But I need to make sure that people are aware that these weaken the AI and don't complain about dumb AI-behavior as a result of it.

Maybe some settings could be done not through the in-game interface, but just through an options.cfg file instead?
It's doubtful if it's possible to balance all the mods. And the more customization you can get for a specific mod or even mission, the better.

[0xEBJC]

Xilmi,

For BRUTAL 8.2.4 I'm assuming you'll be updating to the latest release of OXCE also?  I see Meridian just merged in a change that should properly show 3x3 base facilities in the ufopedia UI.
https://openxcom.org/forum/index.php/topic,11819.msg161988.html#msg161988

I just posted a Facility Pack mod that has a 3x3 facility but relies on BRUTAL due to the current need for the different hangars type properties not in OXCE yet.

No rush, but look forward to seeing that update included in BRUTAL-AI or BOXCE or however it's going to be referred to

[Xilmi]

For BRUTAL 8.2.4 I'm assuming you'll be updating to the latest release of OXCE also?

Yes, plan is to always stay up-to-date with OXCE so none of it's features are lacking from BOXCE.
So I guess I'll do that this afternoon.

[Xilmi]

I'm just storming through houses 1, 2, and 3. Meanwhile, all the other enemies are sitting in their homes and not fighting.
Sometimes the thy can find a nice spot by the window, but usually they just wait.

So, the mission ends up turning into little skirmishes where the quality of my soldiers isn't balanced by the amount of enemies.
If the enemy were actively moving towards houses 1, 2, and 3 during my assault, I'd have to figure out how to respond to that.

You are right. This is definitely a good example for a scenario in which the AIs current play-style is sub-optimal and something that can also happen in the vanilla game.

Ideally I want the AI to identify the best approach based on the actual situation instead of once again going the route with having dozens of ways to configure it.

The spotter-picking-logic was kinda supposed to take care of that but the issue is that only enemies who can get a line of fire will participate in the assault.

Another way to think about it is: If some units already are or likely will get involved in a fight anyways, other units should not just sit back in their save-locations and instead move towards helping their friends.

The current behavior makes a lot of sense from each individual unit's point of view but they are not really playing like a team as using squad-sight is more or less the only thing they do in terms of teamwork.

I think that this is something I can experiment with in the future.

[Xilmi]

It's tough. In some scenarios the previously described behavior made it tougher but in many others it is a massive regression.

Edit: However, this kind of behavior is now available as an option, once again.

[krakp]

Getting a weird crash on 8.2.1. Repro:

1. Start a vanilla game.
2. Sell the Skyranger -> CRASH

The error points to Base.cpp, line 2842
            fac=*(_facilities.end()); // Craft has been found; no more search at facilities

It seems not to be liking something about this pointer - anyone else can repro?

I hope it is not due to my code :-) (I am playing with research at the moment, so I would be quite surprised.... https://openxcom.org/forum/index.php/topic,11805.msg161714.htm)

Got the same crash again - this time when I lost the last soldier during the mission (cause this also removes the Skyranger from my base).

[Xilmi]

Got the same crash again - this time when I lost the last soldier during the mission (cause this also removes the Skyranger from my base).

Was this with 8.3.0?
Is it reproducible? If so, I should be able to reproduce it too quite easily. Note that I wasn't able to reproduce the crash when selling the Skyranger.

Edit: Can you attach your options.cfg? It might be related to a specific set of options. I think I have a good idea which one it could be: The alternative equipment-management option probably. Are you using that one?

[Meridian]

Is it reproducible? If so, I should be able to reproduce it too quite easily.

It is probably not easily reproducible.
As Yankes said earlier, this code is 100% wrong by definition, and results in an undefined behavior.
Basically, you get some garbage and depending on what kind of garbage you get, equally garbage things will happen... sometimes crash, sometime corruption, sometimes nothing, sometimes something else.

Quote from: https://en.cppreference.com/w/cpp/container/vector/end

Returns an iterator to the element following the last element of the vector.
This element acts as a placeholder; attempting to access it results in undefined behavior.

[krakp]

Just tested it a bit more - it looks like I am only able to repro this when running the debug mode (basically F5 debugging in VS2022). It does not repro in Release mode when I start the game "normally". Possibly the Release compilation in some way "optimizes" this incorrect code and does not let it crash? Since it does not repro in release, the direct impact is basically none, i assume (and that's probably why there are no other reports of this).

My repro is very easy:
1. F5 the game in Debug mode in VS2022 (7.11.4. 8.2.1)
2. Start a vanilla game
3. Sell a craft -> Crash
Or
3a. Lose the last soldier in a mission -> Crash (due to losing the Skyranger)

[Yankes]

Debug deliberately crash on code like this, in Release all checks are removed (as cost a lot) and code can access invalid memory.
Why code "work"? as most cases there still vector memory here, and in many cases after removing elements it could have garbage that have valid value.
And this case `*(end() -1)` and `*end()` have same value as `*end()` point to memory that have previous "high mark" of data that vector stored before removing element from it.

[Xilmi]

...

What is this code even? It looks like he wants to prevent iterating through further facilities and thus set the iterator to facitlities.end() when the craft was found.
I'd have used a bool that I set to then check in something like "if(breakOuterLoop) break;".

Admittedly I didn't look at the code from the pull-requests I got when it seemed to be working.

[krakp]

Debug deliberately crash on code like this, in Release all checks are removed (as cost a lot) and code can access invalid memory.

Totally makes sense - have not worked much with C++ compilers but kind of expected a behaviour like this one.
However, even if Release does not check for this (and thus does not immediately crash/assert), it is a kind of bug that should be fixed I think - otherwise we risk a random crash in some other part of the code that would be crazy difficult to debug.

What is this code even? It looks like he wants to prevent iterating through further facilities and thus set the iterator to facitlities.end() when the craft was found.
I'd have used a bool that I set to then check in something like "if(breakOuterLoop) break;".

Yep - this seems to be the right way to implement it:

Code: [Select]

bool breakOuterLoop = false;
// Clear slots in hangar containing craft
for (auto* fac : _facilities)
{
for(Craft *fCraft : fac->getCraftsForDrawing()) // Now, we consider a vector of crafts at the hangar facility
{
if (fCraft == craft)
{
fac->delCraftForDrawing(fCraft); // If craft is at the hangar, it is deleted
//fac=*(_facilities.end()); // Craft has been found; no more search at facilities
breakOuterLoop = true;
break;
}
}
if (breakOuterLoop)
break;
}

It immediately resolved my problem - I guess it would make sense to integrate it into BOXCE.

Thanks for the great brainstorming guys! Cheers :-)
 

[Yankes]

btw even if `fac=*(_facilities.end());` do not crash this is incorrect when you use "foreach" loop, even more it could break logic as it override vector data by other.
If you used classic loop this would look like `*it = *(_facilities.end() - 1);` and it would copy data and not break loop.
For nested loops there is another trick (aside of `goto`) to exit them, `return` and lambda functions:

Code: [Select]

(
[&]
{
for (auto* fac : _facilities)
{
for(Craft *fCraft : fac->getCraftsForDrawing()) // Now, we consider a vector of crafts at the hangar facility
        {
if (fCraft == craft)
{
fac->delCraftForDrawing(fCraft); // If craft is at the hangar, it is deleted
return; //quit lambda not whole function
}
}
}
}
)();



[krakp]

Totally makes sense - I also agree that this is fully incorrect - that's exactly why the debugger would assert here to warn us about it. So I guess it was a bit lucky that I came across it (and that I actually play/test the game in Debug mode).

For nested loops there is another trick (aside of `goto`) to exit them, `return` and lambda functions:

Wow - really cool - I was not aware that you can return this way.... This is like self executing anonymous function, right?

Anyway, personally I am a fan of easy solutions, so my recommendation would be what Xilmi suggested (and I implemented as a test). The code with lambda function is probably more beautiful but in a year from now I would not remember how it works anymore :-).

But hey - this was never my code (I just was lucky to step into the problem) so I will let you decide how (whether?) you want to fix it.

Cheers!

[Yankes]

This is like self executing anonymous function, right?

Yes, `[&]` introduce lambda function (`{...}` is its body) that can `&` reference all objects in function, and last `()` call it.