Brutal-OXCE 9.2.7

[Aldorn]

The mod should be included in the installer. Not sure if it defaults to 'on' or 'off'.

I found only two folders linked to Brutal AI: Brutal_AI and Brutal_AI_TFTD

But the content is clearly not enough to make a mod

Let's see if someone else has more information

Anyway, thank you for your help 

[Juku121]

No, these actually are the mods. The big work is done in code, these small bits just enable the main functionality (and take away human psi). The point is that you do need these (and quite possibly more, there are many extra options documented in the OP and elsewhere) to actually start playing with 'brutal' AI. Just like you need at least a small mod to get physical training facilities, or retaking countries with a pact, or LoS-only psi, etc.

[Aldorn]

No, these actually are the mods. The big work is done in code, these small bits just enable the main functionality (and take away human psi). The point is that you do need these (and quite possibly more, there are many extra options documented in the OP and elsewhere) to actually start playing with 'brutal' AI. Just like you need at least a small mod to get physical training facilities, or retaking countries with a pact, or LoS-only psi, etc.

Ok, agree, thanks

[Yankes]

@Xilmi I mess bit with OXCE AI, I hope that will not break lot of your code.
Overall change was that all sides now have its own "last seen" counters and I reduced lot of `if (factorin == X)` from code.
Goal is to allow modder defined script that calculate "value" of target for AI and allow it make decisions based on it.


This is last commit in series, still WIP but probably you can see how will this change look in future:
https://github.com/MeridianOXC/OpenXcom/commit/d8e08f90cd46fd08075fd797d5a6bf5549e6d3d6

[Xilmi]

I'm seeing 6 files with merge-conflict if I have a look at what merging the test-branch would lead to.
Not the worst I've had so far, so I'll probably be able to deal with it, once it goes into your main-branch.

I have also, in the past added separate tracking for when units were last seen but with different variables:

_turnsSinceSeenByHostile(255), _turnsSinceSeenByNeutral(255), _turnsSinceSeenByPlayer(255),

Considering I'm more or less in maintenance-mode, when it comes to the AI, I'm wondering if now the conditions for merging BOXCE back into OXCE are met.

I said initially that this can't really be a feature that can be considered as "ready" due to the iterative development-process for AI-improvements. But I've reached a point where I'm quite happy with my AI and don't really feel the need to update it any further.

[Meridian]

I said initially that this can't really be a feature that can be considered as "ready" due to the iterative development-process for AI-improvements. But I've reached a point where I'm quite happy with my AI and don't really feel the need to update it any further.

Well, if you don't plan any further updates, then it is practically-speaking "ready".

Considering I'm more or less in maintenance-mode, when it comes to the AI, I'm wondering if now the conditions for merging BOXCE back into OXCE are met.

You mean the whole BOXCE?
You are kidding, right?
We were discussing merging BAI, not BOXCE.
I am not going to merge features, which I have explicitly rejected, like more than 8 bases for example.

If we talk about BAI, I don't reject it immediately, but I also cannot say yes without knowing exactly what it would contain (and the quality of it).
I would be stupid if I was going to buy a pig in a poke: https://dictionary.cambridge.org/dictionary/english/pig-in-a-poke

