Rumors about incompatibility with Brutal-OXCE

[Xilmi]

Hello!

Some days ago I coincidentally read a chat-message stating that my Brutal-OXCE-client would be incompatible with X-Piratez for several reasons. An example was given about grenades detonating at the end of the turn, when not thrown. I since added a check for that flag in the pre-priming-logic of my AI, so they should no longer do that.
However, the comment said "several reasons", which means the one example probably isn't all.

I then asked on the discord-chat if anyone knew anything about other reasons. I got a very vague reply: "pictures of the screensaver in x-piratez". No idea what to make of that, to be honest.

So is anyone else here aware of potential reasons of incompatibility except of the grenade-issue that should be taken care of in the latest versions? I really want to be able to claim my client to be compatible with all the major mods.

[Meridian]

For me, the recent change in map/pathfinding handling is an example of 100% indisputable incompatibility.

Other than that, as I said in several threads, the redefinition and removal of various OXC and OXCE features is also incompatibility for me, e.g. leeroys jenkins, aggressive retaliation, sniper-spotter, picking up items, and many many more.
You could argue that they are "improved" or "changed because of the nature of your mod", but for me that still simply qualifies as incompatible (since using these OXC/OXCE features will result in a different behavior in OXC/OXCE vs. Brutal-OXCE).

If anyone asks me if Brutal-OXCE is compatible with OXCE, I cannot give any other official answer than: no, it is not compatible.

[Juku121]

That's a very narrow definition of incompatibility that's nearly meaningless when applied to a fork whose entire premise is to change AI behaviour.

From my 'player' POV, if a mod behaves differently but doesn't include unwanted behaviour from that mod's users' POV, that's still compatible. A lot of OXC QoL things fall into that category already. We could use a different term if you wish, 'mechanically compatible' or something.

Now, if BAI is still 'mechanically compatible' but destroys balance or atmosphere, that's IMO a different thing. Definitely worth mentioning, and probably something that's going to remain unresolved and worthy of called some sort of 'incompatible', unless someone tries to reimagine Piratez (or some other similar mod) in the BAI context. But I imagine Xilmi is after things that actually make his AI not work as he intended.

[Meridian]

Of course.

That's why I am clarifying my position.

Brutal-OXCE is technically an engine-fork, but practically it is just a single-purpose mod... almost completely hardcoded to the modder's (Xilmi's) needs (and exposing very little to other modders, while taking significant part of the parent engine away from them).

Which is completely fine, I have absolutely nothing against that.... but we need to be very careful with the terminology, so that people don't get confused.

[Xilmi]

I still haven't heard a sound argument as for why bigwalls should be ignored in orthogonal directions but considered as movement-blocking in diagonal-direction.
I say: If the Triton being walk-able is an intentional change over the original game, this should be realized with a proper MCD-modification of the Triton and not by having inconsistencies in the path-finding-logic. I did this MCD-modification and changed the full-bigwalls on the wings into ones that only block towards the inside of the Triton.

Unless someone can make a compelling argument, showing a concrete example where this kind of behavior could deliberately be wanted, I'll continue to consider my change in that regard as a bug-fix. I read about enemies being stuck in the ground several times and I think that this inconsistency is a likely reason for this.

Calling any difference an incompatibility is also quite the stretch in my book. What I meant when asking this question was whether there's game-breaking-bugs like crashes or the AI being unable to cope with the ruleset of that mod in a way that makes them non-threat anymore.

Differences in Leeroy Jenkins, Sniper-Spotter and Picking up items all depend on my AI being enabled. It should be kinda obvious that enabling the AI that is the entire point of the separate client, will lead to different behavior compared to the original AI. And unless the differences in behavior lead to the AI being incapable of doing their job at posing a threat to the player, like prepriming leading to self-nuking did because it was special explode-in-hand-grenades, I do not consider that an incompatibility in the sense of what I'm asking for here.

And when it comes to Aggressive-Retaliation: It obviously is the intention of that option that retaliation-missions of aliens have a higher tendency to be successful. Enabling that feature but then being able to prevent retaliations completely by either deliberately or accidentally putting your bases in the blind-spots of the search-pattern completely defeat the purpose of the feature. So I'd argue that this change goes hand in hand with the intention of this option.

Also the question isn't whether the two engines are compatible. The question is whether the two engines are compatible with the same mods. Differences between how the mod is experienced in either engine depend on what the engine does with it.

The purpose of my changes compared to OXCE are documented on the mod-page. Things that are different within the constraints of what is described there, is not something I consider incompatible.

What I meant is more stuff like: "If the enemies have this sort of armor/weapon/etc. they are unable to use it or use it in a way that is disadvantageous to themselves, whereas it works fine in regular OXCE."

[Xilmi]

