[SOURCEMOD] Brutal-OXCE 7.12.1

[Xilmi]

-) X-Chronicle has various soldier types with special weapons without icons or use in empty hands (they can only be accessed via soldier skills), but the AI uses them anyway directly (not via a soldier skill). At least with the latest version I tried, which is something like 6.4.

I don't really understand what that means. What difference does it make gameplay wise to use an ability directly or via soldier-skills? Can you provide an example/savegame of what you mean?

-) Unexcom defines hangars with a capacity of two, but defines no positions for the crafts. Which will not load, as of version approximate 7.1.

There's a workaround for that since 7.1.2:

"The game no longer crashes with the "Not enough position vectors for crafts allocation."-message when a mod defines a hangar that can have several crafts but doesn't have sprite-offsets assigned to them.

Instead there will only be an error-message in the OpenXcom.log and all craft-sprites are drawn in the center of the hangar-sprite.

The proper way to use hangars that can hold several craft in Brutal-OXCE is to define an offset for the sprite drawing location from the hangar-sprite-center like this:
crafts: 2
craftSlots:

[-10, -10, 0]
[ 10, 10, 0]"

[DeltaEpsilon]

A [nerfing] suggestion for the AI to match the player: the AI should probably not be able to know the whole map on the first turn and have to discover the map tiles itself as well.

[Xilmi]

A [nerfing] suggestion for the AI to match the player: the AI should probably not be able to know the whole map on the first turn and have to discover the map tiles itself as well.

Can you give me some examples in what ways you think knowledge of the map impacts the AI's decision-making?

[DeltaEpsilon]

Well, some simple examples:

1. Missions on maps of high complexity.
Things such as caves or missions localized entirely within buildings with many rooms. AI should not be able to immediately know locations of rooms with high visibility yet good cover and go there.
It's extra cheap with psi-sense since AI ends up immediately coalescing into near perfect spots and/or setting ambushes.

2. Missions where the enemy starts within a small area as opposed to being spread over the map.
Same issue: available vantage (or peek) points should not be immediately known until they're seen.
It should be noted that the player can actually do that with map sense [aka just memorized map tiles] though.

3. General issue: line of fire check should fail if it passes thru unseen tiles
The player doesn't have access to any tools to check if there is a line of fire until they actually post the unit at the tile and try to shoot from there. This is a significant part of consumed TU during a turn often: trying out several positions from which to shoot.
The AI does, but not only can it check it without actually having to move and spend TU, it can check it from any reachable position, including those not yet seen, thus providing it with information the player wouldn't be able to get.
For example, suppose a spotter spots a player unit. A sniper is on the first floor of a building (say, those farmland buildings, with stairs going up) and hasn't seen the second floor. Currently, the sniper can immediately walk up to the second floor, knowing there is a window in there and shoot the player. How would a player know there was a window there and an LoF available besides memorizing that only this particular map tile has this particular distribution of windows on the second floor?