If you can prepare a reviewable PR, Yankes and I can review and see if it is compatible- and maintainable-enough to be merged.
The minimum requirements for the PR would be:
1. one (squashed) commit
1b. at least one A4 page worth of changelog; or something like that to help with the review
2. only BAI, nothing else (e.g. no RA, etc.)
2b. no rejected features (e.g. no 8+ bases)
2c. no features that are on my todolist and I know I want to do them differently (e.g. hangar types)
3. no revert of OXCE commits (e.g. https://github.com/MeridianOXC/OpenXcom/commit/8f1dd59ad1a27485b841f68a068556c403f72fd0 or https://github.com/MeridianOXC/OpenXcom/commit/9a90fab4372841b387319900993d0267251db18b)
4. no OG-incompatible changes (e.g. https://github.com/Xilmi/OpenXcom/commit/123350d3ab0e29c4d25370841964a525545072cf)

I don't know how difficult it will be to create such a PR, but not gonna lie, probably very.

Consider carefully if that is worth your time; and our time.

Considering I'm more or less in maintenance-mode...

Don't know about Yankes, but I am also more or less in maintenance mode since the last year.
I have only 2 big features I still want to do; the rest is community wishlist.
BAI-sized PR is rather heavy on my retirement plans.

[Yankes]

I'm seeing 6 files with merge-conflict if I have a look at what merging the test-branch would lead to.
Not the worst I've had so far, so I'll probably be able to deal with it, once it goes into your main-branch.

I have also, in the past added separate tracking for when units were last seen but with different variables:

_turnsSinceSeenByHostile(255), _turnsSinceSeenByNeutral(255), _turnsSinceSeenByPlayer(255),

Ok, this is equivalent to to my version but I used array to pack every thing to "one thing" as it allow simpler code when
one function handle all cases.

Considering I'm more or less in maintenance-mode, when it comes to the AI, I'm wondering if now the conditions for merging BOXCE back into OXCE are met.

I said initially that this can't really be a feature that can be considered as "ready" due to the iterative development-process for AI-improvements. But I've reached a point where I'm quite happy with my AI and don't really feel the need to update it any further.

I would agree Meridian that we should pull only AI part (if any). Previous I was not in favor for merging this AI but now after couple years of your work and some following of your version I now less against it.

[Xilmi]

Okay, fulfilling these requirements sounds like too much work for me. Especially considering that it still would not be a given and would have to pass reviews that would result in even more work.

The main reason for asking was because I get asked all the time for Android builds of BOXCE.

Maybe there's another way to get there that doesn't involve that whole process.

Something like having BOXCE be on your buildserver (or how it is called) too.

I have indeed ran into issues merging contributor's code. Mostly because it caused merge-conflicts on later OXCE-updates but also functionally. So I understand not wanting to take the burden of potentially having to maintain it.
On the other hand I feel like it's a bit of a waste of people's ideas and time spent working on new features like RA, not to backport them. So if I got pull-requests, I usually tried to make it work somehow. RA is probably the most positive example because it's not like with other feature's who's devs have disappeared and I had to figure out myself why they ceased working. The guy who made it is still active and I can easily get in touch with him.

[jnarical]

The guy who made it is still active and I can easily get in touch with him.

I'm still hunting bugs btw (right now). I'd like to spend much more time working on RA code but too busy at work.
Personally, I don't think merging the whole BOXCE is possible, even AI code seems too be much of work...

For RA it's possible (in theory) with some time and effort, but it needs refactoring. I'm telling this not in the sense of merging to OXCE, but more of implementing on top of it, as different project - if BOXCE ceases to exist. In that case, my userbase will shrink to several people I guess ))

[Meridian]

The main reason for asking was because I get asked all the time for Android builds of BOXCE.

Maybe there's another way to get there that doesn't involve that whole process.

Something like having BOXCE be on your buildserver (or how it is called) too.

We don't have a build server that builds Android version anymore, Stoddard disappeared and his build server is dead.
I build Android version locally on my laptop.
The entire build process is described here: https://github.com/MeridianOXC/openxcom-android?tab=readme-ov-file#building

Note that you cannot build BOXCE for Android just like that.
Android (and also iOS) versions are separate branches with lots of additional code compared to the default branch.
You can even think of them as separate forks.
If you want to build BOXCE for Android, you'll first need to create such branches also in your repo, add/merge the necessary code and solve all the conflicts.
And you'll need to maintain this branch too... just like I also maintain 3 branches of OXCE, not just one.

[Stormtrooper]

RA is the best, but on the other hand to use it I had to download a fork of a fork of openxcom, not sure if making yet another project is the way to go, especially for such niche feature. But again, RA is the best so do whatever you want with it for as long as I can download and play it