while taking significant part of the parent engine away from them

What are you talking about? What "significant part of the parent engine" does Brutal-OXCE take away in your opinion?

I'm not aware of any part of the code that I supposedly have removed. I've only added optional features and very slightly changed the behavior of one existing feature to be more in line of what I think this features intention was while keeping the original functionality of that feature in place as well.

We can totally discuss whether stuff like sniper-spotter-logic, as it is used in base-AI, should also be a possibility in Brutal-AI. We can also discuss, whether reducing mod-verification-level was a bad idea.

I'm open for constructive criticism based on specific changes.

But blanket-statements that claim it's taking away significant parts of the parent engine, need to be underpinned with examples. An optional feature, that you can just disable to go back to the previous behavior wouldn't really cut it for that, in my book.

[Yankes]

I still haven't heard a sound argument as for why bigwalls should be ignored in orthogonal directions but considered as movement-blocking in diagonal-direction.
I say: If the Triton being walk-able is an intentional change over the original game, this should be realized with a proper MCD-modification of the Triton and not by having inconsistencies in the path-finding-logic. I did this MCD-modification and changed the full-bigwalls on the wings into ones that only block towards the inside of the Triton.

Unless someone can make a compelling argument, showing a concrete example where this kind of behavior could deliberately be wanted, I'll continue to consider my change in that regard as a bug-fix. I read about enemies being stuck in the ground several times and I think that this inconsistency is a likely reason for this.

Of corse is "bug" but because its was so long in OXC it become "feature" because many could unconsciously use it.
Without examining impact of changes like this on biggest mods we should not make change like this because it make mods incompatible (aka will change behavior). OXCE did changes like this but did it after long debilitation and consulting all big modders first.

As you are author BAI you can think is justified to change this behavior (as is needed for it), for us who are not interested much in your AI it is not that compelling.

Calling any difference an incompatibility is also quite the stretch in my book. What I meant when asking this question was whether there's game-breaking-bugs like crashes or the AI being unable to cope with the ruleset of that mod in a way that makes them non-threat anymore.

People for smaller changes raise pitchforks, especially how want have 100% recantation of '95, and yes, for some OXC is unacceptable with all its alteration of original behavior (vide climbing triton).
This is subjective thing where you draw line but its should be put some where.
But is one import thing that make it all this, clear who is responsible for solving user bugs and issues?
As far as I understand stance Meridian he saying your fork is "incompatible" he mean will not take any responsibility for any bug/behavior in your fork as it could be introduced by your changes like this.

This mean you can do any change you like in your fork, but all fallout caused by it should be handled only by you.

Of corse if you find but that can be recreated in OXCE then is our responsibility to handle it, but we will not check that if it was encounter in your BAI exe.

Differences in Leeroy Jenkins, Sniper-Spotter and Picking up items all depend on my AI being enabled. It should be kinda obvious that enabling the AI that is the entire point of the separate client, will lead to different behavior compared to the original AI. And unless the differences in behavior lead to the AI being incapable of doing their job at posing a threat to the player, like prepriming leading to self-nuking did because it was special explode-in-hand-grenades, I do not consider that an incompatibility in the sense of what I'm asking for here.

And when it comes to Aggressive-Retaliation: It obviously is the intention of that option that retaliation-missions of aliens have a higher tendency to be successful. Enabling that feature but then being able to prevent retaliations completely by either deliberately or accidentally putting your bases in the blind-spots of the search-pattern completely defeat the purpose of the feature. So I'd argue that this change goes hand in hand with the intention of this option.

This mean philosophy of both forks are different and incompatible, I personally want interaction of each config with each other, you want have independent ones.
In some mods this do not matter at all, in other could alter behavior heavily.

[Meridian]

I still haven't heard a sound argument as for why bigwalls should be ignored in orthogonal directions but considered as movement-blocking in diagonal-direction.

I haven't heard a sound argument saying otherwise.

I said my arguments and SupSuper said his, if you don't consider them sound, it's your decision to make.

I say: If the Triton being walk-able is an intentional change over the original game, this should be realized with a proper MCD-modification of the Triton and not by having inconsistencies in the path-finding-logic. I did this MCD-modification and changed the full-bigwalls on the wings into ones that only block towards the inside of the Triton.

It's not about the stupid Triton!

It's about thousands of maps modders have made over the years, using this functionality, under these assumptions.
These maps WILL behave different, which is absolutely unwanted by OXC/OXCE devs.

Unless someone can make a compelling argument, showing a concrete example where this kind of behavior could deliberately be wanted, I'll continue to consider my change in that regard as a bug-fix.

What can I say.
We will consider your change a game-breaking bug.

I read about enemies being stuck in the ground several times and I think that this inconsistency is a likely reason for this.