This is extraordinarily bullshit in complex maps because non-full tile obstacles and changes in elevation have very unpredictable effects on LoF for the player [try fighting around stairs, it's maddening. Or just in a jungle]. In this regard, the AI cheats.
Being able to test thru unseen tiles is the smaller part of the cheat, being able to mentally teleport and check for LoF is the bigger part.

[Xilmi]

Well, most of what you say is technically correct.

I do, however, think that making the changes you suggest would vastly overcompensate and actually put the AI at a disadvantage. I also think you underestimate the capability of a player to make good guesses about these things. Especially when it comes to experienced players who are the target-audience for this modification.

For example:
You say that undiscovered tiles should be considered as line-of-fire-blocking by the AI because a player couldn't possibly know. Not knowing does not mean being incapable of making an educated guess.
I'm willing to bet that based on what I can see, I would guess correctly in the vast majority of cases, whether there's something within the undiscovered tiles would block the line of fire. I know what kind of maps to expect depending on tile-set and whether it is more likely to be blocked or not. On an arctics-map I know there won't be anything. On an alien-base-map I know there will almost certainly be something.

There's also a point to be made about how in in-game-logic, with the exception of an x-com-base-defense, the Aliens are supposed to have been there before X-Com. Usually hours before. So them having themselves familiarized with the terrain in the area is nothing that shall come as a surprise.

And even if I realized this, the impact likely would be quite marginal due to the aliens starting out spread out. They would pretty much immediately see the vast majority of things they need to see in order to make these assessments.

Also when it comes to guessing whether I'd have a line of fire from a certain tile to another, experience goes a long way with guessing more accurately.

Enabling the "Performance Optimization", besides faster turn-times also reduces accuracy in the AI's guesses. What it changes is that instead of doing the complex line-of-fire-check, it simply draws a mental line between the center of one tile to the center of the other and see whether there's something in the way. This has quite a lot of false negatives and leads the AI to not consider possible shots or go to worse tiles. So you might consider using that option for that purpose.

[GumChewer]

I don't really understand what that means. What difference does it make gameplay wise to use an ability directly or via soldier-skills? Can you provide an example/savegame of what you mean?

I could craft a savegame if you want.
The difference for X-Chronicle is the cost of use in tu/mana/etc, they are defined both for the special weapon and the soldier skill. But the ruleset allows for some more differences.
Another example would be special weapons that the player cannot use under any circumstance, the ruleset allows that. Although I have not seen a mod in the wild doing that.
I could quote the relevant ruleset properties for items, weapons in special, if that helps.

[GumChewer]

If you'll do the UI stuff, I sure can do the rest. The hooking to the AI should be pretty easy. Just need to read the settings from the Geoscape-Soldier, that the BattleUnit-likely has access to.

See the attached screenshots for what I use at the moment. Also accessible from the craft screen. I probably should add a way to access it from the battlescape too. The aggressive parameter could be added easily too.
Let me know and I will do a pull request.

Combining some soldiers being on auto while others are not sounds a bit challenging from the turn-processing-perspective.

As a player I would be fine with skipping the non-auto soldiers till all soldiers on auto are done and then pass the control to the player again.
I use the attached short hack for 7.12 which nearly does that, except passing the control to the player at the end of the turn.

An alternative solution could be to make "hotkeys" for a semi-automatic-behaviour. Basically you press a hotkey for each soldier when it's selected and it will handle stuff with AI immediately but only for that soldier. Different hotkeys for different aggressivenesses.

That sounds great too!
I'm not sure how easy that is, I see the AI do a lot of "Take a very little action, like peek one square, cylce to the next soldier, repeat".

[DeltaEpsilon]

Any thoughts on providing an option for adjusting enabled Brutal AI facilities based on unit's intelligence stat? Say disabling it for units with very low intelligence, provide squad sight for higher intelligence, maybe even third vision mode for higher int still etc. Maybe some kind of intelligence-to-options curve.

[Xilmi]

@GumChewer & DeltaEpsilon:

Currently I've identified some general issues with the AI's logic. So working on feature-requests will have to wait.

I noticed that one of the intended behaviours didn't work properly. But after fixing it, the AI actually did worse in the benchmark. I tried that maybe the feature doesn't make sense and thus disabled it. And this also did work in the benchmark. So if the bugged behavior is better than the intended behavior, this means that my intentional-behavior isn't good.

The intention was: "Don't attack if you can't return to good cover after attacking."
The bugged behavior was: "It went to the position, realized it didn't have enough TUs to both attack and go back to cover and then went back to cover, thus wasting their TUs".

My hypothesis as to why that bugged behavior still led to overall better results is that it could spot enemies it otherwise probably wouldn't have spotted and that the new cover-position was better for acting next turn.

If this makes it better, it means two things:

The current changes to peeking-behavior are probably a regression. My thought process was that if the "walktotarget" was already spotted by someone else, then peeking is not necessary. However, I now realized that a unit that has recently been spotted always takes precedent as a "walktotarget" over hypothetical units that are just guessed. So if a unit was spotted very far away, a unit now might not peek because it already knows a target but thus will miss targets that are much closer. And the aforementioned bug helped against that being an issue in some cases. So instead there should be a peektotarget, which is the assumed closest enemy regardless of whether it was already spotted. But even this might be worse than just always peeking. Maybe peeking logic should be reworked completely. The goal is to get the best possible reconnaissance for the lowest possible TU-investment.

The other thing that this indicates is that the makeshift cover-position it goes to after realizing it can't attack and go to cover could be better than the prior, much safer cover-position afterall. This means that the changes to cover seeking-logic an 7.3.0 also are questionable.
They were made to maximize safety when seeking cover. But this has the disadvantage of units not taking part in an ongoing combat, when they don't want to leave their save spots. This in turn will lead to enemies being singled out.
My idea is to change the behavior when contact has been made. In this case cooperation with the own team should take precedent over individual safety and less good cover should be considered as viable.

There also is a general contradiction with good cover and the peeking-logic. If the goal of peeking is to get the most reconnaissance for the lowest investment of TUs, then too good of a cover-position will contradict this goal.

Overall: Turns out finding the best approach is pretty difficult given how many possible scenarios there are.

[Xilmi]

Let me know and I will do a pull request.

Yeah, doing a PR or linking to your Github-Repo would probably help more than attaching a patch-file.

[GumChewer]

Yeah, doing a PR or linking to your Github-Repo would probably help more than attaching a patch-file.

I've opened a pull request. Just have a look whenever you find the time and let me know what you think.

[Xilmi]

I've opened a pull request. Just have a look whenever you find the time and let me know what you think.

What branch have you directed it to? I'm not seeing it on "oxce-plus", which is what I'm working on.
I'm not seeing it anywhere. I think I should get some sort of notificaction. Can you post a link?

[DeltaEpsilon]

What branch have you directed it to? I'm not seeing it on "oxce-plus", which is what I'm working on.
I'm not seeing it anywhere. I think I should get some sort of notificaction. Can you post a link?

Uhhh..
https://github.com/Xilmi/OpenXcom/pull/4

[Abyss]

Xilmi, hi!
May the goddess bless you, you are wonderful.

For the sake of added variety and value of your mod, please consider these questions:

What do you think of randomization of units aggressiveness within one battle? Is it feasible?
Can BAI core support the multiple aggressiveness scenarios within one enemy turn, given that it can change the value?
What do you think if unit aggressiveness changes to lower value if enemy gets fatal wound?

I think the following options would do great:
* Enable Brutal AI vary aggressiveness of enemy units (On/Off)
* Min Aggressiveness (0-4)
* Max Aggressiveness (1-4)
* Enable Brutal AI lower aggressiveness if unit gets fatal wound (On/Off)

With true random generator, each battle will be different.

[Xilmi]

What do you think of randomization of units aggressiveness within one battle? Is it feasible?

That would both be feasible and relatively easy to implement.

Can BAI core support the multiple aggressiveness scenarios within one enemy turn, given that it can change the value?

The value could be changed on every pass a unit goes through and also tied to certain conditions. My idea of realizing the random aggressiveness was to roll for it at the beginning of the first turn. But it could also happen every turn. But that's probably a bit too random.

What do you think if unit aggressiveness changes to lower value if enemy gets fatal wound?

Not as default-behaviour. Right now the exact opposite is happening. If a unit with a wound knows that it would die or fall unconscious within the next three turns, it goes into sweep-mode in the hopes of accomplishing something while dying in cover and potentially hurting their friends with a pre-primed-grenade.
But I reckon that from the individual's perspective this is not particularly realistic.

I think the following options would do great:
* Enable Brutal AI vary aggressiveness of enemy units (On/Off)
* Min Aggressiveness (0-4)
* Max Aggressiveness (1-4)
* Enable Brutal AI lower aggressiveness if unit gets fatal wound (On/Off)

The first three of these sound good to me. I'm currently quite content with the AIs default-behaviour, so adding more options is fine with me.