Now I am thinking out loud how this can be balanced back with AI getting smarter.You have 3 options:
You have 3 options:
- just like in any megamod introduced out there. By increasing the challenge curve according to player's progress;
- by starting equal;
- by developing completely new gameplay design
Congrats with the release!"not confused" and when I see attachments, its show red OXCE logo :>
And I suggest to change the picture of the executable file icon so that it will not be confused with the original OXCE. Something like this. I'm not sure if one ico file is enough to do this, or if all the other 11 files found when unzipping the exe file need to be processed as well.
Do AI sees where my soldiers are shooting or throwing from? Even if they do it from the middle of the smoke cloud? If so, that would explain why they keep throwing grenades at my soldiers into the middle of the smoke cloud without some notable spotting.Yes, they track where they were attacked from. This is tied to the "Targeting behavior for Brutal AI"-option. If you don't want them to do it, put it down to "2".
Actually, quite curious if anyone is playing BAI in vanilla ruleset for FUN?Well, I do. :o
😃
Actually, quite curious if anyone is playing BAI in vanilla ruleset for FUN?I think, <5% players. Better ask platform owners, if they have such reports.
Congrats with the release!
And I suggest to change the picture of the executable file icon so that it will not be confused with the original OXCE. Something like this. I'm not sure if one ico file is enough to do this, or if all the other 11 files found when unzipping the exe file need to be processed as well.
# Remove molecular-control-disruptor
items:
- delete: STR_MC_DISRUPTOR
research:
- delete: STR_MC_DISRUPTOR
- delete: STR_MC_GENERATOR
manufacture:
- delete: STR_MC_DISRUPTOR
ufopaedia:
- delete: STR_MC_DISRUPTOR
Just discover this in BrutalAI_TFTD.rul. Is it part of BrutalAI philosophy to remove MC Disruptor?Note that this is a Micro-Mod I added and not enabled by default. It was mostly a result of witnessing how laughably trivial the game became with Psi even against Brutal-AI. As I said back then: How good the AI is at controling their units doesn't matter, when they don't have control over their units.
Were you able to find a strategy?To be honest I mostly play with the Mission-Generator. Where the outcome of a single battle has no impact on the progression of a real game.
I like the colors but it looks like an upscaled very pixalated smaller icon.
Nice, yeah I second a new graphic icon for the binary, maybe something more BRUTAL like feeling :)
Note that this is a Micro-Mod I added and not enabled by default. It was mostly a result of witnessing how laughably trivial the game became with Psi even against Brutal-AI. As I said back then: How good the AI is at controling their units doesn't matter, when they don't have control over their units.
To be honest I mostly play with the Mission-Generator. Where the outcome of a single battle has no impact on the progression of a real game.
I've done a big number of attempts of just doing a play-through. I got better at it but as I got better, I also passed my findings to the AI. So the overall perception of difficulty felt similar despite both my own and the AIs progression.
So what I can say is: I'm not aware of any cookie-cutter strategy that makes me win long-term. If I was, I'd look into it. There are some really effective tools, which can give you an edge. And you kinda have to use them. The hard part is still to survive early on before you have most of the tools. And on Superhuman that's really hard.
Well, it is in standard and has user options and is seem to be loaded. So this does has effect on what I am playing. Besides, engine complains that ufopaedia article is missing type_id.Do you happen to be proficient enough in modding to tell me what I'd have to change about it so the engine no longer shows that complaint? :o
Do you mean you play quick battles only and not the whole game? Cannot understand how them can even be played together.I said "mostly", not only. I've done my fair share of attempts of a campaign. A lot of my play-time is testing AI-changes so jumping into old benchmark saves or new-quick-battles is what I mostly do.
Are you saying you don't even plan for this mod to be playable as whole game? That could be fine too. I just trying to understand your intentions.No! What about the sentence you quoted would suggest that? Of course it's supposed to be playable as a whole game. Lowering the difficulty-level actually does a good job at also making it winable.
The only thing I cannot understand how it knows to throw grenades to my soldiers with utmost precision when they are in the middle of the fresh smoke cloud? What other indicators it uses to pinpoint their location besides seeing them directly?Shooting a weapon and throwing or dropping an item to the ground also update the AI's information of your units wearabouts. So basically the same things you'd also notice if the AI did them. You don't want to stay at these locations as they are marked for blind-grenading via these actions.
Do you happen to be proficient enough in modding to tell me what I'd have to change about it so the engine no longer shows that complaint? :o
I don't think it is generated by your mod. However, other mods may generate it IF they carelessly mention ufopaedia STR_MC_DISRUPTOR. Like mine does.In this case it might be related to load-order or simply incompatibility in general.
So I should probably adjust my rulesets if I want to get rid of it. No worries.
With this in mind, let me reiterate the question. Are you sure it makes game very easy when psionics are involved? After all aliens control aquanauts as well.This is not a complete removal of the psionics-feature. The complete removal of the psionics-feature has it's own mod called. "XComUtil: No Psionics". My mod only disables the researchability of the item that allows X-Com-Soldiers to use it. Aliens can still use it and you can still screen and train your soldiers with a psi-lab to become more resistant against Psi.
Any other means to cope with this without complete removing psionics feature?
I understand how I notice aliens shooting and throwing. Not sure about dropping. Is it somehow also gets the focus? Meaning at some far corner that I cannot see the camera shows the alien dropping stuff on the ground?No, but dropped items are shown on the minimap. If you do a before and after-comparison you can see if new items appear on the minimap. Aliens usually don't drop stuff anyways. Players use it as an alternative to throwing, when it comes to smoke-grenades.
However, practically wise it is quite impossible for human to mark and remember exact spot of shooting/throwing origin. At times I recall where they were attacking from but not sure about exact tile. That is beyond my mental abilities. I guess, same for most other humans.When you use lower projectile-speed and pay attention, you can tell it much better. I've seen this mostly done by Trauson, whom I learned a lot from. He deliberately sacrificed soldiers to then pay good attention to where they were attacked from and then carpet-bomb these locations with grenades. So I taught the aliens to do the same and at the same time be better at countering his strategy by moving after shooting instead of staying were they were.
With this in mind, would it be human like fair to not give AI a super specific location of action it cannot see? Maybe do the same to the human as well to maintain fairness?As I said before: This feature is completely optional and only happens when "Targeting behaviour for Brutal AI" is set to 3. So you can turn it off, if you think it's unfair.
With this I feel like aliens penalize the person accidentally farted by immediate shooting and throwing at their location.
😲
Alien activity tracking tool.Can you talk a bit about it. I'd be mostly interested in learning how it comes to this pop-up. Like is there a frequency how often it checks and will there be several checks for the same activity?
It shows sectors (regions/zones) with 5+ hours of continuous untracked UFO activity. Pops once new region/zone comes into list.Sounds good! :)
The continuous counter is reset when there is no more untracked UFO activity in sector or there were actual UFO detection.
Currently all hardcoded but I surely can add multiple parameters to it. Not sure it makes sense, though. 5 hours seems to be a good spot. Lower values would generate many false positives for fly throughs.
Brutal-OXCE 7.13.0 - Smoother aggressiveness progression
How can you estimate new intelligence options, compared to old ones?Well, to be honest I was/am a bit afraid of the feedback of those who used the old one. The old one led to the AI being severely nerfed and playing a lot worse. The new one makes it only slightly weaker than previously just using "Weighted randomization" but at full intelligence. Repeated reports about the AI doing something really stupid and then seeing that it's because of all the random moves it does, triggered me a bit in this regard.
Changelog section only, will show the amount of work you've done.The complete change-log can be found on the github-page. I made a threat linking to it.
This could be a better solution to level the playing-field without having to disable the AI's capabilities.And here we go. :)
Holding the Alt-key will now highlight the locations where enemy units have last been spotted in the current or previous turn in addition to showing the result of using a motion-scanner.
If both applies the motion-scanner result will be used as it is more current.
By the way, how player can tell what level these yellow arrows are? I never could understand this after using scanner. However, the scanner does not reveal the level too. So, I thought, that is acceptable.You are right. In multi-story-houses it can get confusing. I noticed this in my own play-testing.
In visual AI detection level matters, though.
1. You may need to clarify what "current or previous" turn means. Maybe just clearly state that these are location where motion scanner detected motion in player turn + places where they shoot, threw, or dropped items on the ground in last alien turn.Current means during the turn of the player. For example when the alien reaction-fired. And previous is when it was the alien's move.
2. What is "if both applies"? Meaning they detect something in the same tile? Then, obviously, player would see the single arrow there. Do you mean scanner somehow can override or remove any of the alien turn detection?I mean when an alien was both spotted during their turn and then scanned during the player's. The problem occurs in combination with your last remark. The scanner-information is more up-to-date but lacks the information of the z-coordinate. If I make sure to show the right z-corrdinate for the spotted unit, then overriding it with the scanner will ruin that information. So I need to think about a better solution.
You are right. In multi-story-houses it can get confusing. I noticed this in my own play-testing.
The z-axis always gets set to the current one when drawing the arrow. I'll experiment what happens if I don't do this.
The problem occurs in combination with your last remark. The scanner-information is more up-to-date but lacks the information of the z-coordinate. If I make sure to show the right z-corrdinate for the spotted unit, then overriding it with the scanner will ruin that information. So I need to think about a better solution.
Do I understand correctly that AI marks not only dropped items but also picked up ones? I.e. something was laying on the floor and now it is not.I'm actually not sure about that. I think there may be a bug/unintended marking, which I wasn't aware of until I played with the new Alt-feature and sometimes could see a mark when I don't think I should have seen it. I have yet to find a way to reproduce it and figure out the reason in order to fix it.
Also in regards to your other point about how exactly it should be displayed. You suggested to use something other than the arrow. That's a lot trickier to implement. For the arrow I just had to hijack the respective existing method and make some adjustments. To draw something different instead would be more difficult.
Also the way it's implemented iterates through the units, that's why it makes only one arrow per unit if both scan and spotted is the case. So what I hope I can maybe accomplish would be a separate different color-arrow that is also only shown on the level the unit was seen.
The old one led to the AI being severely nerfed and playing a lot worse.Well, it would have been comparable to vanilla AI on 40% random on the battle output, if not grenades.
Now the puzzle starts coming together. It is still hard but, at least, I know why am I getting hit out of nowhere.Yup, your conclusions about how to tactically adapt are spot on.
At which point AI receives a clue an item dropped on the ground? Immediately or at their turn? Do they notice if I drop and pick in same turn?Unfortunately it's immediately. Simply because it was easier to make the call when it happens rather than checking the before and after state of all tiles. And to be honest I'd rather remove that capability alltogether instead of implementing it in a way where it's only at the end of the turn. It's not important enough for the overall play of the AI to put in that effort.
I just tested it and the AI doesn't work properly with bug-hunt-mode enabled.I fixed it and it now works as intended.
I checked your code and it seems that you attach "last spotted" property to the unit. This does not seem right since spotting action outside of visibility does not reveal the unit itself, only action.Technically all of this is correct. One thing to take into consideration is effort vs. benefit. Tracking all the action-locations independently in a new data-structure, which also would have to be added to the save-game-structure just to then also write an algorithm that tries to deduce unit-locations from this data is something that just doesn't seem worth it. I'd say the end-result of that effort would be practically indistinguishable from the current behavior. And that is not something I consider worth spending several days of coding and testing for.
Meaning, you have a location where shot originated from. Which unit did it remains unknown. Moreover, game does not indicate whether multiple actions were conducted by same unit or multiple. Of course, one can infer that actions from opposite corners cannot be done by same unit but this is up to human/AI to decide. The point is game engine should provide the information, not conclusion. In this regard, action locations are self informational data not related to any unit. If unit is invisible it is not even possible to tell whether it is still at location or moved away.
This is, actually, another strong reason not to mix it with scanner indicators because it spots actual units, not action locations.
The change to how intelligence works is basically a shift from low intelligence causing occasional massive blunders to low intelligence causing inaccuraciesWell, that's fair. But let me represent literally everyone here on forum: All-hiding is boring! We want random strategies!
Played with yellow arrows a little. Much more satisfying. They blind shoot me but I do the same sometimes with better efficiency.What aggression-settings do you use? On a balanced aggression, like the default 2/2, they should only rush toward your troops if they think they can overwhelm you. Also it seems to be a bit contradictory. Both sides doing a lot of blind-shooting doesn't sound like rushing.
Game seems fair but playability is seriously skewed. Combat is very fast and very intense. They rush toward my troops and whole battle continues and ends is in transport vicinity. Blind shooting is the 90% of all damage dealt to both sides. It is spiraling retaliation on retaliation.
What aggression-settings do you use? On a balanced aggression, like the default 2/2, they should only rush toward your troops if they think they can overwhelm you.
Also it seems to be a bit contradictory. Both sides doing a lot of blind-shooting doesn't sound like rushing.
I'd actually like to see some footage where you point out what issues you have.
It seems like you'd prefer the AI not to do blind-shooting rather than having a feature helping the player do be better at doing the same. Oh wait, there seems to be another contradiction. You say it's much more satisfying but then you say playability is seriously skewed.
I can't really deduce what your preferences are.
1) Is what being discussed above means that BAI knows whether you drop something on ground and marks this as enemy position?It used to be the case that the AI notices that. But I'll remove that in today's patch.
If yes, then would it be within line of sight or everywhere on the map?
2) I read the statement about snipers. This is one of particular winning strategies for players. There is bunch of them, and I can't believe BAI can adapt to every single one.Well, my mindset as AI-programmer is to either copy or counter the strategies of the player. If you are aware of winning strategies of the player that BAI seems to be particularly unprepared for, please let me know so I can look into it.
Like, your initial intention so AI avoids proximity grenades = minus one strategy for player.
Human's brain is a thing that tries to crack and abuse any (pseudo)winning mechanic both in game and IRL.
3) How would AI understand that it's push time? It has to peek, otherwise the active battle map transforms into trap/puzzle, which is worst experience from the player's perspective. Personally, I would agree to play if they will not exceed 20-30% times overall.The algorithm that determines the internal aggressivness considers morale, unit-stats and unit amount. This is the "flowing"-part of it and it gets multiplied with whatever base-value for aggression is set.
4) Look at the scenario: 15 units came in craft, 2 are out, others are standing inside behind the doors (let it be Triton). What 20 enemies will do? Will BAI estimate overall enemy amount as 2? Will it push? Or AI knows that 15 units came and will run for cover from turn 1?Right now they know how many units you brought. It would be possible to make them not know about the amount until they've actually encountered the units. Could be done by checking the "turnssincespotted"-variable and skip everyone for these evaluations where that is at the inital value.
5) This particular question is quite important, because what else will make player feel that it plays vs sentient AI otherwise than chess-AI. The chess-AI leaves worst and most disgusting taste after each battle, steals fun.Well, the AI is not sentient. And replicating signs of sentience via heuristics isn't really something I feel capable of. It's all a bunch of algorithms that calculate scores to pick between the available options. What kind of information is accessible to these algorithms has impact on the outcome. The tech to make it feel sentient is probably there. Would require someone to train a NN on some array of super-computers for a while and there we go. But I'm a hobbyist who just does what he can in his free-time.
6) I would still leave nerfed option for near-casual players, only because it's already there.I'd like to look into accomplishing something similar to what I've done with aggressivness with the intelligence. Going back and forth between really good and really bad moves depending on a die-roll feels wrong to me. I'd rather have something gradually scaling.
All-hiding is boring! We want random strategies!I guess we need to define what a "strategy" is supposed to be in this context. The tactical combat is usually called tactical combat because it's more about tactics and not so much about strategy. A strategy is a long term plan you are slowly working towards. Something that in the context of X-Com applies more to the geoscape. Tactics is much more in the moment. Deciding what you do at any given turn. There is no long-term-planning of my AI in tactical combat. The aggressiveness maybe is the closest to resembling some sort of strategy as it decides between trying to bring the fight to the enemy or trying to lure the enemy into an ambush.
7) What do you think, can you split enemies on the single map into BAI units and vanilla units? This will make more sense in terms of overall efficiency. Vanilla units do what the do in vanilla game (doubtful effectiveness, yet still makes heat), BAI units do what they do as intended.It's probably better to fixate units on one behavior rather than randomly switching between them. This should help against just spamming end-turn until all units randomly wandered into reaction-fire.
They share vision, may it even sometimes be sniper-spotter vision.
This approach may work a little bit better than BAI makes blunders itself.
The amount of VAI/BAI may be random.
The VAI/BAI control may be static or random too.
Each mission makes unique experience. Some are easier, some are tougher.
Players never guesses what comes next.
Surplus here that initial enemy units layouts can be whatever from "all covered inside somewhere" to all standing around your Humvee, facing you with RPG's in their hands.
8) Have you had time/curiosity to see the Osiron Hacienda save?I had forgotten about it. I'll try to find it in this threat and see what the AI itself thinks is the best approach based on the aggression-scaling. I can try and see what happens when I set aggression to 1/9 and to 9. Which should represent both of your suggested strategies and see how well each one does.
It is wonderful map for AI to take multiple strategies, all winning. Both covering inside and sturming player's positions with massive attack.
9) Do you think it worth effort to teach BAI to estimate storming possibility/efficiency by measuring amount of bullets and DPS player caused within first 2-4 turns?No. And for the same reason as I told Alpha Centauri Bear: Using complex data-gathering-algorithms and heuristics just to determine an readily available value like "enemy unit count" generally seems like a bad effort:usefulness-ratio. I did that for the enemy positions because knowing exactly where each enemy is without scouting is a massive tactical advantage.
I want to propose you a thing, that will draw additional attention: silenced/loud weapons mechanic. This is purely AI mechanic. Right now there's no such presented.That's actually a neat idea. These silent weapons wouldn't let you see where they were fired from, only when they hit and they wouldn't tell you and the AI the location of the attacker. But it would be some work for the AI to make them avoid something they have no clue about where it is. I think a way to make it work would to put the assumed enemy-position on themselves and then run the algorithm that guesses where it could have gone out of visibility.
Loud reveals the area of possible player unit location, while silenced makes AI understand they under siege, still not knowing where exactly enemy is. Could be good thing to brainstorm the logics.
Difficulty settings and balance should be done by parametrizing unit strength and other things. Similar (but opposite) to vanilla dumb AI with overpowered units.Your word in Abyss' ear! :D
All defaults. That is right. They think they can overwhelm me and then, boom, they not. Sure, sometimes I have to hunt one two remained but usually the battle is done by then.If this is the case, then it sounds like it's not really working as it should as of yet. I'd like to have a save from such scenario so I can investigate what could be done about it. I'd like to know what aggressiveness they internally calculate.
No need to modify anything at this point. These are just "front line reports".Okay, thanks.
😄
If this is the case, then it sounds like it's not really working as it should as of yet. I'd like to have a save from such scenario so I can investigate what could be done about it. I'd like to know what aggressiveness they internally calculate.
8) Have you had time/curiosity to see the Osiron Hacienda save?The Osirions get an initial adaptive aggressiveness of 8 up from the base which is set to 1.
It is wonderful map for AI to take multiple strategies, all winning. Both covering inside and sturming player's positions with massive attack.
I don't really understand what these 2 new options do. How does their values change the AI?They belong together and work similarly to how it used to work before but with fraction-arithmetics and normalized around the value of 1.
As I have it set now the AI has become real dumb. They like to setup traps, which is cool, but they have a tendency just to send out one by one now. Especially through doors. I think 8 or 9 just walked in here and just died to the dog.Over the course of how many turns? What do your other settings look like?
They belong together and work similarly to how it used to work before but with fraction-arithmetics and normalized around the value of 1.Oh, so it is the first divided by the second, so if the first is bigger they become more aggressive?
So with 1 over 2 to or 0.5, they are more on the careful side.
Over the course of how many turns? What do your other settings look like?It was just 2. They have a tendency to spread out and just attack one by one, or if they are in a group, form a conga line and just walk into an ambush. They get like 1 or 2 attacks then they just move away 1 or 2 tiles to be killed next turn, if they survived.
I think it could be a very similar issue to the one I just noticed myself in the hacienda-mission.
The AI wasn't really tested for scenarios like that where there's a lot of individually weak enemies that have to make use of their numbers to accomplish something.
Do they get in attacks on the dog? Do they strand without TUs near it? Can I have a savegame of that scenario?
They get like 1 or 2 attacks then they just move away 1 or 2 tiles to be killed next turn, if they survived.If this is the case, then your units obviously outclass them by an order of magnitude.
Here is an example that just happened a few turns later. My unity was on the cursor facing away, and the enemies just walked up to it and start shooting or punching. They did no damage and you can see the result.
Cause all this happened with melee, no shooting.Melee tactics are all being discussed, so if you have a suggestion of optimal behavior in this particular case - it's most welcome. Right now no other than hide and ambush was proposed.
The aggression-mode-setting now has only the option to multiply unit-aggression with the baseline-aggressiveness instead of replacing it. This way the baseline-aggressiveness can be adjusted to the aggression-values used within the mod to produce the desired results. For example if 2 is supposed to be the avarage balanced behavior the baseline-aggressiveness should be set to 1 over 2.
Also when you guys play quick combat, which race do you play against? I found that even slight variation in alien toughness has very significant effect on the combat. Six soldiers have enough firepower to fend off six Gillmen but six Lobstermen will just cut through them as hot knife through butter just because they cannot be killed in one turn.
Melee tactics are all being discussed, so if you have a suggestion of optimal behavior in this particular case - it's most welcome. Right now no other than hide and ambush was proposed.I'm not sure I'm that experienced with XCom to give ideas on how it should work, but there are a few things I want to mention. I always try to use the latest version. My settings are in a post above.
Personally, I think one single optimal model for BAI tactics is not good, so boosting melee strategy in one condition (closequarters) will lead to decrease of melee efficiency in different (open field).
BTW which version of BAI did you use?
One more thing I noticed playing campaign. It is near impossible to acquire live specimen as they all carry preprimed grenades. Kamikazes.I had this problem too and if they had a key item it was really bad so I turned it off. I used dogs to pick up bombs but a big problem is also that you can't tell if it's a mine or a bomb.
Looks like the only way to do it is to jump on somebody with few soldiers with stun rods and pick the primed grenade once the body falls. Didn't try it yet but it seems to be quite difficult.
Long range stunning becomes quite useless for this purpose.
You said you are playing campaign with this mod too. How do you capture them?
I think that units, no matter how unmatched they are, should fight with their ranged weapons, unless they are melee units, and only consider melee if they think they can survive the next turn (hit and run) or can't run away.
But I don't want to enable BAI for brutes either. Having monsters hide behind obstacles indefinitely and then rush out and unleash 500 hits when you take one wrong step is no fun either. It's especially bad when you face monsters so tough you can't deal with them at the start of the game, that they just rush you and kill you.
But I also kinda want brutes to have some BAI features, cause right now they just walk around in circles and don't know what to do. If you have a flying unit you can just herd them and that feels off with such powerful units as Chryssalids.
An other problem with inconsistency I have is with Chasers. From the first turn they just rush you with no regards to survival. And if one of them has the mighty egg launcher it's really bad. Add to this the absurd amounts of units in XCF. I'm not sure how to deal with this other the just blindly run out from the spawn and try to hide, or if possible try to spread bombs, but running around with pre primed bombs is bad. But if you can survive 2 or 3 turns, then they tend to become really cowardly.
In one ship mission only a few spawned outside the ship and got killed. The rest inside the ship, 10+, just decided to cover in fear or something, and camp the door. Not very Chaser like behavior and they got a rocket for it.
On the other hand, this behavior works very well for Hybrid bases. The assaults come rushing forth while the rest do a more careful approach. It feels really nice and the only problem again is the huge amount of units at the start.
Well, if you set the squad's aggression mode to the unit's intelligence, then you should have 2 in the numerator and 2 in the denominator. So, if the unit's aggression is conditionally equal to 3, it will look like this (2/2)*3. In your case, the final value will reduce the aggression of opponents by 2 times. (This may not be accurate :D )
Numenator = 1
Denominator = 2
One more thing I noticed playing campaign. It is near impossible to acquire live specimen as they all carry preprimed grenades. Kamikazes.Aliens pre-priming their grenades is also an optional feature, that can be turned off separately.
Looks like the only way to do it is to jump on somebody with few soldiers with stun rods and pick the primed grenade once the body falls. Didn't try it yet but it seems to be quite difficult.
Long range stunning becomes quite useless for this purpose.
You said you are playing campaign with this mod too. How do you capture them?Sometimes they randomly just survive. I haven't gotten far enough to do a deliberate life-capture on higher-ups.
Also when you guys play quick combat, which race do you play against? I found that even slight variation in alien toughness has very significant effect on the combat. Six soldiers have enough firepower to fend off six Gillmen but six Lobstermen will just cut through them as hot knife through butter just because they cannot be killed in one turn.I definitely wouldn't go up against Lobstermen in basic gear. You need the tftd-equivalent of power-suits and some sort of melee-weapon, which they are weak against.
It seems to require quite fine tuning in alien stats to make campaign playable.
Is unit intelligence used anywhere in current default settings?Not in default-settings. You'd have to modify the "Intelligence-mode"-setting and put it to "1" or "2" in order for unit-intelligence to have an impact on the AI's behavior.
Aliens pre-priming their grenades is also an optional feature, that can be turned off separately.
Sometimes they randomly just survive. I haven't gotten far enough to do a deliberate life-capture on higher-ups.
I definitely wouldn't go up against Lobstermen in basic gear. You need the tftd-equivalent of power-suits and some sort of melee-weapon, which they are weak against.
Not in default-settings. You'd have to modify the "Intelligence-mode"-setting and put it to "1" or "2" in order for unit-intelligence to have an impact on the AI's behavior.
Have no single idea what to set as EA numerator and denominators.Le me try...
Tried to read it carefully, but my end-of-the-year-final-reports-fucked-up brain cannot comprehend what these variables do.
Can you explain this on fingers?
Does that mean setting Aggressiveness mode = 2 (to use Leeroys flags) in XCF is pointless, as it directly interferes the NO to brutal brutes? Or I am getting something wrong?Yes, if Brutal Brutes is disabled, then aggressivness-mode 2 would be pretty pointless in the scenario you described.
What is aggression in vanilla OXCE? Isn't it some sort of modificator which shows how often unit will decide to attack, given an opportunity? Vanilla 0-10 gradation represents chances for when unit will decide to move somewhere instead of performing an attack?Firstly: 0-10 isn't really "vanilla" afterall. I checked the vaniall-rule-files and it uses values from 0-2.
Minotaur with flamethrower has ruleset aggression =5 , is not brute. Thus with abovementioned settings, it will be more pushy other then defensive, but still sometimes take cover, right?Yes, this is correct. But as said before, it also scales with morale and perceived unit-power. So if their team is rather weak they might still be more skittish.
Cybermite is Leroy, but has aggressiveness = 2, thus supposed to be more careful, but still doesn't take cover. I can't comprehend it.Well, no. Leeroy always overrules aggressiveness and basically forces the unit to be suicidal no matter what aggression otherwise says.
But I don't want to enable BAI for brutes either.Up until this point what you described really sounded like a bug to me. But if BAI for brutes isn't enabled, then you are essentially just fighting the default AI, which I have no control over. After being used to playing brutal-AI the default-AI just starts looking incredibly stupid by comparison.
Having monsters hide behind obstacles indefinitely and then rush out and unleash 500 hits when you take one wrong step is no fun either. It's especially bad when you face monsters so tough you can't deal with them at the start of the game, that they just rush you and kill you.I think I really wanna go back to the stance of I had when I initially started, which Alpha Centauri Bear also recently mentioned:
Generally, I think you should make AI as smart as possible and do not dumbing it for easier difficulty.I feel like I already invested too much time into arbitrarily limiting the AI's capabilities in order to provide options to nerf them just the right amount to make the game feel balanced. Modders can throw all sorts of scenarios at the player and I simply can't predict or know all of them, let alone do intesive testing and tweaking of AI-options just so every possible scenario can somehow "feel right" to the player.
Difficulty settings and balance should be done by parametrizing unit strength and other things. Similar (but opposite) to vanilla dumb AI with overpowered units.
One more thing to mention is the option to tweak aggressiveness. I don't like this, just have an option for setting aggressiveness mode and then just do the tweaking under the hood from testing.I totally agree with this. It is a really good example for an "overchoice"-kind of option, that hardly anyone will want to mess with out of fear of "making it worse". So it might aswell not exist. Deciding on whether displaying aggressive or defensive behavior is something that should be done based on the game-state and I'm still looking into better algorithms to do so. Was experimenting around with an intresteing idea before christmas and now that I'm back I'll look into that some more. This might very well end with removing the option to tweak the multiplier from the outside.
Livingweapon: true is same for a number of creatures, most of which are wild creatures, like megascorpions and even zombies. I'm not sure, but isn't this flag enabled makes possibility of brutal brutes on/off switch?It was considered. And I'm not really opposed to changing it to that. But I think I looked at examples for units with that flag and must have felt for at least a few of them that it wouldn't fit. But that's always the problem with arbitrary restrictions. Either the current way and this way are arbitrary. I think a better way was to introduce a new parameter. Something like forceNoBAI or something like that, which modders then can give to certain units in order to override the global setting in the other direction.
Probably we should ask Sol how exacly chryssalids should be represented with BAI in particular.I'm wondering what that should eventually lead to. I mean it would surely be interesting to hear something about that. But Chrysalids aren't the only unit in the game so what's next? I certainly won't be coding a separate kind of behavior for every single unit modders can come up with and have an optionion of how those should act. Especially not of these kinds of behavior are an obvious deviation from optimal play.
Xilmi, I overviewed the units RUL file and found few inconsistencies regarding intelligence numbers.Well, you're not the first to come to the realization, that these numbers are all over the place and thus not really a good bases to base behaviors on. That is because intelligence is not really used for decision-making in the standard-AI. It's basically just "how many turns does this unit have access to player-unit's whereabouts after spotting them?". The way base-AI works makes this almost exclusively relevant for using PSI-attacks against the player-units.
A sub-conclusion is: intelligence in RUL file may not correlate with 0-10 scale, but rather represents some abstract behavioral model. I mean, that int =1 doesn't mean that creature is stupidier than one with int = 6, it might be just some other decision-making framework.
Have to ask someone more knowledgeable about the topic.
Also, same little trouble may be with unit aggrassiveness in the Rul file, too.
What is the intelligence range? 1-10?Right now it's 0-5. At least as far as leading to a differentiation in the outcome. Everything above 5 will just have the same result as 5.
I think you should make AI as smart as possible
Right now it's 0-5. At least as far as leading to a differentiation in the outcome. Everything above 5 will just have the same result as 5.
Up until this point what you described really sounded like a bug to me. But if BAI for brutes isn't enabled, then you are essentially just fighting the default AI, which I have no control over. After being used to playing brutal-AI the default-AI just starts looking incredibly stupid by comparison.It really is stupid. Melee only units just don't move in to attack if you keep some distance. BAI should definitely control them, but they should probably value getting closer to you over taking cover. That would make it fair I think.
Modders can throw all sorts of scenarios at the player and I simply can't predict or know all of them, let alone do intesive testing and tweaking of AI-options just so every possible scenario can somehow "feel right" to the player.I know, that's why I play XCF on level 3. ;D
I honestly feel like this was taking a path in the wrong direction. Using a mod that wasn't designed with BAI in mind is pretty much "at once own risk". And I'd like to remind that difficulty-levels still do exist.
Because (lorewise) some aliens are dumb meat puppers and/or feral critters, while the others are psychic masterminds or ET stormtroopers?
Sure, but then someone also has to tweak the mod(s) to include data for both AIs. Reusing existing intelligence variables is a compromise and, like many compromises, it does its job but not well.I intending to do replacement unit_RUL file for XCF, there's not much of units. Around 200 or so. And pretty all units are familiar enough to work around. But I have no idea how to make it as optionable mod via settings, not as permanent replacement.
What exactly are you asking for as far as an 'optionable' mod goes? You can already make a mod either recommend or enforce individual game settings, and one can certainly set any global variables that need resetting for BAI compatibility.
I don't understand the notion of mod "compatibility". Why they even should be?Because they change different aspects of the game, and some people want to play a megamod with harder AI? One that's not likely to migrate over to BAI in its entirety, that is. Hoping some random fan will make a compatibility patch vs providing some built-in compatibility is the question here.
After all higher intelligence number leads to deadlier unit in this mod. However, if they diverge than they diverge.The point of this tangent was that in vanilla/mod rulesets, higher intelligence isn't necessarily 100% correlated to more 'intelligent' or even more dangerous units.
Simply, how it is all done so one ruleset is forcefully getting replaced with another one, while original Sol's unit.rul file stays intact. Probably, call it "Brutal-AI optimization of units for XCF".As long as you don't go into people's houses enforcing the ruleset replacement (or at least hacking their machines :P), nothing 'forceful' can happen to files and computers not under your control.
The alternative can be just replacement of original unit.rul file with another, which contains adjusted intel and aggro settings.
Because they change different aspects of the game, and some people want to play a megamod with harder AI? One that's not likely to migrate over to BAI in its entirety, that is. Hoping some random fan will make a compatibility patch vs providing some built-in compatibility is the question here.
The point of this tangent was that in vanilla/mod rulesets, higher intelligence isn't necessarily 100% correlated to more 'intelligent' or even more dangerous units.
No arguments here. I never even paid attention to unit intelligence in vanilla/OXCE. That is why I am very curious how people use it in other mods that they want to transfer this functionality to BAI ???Vanilla AI and BAI work in different way, and Xilmi was the first person to propose migration of native (i.e. modder-set) intel and aggro settings into BAI. What is being discussed here is that, although, approach is overall good, the VAI and BAI intel and aggro doesn't exactly correlate in a way one may suppose on the initial look. Thus, while most units work perfectly fine, others work not as intended.
The winter queen's outfit should give 1 glamour and 1 silver chip. If you upload the save file to brutal OXCE, launch the mission, and then immediately fly away on the first turn, there will be no loot.There definitly were ninja badges in my last playthrough. That was 7.9.13
All units of the ninja faction have built-in ninja badges. Badges will also not appear after killing ninjas.
If you upload the save file to brutal OXCE, launch the mission, and then immediately fly away on the first turn, there will be no loot.The save you attached is during a base-defense. If I abandon it, I lose the base and everyone who was in it. Are you sure it's the correct save you wanted to attach?
The save you attached is during a base-defense.
There's a bug in 8.0.1 that makes it very very likely to crash when you end a mission. It happens both when you finish it or choose save and abandon game. The save does not corrupt though.Damn. That's horrible to hear. :'(
It also randomly crashes during enemy turns so I had to revert to 7.13.1. It was crashing constantly so it is not really playable.
Damn. That's horrible to hear. :'(No it's gone since I reverted. But it should have happened to you for sure so it might be something else.
So now it's not only that I have to redo the merge and hope to not break the hangars again but also look for the reason or even reasons of a crashes.
Do you happen to have savegame(s) from just before crashing? It could potentially be related to going from 32 to 64 bit. But could also have other reasons. I had some weird issues related to pathfinding-destructor.
A thought that struck me: how does Brutal AI handle the situation when an enemy is given at least two weapons, and the better one suffers from the two-handed penalty? Or they both do? Or they get something like four handguns with different stats/ammo? How do they choose? Do they choose? And, most importantly, how do they avoid the two-handed penalty manage to use two-handed-only weapons in this situation, if at all? Something like a rocket launcher, an axe and a pistol all at the same time.The way "multiple weapons" are handled via the AI-API is not really fleshed out. Most likely because the vanilla-AI can't do that at all. They just determine their "main-hand-weapon" and then go ahead using it. The main-hand-weapon is determined by looking at the right and left hand. If there's a weapon in each it'll pick the one that requires fewer TUs for a basic attack. Additional weapons are ignored. That's how, for example the Lobsters in TFTD don't know they have a melee-attack and the little saucer-terrorist in TFTD don't know they have a ranged-attack.
Could anyone else reproduce the crash and has a save from shortly before?Hi!
I've been trying to catch a crash for an hour now and it simply doesn't happen on my side. :\
I can confirm the game crashes when you press save&abandon the mission when playing Ironman. The game crashes to windows. But should leave to main menu. The issue may overlay with what donk has described.I could reproduce it once myself. With 8.0.2 I now provided a 32-bit-version again. Unfortunately the issue was not reproducible enough to do good testing or be confident that it's a 64-bit-issue. I do, however think it's quite likely it is. So it would be nice if the people for who it crashed frequently in 8.0.1 could try whether the crashes stop with the Win32-variant.
The save is attached.
Actually, I also want to complain on BAI, which in 8.0.1 has only one aggressiveness adjustment. And when set to "baseline" it is not competitive at all. Enemies all lurk, doing only 30% of possible damage.This sounds odd. They should be competitive regardless of aggressiveness. I do a lot of playtesting and when I play 14 Soldiers with regular guns, a grenade and a smoke against a Large Scout with lowest tech Sectoids I get a close battle. The cases where higher aggressiveness made it harder were the ones where the Aliens spawned right outside of the Skyranger. For this case the spotter-logic works in the sense that they are willing to expend the TUs of one of theirs to spot people inside and shoot inside.
And I still cannot switch it to "baseline + modder-set", because ruleset numbers for VAI are not good (actually, very bad) for BAI.A min- and max-floating-point number for absolute aggressiveness in the rul-file would probably be the best solution when it comes to handing control to the modder. The idea of a variable multiplier was more for experimentally determining suitable values but not nice for the player who didn't know what to set it to. Alternatively there could also be fixed multiplier to the values from the rul-files that allows a much bigger range without the need to change the structure. For example with a multiplier of 0.1 and valid values from 1-100 or so there also would be a lot of variety. But this would of course lack the advantages of having a separate min- and max-value.
The suggestion was to make BAI consider ruleset aggressiveness as multiplicator, rather than surplus. So, 0.5 aggressiveness will make unit more cautious, while 4.0 will make it rush like devil. Then, I can run around the ruleset numbers and make tuned unit-aggressiveness submod for XCF.
It also can be very purposeful to look at current formula of the aggressiveness-related weights.
The advanced suggestion is to make BAI consider a range of aggressiveness as multiplicator.
For example, RUL file can contain diapason (like, aggressiveness: 1,0/1,8 - for min and max), from which BAI can randomly pick and assign aggro for each given unit on map. That can make some interesting results. Of course, this unit.RUL mod will be used for BAI solely, excluding VAI gameplay.
This also can be under additional +number in settings, no need to replace options for aggressiveness, that are already there.
So can you confirm that you have indeed tested with the same starting-save or very similar conditions when you found a reduction of damage to only 30% of "possible damage". Or how did you determine what amount of damage is possible?Yeah, I can. This previous savefile I attached is the mission that I tried multiple times with various aggro settings. The 7.13.1 where I set recommended 1/2 "baseline" + modder-set squashed my units in 10 turns, just because every enemy attacked simultaneously, minotaurs rushed with macro-flamers and axes (actually, I love how BAI prefers macro-flamers instead of melee option). Also, BAI thrown more grenades. I was lacking ifrepower and had to decide whether I should fire or reserve TU's for incoming enemies. None would help, because it's map with 50 enemies.
This caused units to think they should be spotters when becoming one wasn't a viable option, making them walk into reaction-fire without their allies being capable of providing significant assistance.Well, that mission was pain in the ass (I dealt it 4 times, lost badly 3 times and easily won on 4th). It usually spawns in mountains/open field, but now spawned in close urban area. That is why sniper-rifle loadout was wrong. I clearly don't wan't to play it again to check.
For example with a multiplier of 0.1 and valid values from 1-100 or so there also would be a lot of variety.Well, the 4 for max aggressiveness is arbitrary number to which everyone got used to. And it was introduced by you.
for experimentally determining suitable values but not nice for the player who didn't know what to set it toYep. I am going to make a submod, so players don't have to do anything.
Beside you you not have debugger that stop when crash happens? you should have function backtrack of crash site and see from whereWell, the last code inside of non-external libraries when the crash happened was inside of SavedBattleGame::~SavedBattleGame() at the call of "delete _pathfinding".
this code is called.
I noticed that other deconstructors, like Pathfinding, for example, also don't contain any code. I haven't kept up with how C++ changed over the years. My assumption is that manually deleting stuff inside of deconstructors isn't really necessary with modern compilers.
And since making a false claim is the best way to learn something on the internet because it will trigger someone to come out and correct me, I'll just claim that this is the case and therefore just deleting the contents of the destructor was the right way to fix the issue.
I've tested 8.0.2 32 and 64 bit today. No crashes and 64 bit is noticeable faster. Good shit.Unfortunately I was able to crash 8.0.2 and have a save from which it was reproducibly happening every time. And since my "fix" in 8.0.3 was deemed not viable by everyone who looked at it, I'm still trying to find a real solution that fixes the root-cause and not just treats the symptoms while creating arguably worse side-effects.
That is unfortunately a very wrong assumption.Yeah, I thought so. But I honestly don't know how to find and fix the cause of something that isn't a simple segmentation-fault.
It's not the right way to fix the issue.
Now you are leaking (a lot of) memory and eventually will spend the entire memory (and start crashing on out-of-memory).
Edit: According to ChatGPT since _nodes is a std::vector, deconstruction isn't necessary as vectors handle the deletion of their elements automatically.
std::vector<PathfindingNode> _nodes;
std::vector<PathfindingNode*> _nodes;
It's about what the elements are.Code: [Select]std::vector<PathfindingNode> _nodes;
will be cleaned up automatically (by the vector deconstructor)Code: [Select]std::vector<PathfindingNode*> _nodes;
would not be cleaned up automatically, you would need to first delete the content of all the pointers manually... and then just the pointers themselves would be cleaned up by the vector deconstructor.
https://stackoverflow.com/questions/12068950/c-destructors-with-vectors-pointers
Did you say this is reproducible? Please point me to the whole info (version, save, reproduction, etc.). I will try to pinpoint the problem if this is what you are looking for.You'll have to update to the last check-in of my repo, where I put back the contents of ~SavedBattleGame.
Is this error stack trace? Are you able to run it from VS in debugger?Just tried. Apparently I need to set some /bigobs-flag to even compile in debug-mode.
void SavedGame::setBattleGame(SavedBattleGame *battleGame)
{
delete _battleGame;
_battleGame = battleGame;
}
@XilmiThe _battleGame that is being deleted in SavedGame::setBattleGame looks like a valid object. It has members like _missionType = "STR_TERROR_MISSION", which is what the mission is. And the parameter when it's called from DebriefingState::init() is just a null-pointer. So it tries to delete the current valid _battleGame-object and then set the _battleGame-pointer to nullptr.
Problem could be call to `~SavedBattleGame` it self. If you double delete then you make hell break loose, as its our favorite UB and effect is unpredicted.
On some compilers work "fine" on other crash instalty. or random and after some time whole game get corrupted and break in unrelated place.
See code:Code: [Select]void SavedGame::setBattleGame(SavedBattleGame *battleGame)
{
delete _battleGame;
_battleGame = battleGame;
}
What if `_battleGame` and `battleGame` point same objects? or you call `setBattleGame(x); setBattleGame(x); setBattleGame(x)`?
You need check what exactly is pointed by `_battleGame`, is this valid object? or some garbage?
Overall this is one of OXC few faults, manual memory management. (mainly as it used C++98 standard), in OXCE we use C++17 that have lot of
tools that fix problem like this making ownership of pointer more explicit (like `std::unique_ptr`, use `std::optional` or dropping `*` and use `std::move`).
The _battleGame that is being deleted in SavedGame::setBattleGame looks like a valid object. It has members like _missionType = "STR_TERROR_MISSION", which is what the mission is. And the parameter when it's called from DebriefingState::init() is just a null-pointer. So it tries to delete the current valid _battleGame-object and then set the _battleGame-pointer to nullptr.And how this could affect anything? do `PandfindingNode` try delete `_prevNode`? No, it could even work without any destructor.
The issue really seems to be deleting the _nodes and _altNodes-vectors. (std::vector<PathfindingNode> _nodes, _altNodes;)
According to ChatGPT it could be problematic that the PathfindingNode-object has a pointer to another PandfindingNode via PathfindingNode* _prevNode;
"The PathfindingNode class seems to contain pointers (PathfindingNode* _prevNode) that reference other PathfindingNode instances, forming a linked structure. When you're using std::vector to manage a collection of PathfindingNode instances and they contain interconnections via pointers (_prevNode), deleting these nodes within a std::vector can potentially lead to issues.
If nodes are connected in a complex manner (such as forming a linked list or a graph), deleting them within a std::vector could break those connections and cause issues when pointers are no longer valid after deletion."
Good observations. I thought about the same.As far as I know that's OXC-code. OXCE-team isn't fond of manual memory-management but hasn't replaced it everywhere due to how enormous of a task that is.
Few questions.
Is this setBattleGame an OXC/OXCE code? Why BAI suddenly makes it break? Do you speculate there is a trouble waiting to happen and BAI just create a condition for it to popup?
I understand PathfindingNode is application class and not the library one. Didn't understand a reference on "PathfindingNode usually has a problem when deleting ... ". Is it some common knowledge?
Another thing I don't understand why storing linked list in vector may cause any trouble. Links are stored as pointers. Meaning destructor will just delete the pointer itself disregarding pointed object altogether. It should be completely irrelevant if pointed object is deleted by that time.As Yankes said: ChatGPT is a devious assistant. It can make up theories that sound kinda plausible, even if they are nonsense. Especially if you speculate yourself. It will pick up on your speculation and come up with a plausible-sounding explanation as for why something where you just asked: "Could it be that...?" is the case.
I suggest small change, set `_missionType = "F*** UP";` in destructor and put break point before that, and see if any break point stop, object do not have this value already there. You slimly do not rule out possibility of double delete of this object. If object is garbage it still hold data, whole point is normally you can leave trash behind if nobody can notice, and in case of string it can still hold value as `std::string` is allowed to have buffer inside itself for charters. Alterative it still point to old memory that had text. And in case of `std::vector` it could be this second case.I've worked with break-points and I'm pretty sure it's not a double-deletion because it happens after reaching the destructor for the first time.
int _tileLastSpottedForBlindShotByHostile, _tileLastSpottedForBlindShotByNeutral, _tileLastSpottedForBlindShotByPlayer = -1;
std::map<Position, int, PositionComparator> AIModule::getReachableBy(BattleUnit* unit, bool& ranOutOfTUs, bool forceRecalc, bool useMaxTUs)
{
Position startPosition = _save->getTileCoords(unit->getTileLastSpotted(_unit->getFaction()));
std::map<Position, int, PositionComparator> AIModule::getReachableBy(BattleUnit* unit, bool& ranOutOfTUs, bool forceRecalc, bool useMaxTUs)
{
std::map<Position, int, PositionComparator> tuAtPositionMapDefault;
if (unit->getTileLastSpotted(_unit->getFaction()) == -1)
return tuAtPositionMapDefault;
...
Position startPosition = _save->getTileCoords(unit->getTileLastSpotted(_unit->getFaction()));
Simply adding this check at the top of this function makes this not to crash anymore. I am not sure if it also screwed the AI computation but, I guess, you can figure the rest.Awesome! :) Thanks a lot for finding it!
Yeah, I can. This previous savefile I attached is the mission that I tried multiple times with various aggro settings. The 7.13.1 where I set recommended 1/2 "baseline" + modder-set squashed my units in 10 turns, just because every enemy attacked simultaneously, minotaurs rushed with macro-flamers and axes (actually, I love how BAI prefers macro-flamers instead of melee option). Also, BAI thrown more grenades. I was lacking ifrepower and had to decide whether I should fire or reserve TU's for incoming enemies. None would help, because it's map with 50 enemies.I actually sat down and played that map myself just now with 8.0.4. Took me a good hour. I lost while killing 27 enemies in 20 turns. But admitedly I played a bit poorly in regards to the proxy-grenades. I forgot my soldiers had them and repeatedly stepped into my own mines.
Well, that mission was pain in the ass (I dealt it 4 times, lost badly 3 times and easily won on 4th). It usually spawns in mountains/open field, but now spawned in close urban area. That is why sniper-rifle loadout was wrong. I clearly don't wan't to play it again to check.You mean you didn't replay the same mission but only a similar one? The one you won was the one in the urban area or not? It's not entirely clear to me.
But clearly not in case of battles vs x3 enemies (of same power), where rushing strategy for AI is better.A TFTD-player told me that for his play-style it is very helpful if the AI rushes. I think the main difference between the scenarios is weapon-range. In vanilla-TFTD all weapons have infinite range. When there's more units with short range, the entire team probably should play more aggressively.
The thing angered me was when BAI in two turns thrown 5 units through the same door, which had exit tile in reaction-sight of my snipers. That was enough to get that something goes wrong with decision making.Okay, this really sounds like it could be related to the bug fixed in 8.0.2:
Well, the 4 for max aggressiveness is arbitrary number to which everyone got used to. And it was introduced by you.In a way that "fluid"-aggressiveness-scaling seems like a bad approach when it comes to decisiveness. I put autoplay to maximum because anything else ruins the comparability of my benchmark-saves. But I see sometimes that this kind of approach works well enough. I have an idea for something that is kinda similar to maximum but that situationally considers cover when the unit made contact and it's readily available.
I think simpler is better. So, if you chose this over min-max range, no trouble.
If min-max in same battle, then bunch of attackers, bunch of lurkers and so on. Which will result in force split. Which, in its turn, will lead to lose of competitive power. In theory. I don't know what will happen during real gameplay, given all these advances in BAI decision making.
Yep. I am going to make a submod, so players don't have to do anything.My convictions are very volatile. Like I'm very quick to change my mind. I'd say at least in the current situtaion there isn't too much benefit for setting all values in a sub-mod, while I'm thinking about drastic-changes to the aggession-model.
I'll do it right ahead after getting the understanding of actual/final decision weights.
So that would be great to chat on them and/or look at formulas, if you share the lines where to look at and how to understand them.
But then, approach should be verified, at least not drastically changed every new version.
UPD don't take my whining about "AI is too easy" and "AI is too strong" as bipolar disorder.I think my reaction to "too strong" in the future will be: "Then mod it easier/lower the difficulty", whereas I will take to "too easy" very seariously and will want to look into the reasons for that and what to do about it.
I am looking for balance that kicks my ass, but yet is possible to beat:)
I think my reaction to "too strong" in the future will be: "Then mod it easier/lower the difficulty", whereas I will take to "too easy" very seariously and will want to look into the reasons for that and what to do about it.All right, I'm seeing that BAI is now starting to get perilously close to the 'auto-spot on hit' mechanics of vanilla scout-sniper via spotting on accidental hit and spotting firing locations not approximately, but with extreme precision. Which matters most on reaction fire, but even for usual combat it means that the already troubled camo/vision system is being sidelined in favour of straight-up firefights. While I don't dislike the concept, I very much do dislike the execution. How do I 'mod it easier'? Difficulty will do nothing for this issue, and I don't really want to just plain handicap every enemy weapon for beyond-LoS firing.
All right, I'm seeing that BAI is now starting to get perilously close to the 'auto-spot on hit' mechanics of vanilla scout-sniper via spotting on accidental hit and spotting firing locations not approximately, but with extreme precision. Which matters most on reaction fire, but even for usual combat it means that the already troubled camo/vision system is being sidelined in favour of straight-up firefights. While I don't dislike the concept, I very much do dislike the execution. How do I 'mod it easier'? Difficulty will do nothing for this issue, and I don't really want to just plain handicap every enemy weapon for beyond-LoS firing.Brutal AI has worked like this since quite some time.
This mission has tons of cover so I can very well imagine that the AI can do a good job with being aggressive on it. They also threw lots and lots of grenades. The high health-pools compared to the damage and the availability of medikits also helped me under consideration that the enemy played less aggressively.This mission is proposed to be done with higher tier armor, which was not available at the moment, because my overall on-globe progress is non-optimal (guess why :) ). If not urban location, the proxy grenades would have been very useful. I had it never occured in town.
Overall the level of challenge felt good considering me probably not playing very well.
You mean you didn't replay the same mission but only a similar one? The one you won was the one in the urban area or not? It's not entirely clear to me.I played exactly the same mission four times from backup.
A TFTD-player told me that for his play-style it is very helpful if the AI rushes.Overall, AI rush is very niche. It should be occurring if the conditions are positive:
I think my reaction to "too strong" in the future will be: "Then mod it easier/lower the difficulty", whereas I will take to "too easy" very seariously and will want to look into the reasons for that and what to do about it.I watched a year ago when there was a misunderstanding between you and the modders. If you remember what I mean. While the progress of BAI is great and all conditions for cooperation on megamods are in place, there is no clear movement yet. Perhaps rebalancing mods under BAI requires effort (mods have been created from several to ten years) comparable to months of debugging and gameplay-testing. And, in the end, it may be that only the community can rebalance it optimally.
The formula is pretty much this:
100 / (discoverThreat + walkToDist * myAggressiveness);
The AI considers a unit as a valid target to attack on the current turn when the unit was "seen" in the current turn. target->getTurnsSinceSeen(_unit->getFaction()) == 0
I think this would be justifiyable to have as an option. It's a bit of a grey area in terms of whether that can be considered cheating or not. The introduction of holding Alt to see where the AI units were spotted shooting from even without actually seeing the units leveled the playing-field when it comes to precision. But that could also be considered as: "Allowing the player to cheat too so the AI-cheat becomes more justifyable."
This was previously always the case but now can be turned off. Disabling it will help units with stealth- and vision-advantage to rely on reaction-fire-based-strategies without instantly triggering retaliation to their exact position.
The AI will still know where the shot came from but can no longer target that tile without visual confirmation.
You rush in decisions.Hu? How is adding a new option, which doesn't even change anything unless the player deliberately changes it a "decision" on my part? Juku asked what he could to modding wise against this kind of behavior. I realized that there wasn't much he could do and that it would be easy to add an option to change how that works.
The base option of counter-reaction fire was something very new to X-COM mechanics.I guess you mean for the case that the spotting from getting shot at is deliberately disabled by the player?
- will BAI prefer hiding&lurking instead of shooting
- what if it's impossible to get reach the positions alive? Will BAI have to run to discover, sacrificing units one by one in order to reveal enemy positions?
BS is cool thing, which also adds dynamics. Just imagine 10 guys simultaneously shooting through the area with rifles, like mexican mafia from B-class action movies.This is not a trivial task. It requires an underlying logic. Blind-shooting reveals your own position, likely wastes ammunition and TUs that could have been used to improve the own position and/or preserved for reaction-fire.
Okay, okay. You got me. I just really desire it for you to implement BS into the battles :D
Hu? How is adding a new option, which doesn't even change anything unless the player deliberately changes it a "decision" on my part?Oh, pardon me. I must be f****ng into my eyes whole time, thinking it is permanent change (given all psychological wounds you inflicted on players by denouncing AI nerfing system <- it was a half-serious joke).
If you attack tiles that don't contain enemies or objects, the shot will be aimed at the floor. So chances of hitting someone near that tile with stray-shots is reduced quite a bit because of thatRecently I was thinking of the ghost spawn mechanic. It's quite simple.
I want to mention enemies sometimes walk into their own grenades.I don't think that's unique to the AI... :P
BTW i recently walked on mine, which exploded. Amazing things happen
I don't think that's unique to the AI... :PWell, I don't want to think about all the times I walked on my own mines... But you expect better from the aliens that can travel through space, maybe. ;D
BTW i recently walked on mine, which exploded. Amazing things happenThat was about AI pre-priming mine and carrying it around as grenade for later. Surely, they don't know the difference.
I want to mention enemies sometimes walk into their own grenades. Someone throws and then someone else just walk up to it. I think it happens when I have an armored unity that they can't hurt so they decide to melee it ignoring the bomb on the ground.The score for going to a tile inside the blast-radius of a grenade in order to attack is halved. That means if they have an option to attack from outside the blast-radius they'll go into the blast radius only if they think their damage will be twice as high or better if they do so.
I'll add that when they walk into melee range of a tough unit, they might still fire their gun, which makes little sense.Please be a little more concrete about the details of the scenarios you describe. Who is "they"? A unit with or without melee-capabilities? Does the tough unit have that close-quarter-combat-ability that is used in some mods that can make shots fired in melee-range of them miss or not? Ideally a save-game where that happens would be great. There's just too many possible parameters to say whether it's silly or not. The idea behind going into melee-range with ranged-weapons usually is to maximize damage-output by minimizing the chance to miss.
And an other thing. Enemies don't seem to care if theirs are close my unit, they will still throw bombs. All this is when fighting hybrids.What do you mean with "hybrids"? I need very exact information, ideally save-games so that feedback like that can properly be taken into consideration.
The score for going to a tile inside the blast-radius of a grenade in order to attack is halved. That means if they have an option to attack from outside the blast-radius they'll go into the blast radius only if they think their damage will be twice as high or better if they do so.But that's the problem, they deal no damage. They don't even try to attack the rear where they actually might do damage, even if they have plenty of TU:s. Hm, do they also consider tanks as cover too?
This may or may not be foolish based on the exact situation. My thought-process was that on average it's best to try and maximize damage done to the player on the AI's turn instead of giving the initiative back to the player. So even if the melee-unit sacrifices itself in that maneuver, if they can kill or severely damage the player-unit, it is considered worth it.
Please be a little more concrete about the details of the scenarios you describe. Who is "they"? A unit with or without melee-capabilities?Well, I'm vague since it applies to so many units I'm not sure what to type. This is XCF so I guess most units have some sort of melee. This is so common I'm surprised it hasn't happened to you. Do you have a game that you play along with as you make the AI?
Does the tough unit have that close-quarter-combat-ability that is used in some mods that can make shots fired in melee-range of them miss or not?No, tanks does not. I have not seen them do this to units that has melee.
What do you mean with "hybrids"? I need very exact information, ideally save-games so that feedback like that can properly be taken into consideration.Hybrids, the race. The weakest aliens in XCF. I'm not sure how I can make a save since I don't know when this will happen.
But that's the problem, they deal no damage. They don't even try to attack the rear where they actually might do damage, even if they have plenty of TU:s.I checked their weapons. Wakizashi has 30 Power, so it does no damage to a tank from either direction as the tank has 60 armor. So not walking around it to attack from the rear makes no difference to damage but it makes difference to their own safety/exposure, so they rather not.
Hm, do they also consider tanks as cover too?No. Neither yours nor their own.
This is so common I'm surprised it hasn't happened to you. Do you have a game that you play along with as you make the AI?I usually play the base-game, as it seems to be the most logical thing to do. As I said, the modding-capabilities seem to be sheer endless and taking everything that can happen their into account is hard.
But here's a save where it did happen the previous turn. This time it's cults and not hybrids, but the behavior is the same.It didn't happen on the current turn though. Units that got into melee-range and had a melee-weapon did us the melee-weapon.
Notice the group around one of the tanks. The white dude has both melee and ranged, but he just walked up to the front and shot. The orange one is just ranged and he did the same. The black one is mostly melee and he just went up to the tank and took a few swings and threw some knifes. All from the front. They had plenty of TU:s to walk around before attacking.Again, plenty of TUs you say... but nothing about energy. Could it be that it happened exactly for the reason I mentioned earlier: A lot of the melee-attacks also costing energy? Could it be they were low on energy and thus only could use a limited amount of melee-swings, which cost energy, and then continued with ranged weapons that only cost TU but no energy?
Wakizashi has 30 Power, so it does no damage to a tank from either direction as the tank has 60 armor.You're right, but there's a lot more to it than just 60 >= 30*2. Swords have an armour penetration malus, and scale with user stats. That katana can do something like 160-180 damage at maximum, depending on which of the two ninja dudes is wielding it. But they also work against 40% higher armour. Melee is pretty bonkers in both XCF and Piratez.
The only ones that could deal damage are the ones with the Katanas, which has 50 damage and thus theoretically can harm the 60 armor-tank if they roll high enough.
And modders really don't seem to care about AI, as the base AI couldn't even use different weapons at all. Yet a lot of enemies have more than one. Makes me wonder why.Modders don't really have much access to AI, hence the disinterest. Multiple weapons on enemy units are mostly for immersion and/or looting, as far as I can tell.
It's kinda gruesome how much Mods meddle with the game-mechanics. Supporting all of these scenarios via AI is a gargantuan task. And modders really don't seem to care about AI, as the base AI couldn't even use different weapons at all. Yet a lot of enemies have more than one. Makes me wonder why.Maybe it's their passive way of asking: Look at this cool thing that is possible if someone feels like doing something. Wink, wink. ;D
Another aspect is that the units are afraid of reaction-fire. This is something that might deter them from walking around a unit, if it doesn't promise a lot more damage.Strange, because they very often start walking back and forth between 2 tiles just in front of the tank before attacking.
It didn't happen on the current turn though. Units that got into melee-range and had a melee-weapon did us the melee-weapon.That's unfortunate. Because it happened to me, after killing the 3 dudes some more came from the building. That's why it's hard to know when to make save backups, you don't know when you should and you can't really make a new save for each turn.
As I already told to Abyss: Ironman is horrible when it comes to being capable of providing save-games for feedback. It is possible to restrain oneself from save-scumming without ironman enabled. And by not having it enabled, it is still always possible to use autosaves for analysis.I didn't know that BAI was this new. I just grabbed some cool shit and through this together and after watching streams I knew I wanted a better AI, so I gave this no thought. Now I'm hundreds of hours in and I don't want to undo that. Besides, it lead to the crash bug being found. ;D
Again, plenty of TUs you say... but nothing about energy. Could it be that it happened exactly for the reason I mentioned earlier: A lot of the melee-attacks also costing energy? Could it be they were low on energy and thus only could use a limited amount of melee-swings, which cost energy, and then continued with ranged weapons that only cost TU but no energy?Nah, I never thought of energy since they sure had no problem throwing out lots of attacks. Besides, the orange guy had no business being in melee range having only ranged weapons.
Edit:Hey, don't get me wrong here. I'm happy for all progress with this.
Okay, I made respective modifications to the code. The AI now also considers energy-consuption when evaluating different attack-options. In the scenario at hand this leads to more shooting from the distance instead of running into melee-range only to then realize they don't have enough energy to perform the intended melee-attacks and then using ranged-attacks from up close instead.
Supporting all of these scenarios via AI is a gargantuan task. And modders really don't seem to care about AI, as the base AI couldn't even use different weapons at all. Yet a lot of enemies have more than one. Makes me wonder why.They can, ninjas wielding both katanas and throwing knifes performed both kinds of attacks in XCF way before BAI was presented. Although, I have no clue what exactly triggered one or another. Perhaps, just range to a target.
I've found a new crash. It has only happened on this mission so I'm not sure if it's XCF or BAI or a combination of the 2 that's the issue, but it happens often enough to post it. I can't replicate it, but it happens more and more frequent the further the mission goes on. So I'll just post the save and if you keep playing it should eventually crash during the enemy turn. For me it crashed when I finished the current turn but it's not guarantied, probably depending on your actions during the turn.Oof, this looks like another tough one.
[Inline Frame] OpenXcom.exe!OpenXcom::?A0xb83b7f39::getBlockDir(const OpenXcom::TileEngine::VisibilityBlockCache &) Line 273 C++
> [Inline Frame] OpenXcom.exe!OpenXcom::TileEngine::calculateLineTile::__l2::<lambda_1>::operator()(OpenXcom::Position) Line 4556 C++
OpenXcom.exe!OpenXcom::`anonymous namespace'::calculateLineHelper<`OpenXcom::TileEngine::calculateLineTile'::`2'::<lambda_1>,`OpenXcom::TileEngine::calculateLineTile'::`2'::<lambda_2>>(const OpenXcom::Position & origin, const OpenXcom::Position & target, OpenXcom::TileEngine::calculateLineTile::__l2::<lambda_1> posFunc, OpenXcom::TileEngine::calculateLineTile::__l2::<lambda_2> driftFunc) Line 117 C++
OpenXcom.exe!OpenXcom::TileEngine::calculateLineTile(OpenXcom::Position origin, OpenXcom::Position target, std::vector<OpenXcom::Position,std::allocator<OpenXcom::Position>> & trajectory) Line 4574 C++
OpenXcom.exe!OpenXcom::AIModule::hasTileSight(OpenXcom::Position from, OpenXcom::Position to) Line 6424 C++
OpenXcom.exe!OpenXcom::AIModule::tuCostToReachPosition(OpenXcom::Position pos, const std::vector<OpenXcom::PathfindingNode *,std::allocator<OpenXcom::PathfindingNode *>> nodeVector, OpenXcom::BattleUnit * actor, bool forceExactPosition, bool energyInsteadOfTU) Line 4376 C++
OpenXcom.exe!OpenXcom::AIModule::brutalThink(OpenXcom::BattleAction * action) Line 3117 C++
OpenXcom.exe!OpenXcom::AIModule::think(OpenXcom::BattleAction * action) Line 307 C++
OpenXcom.exe!OpenXcom::BattlescapeGame::handleAI(OpenXcom::BattleUnit * unit) Line 343 C++
OpenXcom.exe!OpenXcom::BattlescapeGame::think() Line 238 C++
OpenXcom.exe!OpenXcom::BattlescapeState::think() Line 865 C++
OpenXcom.exe!OpenXcom::Game::run() Line 336 C++
OpenXcom.exe!SDL_main(int argc, char * * argv) Line 127 C++
It then gets into this part of C++ I have difficulty understanding. With the Lambdas. For reasons I don't understand I can hover over some of the parameters to see their values but not all of them.I meet problems like this when compiler optimalize out variable I like to look on. some times `volatile` to keep compiler hands away from it.
There is a way to make stun aliens wait for the next turn (vanilla) once they wake up?Since player units also could act immediately when they woke up from stun, I thought it was only fair to allow the AI to do the same. It is one of the arbitrary limitations I removed from the AI.
They wake up and shoot or run immediately and capture them is extremely hard and annoying.
fac=*(_facilities.end());
This code never can be correct, `end()` is always invalid pointer and you can't deference it.
Are you running the release version? Or debug?I run it right from VS usually.
Items created by built-in weapon sets were placed in the wrong slots.Can you elaborate a little bit more what I'm seeing here?
Xilmi,
I found an alignment issues in the craft soldier equipment menu, see attached pictures. The issue does not present it self in OXCE, just BRUTAL
Again, thanks for an amazing fork of OXCE
Can you elaborate a little bit more what I'm seeing here?
Also, this alignment issues wasn't there when I was using BRUTAL v7.x (I can't remember which version I was using) maybe 7.12.2? I only saw this issue after upgrading directly to v8.2.0, I skipped the other versions in between.Yes, the alignment issue is a result of accepting a PR from Alpha Centauri Bear and was reported before here:
So apparently mods have additional ways to assign equipment to enemy units that are different from the way it works normally
Or are there also ways that this could negatively impact player-units as well?
No, mods just use the standard OXC logic here.If this is the case I guess I have to debug the concrete example.
Or are there also ways that this could negatively impact player-units as well?
If this is the case I guess I have to debug the concrete example.
Items that have a default-slot or a slot-order by item-category will now use the corresponding logic for how they are equipped, even if smart-equip is enabled.
if (Options::oxceSmartCtrlEquip)
if (!placed && Options::oxceSmartCtrlEquip)
[2024-02-16_09-17-17] [INFO] STR_MEDI_KIT placed to STR_BELT due to fallback
[2024-02-16_09-17-17] [INFO] STR_MOTION_SCANNER placed to STR_BELT due to fallback
[2024-02-16_09-17-17] [INFO] STR_HIGH_EXPLOSIVE placed to STR_BELT due to fallback
[2024-02-16_09-17-17] [INFO] STR_GRENADE placed to STR_BELT due to fallback
[2024-02-16_09-17-17] [INFO] STR_PROXIMITY_GRENADE placed to STR_RIGHT_LEG due to fallback
[2024-02-16_09-17-17] [INFO] STR_SMOKE_GRENADE placed to STR_RIGHT_LEG due to fallback
[2024-02-16_09-17-17] [INFO] STR_PSI_AMP placed to STR_BACK_PACK due to fallback
[2024-02-16_09-17-17] [INFO] STR_ALIEN_GRENADE placed to STR_LEFT_LEG due to fallback
[2024-02-16_09-17-17] [INFO] STR_MIND_PROBE placed to STR_BACK_PACK due to fallback
[2024-02-16_09-17-17] [INFO] STR_PLASMA_PISTOL_CLIP placed to STR_BELT due to fallback
[2024-02-16_09-17-17] [INFO] STR_MIND_PROBE placed to STR_BACK_PACK due to fallback
...Thanks for the hints. I thought I removed the debug-messages.
The AI is too passive in 8.x.x version for Xpiratez mod.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?
The game design in Xpiratez is such that the battles should be quite active.
The player's units lose morale every turn if they don't kill enemies. Also, their Freshness decreases every turn.
Another problem is that there are mortars in Xpiratez. In some missions, you can blow up houses from afar without taking any risks at all.This is indeed a more valid issue. The AI should already press the attack when there is no cover anymore. But when they die inside the house when you blow it up, this of course won't help.
Now, if I put my squad under AI control, then both sides will not clash in battle at all (1.png).Press the "c" button. This brings up the auto-combat-customization. You can right-click on the soldiers there and change their aggression to "3", which is the mode where they are forced to push ahead.
Is it possible to return scale of aggressiveness from power-balance as an option in the settings?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. They also have a lower score to stay in places where they have free vision to their fallen allies.
Or make a new option in the settings, so that in the absence of violence, the AI would start acting more aggressively after a few turns?
Or make AI more aggressive in general, as an option?
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.
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.
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?
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.
I'm just storming through houses 1, 2, and 3. Meanwhile, all the other enemies are sitting in their homes and not fighting.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.
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.
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).Was this with 8.3.0?
Is it reproducible? If so, I should be able to reproduce it too quite easily.
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.
...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.
Debug deliberately crash on code like this, in Release all checks are removed (as cost a lot) and code can access invalid memory.
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;".
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;
}
(
[&]
{
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
}
}
}
}
)();
For nested loops there is another trick (aside of `goto`) to exit them, `return` and lambda functions:
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.
I'm currently playing XCOM Files with Brutal AI and I'm having a blast. I can see the opposition making very cool moves like peeking out, shooting a few rounds then going back to cover. Great stuff.Thanks for the feedback!
However, in most of the mission there is always one little fucker, often with only a melee weapon or a monster, that go into a corner and just wait here until I find him. I tried to activate Omniscience for th AI, in the hope that if this last guy knew were my troops were he would go toward them but no he just stay in his corner.
I guess this make sense tactically for him, if all my friends just got killed by some SWAT team and I just had an axe I would also hid behind my bed but it is becoming very tiresome. I basically had to alway kill this last guy with the command console or I lose too much time. But I dont like that.
Did I fuck up somewhere in installing or setting up the mod ? Is this a normal move for the AI ? Are there any solutions ?
Thanks !
Thanks for the feedback!
Let me describe how exactly the AI works and explain why this causes some units to behave in a non-immerserive manner.
Yes. That's exactly what "Aggression-Mode for Brutal-AI" setting "1" is there for. It uses the units aggression as per the *.rul file to determine which behavior to apply.
Aggression 3 and above skips all of the other steps between attacking and walking towards the supposed position of the enemy. If they can attack, they will. If not, they will close in.
Regarding killing the last alien. I think someone introduced surrender option making AI surrender when they are overwhelmed. I think this should solve the long ending problem without tweaking AI algorithms.
I think that might be the problem. When I look into the .rul files for certain Zombies units, some have LeeroyJenkins and some don't, some have agression 9 and some 2...Unless you're playing a modified XCF, that's not a problem. The zombies with aggression: 2 are Chryssalid spawns and not present on normal missions. All the other 'regular' zombies are leeroys, the only exception are the intact Zombie Troopers - who have weapons. Ghouls and other 'evolved' forms are not leeroys, but they're also armed or otherwise dangerous without charging.
I think I have this option checked, and It works sometimes but not always. Must depends on ennemy moral.It's not an option you can check, it's a whole algorithm finetuned in the rulesets. XCF comes with it out of the box, but some parameters might need tweaking if the current implementation is not to your liking. The biggest roadblock to not getting surrenders is the presence of non-surrendering units: robots, higher ranks, etc.
Unless you're playing a modified XCF, that's not a problem. The zombies with aggression: 2 are Chryssalid spawns and not present on normal missions. All the other 'regular' zombies are leeroys, the only exception are the intact Zombie Troopers - who have weapons. Ghouls and other 'evolved' forms are not leeroys, but they're also armed or otherwise dangerous without charging.
It's not an option you can check, it's a whole algorithm finetuned in the rulesets. XCF comes with it out of the box, but some parameters might need tweaking if the current implementation is not to your liking. The biggest roadblock to not getting surrenders is the presence of non-surrendering units: robots, higher ranks, etc.
There is also bug-hunt mode, which is also in XCF by default. Usually the mission is long over before it kicks in, though.
I also would love to not receive a grenade under my agent feets from the other side of the map but alas that has nothing to do with your great mod.
Is there a problem with v8.32 as it won't start-see attached.It works for me. Have you tried a clean reinstall? Did it work with a prior version?
Is there a problem with v8.32 as it won't start-see attached.
It works for me. Have you tried a clean reinstall? Did it work with a prior version?
I've seen someone who tried to stream it run into similar issues. If you use a steam-installation of UFO, make sure to only copy the contents of the sub-folder "XCOM" into the "UFO" folder as opposed to the contents of "XCom UFO Defense".
Not sure it's the same issue. But that was the issue the streamer had.
4.) Verify with the latest version BAI v8.3.2 that you are only using it's file structure and NOT OXCE+ file structure...
-- OXCE+ has all it's share common data files combined into a single binary, BAI does not and places them in the directory as individual files.
OXCE+ does not exist since year 2018, please stop using that name and stop confusing everybody.
OXCE always had and still has the same file structure as OXC (and as BAI), both the installer and the zip archive contain common files in a directory as individual files.
(usage of common.zip is not default and completely optional)
Is there any way to take this mod as a base, but disable all the main mod features?Yes, all features can be separately disabled. You can disable the brutal AI and enable auto-combat if you want.
I'll definitely try out the new ai, but for now I only want automated combat
What does CTRL button do when aiming at units? It shows some percentage value different from chance to hit, is it cover or something?Yeah, it's exposure-percentage of the unit. This is basically multiplied with the normal hit-chance at that distance if realistic-accuracy is enabled.
Edit: found my answer in https://openxcom.org/forum/index.php?topic=11928.0 TL;DR yes it is. ;D
"Aggressiveness-mode" => This replaces the old "Inherit aggression"-toggle and has a total of three options for now:
0> Baseline Aggressivness. 1> Multiplied with unit-aggression. 2> Multiplied with unit-aggression and take Leeroy-flag into account.
0> Seek out best cover possible. 1> Use unit-aggression. 2> Breaking line of sight is good enough. 3> Don't care about cover.
"Intelligence-mode"
0> Static intelligence.
1> Inherit intelligence from unit-intelligence
2> Inherit intelligence from difficulty-level.
Realism: impossible to tell without knowing what you consider 'realistic'
Purely technical complexity: 2-1-1.
what means 2-1-1?
2> Multiplied with unit-aggression and take Leeroy-flag into account.
1> Use unit-aggression.
1> Inherit intelligence from unit-intelligence
maphack by aliens - is not a realism (Targeting behaviour 4 + Bug hunt)The aliens can mind scan you. Realism! ;D
leeroy too, maybe
how to configure these two options to get maximum complexity and realism?The options you cited are outdated.
are these options the most brutal?No.
bug hunt Modemaphack = cheat
Targeting behavior 4
That's why it's disabled by default.it seems default BAI settings are most brutal
"Brutal AI avoids proximity-grenades" is working not perfectly, it is very easy to use these grenades, almost always you will catch some sectoid (even if there is a workaround) (and even if he was alone, he was not a suicide scout for attack by other teammates)Is this with tweaked intelligence and/or aggression?
although to be honest, I had never used these grenades before and only started using them to defeat Brutal AI, because it is very difficult to win by other ways (Of course it’s possible, but with these grenades it’s much easier)
in other aspects - the quality of AI is at a very high level, x3 harder than original AI
if you throw a proximity grenade near the door of a houseWait, you said "house", not UFO. I think I know what likely happens.
I play xcomfiles on the brutal. I am disappointed that zombies and other animals, which usually behave ultra aggressively, run away and hide like girls behind a corner. I drove four zombies with 4 agents in 40 turns. Is this normal, or should I change something in the settings?Putting the Aggressivness-mode to 1 might help in this case.
it seems that rockets blown up at Avenger ramp always and never fly into Avenger itselfThanks for the report I'm gonna have a look at this.
so alien ramp-rocket is a bug
Sectoids are a bad species to test this because they MC meyup
Are you maybe using realistic accuracy
realistic accuracy + explosion height 2 + mod Psi LoFI first tried just the saves but without your options.cfg.
superhuman + max tech + sectoids + battleship + skyranger / avenger
attached (https://openxcom.org/forum/index.php?action=dlattach;topic=11663.0;attach=63419) below: avenger save file + skyranger save file + options for 8.5.2 - to reproduce just click "end turn" (and copy options and load) - you will see 3-4 rockets into ramp and humans will alive
(and need to translate options string - STR_BATTLEALTGRENADES)
So my suspicion was that you have enabled "OpenXCom: Unlimited Waypoints". And indeed, you have. So I'm pretty sure it's related to that one.
name: "OpenXCom: Unlimited Waypoints"
version: 1.0
description: "Allows unlimited waypoints, Aliens will be limited by difficulty."
author: the OpenXcom team
Fix is available in 8.5.3.
Oh, and I recommend maybe not using the "Unlimted Waypoints"-Mod if you don't want to be spawn-killed by aliens with Blasters.
ahI agree. The description for that mod is absolutely terrible and I only know what it does because I first read the reference to it in the source-code.
is it an unlimited number of firing points for a blaster launcher (9 or 999), but not alien soldiers starting spawn points on the map?
Putting the Aggressivness-mode to 1 might help in this case.
not sure - bug it or feature - but alien missile always fly into craft, even if target is far away from itThat's extremely bizarre and I'm actually quite baffled.
here is the save (https://openxcom.org/forum/index.php?action=dlattach;topic=11663.0;attach=63432) with start of human turn
shoot from the tank in any direction and press "end turn"
alien rocket will fly into craft, will out, and will fly to the tank
1. Can you make BAI understand non-whole numbers of aggressiveness?I had that in the past with the fractions. But I got rid of it. Right now there's only 3 levels left so that they can actually be distinct.
2. Can you reserve special number (or letter: X = extra) for Zombie-like no-matter-what-wanna-kill-what-I-see units? For example, it may be 666 (or 69). If aggressiveness: X then unit always behaves as a killing machine.Everything 3 and above as well as enabling leeroy-flag will do that already.
3. Can you reserve special number for these units who are supposed to stay inside the ship, where they had spawned? But with that in mind: if this unit spawns outside, it acts alongside others. This particular mechanic can be achieved via special mark past the number.I really don't think it is reasonable to make changes like this.
Edit: all these suggestions are for new UNITS.RUL file, use unit-aggression. Then there is a chance for game to be balanced around units behavior.There's so many options to tweak brutal-AI already. Including not using it at all. I can't chase every vague idea someone comes up with and hasn't really thought through without previously having tried to use the existing options.
And please, remember: game is for a player, not for a computer. There must be fun to play mods, not constant pain in the ass (80% maps = enemy spawn 250% stronger than players, repeat 500 missions).
Hi Xilmi. There is such a suggestion: add reaction shots when opening doors (maybe as a switchable option).I don't really want to change the game-mechanics and get rid of the "mutual-surprise"-rule, which is what suppresses reaction-fire when two units see each other at the same time in cases such as someone opening a door. This would make reaction-fire a lot stronger and lead to a different and likely rather stale camping-meta.
The fact is that enemies, especially with aggression 0, really like to ambush behind doors and it would work if the fire trigger worked. It looks something like in screenshot 1
Of course, they will be killed due to the lack of a rocket shot, since the right to the first shot is always with the one who opened the door.
Knowing this, I will just ambush a little to the side of the door and thereby kill the enemy anyway.Screenshot 2
That is, the absence of a fire trigger when opening doors almost always works in the player's favor.
0 is where the enemies prioritize survival by looking for good spots that are difficult to reachWell, number 0.3 may refer that unit takes 70% of actions as hider, whereas 30% actions as slow-progresser over the map. That could make sense in terms of diversity and unpredictability.
1 and 2 is the progression-mode. The enemies will be somewhat careful but afterall their goal is to sweep the map, search for enemy units and kill them
3 and above is the aggressive mode. The enemies will just try to end it quickly by rushing forward without any regards of safety.
Well, number 0.3 may refer that unit takes 70% of actions as hider, whereas 30% actions as slow-progresser over the map. That could make sense in terms of diversity and unpredictability.That's a decent idea and wouldn't require any weird in-between-behaviors. Unfortunately all the unit-aggression-values are read as integers, so only full numbers are allowed. I don't know how much of an effort it would be to convert them to floats and whether this would break compatibility. In rul-files that use floats, i usually see them written as 1.0 and such. But maybe a float-reading-function can also deal with integers.
BTW please remind me if this is still working: the more AI believes it wins, the more aggressive becomes?I don't think that ever went live. I've only experimented around with stuff like that but the results were quite disappointing. Especialls since I analyzed scenarios where the player thought the enemies had an advantage when they actually didn't. (There were a lot of enemies but they all were way weaker than the player-units)
Does it know amount of player units at the beginning of the match?
Does it count overall armor and shooting capabilities of it's own units while making sturm-solutions?
I guess I can give it a try.Thanks, I think it has potential, too. Also, it can be written in more AIsh manner, like
(and need to translate options string - STR_BATTLEALTGRENADES)Is it fixed now?
v1 - just shoot by yourself at the ramp from your aircraft on the first turnYeah. That's the issue with how I implemented blind-shooting and why it only exists for the blaster in the first place.
v2 - shoot from the ramp to any direction and step back and press end turn and wait alien missile
do these hotkeys not work on the equipment screen?I actually have no idea. I never tried this. If you say they don't work there, then that's probably true.
crit error - cydonia part 2, alien movementI'm looking into it.
BOXCE 8.6.0I have fixed the crash in the meantime and thought this might be somehow related. But it isn't fixed by the one that fixed the crash. I still think it might be somehow related. What possibly happens is that the celatid supposedly reaction-fires but it doesn't work because of too low ceiling or something but it still interrupts the movement.
bug - cydonia part 2, turtle moving under Celatid vision
to reproduce:
1 download save + options (https://openxcom.org/forum/index.php?action=dlattach;topic=11663.0;attach=63769)
2 move your unit like in image below, it will move 1 tile per click (and stops moving) just because Celatid sees him
I tested this with regular OXCE and it also has the same bug.
This issue goes deeper. Even if I control the Celatid myself I don't get any error-message if I try to shoot but the shot doesn't actually fire. So whatever is done to check whether a shot should be working seems to succeed but the actual shot doesn't.Is this present in regular OXCE too?
Is this present in regular OXCE too?Yes. It doesn't use the game-logic from Createprojectile to check whether the shot will be fired but some weird Mod-script or something that apparently says it's okay without doing actual checking.
Maybe try to talk Meridian into implementing your fix… but it’s most probably OXC related, and getting pull request approved there… it’s kinda impossibleMy fix is actually more of a workaround and can't really be ported back as I'm using one of my AI's routines to do that. An AI-routine that I've written because the engine seemed to lack a function that had the required functionality anywhere else and it was the AI where I first felt the need for such function. It is based on the logic from int Projectile::calculateThrow(double accuracy).
Technically SupSuper should fix it as you probably could recreate in in base OXC :)I maybe should do that. And if it's just to hear why he doesn't bother doing it. :o
I maybe should do that. And if it's just to hear why he doesn't bother doing it. :oAs long it do not catastrophically problem (like recent server move) he do not have time to fix bugs.
But are you a genetically engineered alien war-creature? :PIncluding all earthlings from all mods on xcom. When all units immediately engage after a knockout, this raises many more questions than if they had recovered from 0 tu.
Hey, Xilmi!In 9.1.0 there's a way for the AI to bump up it's current aggressiveness-level.
The latest release seems quite promising, but what do you think, is it still a viable idea to make BAI understand non-whole numbers to switch between two types of aggressiveness models? I mean, sometimes it is not just "camper" and "ambusher" roles that make pain-in-the ass. It's more about what you cannot expect from this particular unit. If "zealot" goes suddenly goes into "ambusher" state, it can make ppl thrill. As in the vanilla UFO game. Mysterious and new back in 1994-1997's.
Weighted randomization (using the default value more often than other values) and based on the game-state. Morale seems like the most logical value to use.Weighted randomization surplus which depends on morale is good, but also reverse scenarios are acceptable: when units that are supposed to be zealots, start to hide for a random amount of turns and then became zealots once again, coming out of shitholes and dark places of any kind.
Weighted randomization surplus which depends on morale is good, but also reverse scenarios are acceptable: when units that are supposed to be zealots, start to hide for a random amount of turns and then became zealots once again, coming out of shitholes and dark places of any kind.The aggressiveness-levels written in the rul-files of the base-game are all 0-2. This is kinda in line with the suitable levels for BAI. If modders, for some reason, massively exceed what was common in the base game, then this is something I can't really take into account. It is supported but might lead to undesirable results.
Well, based on my perception of BAI's previous versions, it usually makes it hard to proceed without casualities within player's troops, setting up ambushes quite good, but rarely relying on reserved TU's for reaction shots. From player's perspective, this lowers the most consistent part of the joy (a gambling within a game), making it rather a straight-forward chess game, than a a sort of rogue-like role playing game.
I can't comment current BAI, as still want the thing to happen: be it possible to rewrite all RUL aggro settings manually. Now it comes much closer to that.
Remember, that aggressiveness level written in OXCE RUL file has nothing in common to be compared with BAI aggressiveness.
So. There is HARDLY an option to "choosing option 4 means aggressiveness is inherited from unit-aggression" at the current state of BAI-mod (XPZ/XCF) compliance, because units then will behave unnaturally, and most likely push themselves to death, even weakest ones that should otherwise passively run around in vanilla. And, btw, they run around so to make mission more mild/narrow in terms of shooting density (such balanced, that's it). So player don't have to deal with all 50-100 troops simultaneously turn 2.
And one more thing. There's invisible units on player's side too. By invisible I mean really invisible, not CAMO. Last playthrough I had one catgirl making beef out of whole BAI cruiser because they couldn't do anything regarding it. Invis = 5, range = 20.
Of course, I cancelled reaction shots my turn. But vanilla has sniper-spotter. What can BAI make in this case?
I did provide some options to nerf the AI to get some kind of in-between-state between the base-AI and the fully brutal experience. It's on the player to figure out what options they like.It's intelligence, right?
So for example if the calculated score for a tile is 100.Thanks. With this in mind, I think it will be a mess with model that switches between aggressiveness levels, too.
0 Intelligence means the score is now RND(0-100).
1 Intelligence means the score is now 20+RND(0-80)
2 Intelligence means the score is now 40+RND(0-60)
3 Intelligence means the score is now 60+RND(0-40)
4 Intelligence means the score is now 80+RND(0-20)
5 Intelligence means the score remains 100
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.
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.
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.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.
[FATAL] Error loading file '.../common/SoldierName/Polynesia.nam'
Your merge doesn't seem to work.Your screenshots seem to be from before I fixed it myself in a slightly different way.
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.
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.
Wait what? i thought the "2" was the amount of bytes and the actual contents (turns) was inside of the "binTiles:"-line.
1. New saves created with 9.2.3:
Loading is fine. Gameplay is fine.
2. Saves from 9.2.2:
Loads very slow and AI/Autoplay-turns are slow for some reason.
3. Saves from <9.2.1 but >2.0.0 or whenever I introduced the turnLastExplored:
Loads quickly BUT AI/Autoplay-turns are slow for some reason.
4. Very old saves from when I just started and before turnLastExplored:
Loads very slow and AI/Autoplay-turns are slow for some reason.
I changed it now as you suggested.
9.2.3 will be compatible with everything except 9.2.2 and very old saves or saves made with regular OXCE.
Before the saves made with OXCE still did work though.
9.2.3 will be compatible with everything except 9.2.2 and very old saves or saves made with regular OXCE.
Before the saves made with OXCE still did work though.
[2025-01-27_20-57-31] [WARN] unserializeInt has invalid sizeKey of 2 .. this can mean deserialization data is ill-formed
[2025-01-27_20-57-31] [WARN] unserializeInt has invalid sizeKey of 2 .. this can mean deserialization data is ill-formed
[2025-01-27_20-57-31] [WARN] unserializeInt has invalid sizeKey of 2 .. this can mean deserialization data is ill-formed
Log(LOG_WARNING) << "unserializeInt has invalid sizeKey of " << sizeKey
and `sizeKey` is `char`, this mean it output character not int. '2' is 50. And this is not any of 3 available sizes of tile (1byte, 2byte and 4byte).case 1: ... //current code
case 2: ...
case 4: ...
case '1': ... //hack for wrong version
case '2': ...
case '4': ...
can you check if we can somehow help with this issue?
TL'DR: OXC/OXCE battlescape saves don't load in BOXCE
I cloned Xilmi's repository, built it, ran it. Loaded why_so_unbearable.sav, saved it to why_so_unbearable2.sav. Loaded why_so_unbearable2.sav. No crash.
[2025-01-28_00-31-10] [WARN] unserializeInt has invalid sizeKey of NUL .. this can mean deserialization data is ill-formed
[2025-01-28_00-31-10] [WARN] unserializeInt has invalid sizeKey of NUL .. this can mean deserialization data is ill-formed
[2025-01-28_00-31-10] [WARN] unserializeInt has invalid sizeKey of NUL .. this can mean deserialization data is ill-formed
NUL is \x00. So you seeing 2 is probably a result of some sort of UB. The actual value of that variable is 0._lastExploredByHostile = unserializeInt(&buffer, serKey._lastExploredByHostile);
_lastExploredByNeutral = unserializeInt(&buffer, serKey._lastExploredByNeutral);
_lastExploredByPlayer = unserializeInt(&buffer, serKey._lastExploredByPlayer);
if (serKey._lastExploredByHostile != 0)
_lastExploredByHostile = unserializeInt(&buffer, serKey._lastExploredByHostile);
if (serKey._lastExploredByNeutral != 0)
_lastExploredByNeutral = unserializeInt(&buffer, serKey._lastExploredByNeutral);
if (serKey._lastExploredByPlayer != 0)
_lastExploredByPlayer = unserializeInt(&buffer, serKey._lastExploredByPlayer);
NUL is \x00. So you seeing 2 is probably a result of some sort of UB. The actual value of that variable is 0.
binTiles: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
binExtended:
OXCE_X1: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
OXCE_X2: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
OXCE_X3_V2: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
BOXCE_N2: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
FTA_Z: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
At least now compatibility problems will be reduced to having unique names in all forks.I think if better would be split binary data in separate buffers that are loaded by name:
aaaa, this is new property that is not in OXCE, this mean my previous comment is not accurate. This mean OXCE save should not have it.Yes, the purpose of these is simply for the AI to remember at what turn it has scouted each tile on the map. This is used in AI-code for determining where to search for enemy-units.
But this save was generated by OXCE? Should this save be from BOXCE?
I was seeing 2 (character '2', not number 2), because I was loading the broken BOXCE 9.2.2 save, not an OXCE save. Sorry for the confusion.Thanks!
Anyway your fix makes sense and works, @Xilmi: see attached.
With this fix, I can load any OXC/OXCE/BOXCE save... except for the broken/incompatible BOXCE 9.2.2 saves.
Suggest adding two lines to common\Language\OCXE\ru.yml:Added in my repo but won't make a new build for this.
STR_NO_CRAFT_FILTER: "В транспорте"
STR_NOT_ASSIGNED: "Не назначен"
I don't think you need to include yaml-cpp.dll in the releases anymore.Can I remove both yaml-cpp and yaml-cppd or do I need to keep the latter?
I think my AI-mod is now complete enough for me to consider it releaseable.
It's both, a fork of OXCE and a data mod for the latter. The first one is more important, though.Thank you Juku121 :)
I think my AI-mod is now complete enough for me to consider it releaseable.
The mod should be included in the installer. Not sure if it defaults to 'on' or 'off'.
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
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.
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.
Considering I'm more or less in maintenance-mode...
I'm seeing 6 files with merge-conflict if I have a look at what merging the test-branch would lead to.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
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.
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.
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 just want to say : I could get a lot of people I know IRL (we talk via social media now) about brutal ai being added to openxcom. Im the only one of us that has been willing to try OXCE (loving it). But the work Xims done is amazing. And it would be a masterstroke both teams can make this happen.I'm not quite sure I understand that correctly.
I think theres a lot of people who are reluctant to go to oxce but would flip that switch to YES and never go back. These aliens are BRUTAL
Im wishing you all the best of luck.
There are some people who won't even try OXCE because they feel like "too much is changed from original".I bump into bugs and even crashes every time I run OXC. It’s just grandpa project for more recent forks.
I know, because I was one. I used openxcom for like a decade? I tried for like a day to figure out how to get brutal AI to work without having to use OXCE but finally gave in. In an hour of playing Extended I knew I could never go back.
I believe the tagline of OXCE is once you try it, youll never go back.
I bump into bugs and even crashes every time I run OXC. It’s just grandpa project for more recent forks.Debug mode crash is not "valid" crash :> (probably I personalty fix that teleport with 2x2 units in OXCE because I needed to test somethings).
Just in case - I get crashes in OXC when using debug mode and teleporting my units all over the map. I guess it’s legit. My use case isn’t the same as for regular players.
Debug mode crash is not "valid" crash :> (probably I personalty fix that teleport with 2x2 units in OXCE because I needed to test somethings).I got the same bug in both OXC and OXCE, where you could shoot with aimed to one target, with high >80% accuracy dozens of times without a single hit.
All crash should be fixed and where fixed in OXC, many cases it was backport from OXCE fix.
If fix is small then PR with it will be merged to OXC sooner or later (depending how much affect players).
I got the same bug in both OXC and OXCE, where you could shoot with aimed to one target, with high >80% accuracy dozens of times without a single hit.This could be simply RNG fault, accuracy do not mean how often you will hit target but how spread its trajectories as you should know. Add some RNG basis, some distance and you could have cases when spots you can't hit targets in many hits.
As I was tinkering with accuracy code for long enough, I made a small “mod” where shot from laser pistol or rifle takes 1 TU, so I could easily confirm something is wrong, just by shooting many times without changing anything else.
I ain’t 100% sure I fixed that in my version of code, most probably I did. But I can’t make myself put any effort to debug that again, knowing that my another PR is out there for two years already, where I fixed a bunch of issues with visibility, making OXC behave closer to OG, particularly for cases when in OG one unit could see another, and in OXC, in the very same conditions - he is not.I mean crashes not glitches. If you test long enough you will find many corner cases in engine (some could even be my fault :D). Probably your PR get ignored as it need same amount of work on our side to analyze as you did to create it.
This could be simply RNG faultImagine 20 shots in a row with 85% going through exact same voxel.