This is at least the fifth time you "have a suspicion" that some random vaguely described behavior is definitely connected to a change you have made two days ago.
It's called confirmation bias.

It wasn't the case the first 5 times and it very likely won't be the case this time.

Unless you can provide at least some evidence, we assume it is correct and you have to prove otherwise. Not the other way around.

Calling any difference an incompatibility is also quite the stretch in my book. What I meant when asking this question was whether there's game-breaking-bugs like crashes or the AI being unable to cope with the ruleset of that mod in a way that makes them non-threat anymore.

Differences in Leeroy Jenkins, Sniper-Spotter and Picking up items all depend on my AI being enabled. It should be kinda obvious that enabling the AI that is the entire point of the separate client, will lead to different behavior compared to the original AI. And unless the differences in behavior lead to the AI being incapable of doing their job at posing a threat to the player, like prepriming leading to self-nuking did because it was special explode-in-hand-grenades, I do not consider that an incompatibility in the sense of what I'm asking for here.

Of course.

Everything can be exploited in one way or another... as you have already found out, since you have changed your decisions back and forth many times (judging mostly by the changelog).

If you disable modder's decisions about let's say picking up items, there will be consequences.
Let's say Dioxine wants enemies to pick up Plasma Rifles, but not Blue Chips.
If your engine ignores these settings, enemies will start picking up Blue Chips and be rendered non-threat.

Everything has consequences.
Nothing is for free.

Also the question isn't whether the two engines are compatible. The question is whether the two engines are compatible with the same mods. Differences between how the mod is experienced in either engine depend on what the engine does with it.

Sorry, but that's not how I define compatibility... maybe my definition is also extreme... but then yours is the opposite extreme.

If the same mods do different/opposite things under different engines... then calling them compatible is simply wrong (IMO).

Why would modders even bother modding, if they don't have control over the outcome?

[Meridian]

I'm open for constructive criticism based on specific changes.

I'm not here to criticize you.
You can do whatever you want.

I'm here just to protect my interests.
And it is in my interest to properly and honestly explain to modders and players using my engine, that your engine is not compatible with it.

I don't want anything more from you than to be honest.

If I missed the point of this thread somehow, I am sorry, feel free to delete the whole thread if you want.

But blanket-statements that claim it's taking away significant parts of the parent engine, need to be underpinned with examples. An optional feature, that you can just disable to go back to the previous behavior wouldn't really cut it for that, in my book.

Just look at how many modders recommend your engine.
None.
(correct me please if my info is too old)

And even modders, where you would naturally have the biggest chances... for example Hellrazor and his Hardmode... have turned theirs backs to you, because of the incompatibilities and because of the modding options you have taken away from them: https://openxcom.org/forum/index.php/topic,10890.msg153730.html#msg153730

[Juku121]

If I missed the point of this thread somehow, I am sorry, feel free to delete the whole thread if you want.

To me, the idea behind this thread appears to be to point out concrete examples of how BAI breaks compatibility. So not theoretical incompatibility, but issues that make mod+BAI not work at all in some circumstances - as opposed to making mods work differently.

I do agree that a fork that's breaking what standards there exist for OXC modding should also shoulder the responsibility for any bugs that arise due to their changes, but Xilmi hasn't asked you to resove his bugs, has he?

Just look at how many modders recommend your engine.

That's kind of a low blow, since BAI is quite new compared to most mods, and completely invalidates existing balancing methods.

Hellrazor is a good example, but I am not sure his objection that an AI-changing mod does not allow him to continue using old AI parameters is entirely valid.

[Meridian]

That's kind of a low blow, since BAI is quite new compared to most mods, and completely invalidates existing balancing methods.

Yes, and I have regretted writing this already 5 seconds after posting it.
Sorry.
Emotions are taking over when trying to convey a simple message and being ignored.

[Dioxine]

Well, it makes several missions unplayable or working radically different than intended (eg enemies killing Damsels), so not compatible with XPZ.

