OpenXcom Forum
Modding => Released Mods => Brutal AI => Topic started by: Xilmi on December 17, 2023, 01:08:15 pm
-
I think my AI-mod is now complete enough for me to consider it releaseable.
The current version can always be found here: https://github.com/Xilmi/OpenXcom/releases
This mod is forked from OXCE and provides a few new options both for modders as well as for players themselves.
All the while being compatible with every mod that is also compatible with OXCE.
Installation-guide:
https://www.youtube.com/watch?v=fV4VGWHe5zg
As the name suggests, the new options are primarily centered around AI and in particular about making the AI more difficult to beat.
There's one non-optional-change to how manufacturing works:
An item in the workshop-queue will only use workshop-space when either at least one engineer is assigned to it or production has already been started. This allows you to queue a lot of items to produce one after the other without granting any advantage to parallel production.
Here's a list of all the new options and what they do:
Geoscape:
"Aggressive retaliation" => This option existed before but was slightly modified. In addition to it's previous functionality of allowing all UFOs to potentially discover a base, it changes the behaviour of UFOs on a retaliation mission in a way that instead of searching the base near pre-programmed areas in a big area around the actual position of the base. This fixes an issue that allowed for better or worse to almost completely avoid base-defense-missions when putting bases in certain locations that weren't anywhere near the search-areas of the corresponding region. The radius of the area being searched is approximately 2670 km.
"Enhanced dogfight behaviour" => When enabled, as soon as you start shooting the UFO, you can only use max-distance or retreat when your craft is actually faster than the UFO. Otherwise the UFO will try to keep you within it weapon-range. The main impact this has, is that you can no longer kill every UFO as soon as you unlock the plasma-craft-gun or other weapons that outrange-the UFO with standard interceptors. You either need to bring several to deal enough damage until it gets in range of their own weapons or need faster craft.
"Hidden alien activity notification" => Shows sectors with 5+ hours of continuous undetected UFO activity.
Battlescape:
"Realistic accuracy and cover system" => Feature developed by Joy Narical and merged into Brutal-OXCE. Find the full documentation here: https://github.com/narical/openxcom-accuracy
"One-click grenade priming" => When enabled has the following effect: "You can no longer select the amount of turns after which grenades shall explode. The timer will just be set to 0 without having to pick a value."
AI:
"Brutal-AI" => This is the name-giving core-feature of this Mod. It includes an almost complete rework of how the AI determines what to do. All enemies can see and attack what anyone on their team sees. Not only that, they can even change the order in which they operate, so that for example a spotter will wait for other aliens to act first before it decides to continue looking for enemies or to hide again. It will generally try to maximize damage-output when attacking and is very capable with using grenades. A lot of bugs in the basic AI are fixed with enabled brutal-AI. (For example arcing-shot-prediction-bug) Those bugs were deliberately not fixed in the base-AI to keep it behaving exactly as it is. An exception are bugs in the "pick up items"-code, as that's also optional for base-AI.
"Brutal AI for neutral forces" => If a map features a third faction, you can let them be controlled by Brutal-AI too. If it's civilians all that'll do is make them hide a little better. If it's Space-Marines they now may actually prove worthy allies.
"Allow AI to use explosives on turn one" => Ignores all turn-delays for items that may be set in mods. By default only blaster-launcher and grenades are concerned. But it would also overrule other turn-limits.
"Bug hunt mode for Brutal AI" => Since the basic-AI also is cheating, Brutal-AI does so as well by default. This option allows to disable AI-cheating and makes a massive difference in perceived difficulty. When enabled the AI knows where all of your units are all of the time. But it only uses this knowledge for movement-purposes. It will not shoot at your units without first revealing them. It will, however, take this information into account when deciding where to move. Disabling this means the AI has no clue where your units are and will start randomly scouting the map until it sees one. When it sees one temporarily that then moves out of vision, unlike the base-AI it will not know where it went, only where it was. It will then either check or fire at this position and then consider the unit it saw there gone. It will also update that knowledge once it sees the unit somewhere else.
"Allow Brutal-AI to pre-prime grenades" => Isolated AI-units that have nothing to attack will prime their grenades to then be able to use it later for a much lower TU-cost compared to only priming it when it has a target for it.
"Brutal AI avoids proximity-grenades" => If enabled units controlled by Brutal AI will recognize when there is a proximity-grenade on their path and avoid stepping on it. Not working for units with maximum aggressiveness.
"Spread out" => Units controlled by AI will deliberately avoid standing too close to each other in order to reduce the impact of explosives.
"Performance optimisation for huge maps" => Normally the AI will pathfind for the entire map and also remember line-of-fire and vision for all it's units in the entire map's range. Now this will be toned down when the amount of tiles on the map times the amount of enemies exceeds that of a 60x60x4 with 30 enemies. With this option massive maps like 120x120x10 with 115 enemies become kinda playable again.
"Targeting behaviour for Brutal AI" => There's 4 different behaviours which kinda act as a difficulty-level the default is 3.
1 => As for the base-AI, the AI-units can only attack what they can see themselves.
2 => AI units can also attack whatever any of their friends see.
3 => AI units will remember locations of player-units they've become aware of and use blaster-launcher-weapons against them.
4 => The AI goes into hard-core-maphack-mode and can now attack everything it has a line-of-fire to without the need for vision. It is completely ridiculous and I don't really recommend using this.
"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.
"Intelligence-mode"
0> Static intelligence.
1> Inherit intelligence from unit-intelligence
2> Inherit intelligence from difficulty-level.
"Automated combat" => Hands the control of even your own units to the AI. Warning: That's a bit experimental and might not produce the results you desire. Can be toggled on and off during your turn in Battlescape by pressing ctrl+a.
"Sneaky AI" => This was not changed in how it works. It prefers going longer paths over paths that are visible to the enemy. It was just move to this new category because it fits here.
Extended:
"Fog of war" => When enabled any tile that was previously visible to the player but currently isn't will now be drawn in the selected fog of war color.
"Select fog of war colour" => Values from 1 to 15, each representing a different shade colour. Hint: 1 and 6 look good.
"Smart ctrl-click and auto-equip" => Ctrl-clicking items in the loadout-phase will prefer slots that are faster to reach. The off-hand will be deprioritized if the main-hand holds a two-handed item. Auto-equip uses the same logic.
Features for Modders:
All the features for brutal-AI can also be enabled separately while the player themselves has disabled them. This way modders can customize the experience as they with for their players.
The files to edit for that is "units.rul"
You can add the following:
"isBrutal" (true/false)
"isCheatOnMovement" (true/false) (equivalent to omniscience for brutal-AI)
"aiTargetMode" (equivalent to Targeting behaviour for Brutal AI)
Note: If "Inherit unit-aggression" is enabled, the Aggression-stat of the unit will be used. However, if the aggression-stat is 3 and above, it will map to Aggressiveness 3. The maximum aggression via inheritance can only be achieved with the LeeroyFlag. This is because in some mods a lot of units use aggression-values of up to 8, which otherwise would all map to a pretty bad and non-competitive behaviour.
If both the mod and the player use brutal-AI-options but they differ, the higher one will be used. For example: You set "Brutal AI" enabled with "Omniscience" and target-Mode 2 and the Mod has it enabled but no omniscience but target mode 3, the unit will use target-mode 3 and omniscience.
If asked to describe how using this mod with default-settings (ignore-grenade-timer/brutal/omni/preprime/3) increases difficulty, I'd say when we quantify difficulty with the kill:death-ratio for soldiers, I'd say it's about 5 times more difficult. Especially early-on with basic gear and especially when the enemies have access to explosives.
If you want to combine this with other mods that increase difficulty, I recommend to tone it down and maybe use the non-cheating-variant and fire-mode 2. Unless, of course, you are ready to suffer or really, really good at this game.
Major Milestones:
2.0.0: Movement-logic completely rewritten to be much more efficient and comprehensible.
3.0.0: Inclusion of auto-play, allowing the possibility for player-controlled-units to be controlled by the AI.
4.0.0: Consideration of all possible attack-options of all equipped weapons. Including walking closer to increase accuracy or use melee-weapons.
5.0.0: Prediction of enemy-movement and taking it into account for decision-making.
6.0.0: Using a heat-map to quantify danger and being aware of potential support from allies when deciding how brave to be.
7.0.0: The AI is now capable of weighing self-preservation against attacking making it less likely for them to end their turn exposed when decent cover is nearby.
8.0.0: 64 bit executable, the AI can now determine to use a dedicated spotter.
-
Congratulations!
This is a step which was required to keep things clear.
One place is for AI, other for UI, etc.
Please consider making the following sections:
- FAQ
- changelog
- suggestions
- bugreports
- realistic accuracy
- user interface and options menu
- misc
- donates (optional, I don't know if you have Patreon/etc or you don't need any)
-
Excellent job! I am playing it now and am very pleased. AI keeps fighting until last soldier trying to kill as many of mine. No casualties missions are now rare.
One question about your mod philosophy. Meridian accept only strictly "vanilla compatible" changes. Do you inherit this or you allow yourself to wander in somewhat different directions? Just asking this to make sure whether I should propose some non vanilla compatible changes or make my own fork. Thank you.
-
I pulled and built your main branch. It compiles fine for Win32. I guess the code is OK, this is just your environment. I suggest you delete the project and then just open the SLN fine and configure it for Win32 and it should work again.
-
I created this post right when the sub-forum was created. At this point in time I didn't know the admin was going to move the old-thread and all the other threads in here as well.
I personally see little reason to add sub-forums to this sub-forum of a sub-forum.
-
Played it a little more.
Added many distance penalties for shooting (including aimed) and nonLOS penalty. That including all throwable explosives. So they should be much less precise at higher distances too. Made it somewhat more bearable to the level that very very careful combat can lead to success. Still AI is so effective that any sloppy decision ruins the mission.
From the player perspective it is very interesting to try to predict AI, catch it on counter attack, block it with proximity grenades, etc. However, it requires so much mental efforts that passing mission after mission just exhausts me. I save and quit and then return to the same combat after a day or so refreshed. Yet, it may take few iterations to go through a mission. I cannot imagine how frustrating this will be on ironman.
This is NOT to criticize the BAI. It is really great. The problem is in vanilla preset that made aliens deadlier to compensate their stupidity. Now I am thinking out loud how this can be balanced back with AI getting smarter.
-
Actually, it vividly reminds me "Aliens" when they expected it to be a bug hunt but got 3/4 of their platoon wiped out in first attack. They were also terrified to realize how intelligent their enemies are.
🤣
-
Now I am thinking out loud how this can be balanced back with AI getting smarter.
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
-
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
Leaning toward starting equal now but dialing down alien stats, etc.
By challenge curve you mean scaling to player level? I would try to avoid it. Vanilla already doing pretty well on this increasing challenge with script events. Appearing deadlier species, tougher encounters, etc. Player just need to catch up with it. The ability to catch up is one of the strategical challenges those I like.
-
Actually, quite curious if anyone is playing BAI in vanilla ruleset for FUN?
😃
Or is it just a base for other people to build their mods on top as I do?
-
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.
-
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.
-
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.
"not confused" and when I see attachments, its show red OXCE logo :>
You probably do not update all icons embedded in file.
-
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
-
Were you able to find a strategy?
-
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.
Most come for megamods, because they have enhanced content + social promoting works quite nice. Dioxine has had a couple of positive reviews of X-Piratez back in 2014 (?).
Some come in nostalgy of original X-COM, but then also leave as megamod players (see above).
Btw I quite suggest you to see https://openxcom.org/forum/index.php/board,27.0.html
Finnik makes something unique and you can share your splattering energy with him, if. Because this has potential of "by developing completely new gameplay design"
-
Thank you for pointer. I will definitely talk to the guy to compare notes and exchange ideas.
-
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.
Nice, yeah I second a new graphic icon for the binary, maybe something more BRUTAL like feeling :)
-
Just discover this in BrutalAI_TFTD.rul. Is it part of BrutalAI philosophy to remove MC Disruptor?
# 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'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.
-
Nice, yeah I second a new graphic icon for the binary, maybe something more BRUTAL like feeling :)
I like the colors but it looks like an upscaled very pixalated smaller icon.
-
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.
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.
-
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.
Do you mean you play quick battles only and not the whole game? Cannot understand how them can even be played together.
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.
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.
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, of course, every single thing helps. Generally, I am absolutely fine with AI using its knowledge about my soldiers as I would about theirs.
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?
-
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.
I don't know what you mean by "Cannot understand how them can even be played together." Who does "them" refer to in this case?
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.
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.
Any other means to cope with this without complete removing psionics feature?
-
Thank you for update. And don't need to get upset. People quite often misinterpret things without ill will.
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?
Yes. That is what I deduced. This technically fair. After all engine does show these actions of opposing party to the player. 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.
Not sure about you, though, as you mentioned to teach AI everything you yourself use.
😃
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?
With this I feel like aliens penalize the person accidentally farted by immediate shooting and throwing at their location.
😲
-
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.
So I should probably adjust my rulesets if I want to get rid of it. No worries.
In this case it might be related to load-order or simply incompatibility in general.
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.
Any other means to cope with this without complete removing psionics feature?
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.
Also: Since you don't have to fight against PSI-aliens you'd abuse it against those who don't have it themselves.
-
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?
With this I feel like aliens penalize the person accidentally farted by immediate shooting and throwing at their location.
😲
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.
-
Alien activity tracking tool.
-
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?
-
Brutal-OXCE 7.13.0 - Smoother aggressiveness progression
Updated to OXCE 7.10.0.
Tim Nevolin:
Right aligned numbers in lists.
Xilmi:
Improved the heuristic of how the AI determines which item to pick up when having several options.
When an opponent is not where it was expected to be the algorithm that takes a guess where it could be instead now takes into account how far the opponent could have travelled since last seen.
This should help with completely unreasonable guesses.
Brutal-OXCE now has a different icon to make the executable easier to tell apart from OXC and OXCE.
Fixed an issue where weighted randomization caused AI-units to reposition over and over until all their TUs are spent leaving them with no chance to reaction-fire. The units will instead mark themselves as wanting to end their turn after the first non-attacking and non-peeking-move and only wake up again if any of their team-members finds something interesting.
Weighted randomization was merged with intelligence-scaling. The old intelligence-scaling that made the AI do random-moves was way too extreme in making the game easier, which was against the design-philosophy of brutal-AI. So instead intelligence now impacts the roll-range for the random-score-modifier of the previous weigthed randomization. The lower-boundary is 0.2 times intelligence. The upper boundary remains 1.0. Attack-moves are now also subject to the intelligence-roll.
Units that have made a move with the intent of getting into an attacking-position will no longer perform a second iteration of the movement-logic to check their time-unit-preservation in order to prevent indecisive behavior caused by application of a random score-modifier.
The way aggressiveness works is now way more gradual and doesn't alter the behaviour in extreme steps like the previous integration.
The way it works now is that an aggressiveness-based factor is applied to the "will to be closer to the enemy". This factor gradually shifts the behavior from careful to aggressive.
Baseline-aggressiveness can now be set with two numerical values from 1-9. One acting as numerator and one as denominator. So aggressiveness can be set up from 1/9th to 9.
The meaning of this value roughly is: "How strong do I feel compared to one unit of the enemy."
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.
The aggressiveness is now always impacted by both morale as well as a rough estimate of each team's total combat-power. This way the AI will situationally adapt to what's happening and decide if it shall be more defensive or more aggressive compared to the baseline.
Even at the lowest aggrssiveness the AI will be at the very most be as defensive as the previous aggressiveness 1 behaved. That means they will still move up to the closest tile they deem to be save based on their scouting-information.
Aggressiveness of 1 is now similar to how prvious aggressivness 2 behaved.
An aggressiveness of "1" is now a threshold for two behavioral shifts: Below that threshold there is an increasing score-bonus for being indoors. The reciprocal of the aggressivness is multiplied with the score of a tile, when this tile has a roof above.
The other shift is that above a value of 1, the AI no longer will prefer reserving time-units for breaking line of sight over performing an additional attack.
The previous completely reckless behavior now is only possible with units that have the Leeroy-flag and at aggression-mode 2. Otherwise high aggressiveness-values will not put a lot of emphasis of taking cover but will still make use of existing cover if it is opportune while closing in.
Also non-Leeroy-units that know they have been seen during their turn will always want to take cover regardless of how high their aggressivness is.
Changed the defaults for the aggressiveness-numerator back to what the previous version's aggressiveness was and and adjusted the denominators accordingly so that the AI's behavior is roughly similar to what it previously used to be.
Adjust aggression-defaults for the presets too.
-
It shows sectors (regions/zones) with 5+ hours of continuous untracked UFO activity. Pops once new region/zone comes into list.
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.
-
It shows sectors (regions/zones) with 5+ hours of continuous untracked UFO activity. Pops once new region/zone comes into list.
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.
Sounds good! :)
-
Brutal-OXCE 7.13.0 - Smoother aggressiveness progression
Hi Xilmi!
Thank you for the newest release!
I've got too much work to do before the NY, but want to play vs new BAI scoring levels badly.
How can you estimate new intelligence options, compared to old ones?
And... Actually, why won't you make some subthemes in forum?
Changelog section only, will show the amount of work you've done.
Cheers!
-
I think I am able to formulate my concerns more clearly now. Keep in mind these are just out loud thoughts without intent to persuade anyone. This is your mod and I won't cry if this won't get into it.
Point of view #1: formal fairness
Game engine is a platform providing (theoretically) equal experience to either party. Besides, in turn based strategy, such platform should also be a storage of all the data pertained to each party and should provide them on demand at any point unlimited number of times as needed for the party to make a decision. The great example is indication of spotted enemy unit. Once spotted, the engine provides this information to both AI (in form of variable stored for the whole duration of AI turn) and human (in form of visible figure on the battlefield). Player can save the game at this moment and return to it in a year and still have access to all information available to them to take a decision.
The knowledge of the "attack origin" is not like that. Engine indeed saves it and makes it available to AI for how many times it wants to recheck it but not to human. Player has to be very sharp in marking all attack origins in memory, then be able to remap all their visual cues to the actual map, and maybe even draw a paper map for themselves so multiple locations won't fall from the memory, etc. I hope the point is clear.
Point of view #2: playability
Besides the chess like mind wrestling, ground combat is still part of bigger game that has to be playable to be attractive. With this in mind it is probably wise to not introduce any super strong or super weak strategy/exploit to not diminish importance of other game elements. Otherwise, it turns into one trick pony getting boring very fast.
Ability to detect when opponent's unit shoots, throws anything (including smoke grenades, flares, grenade relay, or even just passing equipment to each other), or even simply drop some unneeded equipment, or just fart - seems like such overpowered ability. Heck, it is now dangerous to even freeze in panic or become unconscious letting your weapon rolling out of your hands. Meet the grenade next turn and your unit is dead.
Such extra detection outweighs spotting by order of magnitude in quantity and efficiency. No distance limits, no visibility limit, practically whole player squad can be pinned on a map without even approaching enemy. Makes other risks tiny comparing to this one.
I absolutely welcome smart AI making me utilize each and every bonus in the game, maneuver, use tools, get prepared, research, get visual cues, compute in memory, etc. However, when most of the time battle can end in 1-2 turns it kind of ruin playability and interest in strategizing in general.
Here are few thoughts what can be done about it, should you be interested, of course.
If you want to keep it for AI it would be nice to show same information to player in permanent manner. Like arrows after detecting movement on the scanner.
Other option is to blur this information to AI imitating not exact human perception. I.e. introduce random location error or something. More difficult, I think.
Maybe reduce AI perception to see such event within certain range.
Since AI units rarely drop things, use smoke grenades and flares, maybe exclude these events? If not all of these, then maybe only dropping items? Otherwise, unconscious soldiers will become dead in a matter of seconds. No use in saving them (will just lose a medic as well).
-
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.
Similar is true for how the aggression works now. They won't just jump to doing completely foolish and selfless things at higher aggressions and also won't play completely passive at the lower ones. It's more narrow in the sense of staying in a window of viability.
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.
-
@Alpha Centauri Bear
I like the idea of adding indicators for the player about where enemy-activity was noticed. The information is already tracked anyways because Autoplay also makes use of it. Using the same yellow arrows as provided by scanning shouldn't be too hard.
This could be a better solution to level the playing-field without having to disable the AI's capabilities.
-
This could be a better solution to level the playing-field without having to disable the AI's capabilities.
And here we go. :)
-
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.
In visual AI detection level matters, though.
-
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.
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.
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?
-
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.
In visual AI detection level matters, though.
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.
-
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 with yellow arrow is to understand what level they point at even if you don't reset their z-axis. Since it is two-dimensional screen we have, you can easily mistaken its position to the one level above but closer to you. Maybe drawing some kind of cube shape like the battlefield cursor but different color. Then player can understand the position exactly by aligning cursor with the marker.
I am not proficient with the "yellow arrow" mechanics. I may be wrong. See what works best for you.
Another idea could be to color it differently from the one generated by the scanner. Probably makes sense too since they are different mod mechanics and can evolve differently too.
-
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.
That is what I was asking. I don't understand what is to override. These are two pieces of completely independent information. They depict LOCATION not the unit. Player spotted a location where shot came from. Then player spotted a location where there is a movement. They could be created by the same unit - nobody cares. They may coincide on the map and look like a single mark - that is fine too. You should NOT remove a marker for the shot just because the unit moved and later was detected by scanner. This is just a helper for the player to remember things. It is not like player forgets where shot came from just because they used the scanner.
🤔
-
Folks, who is interested, please help me to figure out best UI.
The topic: https://openxcom.org/forum/index.php/topic,11659.0.html
Notification pops when continuous undetected alien activity in area reaches threshold. This is a player helper that allows not to watch graphs on a regular basis.
The question is how to handle countries (the second tab in graphs).
Countries do not cover whole globe. They also can intersect with multiple areas. So it seems to be helpful information to pinpoint location.
The problem is UFO usually resides slightly longer in area than in country. So if we would show them separately, the country popup would almost immediately follow up the area one. Is it annoying? Does it make sense to show them together? Does it make sense to just list all areas and countries in the list, etc.
What do you think?
-
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.
-
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.
Edit: I tested it and also checked the code again: Picking up items doesn't mark. Something I had forgotten that also marks and might be the explanation for the unexplained markings is getting hit. For example by friendly fire or by blind-shooting. It still doesn't really explain it because I'm got one right inside the UFO, where there is no reason for anyone to have been affected by friendly-fire.
But I can't reproduce it. So I'll just have to keep going and observing.
Oh, I think I get it now. It's because I used Autoplay. And autoplay runs the AI-routine that guesses for a new location when they see the location they guessed is vacant. So he probably was seen at the door. Then someone looked there and he wasn't there anymore, so they guessed he must have gone into the UFO. I think I'll go with that hypothesis. In this case stuff like that shouldn't happen when I play myself.
-
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.
That is the exact reason I think you should not reuse scan spotted routine. You don't want to hook on its future modifications in OXCE. I still think the cleaner solution would be to draw your own as they they have conceptually different marking mechanics, not even mentioning they are originated in different forks.
I sure may help you if you are interested.
-
Now the puzzle starts coming together. It is still hard but, at least, I know why am I getting hit out of nowhere.
The tactics differences summary:
- Priming and throwing at the same turn is a NO-NO. Even more relay throwing. Pre-prime, throw, then run for your life the hell out of this location. At least at the sonic pulser explosion radius.
- Same for shooting. Reserve time for get out of cover, shoot, fall back.
- No dropping stuff on the ground. Ugh. If had to - run away.
- Move in a relative compact group to retaliate against jump shooters. This is no different from vanilla except here it is much more difficult to shoot them back from far away due to them taking cover much better. It may require some amount of maneuvering to get into retaliation position.
- Move groups in sweeping fashion trying to keep uncleared locations just by one side of the squad. Moving toward the center in between unknown locations is mighty dangerous.
I also found some bearable disembarking tactics. Let tanks slightly out of the bay so they do not interfere with soldiers internal transport movement. Soldiers preprime grenades (regular or smore or whatever), run out of the transport, throw, run inside. Few turns like that to cover area with smoke or as long as needed to throw grenades at everyone in vicinity. Then disembark and spread. Meanwhile, use scanners to spot enemy nearby and use tanks to kill them at close range. Tanks may be banged up pretty badly and even destroyed but this seems to be least evil comparing to losing whole squad.
-
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.
60, 80, 100% randomness were completely useless options, in this regard.
I found it quite challenging to play SH/Ironman vs 20% random, which I switched to after some adaptation. And 100% intel is unbeatable in long term.
I would play vs 100% BAI on a map with unit ratio 1:2 - 1:2,5, but when it comes to 1:4 it is getting too troublesome. So dismission of this option solely affects SH players, while other difficulties are affected much less.
So,
- I would still leave it, but marked as *only 100% BAI reports accepted*
make randomness quantity more narrow, from 0 to 40, with increment 10.
- 20% means that 80 out of 100 still kill you, while 20 do things.
BTW, battle vs human fractions ends when ~20% enemies are left and leaders are killed.
- And while initial number of 100 enemies with even 40% randomness gives the significant push, further AI power dissipates quite rapidly. This is what I disliked, despite the good effect of few first turns.
A couple of options to maintain the combat potential of BAI in case of randomness stays:
- hard binding of random units (mean they are useless dummies until the endo of the battle)
- or decrement of randomness upon battle goes on: 40% in the beginning - 30% turn 3, 20% turn 5, 10% turn 7, min cap is selected by player.
-
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.
Something that used to work pretty well was flanking. Once the AI has a grasp where your units are, go a long way around and attack them from the backside.
However, I implemented counter-measures by adding different ways of peeking. Before the AI would always only peek towards the direction they'd expect the enemy coming from. Now they also like to peek at any location that haven't been revealed this turn.
While this makes flanking a lot more difficult, it's still kinda valid. The AI will usually end their turn in positions from where they hope to ambush the player based on where they think the player is. So appearing suddenly at a position they are not expecting you to come from can work well.
But yeah, disembarking is difficult. Especially with no cover or only alien-infested cover nearby.
-
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?
-
@Abyss:
My issue was that in XCF, there is this sniper-meta. Player builds a line of units that cover a huge amount of the map. Due to the combination of high sight-range and these units having awesome reactions and accuracy, the best way to play against that is to stay inside and wait until they move in range in order to ambush them.
A random chance to deviate from this behavior and run outside means it's just a lot of pressing end turn while a small amount of units will make the suicide roll and walk out of their cover into the reaction-fire of the snipers.
The change to how intelligence works is basically a shift from low intelligence causing occasional massive blunders to low intelligence causing inaccuracies. It's akin to how this is also resolved in modern chess-engines. Earlier their lower difficulty levels would also blunder from time to time. Nowadays they calculate the best move among some others and then pick a move that is closest to the average inaccuracy of a player of the ELO it tries to emulate.
In order to truly do something similar in my AI, instead of randomizing the result of each move but still picking the best score, I'd have to put all scores in a map, so I could then pick the score that is closest to the desired percentage of the best move.
I could do an experiment where I reverse it and look at what it looks like when the AI picks the worst move of the ones it considered for a certain purpose.
-
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 think the greatest potential is within the "guessing where the enemy might have gone"-method of the AI. The potential of further improvements in that regard can be seen by enabling "Bug hunt mode for brutal AI".
Edit: Except it isn't. I just tested it and the AI doesn't work properly with bug-hunt-mode enabled. I guess that's something I can fix. It seems to both not consider attackable targets attackable and also not want to peek at all. It used to work along time ago but currently doesn't.
-
I second that. The ability to notice where on the battlefield someone dropped a used ice-cream cap is kind of cheesy. I never used it as a player and I doubt anyone does this on a regular basis. So this should preserve fairness.
Also, as I mentioned before, this would just doom unconscious soldier right there. That seriously impair the "healing" mini game.
-
Note on the spotting mechanics. Can open separate thread if needed.
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.
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.
-
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.
The AI usually loses most of it's units in that mode once it becomes very confident that it is winning and starts pushing forward, exposing it's units.
So while it would achieve better kill:death-ratios if it didn't do that and stay at low aggressiveness, there is a purpose in that:
Trauson used to just manually loot the corpses of the areas of the map he controlled, even if he didn't see a chance to win the mission. That's partly why scaling aggressiveness was introduced. Low aggression would lead to stalemates, which is not desirable.
-
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.
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.
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.
-
Agree. More or less the same.
-
Played with yellow arrows a little. Much more satisfying. They blind shoot me but I do the same sometimes with better efficiency.
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.
-
Hi! What a nice weekend) Let's talk a bit, if you don't mind:
1) Is what being discussed above means that BAI knows whether you drop something on ground and marks this as enemy position?
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.
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.
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?
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.
6) I would still leave nerfed option for near-casual players, only because it's already there.
Thus you will allow play SH (what most prefer because it is better for overall gameplay progress. More enemies = more experience to soldiers, better scores, more loot).
The change to how intelligence works is basically a shift from low intelligence causing occasional massive blunders to low intelligence causing inaccuracies
Well, that's fair. But let me represent literally everyone here on forum: All-hiding is boring! We want random strategies!
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.
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?
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?
UPD.
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.
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.
-
Played with yellow arrows a little. Much more satisfying. They blind shoot me but I do the same sometimes with better efficiency.
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.
-
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.
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.
Also it seems to be a bit contradictory. Both sides doing a lot of blind-shooting doesn't sound like rushing.
Do you mean rushing battle or AI rushing toward me? I don't see how it is contradictory. Some blind shoot me and other gather at my location.
I'd actually like to see some footage where you point out what issues you have.
These are no issues. Interesting play. I just recite what I see.
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.
No preferences at this point. Still testing. I didn't say I like or not like them blind shooting. That seems fair and I can adapt. Already did, actually.
Skewed in term of battle duration and progression compared to vanilla. Very intense first few moves and then game over for one or other side.
Again, I am not saying I like or dislike it. This is just how it is. Obviously, because AI tries to use opportunities fast.
No need to modify anything at this point. These are just "front line reports".
😄
-
Generally, I think you should make AI as smart as possible and do not dumbing it for easier difficulty.
Difficulty settings and balance should be done by parametrizing unit strength and other things. Similar (but opposite) to vanilla dumb AI with overpowered units.
-
1) Is what being discussed above means that BAI knows whether you drop something on ground and marks this as enemy position?
If yes, then would it be within line of sight or everywhere on the map?
It used to be the case that the AI notices that. But I'll remove that in today's patch.
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.
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.
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.
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.
Stats are important. Speedislife sent me a save from a mission in XCF, where he was reasonably outnumbered. But because the individual units were comparatively weak, they still only went with an aggressiveness of like 0.37. So not very confident that they could overwhelm the player with a push and thus resorting to more of an ambush-playstyle.
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.
But I would argue that they kinda see how big your craft is with which you arrive so knowing the ball-park of how many units you have kinda makes sense.
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.
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.
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.
8) Have you had time/curiosity to see the Osiron Hacienda save?
It is wonderful map for AI to take multiple strategies, all winning. Both covering inside and sturming player's positions with massive attack.
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.
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 just add up stats of each side and compare that ratio to determine the aggession-ratio. That actually needs a bit improvement because the euqipment isn't taken into account.
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.
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.
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.
-
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
That used to kinda be my opinion too but I feel I was talked into putting quite a bit of effort into creating options for no other purpose than making the AI easier to play against.
-
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.
Save from which point? Beginning of the battle? Last turn?
-
I don't really understand what these 2 new options do. How does their values change the AI?
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.
-
8) Have you had time/curiosity to see the Osiron Hacienda save?
It is wonderful map for AI to take multiple strategies, all winning. Both covering inside and sturming player's positions with massive attack.
The Osirions get an initial adaptive aggressiveness of 8 up from the base which is set to 1.
So I'm expecting them to swarm out and push towards you.
In turn 1 all of them moved forwards but noone actually left the Hacienda yet.
Hmm... but they don't. It seems like they physically can't leave the house. Okay... This map is bugged. The door just won't open. They try to get out but they can't. So they are fight around the wall. So this save is not a good one to test the new adaptive aggressiveness.
I restarted the mission and teleported a soldier in debug-mode to the door to shoot a hole in it to allow them to leave. Let's see what happens now.
Okay by turn 2 4 dudes have left the hacienda. I put my soldiers in sniping position and have thrown a few lamps. I got hit a by a kind of grenade launcher after one of my guys reaction-fired. So had to heal up 3 of them. I think reaction-fire-tactic won't work as they answer that with return-fire. Can try luring them closer first by skipping my turn.
They arrive in peacemeal. I killed 5 of them. Aggression dropped to 6. The door only being one tile wide now made it so that one stopped there blocking everyone else. But they are also still trying to avoid AoE and so they come out quite slowly through that choke-point. Overall it looks pretty uncoordinated. Not like they are acting as a collective but pretty much like individuals, who think the others got their back, while many of the others are still in their rooms.
Okay, here's a few ideas to deal with that: Higher aggression should suppress the need for cuddle-avoidance. I could basically divide the cuddle-avoid-modifier by the aggression. So that the aggressive units are more willing to share spots and not always wait for the location to be vacant before moving further.
The other idea is to make the units aware how far away or close they are compared to the average of their team and use that to modify their personal aggressiveness.
For example if a unit is 10 tiles away but on average the team is 40 tiles away, then I could do something like multiplying their individual aggression with 1/4th. This should naturally lead to some sort of "waiting for the others"-behavior.
Both of these measures combined should lead to a more coordinated push.
-
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.
So with 1 over 2 to or 0.5, they are more on the careful side.
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?
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 belong together and work similarly to how it used to work before but with fraction-arithmetics and normalized around the value of 1.
So with 1 over 2 to or 0.5, they are more on the careful side.
Oh, so it is the first divided by the second, so if the first is bigger they become more aggressive?
Over the course of how many turns? What do your other settings look like?
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?
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.
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.
Sorry, no save since this is ironman, but here are my settings. I have lowered aggressivness mode to 1 since it said that that would match 2 from previous version.
-
They get like 1 or 2 attacks then they just move away 1 or 2 tiles to be killed next turn, if they survived.
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.
If this is the case, then your units obviously outclass them by an order of magnitude.
If they do attack but your unit takes no damage, then there obviously is nothing they could have done better except of delaying the inevitable by avoiding your units and not even trying to attack.
I made it so that when they don't do damage they will still attack. It might make them look stupid but it will prevent wasting your time.
-
Well, I'm not that much better. Still using human weapons, and synthsuits are not that great with armor. It's just with melee synthsuits boosts a lot, so that might throw off the AI a bit? Cause all this happened with melee, no shooting.
-
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.
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.
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?
-
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.
It seems to require quite fine tuning in alien stats to make campaign playable.
-
Is unit intelligence used anywhere in current default settings?
-
Hi Xilmi!
I downloaded the new release and gaze into new aggressiveness settings.
Have no single idea what to set as EA numerator and denominators.
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?
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.
UPD.
So I set
Aggressiveness mode = 2 (to use Leeroys flags)
Numenator = 1
Denominator = 2
And some units go more aggressive, while others are more cautious?
In XCF only zombies, cybermites and pinky demons (doom fractions) have Leeroy flags.
And, I guess, Leeroy flags there means they just push straightforward no matter what.
And, You have the Brutal brutes option, which if set NO, sets all inventoryless creatures to vanilla behavior.
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?
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?
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?
Cybermite is Leroy, but has aggressiveness = 2, thus supposed to be more careful, but still doesn't take cover. I can't comprehend it.
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.
Keep exploring the depths of OXCE mechanics! My advise is pretty the same - go play either XCF or XPZ and get used to what ppl did across last 10 years, how they workout the balance and introduce different instruments to deal with specific enemies.
Like, in megamods lobsterman are very susceptible to toxic gas weapons and grenades, because LORe says they have... gills? Ingenious, right? One grenade can instantly kill or down 20 lobstermans.
-
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.
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?
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.
I had a monster mission fighting Chryssalids and it was really dumb. Chryssalids can easily kill my units in 1 hit, but what do they do? They where absolutely terrified of my units for some reason and during the entire battle, 25 something turns, and they did not come close once during this (I use synthsuits with black ops weapons). All they did was walk back and forth trying to keep distance, sometimes taking cover. All they attacked where the civilians and once they they where turned to zombies they really didn't know what to do. Even the zombies behaved like this while in zombie missions they just try to swarm you.
Compare this to my previous post about ranged units forming lines to melee me and this becomes something that's not quite right.
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.
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.
One more thing I noticed playing campaign. It is near impossible to acquire live specimen as they all carry preprimed grenades. Kamikazes.
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 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.
I think they should be able to pre prime but then use it the next turn or un prime it, or something like that. That might be a bit convoluted though.
-
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.
For Cryssalids there should be something new, but zombies worked as intended in my previous playthrough under BAI 7.12.1, mean they roar and attack just like it was in vanilla (thx for Xilmi to arrange them).
Cryssalids are supposed to me more sentient, but they still a smart biological-terrorism weapon, thus they should attack. Hide and attack. Or rush and attack.
I guess we should look into their RUL profile.
There are few chryssalids, lol.
The one we probably look at is:
- type: STR_CHRYSSALID_TERRORIST
race: STR_CHRYSSALID
rank: STR_LIVE_TERRORIST
stats:
tu: 110
stamina: 140
health: 96
bravery: 100
reactions: 70
firing: 0
throwing: 0
strength: 110
psiStrength: 50
psiSkill: 0
melee: 80
armor: STR_CHRYSSALID_ARMOR
standHeight: 21
kneelHeight: 16
value: 40
deathSound: 9
intelligence: 4
aggression: 2
energyRecovery: 40
livingWeapon: true
builtInWeaponSets:
- - STR_CHRYSSALID_WEAPON
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?
Chryssalid itself shouldn't be running back and forth, but rather do it's stuff around, like running from building to building, looking for a target. It also has good intelligence, meaning it can hide. And aggression is quite low, meaning on average it waits, rather than approaches itself from other side of the map.
My advise here will be switching to Aggressiveness mode = 2, and further options 1/2.
I would also somehow separate chryssalids from low-int creatures to make them really fear-bringing heartstoppers.
Probably we should ask Sol how exacly chryssalids should be represented with BAI in particular.
-
Xilmi, I overviewed the units RUL file and found few inconsistencies regarding intelligence numbers.
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.
UPD: FYI created the topic in X-COM-FILES subforum
https://openxcom.org/forum/index.php/topic,11706.msg160301.html#msg160301
-
Numenator = 1
Denominator = 2
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 )
-
One more thing I noticed playing campaign. It is near impossible to acquire live specimen as they all carry preprimed grenades. Kamikazes.
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.
Aliens pre-priming their grenades is also an optional feature, that can be turned off separately.
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.
It seems to require quite fine tuning in alien stats to make campaign playable.
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.
-
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.
No need to turn it off. This is the key feature. I am thinking how to work life capture out with this. It should be fine if it is difficult but doable.
Other option could be to exhaust them from grenades. How many they are carrying?
Sometimes they randomly just survive. I haven't gotten far enough to do a deliberate life-capture on higher-ups.
They may randomly survives in vanilla after shot at but their own grenade makes sure they are dead. I never just randomly captured lived one yet.
-
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.
I agree and I am not trying to fight stronger species without proper gear. My point is that vanilla balance is not working with smart AI anymore. Alien stats need to be corrected.
What I did so far is reduced their strength to match my soldiers. Otherwise, with strength 70, they throw grenades over the map.
-
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.
I don't want to. Playing defaults. Just making sure.
What is the intelligence range? 1-10?
-
Have no single idea what to set as EA numerator and denominators.
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?
Le me try...
The base-value for the aggression is calculated by dividing the numerator by the denominator. Since both have a range of 1-9 the possible results range from 1/9th to 9.
This value is then multiplied with a morale-factor, a unit-power-estimate-factor and, if enabled, also with the unit's aggression-value.
The AI internally determines the score of potential tiles to move to by using the reciprocal of the sum of a "discoverThreat" and a "walkToDist". So the lower the sum of walkToDist and discoverThreat, the better the value of a tile.
Now with the new way aggression works, the aforementioned aggressiveness-value gets multiplied with the walkToDist. Since this happens for all checked tile it means that the relative impact of the walkToDist on the score decreases for values lower than 1 and increases for values higher than one. Or from the opposite direction: Cover becomes less important in the formula with higher aggression-values and more important with lower aggression-values.
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.
The value is used in several algorithms:
How many TUs to reserve while patroling.
Chance to move to a location from where the unit can attack.
Chance to perform an escape, fight or ambush-action.
When sniper/spotter is enabled it also impacts the fire-mode-choice while sniping to some minor degree.
When the unit has to option to either use melee- or ranged-attacks, it also increases the odds to perform a melee-attack.
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.
Difficulty settings and balance should be done by parametrizing unit strength and other things. Similar (but opposite) to vanilla dumb AI with overpowered units.
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.
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.
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.
The basic idea is to use the same/a similar mechanism that determines "discoverThreat" of the own units to determine the safety of the enemy units and then decide whether trying to reveal them with a spotter is the right play.
I have a test-save with a skyranger-exit facing a house full of aliens. I think 5 or so. Smoke-grenades have been thrown. Right now once the grenades go up the Aliens just hide away. Hiding isn't the worst but there clearly is a better option. One alien could step forward and reveal a bunch of X-Com through the smoke so the others can shoot. So they can determine whether and how many of them should have a line of fire to where they had seen the enemy units before and they should also be able to determine whether one of them can walk forward for revealing-purposes.
Then they would determine a dedicated spotter, which is likely sacrificed in order to potentially get a bunch of kills on their turn righ away. For best play it should be about correctly identifying the situation at hand and not about some pre-determined but unrelated aggression-value.
-
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.
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.
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.
And since giving this same ability to BAI-units would be rather cruel, intelligence was completely ignored for a long time by BAI.
But that also means that modders never really had to think about what intelligence they'd give to units as it didn't really have a whole lot of impact anyways.
-
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.
But as I indicated in some of my earlier posts, I'm not really wanting to focus a lot of my efforts into doing much with the aggression- and intelligence-stats. They aren't "real stats", so anything I do with that will be arbitrary anyways and just moves me further away from:
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.
Does it mean intelligence of the unit in ruleset is capped to 0-5 too? I have an impression vanilla unit intelligence has a scale of 1-10. Therefore, it would have a bad compatibility to use their default intelligence values with BAI.
And, yes. I am not also fan of arbitrary customization of AI behavior. People think they are almighty gods of configurations but they don't actually know what they are doing. AI is too complex to reduce it to just few dials.
-
Well, I can, at least, go through unit ruleset and customize the intel and aggro levels to match average player expactations (or just mine, if everybody else doesn't care of behavioral inconsistency) of the units. Like, minotaurs should be quite stupid and aggressive, good soldiers should be balanced, and beings like stargods, sectoids and faction leaders should be quite smart.
This solution now seems the only option.
For chrysalids, well, no idea, what comes next. Probably addition of some BAI-only related flag can solve the question. And then - voting between the players and devs can show which exactly units deserve logics.
A couple more questions arose:
Zombies behave as Sol intended, what exactly have you done to them?
Werevolves are controlled by BAI, while being living weapons - why so? Do they have inventory? I don't argue for changing that, just curious. Perhaps my solution will be boosting their aggro to max, as their intended intel expected to be low.
-
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 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.
I know, that's why I play XCF on level 3. ;D
I don't think you should try to cover all possible things that can happen. The biggest problem with XCF is the absolut insane monster count on some missions combined with very bad spawn point designs. It makes some missions awful while the more vanilla ones are fine and fun.
So I have some ideas that might help without fiddling with the AI behavior.
- Maybe on turn 1 the enemy does not try to actively scout or move towards the players spawn point. Many times enemies spawn right next to spawn and there's no way to move out, so I just smoke and hope for the best leading to them moving into the craft/room and start blasting. This is a huge problem when your armor is bad at the start of the game. (My best solution for this was to just make a mad run and try to hide in an other spot, especially against Chasers, but I feel that's bad play that only really works with save scumming.)
- Maybe also make motion scanners work on turn 1? That way I can move away from the worst blob.
- Maybe add an option to reduce enemy spawn count? You can have some system that calculates enemy strength together with their amount and reduce the spawns if it gets too high.
My idea with these suggestions is also that the modder does not have to consider if you play with BAI or not which is good i think.
-
It is not clear to me why people would even want part of aliens to be controlled by BAI and other part by vanilla.
-
Because (lorewise) some aliens are dumb meat puppe
rts and/or feral critters, while the others are psychic masterminds or ET stormtroopers?
-
So, the answer was, that:
Unit intel = amount of turns, when unit remembers of particular targets and is not switching to patrol if/else behavior
And, for unit aggro:
0 = mostly passive
1 = balanced
2+ = mostly aggressive ,meaningful values are between 2 and 8.
The interesting point here is that passive aggression (lol) means that units tend to set up ambushes, rather than attack. More specifically, to retain TU's for reaction fire a lot more than attacking units do. These units include: most alien, human and X-COM turrets, some alien leaders, etc.
Even more interesting, that there's just 1 tone in the 0-1 palette for passiveness, while aggressiveness has 7+ tones.
While high aggressiveness means kinship towards frontal and melee attacks. That may be a key to evaluate satisfactory melee behavior in cases, where unit cannot reach enemy within one turn.
I do feel by instinct, that BAI may use one more particular axis in decision mechanism, but not yet can formulate what exactly it is.
So, what I suppose is:
1) retain TU's for enemy leaders and moving robots, mean if they don't see, they better ambush, than move towards, using whole TU's, even if morale is high.
2) passive units tend face towards supposed player units incoming direction (I have seen several UFO's, which turrets where looking somewhere else during midbattle, if my units were covered. I may be not knowing recent changes, tho)
3) split aggressiveness-based behavioral model into two forks, where high morale doesn't force 0-1 aggressiveness units to rush, but rather ambush.
4) Consider splitting 0-1 aggressiveness into, at least, 4-5 steps, like pure 0 (for static turrets), 0.1-0.2 for leaders, 0.3-0.6 for turrets, 0.4-0.8 for little amount of specific aliens, etc. I'm kind of upset seeing alien leaders run towards death if overall morale is high.
5) to consider how this should correlate with mind attacks from psion enemies.
-
Because (lorewise) some aliens are dumb meat puppers and/or feral critters, while the others are psychic masterminds or ET stormtroopers?
That is right. This is why intelligence parameter is introduced. I mean BAI could easily emulate stupid behavior with low enough intelligence.
My point: it it much easier to tweak one engine and vary intelligence rather then trying to stich two completely different ones.
-
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.
-
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.
Let's see what Xilmi answers on passive aggression.
-
Certainly, but then you're going to be stuck maintaining that compatibility patch. And it won't be nearly enough for 'full' compatibility. Plus, how long are you willing to commit to this?
Never mind that you'll be second-guessing the mod author in quite a few places.
Anway, that's all doable and not even hard, so fire away.
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 understand you point, Abyss. This is exactly what I am talking about.
I don't understand the notion of mod "compatibility". Why they even should be? They are different games even if built from same pieces.
Sometimes people build one mod on top of the existing one. That does not make them compatible.
And BAI is different engine even. What is the use of making some text files compatible between two different code bases????
I get it that people have some common understanding what unit "intelligence" is. I guess, mod authors try to match this understanding with what they program internally. After all higher intelligence number leads to deadlier unit in this mod. However, if they diverge than they diverge. There is no point to adjust them to the smallest variations.
-
To reiterate, I didn't mean to make you life harder. Just pointing out that in majority of cases tuning rulesets to new engine is an inevitable work.
-
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.
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".
The alternative can be just replacement of original unit.rul file with another, which contains adjusted intel and aggro settings.
-
Did not OXC have tools to altering existing mods rulesets? Even more OXCE adds more tools that allow better interacting with base mod by using `update:` or `override:` that check if given item or unit rule exists before applying it.
-
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".
The alternative can be just replacement of original unit.rul file with another, which contains adjusted intel and aggro settings.
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.
OTOH, you already can make small adjustments to most rulesets without overriding the parent mod (as long as people download and enable your submod, that is). See the XCF submod list for many an example. The latest entry, the surrender submod, works exactly as you're describing this, just for different variables.
-
Keep in mind I am not proposing or restricting anything. Just curious why a single aspect of ruleset and engine collided?
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.
That is right. It seems the "compatibility" is understood differently by different people here. If you mean just an ease of migration then I would agree with you.
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 ???
-
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.
Intellect = memory function in VAI, while in BAI it is aspect of action fineness.
Aggro = frontal assault vs ambush-preservation of TU's. It is somewhat close to BAI's intention, but now shifted by some amount of whole numbers (in VAI terms) for amount of units, that are supposed to be more cowards rather than brave warriors.
While lacking serious AI tools, modders of vanilla OXCE balance fights by following means:
- enemy amounts, stats&armors and weapons
- restricting X-COM in same categories
- map design and initial unit layout
The proposed solution for BAI to be top-experience is:
- making formulas clear and final
- and then fine-tune aggro and intel settings in RUL files to estimated values either by modders themselves or by community.
By mine understanding, it should be a multiplicator, rather than surplus.
For instance of balanced aggro of BAI = 1, aggro 3-4 for pusher will be enough to represent super-aggressive unit, and 0-1 - 0.2 will be enough to represent super-coward unit. No need for aggressiveness 7-10.
Again, this all being supposed for psychological validity of unit behavior, i.e. player's game experience, and may a bit nerf the overall power of BAI. Which is compensated by unit amount via difficulty level.
Xilmi says that BAI ain't going to be perfect for any mission out there, unless megamod is created specially with BAI in mind. But we can go close enough by hand-tuning.
-
Xpiratez + brutal OXCE has a problem with spawning items. In Xpiratez mode, there are special outfits that spawn loot only for the fact of appearing on a mission.
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.
The same problem with enemy units.
https://xpedia.netlify.app/##STR_NINJA_ASSAULT
https://xpedia.netlify.app/##STR_NINJA_GAL
All units of the ninja faction have built-in ninja badges. Badges will also not appear after killing ninjas.
-
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.
All units of the ninja faction have built-in ninja badges. Badges will also not appear after killing ninjas.
There definitly were ninja badges in my last playthrough. That was 7.9.13
-
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?
-
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 save you attached is during a base-defense.
I'm sorry. My mistake.
Here is the correct save file (A3.sav). It should be on the geoscape right before arriving at the crash site.
-
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.
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.
-
I never done so, but this particular year really want to wish this particular thread all-prosper and break the limits! To Xilmi: thank you for everything you've done so far. We really appreciate your input! Have a best 2024!
-
Joining the holiday celebration.
I had a real fun rediscovering this game and BAI in particular. Wish everybody prosperous enough life to have time for beloved games!
-
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.
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. :'(
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.
-
Damn. That's horrible to hear. :'(
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.
No it's gone since I reverted. But it should have happened to you for sure so it might be something else.
The only way I could finish a mission was to save and let it crash, then reload and finish it on the same turn. If I passed a turn and finished a mission it would crash again.
The only difference in settings from previous version was that I enabled the new base stats. I also play on lvl 3 ironman and I have some XCF sub mods if you think that matters.
The random crash in the enemy turn was when projectiles were flying so it might be related to the path finding. I did not play long enough to see if it crashed in my turn.
-
I guess I'll just have to play-test a lot including actually finishing missions in a real game and not just Mission-generator-missions and try to see if it happens for me too.
If it doesn't, I'll make a 32- and a 64 bit-version of 8.0.2 so you can see whether this makes a difference for you.
Saw the crash happen in a private stream from someone else.
Noteable was: He was playing with Ironman and it happened when he was doing Save&Exit. It also happened during a Terror mission. So possible necessary conditions are: Ironman and/or a neutral faction existing.
So this is the direction I'll investigate tomorrow for reproducing it.
-
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.
Even with the grenade-usage, the AI doesn't actually change the slot the grenade is in. It just pays the TUs it would cost to move it to the hands ontop of the priming+throwing-cost.
Brutal-AI isn't limited like that. It iterates through all weapons and all fire-modes a unit has and picks the one that it thinks has the best damage per TU, which dynamically can alter by the enemies's armor and distance.
However, the API doesn't switch weapons. There is a "BattleAction"-object which has a weapon-pointer and an action-type, which the AI populates. There are no checks whether that weapon is in a hand. It just uses it from whereever it is. I actually don't know whether the 2-h-penalty is applied if there's 2 items in hands.
Changing how it works would require some modification of the AI too. It would have to take all that stuff into consideration that it currently doesn't. It definitely seems to have been designed around units who have exactly one weapon. So the behavior for units that deviate from that is not properly handled or even defined.
-
Request for different arrow color for "last spotted enemy location".
I see that you use different colors already but they are very similar: bright yellow and darkish yellow. Even if I can distinguish them by staring into screen it would be nicer to have completely distinct colors to not strain my eyes. Any other but yellow would do.
😀
-
Could anyone else reproduce the crash and has a save from shortly before?
I've been trying to catch a crash for an hour now and it simply doesn't happen on my side. :\
Maybe it was related to something in OXCE 7.10.1 and it is fixed since I updated to OXCE 7.10.3. I'll check the notes if something like that could be the case. Really doesn't look like it. None of the commits mention fixing anything.
Oh, and trying to run XCF fails because of a change in OXCE 7.10.3 actually. :o
Edit: Okay, I had the crash happen now. Once. And it wasn't reproducible from the auto-save the turn before. It happened after losing a mission in XCF that lasted roughly 10 turns.
The crash happened at a very odd place. At the destructor of Pathfinding::~Pathfinding() or respectively deep in some dlls that run after that.
I don't have an idea what I could change to fix it or how to test potential fixes. The main-issue being how much I struggled with reproducing it even just once. If it would happen all the time, it would be much easier.
So I guess I'll go back to 32 Bit and we just play a lot and if it doesn't happen again, we assume that it's related to that.
If it still happens, it could be related to the code that determines whether a spotter should be used, which uses path-finding. But I don't really get why it would crash at the end of the mission then.
-
Could anyone else reproduce the crash and has a save from shortly before?
I've been trying to catch a crash for an hour now and it simply doesn't happen on my side. :\
Hi!
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.
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. And I still cannot switch it to "baseline + modder-set", because ruleset numbers for VAI are not good (actually, very bad) for BAI.
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.
-
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.
The save is attached.
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.
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.
For determining competetitiveness I also usually use benchmark-scenarios to make it as comparable as possible. Missions with vastly varying team-compositions are not helpful for comparative testing. 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?
Enemies should attack when they can. Whether they reserve TUs for hiding after attacking or keep attacking until they can't anymore is determined by the quality of available cover.
The idea of the introduction of the spotter-logic is to create a situational logic that determines when a unit should actually push rather then using some sort of non-situational value for that. The overall tactical idea is that all units push towards the location that is closest while still providing the most safety and then inviestigate the situation via peeking until it looks most opportune to ambush the enemy.
Note that there was a bug which is fixed in 8.0.2:
"Fixed an issue with the spotter-determining-code that caused the spotter to think their friends would always have enough weapon-range."
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.
And I still cannot switch it to "baseline + modder-set", because ruleset numbers for VAI are not good (actually, very bad) for BAI.
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.
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.
-
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.
The one in 8.0.1, where I had chosen only baseline, I had it easily won. Even so it was pushing first 2-3 of turns, the battle changed fast towards reaction fire and killing of small waves of some attacking guys, while others were hiding inside the buildings on the map edges (away from actual combat area). Thus, overall enemy push was noticeable, but quite dealable.
The panic spiral of enemies started soon after, so past turn 12 the game became one-side beating.
I am sure that in some scenarios 0-1 aggressiveness is definitely purposeful. But clearly not in case of battles vs x3 enemies (of same power), where rushing strategy for AI is better.
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.
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.
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.
I think simpler is better. So, if you chose this over min-max range, no trouble.
The question is: should every unit on the map be of same picked aggression, or statistically different by min-max.
Theoretically, if same, then missions overall will feel different, which is good.
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.
for experimentally determining suitable values but not nice for the player who didn't know what to set it to
Yep. I am going to make a submod, so players don't have to do anything.
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 am looking for balance that kicks my ass, but yet is possible to beat:)
-
Bad news:
8.0.2 also can crash in deconstructor of Pathfinding. Apparently regardless of whether Win32 or x64 is being used. I was playing all evening 5 missions no problem. 6th mission crash at the end when _battleGame and subsequently _pathfinding are deleted.
The good news is that once I find the actual cause, I can go back to 64 bit. The bad news is that I still need to find it. What I changed was that I now also call getReachableBy for friendly units in order to determine whether a unit that checks whether it becomes a spotter would get support or not.
But the functionalty works and it doesn't crash where it's used. Only when the mission ends, which is the part I don't understand. :\
I also don't really just want to remove this feature that I considered a big enough step to warrant a new major-version. Especially not without understanding how that can cause an issue like that.
-
Simply some code indirectly access it. There is lot of processing after mission end. And of of function doing something else call your function.
Like there is function that do A, B and C, where A and B is needed for mission end but C that is not needed require checking patfinding.
Beside you you not have debugger that stop when crash happens? you should have function backtrack of crash site and see from where
this code is called.
Some times fix is simply add `if` in strategic position, there is lot "fix" like this already in OXC and OXCE (I prefer less hacky solution but some times it impossible).
-
Beside you you not have debugger that stop when crash happens? you should have function backtrack of crash site and see from where
this code is called.
Well, the last code inside of non-external libraries when the crash happened was inside of SavedBattleGame::~SavedBattleGame() at the call of "delete _pathfinding".
I just put out an 8.0.3, in which I simply made the deconstructor of SavedBattleGame empty. This fixed the crash for me.
The most common reason for crashes is dereferencing null-pointers. That's very easy to find and fix with the MSVS-debugger. This kind of issue here was a bit special though.
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.
-
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.
That is unfortunately a very wrong assumption.
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.
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).
-
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.
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).
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.
My current hypothesis would be that somehow inside of the AIModule-object, which itself is an object created for BattleUnits, there still is a reference to pathfinding and that the deletion of the Pathfinding-object causes a problem. But the way this problem expresses itself is what doesn't make sense. If my hypothesis would be correct, I'd be expecting a simple segmentation fault trying to access the pathfinding-object inside of the AI-code. And also the AI shouldn't be running anymore when the mission ends.
But maybe this connection causes issues with the pathfinding-object when the BattleUnits and thus the AIModule is deleted.
It's also not clear how my changes in 8.0.0 should cause this and it wouldn't happen before because what I did there is very similar to something that already existed.
Well, at least I have a save from which the issue is reproducible. Not having a way to reliably reproduce it was an even more horrible situation to be in, when it comes to debugging it.
Can someone help me understand what's going on with the _nodes-Member in Pathfinding.cpp?
In the constructor it reserves memory for those and then fills it up with one node for every tile of the map.
The destructor does nothing.
If the memory is indeed not automatically managed, shouldn't it somehow free up those nodes?
Edit: According to ChatGPT since _nodes is a std::vector, deconstruction isn't necessary as vectors handle the deletion of their elements automatically.
-
Edit: According to ChatGPT since _nodes is a std::vector, deconstruction isn't necessary as vectors handle the deletion of their elements automatically.
It's about what the elements are.
std::vector<PathfindingNode> _nodes;
will be cleaned up automatically (by the vector deconstructor)
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.
-
It's about what the elements are.
std::vector<PathfindingNode> _nodes;
will be cleaned up automatically (by the vector deconstructor)
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
You are right
In simpler words, collection with elements will create elements on the fly, and, therefore, own them, and, subsequently, destroy them itself.
Collection with pointers will borrow these pointers from existing elements somewhere, which were created by somebody else. This mysterious creator should take care of their destruction.
-
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.
Then use the save-game I attached.
Enabled auto-play (ctrl + a).
The Aliens should kill the 3 remaining-soldiers. Once their turn is complete the crash happens.
The place it seems to happen is the vector that should clean itself. It's basically crashing within the depths of the vector's destructor.
-
Is this error stack trace? Are you able to run it from VS in debugger?
-
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.
Here's the complete Call stack:
ucrtbase.dll!_invoke_watson () Unknown
ucrtbase.dll!_invalid_parameter_internal() Unknown
ucrtbase.dll!_invalid_parameter () Unknown
ucrtbase.dll!_invalid_parameter_noinfo_noreturn () Unknown
> [Inline Frame] OpenXcom.exe!std::_Adjust_manually_vector_aligned(void * &) Line 164 C++
[Inline Frame] OpenXcom.exe!std::_Deallocate(void * _Ptr, unsigned __int64 _Bytes) Line 252 C++
[Inline Frame] OpenXcom.exe!std::allocator<OpenXcom::PathfindingNode>::deallocate(OpenXcom::PathfindingNode * const) Line 946 C++
[Inline Frame] OpenXcom.exe!std::vector<OpenXcom::PathfindingNode,std::allocator<OpenXcom::PathfindingNode>>::_Tidy() Line 2045 C++
OpenXcom.exe!std::vector<OpenXcom::PathfindingNode,std::allocator<OpenXcom::PathfindingNode>>::~vector<OpenXcom::PathfindingNode,std::allocator<OpenXcom::PathfindingNode>>() Line 765 C++
OpenXcom.exe!OpenXcom::Pathfinding::~Pathfinding() Line 67 C++
OpenXcom.exe!OpenXcom::SavedBattleGame::~SavedBattleGame() Line 122 C++
OpenXcom.exe!OpenXcom::SavedGame::setBattleGame(OpenXcom::SavedBattleGame * battleGame) Line 1467 C++
OpenXcom.exe!OpenXcom::DebriefingState::init() Line 804 C++
OpenXcom.exe!OpenXcom::Game::run() Line 169 C++
OpenXcom.exe!SDL_main(int argc, char * * argv) Line 127 C++
[External Code]
-
And this is xcom1, right?
-
And I need to match your mod set, of course. The save complains I am missing some.
-
Where do you see stack trace? I don't see it in stderr.txt or in openxcom.log.
-
Yes, xcom1.
The missing mod-set shouldn't really have an impact. It should load anyways.
I see that right in Visual Studio. The logs don't contain info about the crash.
-
@Xilmi
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:
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`).
-
@Xilmi
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:
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.
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.
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.
-
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.
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."
And how this could affect anything? do `PandfindingNode` try delete `_prevNode`? No, it could even work without any destructor.
ChatGPT blindly try guess some thing without no understating of part of this code.
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.
-
Good observations. I thought about the same.
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?
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.
If I knew why BAI makes it break, I'd already have fixed it. There are some massive differences in how BAI uses pathfinding though, so it's not surprising that it has an impact on that.
Notably: I've split findReachable into two methods. The new one being findReachablePathFindingNodes. Old findReachable created all that valuable information for the AI but then only returned a vector of Positions. findReachablePathFindingNodes returns the vector of Nodes and the Nodes have a lot of Information that are useful to AI. For example I can determine the TU cost to reach any tile instantly without another path-finding-call which makes BAI several orders of magnitude more efficient in finding tiles it could go to. VAI just limited itself to a random selection of 111 tiles for that because it ran a separate pathfinding for all of those.
So eventually I didn't just run it for the current unit but also for other units. And not only for the unit's real location but also for hypothetical locations. This is what allows the creation of the move-order, a really well working threat-map and an algorithm that can estimate whether a unit can rely on the fire-support of it's friends.
Since the _nodes get changed by each path-finding-call and I needed them to remain what they are, I created _altNodes, which is for all the calls for other units. The result of that is also buffered in the units itself, so I don't need to call pathfinding for other units that can't have moved anyways.
One idea I had that maybe one of the many calls of findReachablePathFindingNodes that use a hypothetical starting-location gives it an invalid starting-location, which then messes up nodes in a way that causes an issue when trying to delete them. What I haven't done yet is to sift through all the 10,000 _nodes and _altNodes to look at whether something looks fishy there. If I, for example call pathfinding for an invalid position something bad could happen. So yeah, there's definitely enough difference in BAI compared to VAI when it comes to the usage of Pathfinding to warrant causing an issue that never happened with VAI.
I don't think there "usually" is a problem when deleting. Even in BAI this is a rare and hard-to-reproduce case. I just so happened to have a save now where it happens reproducibly. I don't know what about that save is special so it happens there but not in many other scenarios.
-
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.
It sometimes does help to find the real cause. But in other cases it can put you on a wrong path for a long time. I need to be more careful about how I use it.
-
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.
Also it quickly jumped into libraries I didn't have the sources for while trying to debug with break-points.
Basically it gets to:
Pathfinding::~Pathfinding()
{
}
as the last part of "my code" and then disappears into the destructor of vector, where I can no longer see what's going on.
My new theory is that something in the _altNodes is corrupt. Possibly because I dereference a Position-pointer to determine a starting-position. If this pointer is not null but something that is invalid, I don't know what effect that could have. So the next thing I'd like to investigate is whether this could have happened. The logic that checked for adjacent positions to a unit for meeles to see what side had a weakness used to produce out-of-bounds positions. THis was only found by accident, when I had a case where an AI unit did nothing. Turned out it wanted to go to a position outside of the map to attack but obviously couldn't do so. And while that particular issue was fixed, I'm thinking that maybe I'm trying to do a path-finding-call with a similar position like that.
-
I found one attempt to set position (-1, 0, 0). Not sure if this is the culprit but it is definitely a dirty code that scratches my eye.
BattleUnit.h
int _tileLastSpottedForBlindShotByHostile, _tileLastSpottedForBlindShotByNeutral, _tileLastSpottedForBlindShotByPlayer = -1;
AIModule.cpp
std::map<Position, int, PositionComparator> AIModule::getReachableBy(BattleUnit* unit, bool& ranOutOfTUs, bool forceRecalc, bool useMaxTUs)
{
Position startPosition = _save->getTileCoords(unit->getTileLastSpotted(_unit->getFaction()));
With last spottet tile == -1 it sets startPosition to (-1,0,0), which is incorrect, as it does not fit into map tile vector, obviously.
You should treat it as "not spotted" and accurately wrap around it.
-
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.
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()));
-
I tried last version from git and have this crash, now I do not get crash in battle destructor. when I try quit game after it to try again, game crash on `Globe` destructor.
This look like big memory corruption.
[ps]
After changing some mods (last time I had some test mod enabled) game crash on `ctrl-a` and code at `PathfindingNode::connect`.
Probably Alpha is right ablaut cause of this error.
-
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!
Also now everything makes sense!
Why it was happening in terror-missions but not regular ones.
The reason for that is that "friendReachable" is populated before assigning the position-assumptions. I didn't think about that Neutrals are friends to the player and player-units are friends to the neutrals.
So the AI doesn't know their real location and the code that assumes the positions for the enemies is run between filling "friendReachable" and "enemyReachable", so it didn't happen there because the enemy-units didn't have the -1 initial-position anymore.
This also means that using autoplay or brutal AI for neutrals was a condition for it to happen, hence not everyone ran into this issue. Another condition must've been for them to not meet before the mission ends.
So, yeah, simply ignoring the units who we are allied with and don't know their location yet definitely is a sufficient and side-effect-free-solution.
Edit: Okay, I now also tested it and as expected it no longer crashes. What is odd, though is that it impacts how the aliens behave. They seem to move in a different order and do different things. They probably don't have a "TileLastSpotted" for themselves. But in the case it's a unit of the own team it uses the actual tile and not the last-spotted one. So your solution isn't entirely correct yet and I need to slightly modify it.
-
No. I didn't hope it will be correct. This is just an illustration that you should handle -1 value separately and not let it to main processing branch. A lot of IFs everywhere, etc.
I usually rename my variable so the code breaks everywhere it is used. This way I can cover all the usage.
Also, it may be cleaner to hide it under extra layer. Say instead of Position introduce something like OptionalPosition that may either contain valid position or no position. Extra methods: bool hasValue(), Position getValue(). Latter should blow if there is no value. Stuff like this, you know.
-
Coming back to replying to the "normal" kinds of posts here after that horrifying excursion to the memory-corruption-bug.
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.
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. It meant I actually could make use of the medikits.
What also was extremely helpful were the civilians. They were "tanking" a lot of the minotaur-attacks. Most of the minotaurs died early after exposing themselves by attacking civilians. Had the civilians not been and I the target of their attacks I'd have had much higher losses early on, I suppose.
Overall the level of challenge felt good considering me probably not playing very well.
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.
My idea is that the AI should determine the proper approach based on situational in-game-logic. Another important point is decisiveness. So some units hanging back while others try to push and overall it creates a trickling-in-scenario is definitely not the right play.
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:
"Fixed an issue with the spotter-determining-code that caused the spotter to think their friends would always have enough weapon-range."
This probably caused them to nominate one spotter after another thinking other units had it's back when they didn't.
Also: I know you like Ironman but when it comes to producing saves that showcase a buggy behavior, that's not useful as Ironman doesn't make rotating autosaves, which are very helpful to catch buggy behavior. You can turn off Ironman by simply manually editing the save-file. I do that every time with your saves so I can test properly.
Well, the 4 for max aggressiveness is arbitrary number to which everyone got used to. And it was introduced by you.
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.
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'm thinking that situationally recognizing whether to perform this behavior or the current one is probably a better goal than indecisiveness caused by aggession-fluidity. Think about it in a WW1-Trench-war-scenario. You either stay in your trench or you try to storm the enemie's trench. There's no in-between, where you slowly inch-forward towards their trench or some of your side stay in the trench while the others rush forwards.
Yep. I am going to make a submod, so players don't have to do anything.
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.
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.
The formula is pretty much this:
100 / (discoverThreat + walkToDist * myAggressiveness);
discoverThreat is measured in TU. It basically means: "From where I think the enemies are. If I move to that tile, how many combined TUs will the enemies have from where they could spot me.
walkToDist is the distance of the reachable tile that is closest to the enemy + the max-TU of the unit.
As you can see, the more aggressive, the bigger the impact of the distance compared to the discover-threat. If discoverthreat and aggression both are 0 then it will use 100 / walkToDist;
UPD don't take my whining about "AI is too easy" and "AI is too strong" as bipolar disorder.
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.
-
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.
I think this is valid criticism and I think I can change it and/or make it optional.
I could just do the same thing that I did with doors when I still had the AI notice door-opening:
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
"updateEnemyKnowledge" sets this value to 0 when a unit shoots (via reaction-fire) or gets hit (via auto-spot on hit).
Changing it so that in these cases the position is updated but not the "turnsSinceSeen", would mean the unit would no longer be attackable without actually being seen. The AI would first have to confirm the position by walking in on the unit.
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."
So I'd say I'll make it an option and put it under battle-scape and not AI so that whether it's enabled or not it's same for both sides.
-
That would work.
I also don't dislike the idea itself, just how accurate and long-range the spotting is. Several games have had something similar (though I don't know if the AI had access to it, too), like UFO: ET and Silent Storm displaying 'heard' enemies or the alien screams of nuCom.
I don't know how one could make this less precise while not neutering AI decision-making. Some ideas: 1) mark a 3x3 or even larger area, make the AI consider using only HE weapons/grenades/waypoint weapons (edit: that is, spray-waypoint autofire weapons, not Blasterkin /edit) on these. 2) Mark only a random location in that same 3x3, 5x5 or whatever area. 3) My old idea of introducing an additional "no LoS and no spotter' malus, i.e. if a unit (yours or the enemy) doesn't have LoS on their target, their accuracy is multiplied by a fraction, typically 50% (OXCE functionality); if they additionally don't have a 'spotter' (either ruleset or just BAI-enabled unit), multiply the chance by another penalty, like another 50%. So real alien snipers and grenade chuckers can still do this, but not everyone all the time.
-
Hi, Xilmi!
Sorry for late reply, I've seen your message.
Ok, I'll change Ironman, because there are plenty of moments that seem unfair and I anyway have to often reload from backup.
Initially, I switched to Ironman/SH from just SH, because it was kind of enhancing the difficulty in vanilla and I didn't use to reload by in-game months.
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.
Overall the level of challenge felt good considering me probably not playing very well.
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.
Also, that's second team, not the best one.
So, it's doable even vs BAI, but not in my case (actually, I cannot see any player to get optimal on-globe progress with this amount of casualties BAI usually brings)
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:
- overall amount of units * unitpower >= 2,0 or even 3,0. Unitpower is weight-comparison in terms of armor (weight=50; including resistances vs wielded arms, because even 10 armor with resistance 0.2 equals 50 armor in simple approach), weapons (weight = 30; including best possible damage per turn) and combination of TU's (there BAI should assume something, not cheat. I mean, at beginning it should assume that X-COM TU's are ~70, but when few turns pass, it can reconsider these values).
- dense cover before the point of actual approach
- at least some initial shots made actual damage.
- OR melee is seems to be the most reliable way to deal with X-COM (or no other weapons are in stock)
If such adjustment can happen, then it can be more fluid approach.
Also, although it was initial and helpful collab with classic X-COM scenario users, it should be noted that major pf players are megamod users.
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.
You cannot see how personally I wish you and modders take each other hand-in-hand and jump up and down together on a road into a bright future.
- at the same time, players are interested in a strengthened AI, capable of diversified approach to confrontation
- players are interested in the dynamics and quality of the game as such.
- At the same time, the game should not be able to be completed only under the condition of savescuming.
I guess with all this I'm saying in the current moment it would be better to bring back the BAI dumbness level settings until the connection arises, because for now the control over the level of player suffering is solely on you :D
There was cool option of "static intelligence" to adjust weighted-randomization of BAI movement logics, where it rolled from x to 1. Please consider bringing it back in. It should be up to a player. Like, I will set it to 0.6-1.0 most likely, or even 0.4-1.0. :P
The formula is pretty much this:
100 / (discoverThreat + walkToDist * myAggressiveness);
What if myaggressiveness is partially brought by units.RUL (if none, then 1),
while discoverThreat is fluid by means of comparative unitpower (weights: armor = 50, weapon = 30, stats = 20) + unit_excess_over_player? If armor is somewhat better, then more aggressive. But then it can be abused with a craft of 10 no-armor dogs + four power-armor guys. Wait, 3 power-armor guys probably could do nothing against 20 enemies with plasma, right? So... it has all chances to work correctly.
-
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."
I think, the overall decision as concept is good and very intriguing, but the impact on player is too punishing.
I would see it as range-dependent randomization of square (or in-depth rectangle) where famous Bullet-Scanner (a.k.a. BS) can be involved. Then, if target is hit, then the necessary tile is 100% determined.
Also, I would call back Joynarical to do something about grenades so they make landing with range-dependant Gaussian distribution around the target tile.
-
Changelog:
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. The base option of counter-reaction fire was something very new to X-COM mechanics.
Players also use blindfire in some cases. Not as precise as BAI did, but sometimes it helps.
BAI also has no flaring options, which can be used to reveal reaction-fired opponent.
Actually, questions arise now:
- 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?
- etc etc
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.
Okay, okay. You got me. I just really desire it for you to implement BS into the battles :D
-
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.
- 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?
I guess you mean for the case that the spotting from getting shot at is deliberately disabled by the player?
The answer is: It depends. The point of the new mechanic that was added in 8.0.0 is to dynamically determine whether it's worth to try and send in a spotter or not as opposed to the arbitrary behavior created by the aggression-system. By default the aggression-system is disabled but if you use inherit aggression it gets reenabled.
The new system does the reverse logic of determining discoverThreat. It basically does discoverthreat for the enemy units. Currently it uses a 1 for 1 threshold. Basically if at least one unit can use it's full TUs to attack what a spotter would likely reveal, then the spotter is considered. The spotters own TUs are not considered for that. So it has to be another unit that provides the discoverthreat.
So whether the units hide or attack depends on how well the enemy is exposed. If you position your units without cover in a centralized position it's very likely the AI will send in a spotter. But of course also only if that is necessary. As soon as the spotter spots something he returns to its regular behavior, which is the main-difference to the sweep-mode.
In Mods where the player has a massive vision and/or stealth-advantage, it could happen that the AI sacrifices several spotters that all die to reaction-fire. Whether or not the AI shall get some specific logic to better deal with the scenario that tracking of reaction-fire is disabled is a question that the people who'd like to play with that setting should answer. Overall the idea was to make it easier. In a similar vein to not using blind-grenades.
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.
Okay, okay. You got me. I just really desire it for you to implement BS into the battles :D
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.
I, as a player, usually only do it, when I'm relatively certain about the position of an enemy. And that's pretty-much how the AI also works. There's also an engine-thing. 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 that. You'd actually have to aim behind the tile to avoid hitting the ground.
You could use Targeting-Mode 4 and tell yourself it's blindfire. :o
-
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 that
Recently I was thinking of the ghost spawn mechanic. It's quite simple.
Say, there's 3x5 rectangle from which proposed enemy has made out-of-dark reaction shooting. If this area is unreachable via adequate losses, BAI can imagine there is a unit on the tile, and then shoots into it. It is a ghost unit, with whole one purpose - to make a line of shot through this rectangle. The hit mechanism has been already introducted by you, so there's no trouble with actual revealing of units. And then, ASA unit is revealed, BAI switches to original/combined strategy.
Again, this is counter-reaction_fire mechanism, which means X-COM units are static and not moving. Moreover, it is not proposed as a whole turn strategy, possibly 20-25% of available shots can make fair scanning, if area is 3 tiles, and there's 30 enemies vs 10 agents. For guys with low nightvision and a good crowd.
While, as Juku suggested, instant-explosive and incendiary (including plasma, which is good light-setter itself) rounds can aim into some different positions, deeper into the rectangle.
End-turn explosives, like grenades, are already good.
What do you think now?
* on attachment, please read grenadeing as instant-explosive/incendiary targeting tiles
-
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.
I'll add that when they walk into melee range of a tough unit, they might still fire their gun, which makes little sense.
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.
-
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... :P
Well, 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 happen
That was about AI pre-priming mine and carrying it around as grenade for later. Surely, they don't know the difference.
As for intention, yes. Everyone walked into it,eventually
-
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.
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.
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 mindset behind that behavior is that it's better to sacrifice yourself while dealing damage than giving back initiative to the other side that may kill you next turn anyways. Throwing a bomb at short range and then not walking out of the blast-radius usually means they don't have enough time-units to walk out of it again. Which also means that if they hadn't thrown the bomb they most likely couldn't have prevented being killed by you next turn. So taking one of your units with them might still be the best decision.
Also note that the AI will play as if their weapons always have some effect, even if the damage is completely mitigated by the enemies' armor. So if your units are so well armored as to mitigate the AI's attempts to deal damage, a lot of behaviors that otherwise would make sense now look nonsensical as in: "This AI unit nuked itself while trying to damage my tank without success." Yes, this will look stupid but just trying to disengage and hide in these scenarios would be more annoying to play against without increasing difficulty.
Edit: The AI dropping their primed grenades on the ground when they die or get stunned is something that I think I should look at. I think currently they don't register that this also causes a blast-radius of tiles they should rather avoid. So if it happens on their turn due to reaction-fire, they'd still have a chance to avoid the explosion. Definitely something to look into.
-
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.
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.
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?
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 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.
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.
It's XCF with Air Raids/Damage Facilities.
-
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.
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.
Also I noticed from your save that attacking with a Katana requires not only TUs but also energy. So not having plenty of TUs isn't an adequate condition. Actually the AI might be bad with these kinds of attacks as, for example, if alternative movement-methods is enabled, they might decide to run most of the time not thinking about preserving energy for attacks. I even saw a unit get in position to attack, having enough TUs but not enough energy and then being stranded and not attacking at all.
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.
Also, when it comes to 2x2 units, I'm not sure whether my AI is even capable to determine where "behind" is. I wouldn't even know. At least I didn't consider 2x2 units, when I made the logic for attacking from different angles. Just looked at the code. It actually should work.
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.
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.
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.
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?
This seems to be the most plausible explanation here. Especially incase you are using alternate movement-methods, which the AI could have used to run but depleting their energy-pool.
Edit:
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.
-
Wakizashi has 30 Power, so it does no damage to a tank from either direction as the tank has 60 armor.
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.
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.
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:
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.
Hey, don't get me wrong here. I'm happy for all progress with this.
-
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.
Also, vanilla AI seemed to most target weakest armored guy, too.
To conclude, it has had (and still has) at least, some logic
-
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.
-
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 crashes in some code that checks tile-visibility. The positions from where to where it checks were both valid for me when it crashed, so not something similar to the last one. It's also called by an AI-function I call all the time. And in general this should be called a lot. So it's not obvious why it's crashing.
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.
It could very well be another one of these problems that are caused somewhere else and only crash later due to some memory-corruption. :(
-
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.
-
Question: I got a save where, in enemy turn, I answer fire (if survive) with that "Hadriex gun" game crash but not always.
Its a heavily modded game.
[30-01-2024_06-45-54] [FATAL] A fatal error has occurred: invalid vector subscript
[30-01-2024_06-45-54] [FATAL] 0x7fefcd0a460 RaiseException
[30-01-2024_06-45-54] [FATAL] 0x7fefa376690 CxxThrowException
[30-01-2024_06-45-54] [FATAL] 0x7fef795b530 std::_Xout_of_range
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] ??
[30-01-2024_06-45-54] [FATAL] 0x76ad6520 BaseThreadInitThunk
[30-01-2024_06-45-54] [FATAL] 0x76d0c500 RtlUserThreadStart
Again; very modded game, perhaps bug not yours. (X-Files and others mods)
-
Well, crashes during gameplay and not right at the start almost certainly are an issue with the engine and not the mods you use. If the mods somehow create scenarios that otherwise don't happen which then lead to crashes, it would still be the responsibility of the engine to find out about that.
Unfortunately all of the things that could help are replaced by "??".
In order to reproduce it I probably need your mods-folder and your options.cfg.
We could also see if the next version fixes it. I'll likely be removing a rather messy part that is relatively new. Before it's introduction I didn't see issues like that.
-
No big deal, I reload until it work. This mod worth it.
Edit: If you want the save plus the mod list and personal changes I upload all that.
-
There is a way to make stun aliens wait for the next turn (vanilla) once they wake up?
They wake up and shoot or run immediately and capture them is extremely hard and annoying.
-
There is a way to make stun aliens wait for the next turn (vanilla) once they wake up?
They wake up and shoot or run immediately and capture them is extremely hard and annoying.
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.
It would be possible to add this behavior back as an option.
Without code-changes what you can do as a player is to take away their weapon while they are stunned, so they can't pick it up again immediately.
-
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)
-
fac=*(_facilities.end());
This code never can be correct, `end()` is always invalid pointer and you can't deference it.
-
The code is like a year old and totally not mine :-)
https://github.com/Xilmi/OpenXcom/commit/306e12905ad56b743ae6ec3a5c57518f9ef59014#diff-ab5eb291f012da94a1a7a1513fae702f9e60f87002b166f3805d3c72b0e49284
-
Thanks for the report. Yeah, this code is from one of the contributors. Apparently noone has stress-tested it before like this so that bug went under the radar. I'm gonna see if I can fix it this afternoon.
-
I don't get a crash when selling the Skyranger.
-
Are you running the release version? Or debug?
-
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.
-
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
-
I reworked a new BRUTAL icon, I can change the alien face to any other color you desire and the eyes separately if you have a specific request for eye color and face color. In my opinion for the BRUTAL icon a darker face and bright eyes seams more ominous and daunting.
-
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?
I don't know what is intended and I also don't know what is wrong and by what logic it is wrong.
-
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
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.
-
Can you elaborate a little bit more what I'm seeing here?
Okay, let's take a Skyforge Engineer as an example.
https://xpedia.netlify.app/##STR_SKYFORGE_ENGINEER
He has a set of list of items he can come pre equipped with. In this case, it's just a valuable loot, like coins and arc welder, not a weapon. The main wepon and other items generation code is somewhere else.
The problem is that these items replace the weapon he has to hold in his hands. If I load the B1_geoscape.sav in Xpirates without Brutal AI and start the mission, all items will be spawned, and he is holding weapon in his arms.
It looks like items spawned by the Built-in weapon sets are being added to the wrong slots, starting with the hands and overwriting the weapons that should be there.
-
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:
https://openxcom.org/forum/index.php/topic,10967.msg161820.html#msg161820
I interpreted his comment under that one as he'll look into it. If he doesn't I'll look at it myself.
Also: I highly recommend people to report issues as new threats now that we got a new sub-forum, as it makes it much easier to keep track of them and avoid duplicate-reports.
-
@kelltozet:
So apparently mods have additional ways to assign equipment to enemy units that are different from the way it works normally and it messes up their intended equipment when smart-auto-equip is used.
I think I'll limit this feature to the player-faction in order to avoid messing up enemy-equipment.
Or are there also ways that this could negatively impact player-units as well?
I guess the safest way is to disable the Smart Ctrl-Click and Auto-equip-feature when playing mods like that as I don't really see an easy way to fix it otherwise.
-
So apparently mods have additional ways to assign equipment to enemy units that are different from the way it works normally
No, mods just use the standard OXC logic here.
Or are there also ways that this could negatively impact player-units as well?
Yes, in mods this will negatively impact summoned player units (and probably also player HWPs with a secondary weapon).
-
No, mods just use the standard OXC logic here.
If this is the case I guess I have to debug the concrete example.
As far as I understood the code it shouldn't be possible that the weapon gets replaced.
The weapon is placed first and then occupies the slot it was placed in. So the placement of subsequent items should notice that the weapon's slot is blocked and go for the next best kind of empty slot type.
I also haven't seen or heard of this effect before, so that's why I thought this mod is doing something unusual that I'm not aware of.
-
Or are there also ways that this could negatively impact player-units as well?
For the player-units, the effect is minor.
Some of the player's armor also has built-in items generated at the start of the mission.
Example https://xpedia.netlify.app/##STR_DAMSEL_ARMOR_FURS_UC
The items are not overwritten, but simply moved to the general inventory. This is normal behavior, just the order of slots in which things are added is different.
The "Wierd thingie" here is speshial item - glamour. It is kind of resource from a Xpiratez. With normal behavior, it should not be visible in the inventory. If you manually move it from the units's hands to another slot, it will disappear, but it will be in the loot list at the end of the mission. If glamour was generated not in hands, everything would work as it should.
-
If this is the case I guess I have to debug the concrete example.
From commit message:
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.
Bug 1: This is not true, your option will simply overwrite it. In worst case, it could even mark a placed item as unplaced and some nasty side effects.
if you want this to work, you need to consider the "placed" flag:
instead of:
if (Options::oxceSmartCtrlEquip)
it should be:
if (!placed && Options::oxceSmartCtrlEquip)
Bug 2: you are now ignoring weight constraints, poor soldiers get overburdened all the time, see screenshot
Bug 3: you're spamming the log
[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.
I think you're right about all you said.
-
@Xilmi:
Thanks for such a quick bug fix.
Can I make a couple of suggestions?
The AI is too passive in 8.x.x version for Xpiratez mod.
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.
In my opinion, in version 7.13, when enemies thought they were stronger and attacked, it was almost the perfect AI behavior for the Xpiratez mod.
Maybe a little too aggressive, but only a little.
Now, if I put my squad under AI control, then both sides will not clash in battle at all (1.png).
Every turn, units on both sides look out and then hide back.
I understand that in this example there is an almost bare field with two crafts.
But still, I would like the battle to begin.
Is it possible to return scale of aggressiveness from power-balance as an option in the settings?
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?
-
The AI is too passive in 8.x.x version for Xpiratez mod.
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.
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?
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?
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?
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.
There used to be 2 modes that forced the AI to do something dumb. One of them was to forbid picking any target-tile that is same or further away from a supposed enemy than they started on and one that forced them to get as close as possible.
All the other experiements I did where essentially different weighs between safety and getting closer. But all these in-between-modes were essentially worse than the extremes.
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.
Another thing I'd like to look into is mission-type-specific behavior. There are mission-types the player can win without having to kill any enemies. In the base game that's Alien Base, Cydonia 1 and Cydonia 2.
In these kinds of missions it would also make sense to force the AI to be more aggressive. So I'd have to look at identifying those.
-
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.
But is it always fun for the player to play on the offensive side? Well, for some people, it might be. But personally, I like a more balanced approach.
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.
Maybe the effect of the aggression parameter should be bigger.
Another problem is that the enemy does not use numerical superiority when acting defensively.
Here is my current mission in the screenshots (1.png 2.png).
My squad is made up of 9 good quality fighters
The enemy has about 8 dogs, 25 low tier infantrymen and 2 machine-gun armored cars.
On my first turn, I take out a couple of guys in the open field.
Then the enemy takes up positions in the houses.
I'm just storming through houses 1, 2, and 3. Meanwhile, all the other enemies are sitting in their homes and not fighting.
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.
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?
It's doubtful if it's possible to balance all the mods. And the more customization you can get for a specific mod or even mission, the better.
-
Xilmi,
For BRUTAL 8.2.4 I'm assuming you'll be updating to the latest release of OXCE also? I see Meridian just merged in a change that should properly show 3x3 base facilities in the ufopedia UI.
https://openxcom.org/forum/index.php/topic,11819.msg161988.html#msg161988
I just posted a Facility Pack mod that has a 3x3 facility but relies on BRUTAL due to the current need for the different hangars type properties not in OXCE yet.
No rush, but look forward to seeing that update included in BRUTAL-AI or BOXCE or however it's going to be referred to :)
-
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.
So I guess I'll do that this afternoon.
-
I'm just storming through houses 1, 2, and 3. Meanwhile, all the other enemies are sitting in their homes and not fighting.
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.
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.
Ideally I want the AI to identify the best approach based on the actual situation instead of once again going the route with having dozens of ways to configure it.
The spotter-picking-logic was kinda supposed to take care of that but the issue is that only enemies who can get a line of fire will participate in the assault.
Another way to think about it is: If some units already are or likely will get involved in a fight anyways, other units should not just sit back in their save-locations and instead move towards helping their friends.
The current behavior makes a lot of sense from each individual unit's point of view but they are not really playing like a team as using squad-sight is more or less the only thing they do in terms of teamwork.
I think that this is something I can experiment with in the future.
-
It's tough. In some scenarios the previously described behavior made it tougher but in many others it is a massive regression.
Edit: However, this kind of behavior is now available as an option, once again.
-
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).
-
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. Note that I wasn't able to reproduce the crash when selling the Skyranger.
Edit: Can you attach your options.cfg? It might be related to a specific set of options. I think I have a good idea which one it could be: The alternative equipment-management option probably. Are you using that one?
-
Is it reproducible? If so, I should be able to reproduce it too quite easily.
It is probably not easily reproducible.
As Yankes said earlier, this code is 100% wrong by definition, and results in an undefined behavior.
Basically, you get some garbage and depending on what kind of garbage you get, equally garbage things will happen... sometimes crash, sometime corruption, sometimes nothing, sometimes something else.
Quote from: https://en.cppreference.com/w/cpp/container/vector/end
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.
-
Just tested it a bit more - it looks like I am only able to repro this when running the debug mode (basically F5 debugging in VS2022). It does not repro in Release mode when I start the game "normally". Possibly the Release compilation in some way "optimizes" this incorrect code and does not let it crash? Since it does not repro in release, the direct impact is basically none, i assume (and that's probably why there are no other reports of this).
My repro is very easy:
1. F5 the game in Debug mode in VS2022 (7.11.4. 8.2.1)
2. Start a vanilla game
3. Sell a craft -> Crash
Or
3a. Lose the last soldier in a mission -> Crash (due to losing the Skyranger)
-
Debug deliberately crash on code like this, in Release all checks are removed (as cost a lot) and code can access invalid memory.
Why code "work"? as most cases there still vector memory here, and in many cases after removing elements it could have garbage that have valid value.
And this case `*(end() -1)` and `*end()` have same value as `*end()` point to memory that have previous "high mark" of data that vector stored before removing element from it.
-
...
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;".
Admittedly I didn't look at the code from the pull-requests I got when it seemed to be working.
-
Debug deliberately crash on code like this, in Release all checks are removed (as cost a lot) and code can access invalid memory.
Totally makes sense - have not worked much with C++ compilers but kind of expected a behaviour like this one.
However, even if Release does not check for this (and thus does not immediately crash/assert), it is a kind of bug that should be fixed I think - otherwise we risk a random crash in some other part of the code that would be crazy difficult to debug.
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;".
Yep - this seems to be the right way to implement it:
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;
}
It immediately resolved my problem - I guess it would make sense to integrate it into BOXCE.
Thanks for the great brainstorming guys! Cheers :-)
-
btw even if `fac=*(_facilities.end());` do not crash this is incorrect when you use "foreach" loop, even more it could break logic as it override vector data by other.
If you used classic loop this would look like `*it = *(_facilities.end() - 1);` and it would copy data and not break loop.
For nested loops there is another trick (aside of `goto`) to exit them, `return` and lambda functions:
(
[&]
{
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
}
}
}
}
)();
-
Totally makes sense - I also agree that this is fully incorrect - that's exactly why the debugger would assert here to warn us about it. So I guess it was a bit lucky that I came across it (and that I actually play/test the game in Debug mode).
For nested loops there is another trick (aside of `goto`) to exit them, `return` and lambda functions:
Wow - really cool - I was not aware that you can return this way.... This is like self executing anonymous function, right?
Anyway, personally I am a fan of easy solutions, so my recommendation would be what Xilmi suggested (and I implemented as a test). The code with lambda function is probably more beautiful but in a year from now I would not remember how it works anymore :-).
But hey - this was never my code (I just was lucky to step into the problem) so I will let you decide how (whether?) you want to fix it.
Cheers!
-
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.
-
A really cool concept indeed :-). Still - to me there is a high risk of creating write-only code this way, i.e. in 2 years nobody will know anymore what was meant by this pattern :-P.
I am more of a fan of good-ol' if style logic - not so pretty but still totally obvious 10 years later :-D
-
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.
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 !
-
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.
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!
In 8.3.0 I reintroduced Aggression-settings. I think the option is called "Aggression-mode for Brutal-AI" in "Options=>Advanced=>BOXCE=>AI" Those alter the behavior of the AI quite fundamentally.
0 is the default. This is the smartest setting but it also can be tedious to play against.
2 makes units be a lot less smart about being in cover by only considering the current situation and not thinking one move ahead anymore. This should prevent most of the hard-core-camping.
3 just makes them all rush to where they think you are or search your units aggressively when they don't know. So the units will never camp here. This could arguably make some missions even harder. Especially if you fight huge amounts of trashy units.
1 makes the behavior depend on the unit's aggression-setting. So it depends on the mod how they will behave. Note that a unit aggression of both 1 and 2 will lead to the same behavior as previously described under 2 for the overall-setting. And everything above 3 will also behave like "3".
My Idea was for the AI to be able to shift between these behaviors on their own according to the situation. The problem was to identify the right metric to switch. I know there are scenarios where behavior "2" is better than "0" but there's also many where it's worse. "0" is always kinda solid. Even when it's not optimal. That's why it's the default.
-
Thanks for the feedback!
You are welcome and thanks for your work ! AI is often neglected in games and the one you created feels alive and dynamic. I'm sure there are ways to exploit it but for a normal player like me it just feels great.
Earlier today I had a group of three EXALT charges me gun blazing simulteanously after shooting from cover and destroyed my guys that tried to charge the building. It was awesome.
I will try the Agression 1 setting and removing omniscience and see the results.
I actually think the last guy camping in a room could be solved by enforcing more the surrender rules. Sometime the last guy surrends and it's great but often time it never happens. 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.
Thanks for your answer !
-
Sorry for the double post but I came across a weird comportment from the AI.
In two instances I was fighting about zombies and they actively ran away from me.
In one battle one Fat Zombie just ran away for ever until i caught up with him and in another every zombies I came across ran away and then turned back to attack my guys.
Is this supposed to be normal ? It did not feel very zombie-like.
I tried with Agression 0 and 1 and I did not see any difference.
edit : I just had a Zombie Infestation. Every zombie immediately ran away toward the edge of the map despite my guys shooting at them. They even ignored civilians standing around. The worst offenders are the Zombies in white shirt. They never turn back to fight and keep running toward the edge until killed.
You can see on the screenshot below, the zombies hid here for the whole battle, and if they sensed an agent nearny the would attack him and go back into their little hiding place. When attacked from above they just stood there getting shot at.
It actually kind of worked for them but it really did not feel like fighting zombies. I fought a spider swarn just earlier that behaved much more like zombies actually.
-
Let me describe how exactly the AI works and explain why this causes some units to behave in a non-immerserive manner.
Firstly: The AI doesn't know that a player has different expectations about a Zombie than any other unit, so the zombie runs through the same logic as other units do. But it's essentially the combination of low movmement-speed and only being able to attack in melee-range that makes it look unfitting.
Units first check whether they know the position of an enemy. If they do, they check whether they can attack the enemy. If they can, they will do so.
If they can't, they will look for the safest cover. If several positions are considered perfectly safe, they will favor the one that is closer to the enemy. Only if no good cover can be found at all, they will move towards the enemy.
Now if they don't know the exact location of an enemy, they will look for enemies. If they can they first check where they think enemies could still be from previous round. If not, they will just check places they haven't seen this turn. I'm currently experimenting with being more careful during this checking as it seems a big weakness when they are having worse vision than the player.
If they can't find an enemy they will go back to the cover-finding-part.
The zombies, even if they know where your units are, will rarely be able to attack on the same turn. Thus they will prefer to hide in hard to reach corners and hope you come close enough to them so they can strike.
Aggression 1-2 changes the behavior of cover-seeking. Instead of prefering the best cover, they prefer the closest position that is still covered. Knowing full well that it's very likely to be spotted and shot on the enemies' turn.
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. Quite Suicidal but if the numbers are high enough it can work to overwhelm the enemy.
-
Let me describe how exactly the AI works and explain why this causes some units to behave in a non-immerserive manner.
Interesting, thanks for your explanation.
Would it be possible then to adapt those Agression settings according to each unit type ? It would be great for immersion purposes to have differents ennemy having wildly different comportments.
Zombies : Agression 3, just running at you blindly
Counter-Terror Force : Agression 0, making being overly cautious with cover
I guess thats more something for the modder to do (setting each unit individual tags) but, as far as you know, is it possible to have different unit have differents AI, sometimes even in the same battle ?
-
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.
-
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.
-
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.
Oh thanks ! 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...
I will check if changing these value and sticking with Agression setting 1 work, for now i'm setting Agression 2 when facing zombies.
By the way, on mod.io we can read this about the mod :
"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.
I read this as "1 and 2 are the same for units without the Leeroy Flag, only Leeroy-Flagged units will act crazy" but in your answer few posts earlier you say ;
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.
Wich seem to imply that Agression 3 (or 2 there is only 0, 1, 2) affect every single unit regardless of flag.
Which is true then ?
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 I have this option checked, and It works sometimes but not always. Must depends on ennemy moral.
-
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.
There is also bug-hunt mode, which is also in XCF by default. Usually the mission is long over before it kicks in, though.
-
@bluth:
The information on the mod-description is unfortunately outdated. I should update it, for sure.
Refer to what the option is described as in-game. This should be the expected behavior.
-
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.
Ok thanks, I will just continue to switch Agression 2 on Zombies mission and it's perfectly fine.
Yeah Bug Hunt kicks in when the only guy left standing is slow and melee equiped. He realise he has no chance and stay in hiding. Quite smartly actually.
By the way, I also realized why there was some confusion about Agression level. I was using an outdated version of Brutal AI... Now it makes much more sens why you were speaking about Agression 3 and such. Sorry I'm dumb. Maybe those weird things I was seeing will disapear now !
Anyway, I changed some settings, tweak some files and I am now having an absolute blast playing XCF with Brutal AI. Thanks everyone !
-
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.
Yea, I was also thinking about this and wish that the grenade throwing distance was Nerfed. THey should not be allowed to throw complete across the map. Something more realistic is needed.
Example solution: Max Grenade Throw Distance (MGTD) = ( (2 * Strength / 10) + (Throwing / 15) ) ; round down to nearest integer for each calculation.
Soldier has: Str = 60, Thr = 75, then MGTD = 12 + 5 = 17 Tiles
Solider has: Str =45, Thr = 50, then MGTD = 9 + 3 = 12 Tiles
etc...
Accurace logic remains the same, this would only affect max throw distance for each soldier, this would also affect ALL NPCs, enemies and firendly NPCs.
-
Is there a problem with v8.32 as it won't start-see attached.
-
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.
-
Is there a problem with v8.32 as it won't start-see attached.
I have no problems running the current BAI v8.3.2. Have your tried running a clean game with no mods? Did a previous version work and now this one doesn't? More details would be helpful.
Also I see you are running from a MS one-drive, not sure how that works for remote files and data syncing, but it would be a good test to try to run the files from a local file location. What OS are you running? Windows? 10, 11? Have you updated the GPU drivers nVIdia or AMD, or are you running Intel CPU/GPU and ahve you installed the Intel GPU drivers? Sometime generic default MS OS installed drivers have issues and you'd need to install dedicated GPU drivers.
From the looks you are getting a zip file load error? Specifically, the crash log you've shared indicates an issue with mapping common.zip twice, which looks like the game doesn't handle.
Recommend steps to try and resolve (Again I think the biggest two possible issues I see are the following):
0.) Check and see if you have the file `common.zip` in the game directory, do not setup the game with this file, rather use the default release format with a 'common' directory.
1.) Make sure you have a clean game install with no extras
-- Verify that some mod or custom setting isn't causing the problem.
2.) Verify that a previous version of the game works with the original DOS X-Com content
-- If a previous version doesn't work then it's not a specific problem you are having for BAI v8.3.2
3.) Run it from a local file location, not on a remote share
-- Sometimes during a data sync files get read twice
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.
-
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.
Good point, I didn't consider an alternate version of the source DOS files from a steam license... I still have my OG DOS files from the 1990s :)
-
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)
-
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)
Got it, thanks, removed the references to the no longer version (OXCE+)
After looking at the files OXCE is like 26MB with I'm guessing all the *.dll files combined into the main exe, vs BAI that has all the *.dll as seperate files in the root of the game dir.
And I do see I do not have a common.zip file anywhere.
-
I suggest not calling the DLLs common data files.
Common data files are the files in the "common" directory.
-
A propose "common".
Could it be that the issue is that the user has both a "common.zip" and a "common" folder?
-
In such case OXCE loads one and ignores the other.
-
Don't know exactly why but a fresh install cleared the problem, v8.32 working now, thanks for the help.
-
Is there any way to take this mod as a base, but disable all the main mod features?
I'll definitely try out the new ai, but for now I only want automated combat
-
Is there any way to take this mod as a base, but disable all the main mod features?
I'll definitely try out the new ai, but for now I only want automated combat
Yes, all features can be separately disabled. You can disable the brutal AI and enable auto-combat if you want.
-
This may not be the correct place to ask, but I'm curious to know if you have any interest in a stealth line of sight button? I find it really difficult to use stealth armors in the mods that include them because I don't have a clear idea how my character's visibility is being affected. It's especially noticeable in mods where enemy line of sight is extended, like XCF. Does it sound possible to use the same color-grading function to mark out where my character is visible/invisible?
-
What does CTRL button do when aiming at units? It shows some percentage value different from chance to hit, is it cover or something?
Edit: found my answer in https://openxcom.org/forum/index.php?topic=11928.0 TL;DR yes it is. ;D
-
What does CTRL button do when aiming at units? It shows some percentage value different from chance to hit, is it cover or something?
Edit: found my answer in https://openxcom.org/forum/index.php?topic=11928.0 TL;DR yes it is. ;D
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.
-
"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.
how to configure these two options to get maximum complexity and realism?
-
Purely technical complexity: 2-1-1.
Actual in-game complexity of player/computer decisions: likely depends on the map and other factors.
Realism: impossible to tell without knowing what you consider 'realistic'. Especially considering you're the guy with DOSBox speedup addiction and certain other strange ideas.
-
Realism: impossible to tell without knowing what you consider 'realistic'
maphack by aliens - is not a realism (Targeting behaviour 4 + Bug hunt)
leeroy too, maybe
Purely technical complexity: 2-1-1.
what means 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)
leeroy too, maybe
The aliens can mind scan you. Realism! ;D
More seriously, this doesn't really narrow it down much. Do you see the enemy defeating you with optimal play as 'realistic', or do you want them to have 'realistic' weaknesses in tactical decisionmaking?
-
how to configure these two options to get maximum complexity and realism?
The options you cited are outdated.
Which probably means I haven't updated the description since I last changed them.
-
are these options the most brutal?
-
are these options the most brutal?
No.
Realistic accuracy imho helps the player more than the Aliens. (but overall low impact)
Brutal AI for neutral forces can also help the player as it makes civilians pick up and use weapons. (but overall low impact)
Aggressiveness-mode should be 0 for smartest behavior but depending on the mission-type 0 can make it easier (notably if you don't have to kill all aliens and just have to reach a location or destroy an objective).
Intelligence-mode should also be 0 for smartest behavior. But it's impact is lower than aggressiveness-mode. It adds some randomization to the behavior which can make the AI less predictable but by the means of having them make sub-optimal moves.
However, the biggest impact comes from the following two:
Enabling bug hunt Mode for Brutal AI should make it quite a bit harder. The aliens no longer have to peek and search for you or will accidentally get caught by you flanking them. They always know where your units are which allows them to prepare much better ambushes.
The second big one is:
Targeting behavior for Brutal AI. On setting "4" the AI basically gets infinite mind-vision when it comes to targeting. So smoke doesn't help you anymore and they can also snipe you across the map without a spotter.
So with these two it would be way more brutal but by the means of being very unfair by giving the AI abilities you don't have.
-
bug hunt Mode
Targeting behavior 4
maphack = cheat
----
with the same success you can add 100% all weapons accuracy (to all aliens only) and write that this is a smart Brutal engine
and add 500 hp and 200 TU (for aliens only)
---
for special "pro-people", you can turn on this mode: "Targeting behavior 4" + "Terrain destructibility 5" and see what happens on your first pro-mission
-
Sure it's a cheat. That's why it's disabled by default.
Earlier versions did have bug-hunt as default though because it was a lot of effort to teach the AI to play well without it.
I had to give them a memory of where and when they had last seen/noticed enemies and a way to take a guess where the enemy could have gone when it's confirmed not to be where it was believed to be.
-
That's why it's disabled by default.
it seems default BAI settings are most brutal