Brutal-OXCE 9.2.6

[Abyss]

Xilmi, zombies in XCF are not rushing again (aggro = 4 (zombies are Leeroys), intel = 6)
Previously, I reported this issue and you managed to return the original zombie behavior.
Something broke with few releases I skipped playing.

Currently:
- all zombies on map run towards you (regardless if they see directly you or not)
- making some weird moves near your agents (chess positioning + supposed blocking of shoots, which doesn't work for zombies)
- not screaming "GRAWRRRR" as usual in any point of the map
- positioning themselves in anti-grenade pattern with strict spacings between Z's (see screenshots attached).
Turned off "anti-grenade spacing option".

Supposed behavior (can be seen if BAI is turned off):
- only zombies who see or sense you will run towards you.
- when they reach targeted agent, they stand on place and bite. Just bite, not seeking for a weaker spot. 
- make GRAWRRRR scream at the beginning of their turn (each)
- don't care about crowd control. Don't care how many other Zombies are near.

SAV is attached

FYI: Current BAI build makes sense, I enjoy playing with customized units.rul file with inherited stats (both aggro & intel).
Strongly suggest to make mission-to-mission variables not only in the aggression settings, but also in intelligence (see previous message).   

[Abyss]

Report regarding human NPC picking up and using alien plasma weapons.
By lore, only X-COM can do that. And mostly lategame after cracking codes.

[zee_ra]

@Xilmi

I have some thoughts here https://openxcom.org/forum/index.php?topic=10870.msg165711#msg165711, with the interesting part of the thread starting at https://openxcom.org/forum/index.php?topic=10870.msg162989#msg162989, about how to slightly adjust the current hangar index system at the BAI.  Ultimately, the system is not bad, but there exists a snag with setting up a production base, which could produce two types of crafts -- space and fighter -- when we maintain distinction between space and fighter crafts (with the space-crafts requiring larger hangars).  The changes necessary should be relatively minimal, and would play very well in line with the current implementation.

[termidor]

One quick question, in Xpiratez if I choose the setting  1 for Ai targetting, would it respect the standard OXCE spotter mechanics?

[Xilmi]

One quick question, in Xpiratez if I choose the setting  1 for Ai targetting, would it respect the standard OXCE spotter mechanics?

No. With Brutal-AI enabled the standard-AI-behavior is ignored. Setting 1 means no spotting for others and only units who can see a target can attack it.
Setting 2 already means full team-vision and everyone can attack who is currently spotted.
Note that standard OXCE-spotting-mechanics make your units not just targetable on the current turn but also the amount of turns equivalent of the intelligence of the shooter afterwards.

[Kozinsky]

Could you please give a full detailed description of all the new features for modders, as it is described in the modding guide for OXCE?

For example, by studying all available materials on BOXCE, and reading a little bit the source files “Unit.cpp” and “AlienDeployments.cpp” I found such functions:
isBrutal(false), isNotBrutal(false), isCheatOnMovement(false), isAggressive(false), aiTargetMode(0), minBrutalAggression(0).
Maybe some more that I couldn't find and separate from existing OXCE functions.

Please give them a description for the current version of BOXCE.

[Akamashi]

There are 10 enemy aggression values in xcomfiles. There are 3 of them in bAI. Does this mean that the "inherit unit aggression" parameter will not work correctly for all units that have it higher than 3?

[Xilmi]

There are 10 enemy aggression values in xcomfiles. There are 3 of them in bAI. Does this mean that the "inherit unit aggression" parameter will not work correctly for all units that have it higher than 3?

There's 4 in bAI, if you start counting at 0.
But yes, everything above 3 will act the same as 3.
The OG only had 0, 1 and 2.

[Akamashi]

There's 4 in bAI, if you start counting at 0.
But yes, everything above 3 will act the same as 3.
The OG only had 0, 1 and 2.

It's frustrating, but I can't suggest anything to improve. It would be strange to make xcomfiles a reference. And it is most likely impossible to determine the number of variables used for different levels of aggression and to make a gradation through the arithmetic mean.

((

[Xilmi]

It's frustrating, but I can't suggest anything to improve. It would be strange to make xcomfiles a reference. And it is most likely impossible to determine the number of variables used for different levels of aggression and to make a gradation through the arithmetic mean.

I actually tried doing something like that in the past. But gradual aggressiveness never really seemed to work right. So I went with making only a few but very distinct ones.

Someone could make a submod for XCF by using some sort of automated script or something alike that parses through the files and replaces each of their aggressivenesses with a value multiplied with 3/10th and then rounded to the next full number.

[Meridian]

Your merge doesn't seem to work.
For me it doesn't load any battlescape saves when running from Visual Studio, old or new, it immediately crashes.

There are several ways how to fix it.
I'd recommend a backwards-compatible way, see 2 attached images for the needed changes.

[AndyFox]

From the startup log:

[FATAL]   Error loading file '.../common/SoldierName/Polynesia.nam'

- 'Akamu → - Akamu (without ')

In the last line.

[Meridian]

I see you have made a different change.

That change is however NOT backwards-compatible.

The variables in question are now Uint16, and will be saved differently in the save file, potentially again incorrectly if you keep using `setAsQuotedAndEscaped`.

I would still strongly recommend changing those variables to Uint8, because they are basically constants (always equal to 2) and don't need to be Uint16.

[Xilmi]

Your merge doesn't seem to work.
For me it doesn't load any battlescape saves when running from Visual Studio, old or new, it immediately crashes.

There are several ways how to fix it.
I'd recommend a backwards-compatible way, see 2 attached images for the needed changes.

Your screenshots seem to be from before I fixed it myself in a slightly different way.

I now load/save it with 2 Byte-Uint16 at all places. Before it was a mix-up which didn't work.

Going down to only one byte bears the risk of becoming wrong once the battle takes more than 256 turns. I also had previously used 2 bytes to hold those turn-numbers. Or did I?
Maybe I intended it but didn't. In that case I might want to change it. Right now only saves made with current version work properly. If changing it to 1 byte allows me to load old saves again it would be better.

Edit:
Ugh, okay, I never saved it as 2 bytes. So I'll make a 9.2.3 where I go to 1 byte to restore savegame-compatibility.
Thanks for keeping an eye on it and informing me!

[Xilmi]

I would still strongly recommend changing those variables to Uint8, because they are basically constants (always equal to 2) and don't need to be Uint16.

Wait what? i thought the "2" was the amount of bytes and the actual contents (turns) was inside of the "binTiles:"-line.

If that's not the case, I've probably misunderstood the whole savegame-structure.

However, I'll just change it how you say and if this fixes my old saves, I'll put out a new version.