Things like it making game much simpler and one-dimensional (in my opinion it's a camp-or-die mod, at least in its current state), not even worth mentioning, to each their own.

[Xilmi]

Well, it makes several missions unplayable or working radically different than intended (eg enemies killing Damsels), so not compatible with XPZ.

Things like it making game much simpler and one-dimensional (in my opinion it's a camp-or-die mod, at least in its current state), not even worth mentioning, to each their own.

Things such as the Damsel-issue is what I wanted to know!
Now while I don't really know what Damsels are, I assume they are some sort of Neutral unit that the AI shouldn't kill.
While my regular target-algorithm takes "ignoredByAI"-flag into account, I have a suspicion...
I guess they might be killed via blind-fire. Blind-fire is used in particular against locations that are not a valid target but where an enemy has been seen before. And I just realized that my "isEnemy()"-method didn't filter out units with this flag.
It will in the next version.

Can you tell me how I can set-up a scenario where I can test my fix via the "New Battle"-functionality?

There was an issue concerning Extender-accuracy, which always forced the AI to get closer to the player, which meant that when that was used, the AI would always charge. This in turn made camping more effective than it should have been. I think it should be fixed now but I'll test some more.

My point is that I'd much prefer to get some feedback on the things people think don't work rather than them dismissing the project entirely based on their first impression. With feedback, I can look into these kind of things and fix them.

[Xilmi]

It's not about the stupid Triton!

It's about thousands of maps modders have made over the years, using this functionality, under these assumptions.
These maps WILL behave different, which is absolutely unwanted by OXC/OXCE devs.

This is the official documentation of BigWalls:

https://openxcom.org/docs/html/class_open_xcom_1_1_map_data.html#a5856c91db7d68ec89cd7f0ae143dbf9d
"Gets whether this is a big wall, which blocks all surrounding paths.

Return value key: 0: not a bigWall 1: regular bigWall 2: allows movement in ne/sw direction 3: allows movement in nw/se direction 4: acts as a west wall 5: acts as a north wall 6: acts as an east wall 7: acts as a south wall 8: acts as a south and east wall."

I don't think that anyone who has read this would assume that regular type 1 big-walls are supposed to be leaky depending on what angle you approach them.

This is at least the fifth time you "have a suspicion" that some random vaguely described behavior is definitely connected to a change you have made two days ago.
It's called confirmation bias.

It wasn't the case the first 5 times and it very likely won't be the case this time.

Unless you can provide at least some evidence, we assume it is correct and you have to prove otherwise. Not the other way around.

The method "isBlockedDirection" is used within the method "isPositionValidForUnit", which is used in "spawnNewUnit". So a failure of considering orthogonal directions as blocked will allow spawning units into walls.

This can easily be tested with using the warp-function in debug-mode, as it also uses the the same "isPositionValidForUnit"-method. Start a battle on a mountain-map, hit ctrl+d, then go to a wall-tile in a mountain and hit ctrl-w. In both OXC and OXCE the selected unit will warp into the mountain-wall this way. In Brutal-OXCE it won't because isBlockedDirection will return true for these tiles and thus make the position invalid for units to spawn in or warp to.

I would think that this is a pretty good indicator that units sometimes spawning into walls could be caused by an issue with the "solidity-check" of said walls in the unit-spawning-algorithm.

Let's say Dioxine wants enemies to pick up Plasma Rifles, but not Blue Chips.
If your engine ignores these settings, enemies will start picking up Blue Chips and be rendered non-threat.

If there are legitimate reasons not to pick up blue-clips, I'd rather have a generally valid algorithm that can determine whether it's worth to pick something up rather than forcing the modder to create a whitelist for evey item that should be possible for the AI to pick up.

Everything can be exploited in one way or another... as you have already found out, since you have changed your decisions back and forth many times (judging mostly by the changelog).

Changing my decisions back and forth is the result of not being dogmatic. If someone can demonstrate to me why my assumptions were wrong, I'm willing to reconsider and try something else instead. For example: Trauson showed me how exploitable blind-shooting can be and so I changed the AI to not really do it anymore, despite it having seemed highly effective against people who didn't know how to exploit it. As I initially said, AI is not something you just do and be done with. It is a long, iterative process with the goal of trying out different approaches and ending up with whatever achieves the best results.

Why would modders even bother modding, if they don't have control over the outcome?

My expectation as a modder would be that I can give the AI whatever kind of unit/weapon/terrain-combination I can come up with and that the AI then would be capable of grasping what it can do with that on it's own based on the properties of the units, not some arbitrary additional values that have to be set to control the AI.
For example: When I first started modding with Civ 3, the AI would not understand when to build certain buildings and how to use certain units until I specifically flagged them in certain ways. I thought that this was annoying and that a more generalistic approach of AI would use some sort of algorithm to determine the use of this stuff based on it's properties.
And now I'm in the position to write these algorithms. Of course I need to know about the possibilities that they have to be able to handle.

[Meridian]

If there are legitimate reasons not to pick up blue-clips, I'd rather have a generally valid algorithm that can determine whether it's worth to pick something up rather than forcing the modder to create a whitelist for evey item that should be possible for the AI to pick up.

What you call "forcing the modder", I call "giving modders the freedom". Literally.

I see we have completely opposite opinions on how openxcom modding should look like... and that's fine.

I didn't want to create any drama, so this is my last post here.
I apologize to everybody who read through this wall of posts, sorry to waste your time.
I'll refrain from any drama in the future and just try to do honest work as usual.

Happy modding.