First, great work! It's good to see more forks! Looking forward if it would be merged into OXCE or would have a separate release loop.I'm no longer actively pursuing OXCE-integration. If they want to have it, they can feel free to include it though. And that goes for everyone who wants it in their fork.
Second, could you pls describe `aiTargetMode` more?
For mode 3: I guess units also should remember what exactly unit was there, and if they see this unit in another spot, they should understand, that it's remembered spot should be cleared, as it's clear that now unit has a different location.Yes, of course. That's what happens. The location where it was last seen is stored to the battleUnit itself. And when it gets seen somewhere else it's location will be updated to the new location.
[31-12-2022_20-48-53] [INFO] OpenXcom Version: Extended 7.8.4 + Brutal AI 2.1.1 (v2022-12-27)
[31-12-2022_20-48-53] [INFO] Platform: Windows 32 bit
[31-12-2022_20-48-53] [INFO] Data folder is:
[31-12-2022_20-48-53] [INFO] Data search is:
[31-12-2022_20-48-53] [INFO] - C:/Users/N7Kopper/Documents/OpenXcom/
[31-12-2022_20-48-53] [INFO] - D:/Program Files/OpenXCom/
[31-12-2022_20-48-53] [INFO] User folder is: D:/Program Files/OpenXCom/user/
[31-12-2022_20-48-53] [INFO] Config folder is: D:/Program Files/OpenXCom/brutalaiconfig/
[31-12-2022_20-48-53] [INFO] Options loaded successfully.
[31-12-2022_20-48-53] [INFO] SDL initialized successfully.
[31-12-2022_20-48-54] [INFO] SDL_mixer initialized successfully.
[31-12-2022_20-48-54] [INFO] Attempted locale:
[31-12-2022_20-48-54] [INFO] Detected locale:
[31-12-2022_20-48-54] [INFO] Attempting to set display to 1920x1081x32...
[31-12-2022_20-48-59] [INFO] Display set to 1920x1081x32.
[31-12-2022_20-48-59] [INFO] Loading data...
[31-12-2022_20-48-59] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:159: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-48-59] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:173: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-48-59] [INFO] Scanning standard mods in ''...
[31-12-2022_20-48-59] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:181: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-48-59] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:191: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-48-59] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:195: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-48-59] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:237: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-48-59] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:242: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-48-59] [INFO] Scanning user mods in 'D:/Program Files/OpenXCom/user/'...
[31-12-2022_20-49-06] [WARN] Error in version number in mod 'XCF-CyrNames': unexpected symbol
[31-12-2022_20-49-08] [WARN] Error in version number in mod '40k_ROSIGMA_edits': unexpected symbol
[31-12-2022_20-49-11] [INFO] Active mods:
[31-12-2022_20-49-11] [INFO] - xcom1 v1.0
[31-12-2022_20-49-11] [INFO] - Alien Melee v1.0
[31-12-2022_20-49-11] [INFO] - alieninventory v1.0
[31-12-2022_20-49-11] [INFO] - Aliens_Pick_Up_Weapons v1.0
[31-12-2022_20-49-11] [INFO] - Better_Ingame_UI v1.0
[31-12-2022_20-49-11] [INFO] - BasicArmourPediaUFO v1.0
[31-12-2022_20-49-11] [INFO] - diversity v1.3
[31-12-2022_20-49-11] [INFO] - improvedhandobjs v1.2
[31-12-2022_20-49-11] [INFO] - Kneel_Indicator_Cursor v1.0
[31-12-2022_20-49-11] [INFO] - Limit_Craft_Item_Capacities v1.0
[31-12-2022_20-49-11] [INFO] - missilesounds v1.0
[31-12-2022_20-49-11] [INFO] - moar-zero v1.0
[31-12-2022_20-49-11] [INFO] - power-suit-helm-off v1.1
[31-12-2022_20-49-11] [INFO] - PS1 UFO Videos v1.1
[31-12-2022_20-49-11] [INFO] - PS1 Music v1.1
[31-12-2022_20-49-11] [INFO] - PS1 SFX v1.0
[31-12-2022_20-49-11] [INFO] - sanicskyranger v1.3b
[31-12-2022_20-49-11] [INFO] - selfheal v1.1
[31-12-2022_20-49-11] [INFO] - TFTD_Damage v1.0
[31-12-2022_20-49-11] [INFO] - UFOextender_Gun_Melee v1.0
[31-12-2022_20-49-11] [INFO] - X-Com Demo Mission v1.0
[31-12-2022_20-49-11] [INFO] - xcom2012death v1.1
[31-12-2022_20-49-11] [INFO] - commendations v3.2
[31-12-2022_20-49-11] [INFO] - nocheat v1.0
[31-12-2022_20-49-11] [INFO] - Alien Reproduction v1.0
[31-12-2022_20-49-11] [INFO] - Text Revision v0.8
[31-12-2022_20-49-11] [INFO] - extra_explosions v1.0
[31-12-2022_20-49-11] [INFO] - Mission Codenames v1.0
[31-12-2022_20-49-11] [INFO] - daynightUI v1.0
[31-12-2022_20-49-13] [INFO] Loading begins...
[31-12-2022_20-49-13] [INFO] Pre-loading rulesets...
[31-12-2022_20-49-13] [INFO] Loading vanilla resources...
[31-12-2022_20-49-15] [INFO] Loading rulesets...
[31-12-2022_20-49-17] [INFO] Loading rulesets done.
[31-12-2022_20-49-17] [INFO] Loading fonts... Font.dat
[31-12-2022_20-49-19] [INFO] Lazy loading: 1
[31-12-2022_20-49-20] [INFO] Loading custom palettes from ruleset...
[31-12-2022_20-49-20] [INFO] Making palette backups...
[31-12-2022_20-49-20] [INFO] After load.
[31-12-2022_20-49-20] [INFO] Loading ended.
[31-12-2022_20-49-20] [INFO] Data loaded successfully.
[31-12-2022_20-49-20] [INFO] Loading language...
[31-12-2022_20-49-20] [INFO] Language loaded successfully.
[31-12-2022_20-49-20] [INFO] OpenXcom started successfully!
[31-12-2022_20-49-20] [WARN] C:\Users\ailst\OneDrive\Dokumente\OpenXcomGit\OpenXcom\src\Engine\OpenGL.cpp:388: glGetError() complaint: GL_INVALID_OPERATION
[31-12-2022_20-49-21] [INFO] Playing flx, 320x200, 3330 frames
[31-12-2022_20-49-23] [INFO] SDL_mixer initialized successfully.
[31-12-2022_20-49-24] [INFO] Update check status: 7; newVersion: v7.8;
[31-12-2022_20-49-45] [INFO] Attempting to set display to 1920x1081x32...
[31-12-2022_20-49-45] [INFO] Display set to 1920x1081x32.
[31-12-2022_20-50-01] [INFO] Attempting to set display to 1920x1081x32...
[31-12-2022_20-50-01] [INFO] Display set to 1920x1081x32.EDIT: I believe I've found the issue! The Enhanced Dogfighting AI really doesn't like when you have an empty weapon slot on your craft.Thank you for this bug-report! This is extremely helpful. I'll fix it right away. :)
The missions was pretty weird. There was ~17 enemies in total but only 2 were actually active and dangerous. The guy with a sniper rifle and the mindcontroller (maybe that's one guy). Everyone else was either doing nothing or doing not enough and was craft camped by me (by moving out of the craft, shooting and going back).Hi and thanks for the report! I think the most helpful thing you could do would be providing an autosave or something from that mission so I can analyze the weird behaviour.
So providing a save-game or telling me what kinds of enemies that was so I can recreate the test myself in the battle-simulator would be most helpful to better support any units that don't fit in the standard-behaviour.Turns out that I do have two saves, at the start of the mission and at the end. I'll attach both of them.
If there is anything else that I can do for you - let me know.Well, I can't load neither of your saves despite reinstalling 40k + Rosigma.
It first says that I'm lacking some mod that the save was created with and then crashes while writing:
[ERROR] Failed to load soldier STR_NEOPHYTE
Okay, I'll try it again with the sub-mod this evening to see whether the intervention I made yesterday helps in this case or if it is something else.Actually, it seems that you've already figured out the source of the problem. Maybe there is no need waste time to test these exact saves. I played more and a lot of other missions had the same problem with enemies behaving weirdly, so those exact saves are not unique. It's, as you said, probably a 40k/ROSIGMA thing. I already saw quite some talks about the big view distance causing problems.
I already saw quite some talks about the big view distance causing problems.Don't worry. None of these are problems that can't be taken care of. Making the AI capable of dealing with other rule-sets sounds much more sustainable than forcing the mod-makers to adjust their rule-sets to be more suitable to the AI. Higher vision-range and accuracy-dropoff are not unique to 40k, so the interventions will be helpful for all the mods that use them.
Let me know you want me to relay any information relating 40k/ROSIGMA rulesets to their respective devs.
Sorry to be the bearer of bad news, but I found another crashing bug in UFO: the Brutal AI breaks entirely on the enemy turn if you mind control any enemies. (Checking civilians is likely also a good idea if they can use Brutal AI, because I believe they use the same AI packages, but allied with X-Com rather than opposing?) - having X-Com guys get mind controlled works just fine, however. They still act as if smoke grenades are deadly projectiles, but that's not a crashing bug, just vanilla stupidity. This bug existed in the version I reported the first crash on, and also on the latest build.Interaction with mind-control of the player really is one of the least tested things. I have tested it and made some changes to the behaviour. Didn't experience any crashes myself. What I changed was making them ignore their own mind-controlled units and becoming more aggressive. I'll try again and see if I can reproduce it. A save-game would be helpful though. I hope you play self-imposed Iron-Man and not with the in-game-option, as that's very risky in terms of any bug potentially breaking the entire run and not being able to provide save-games that could help fix the bugs.
Unfortunately, in testing this I was shot at by a Muton hiding in a building that I had no idea was there when I turned off the Brutal AI. F for the purity of my Ironman run I suppose. I'm raiding a landed Alien Infiltration Battleship if that makes a difference.
As a side note, allowing the aliens to mind control their own guys to cure your mind control (like what you can do) would be a fun idea...
I initially found out about your work because one of the people in that discord server created a submod that halves the number of enemies in 40k/R, because otherwise it's too hard and enemy turns take too long.Joined their discord and while searching saw there's been a lot of talk about it. More than on the official OXC-discord. They discussed issues about it and made suggestions of what it could do better... all in my absence.
the Brutal AI breaks entirely on the enemy turn if you mind control any enemiesI managed to reproduce it!
I am getting a poor frame rate with this mod on xcom files while normally I have no issues with anything openxcom and my desktop is the opposite of a toaster performance wise.Theorethically this should only impact turn times of when the AI is moving. I wouldn't know how this should be causing frame-rate-issues.
I ran this once and all OpenGL shaders began crashing the game for all OXCE installations. A restart fixed this, and I already couldn't change shaders in-game without a crash (changing them in the .cfg worked before, but not this time), so it's not quite all or likely even most Xilmi's fault. But it's an additional hurdle that makes me hesitant to continue.I honestly have no idea what and why people have these odd issues with the game. Segmentation-faults or endless-loops within AI-code is something that I'd feel responsible about. But OpenGL-shaders? I haven't touched any of this stuff at all.
The aliens also weren't very hot against dogs in semi-decent cover. Wonder if it was the UFOExtender accuracy that made them shoot and miss most of the time? Although the whole thing was part of a strange challenge mission, so maybe not really representative.Which version was that? I've recently added better support for "UFOExtender accuracy" as that's default in the WH40k mod. With versions prior to 2.3.0 the enemies wouldn't know to come closer when they already can see the target. They'd then either not attack at all or take shots as soon as the hit chance was > 0.
But OpenGL-shaders? I haven't touched any of this stuff at all.Well, as I said I already had a minor version of the same problem before, and Meridian was just as much in the dark about that as you are.
Which version was that? I've recently added better support for "UFOExtender accuracy" as that's default in the WH40k mod. With versions prior to 2.3.0 the enemies wouldn't know to come closer when they already can see the target.2.2.4. If they know to come closer now, that's a lot better. Most big mods use UFOExtender accuracy these days, I think.
They'd then either not attack at all or take shots as soon as the hit chance was > 0.On (almost) flat terrain, that's actually not a bad tactic since 'hit chance' is significantly lower than actual chance to hit in that case.
If it was with the recent version, then I'd like to have a test-savegame (with mentions of the mods in use) and a description of how the proper behaviour would look like.It wasn't. But in case you're interested in trying to make this mission harder...
mods:
- "x-com-files ver: 2.7"
- "dark-geoscape ver: 1.0"
- "xcomfiles-hyper-and-trajectory ver: 1.0.1"
- "x-com-resound ver: 2.30"
- "Katomusic ver: 1.0"
2.2.4. If they know to come closer now, that's a lot better.There were also issues with units just walking back and forth and clumping up when omniscience wasn't used. Overall the behavior in 2.3 is way better and way more decisive in scenarios as the one described.
On (almost) flat terrain, that's actually not a bad tactic since 'hit chance' is significantly lower than actual chance to hit in that case.Then this isn't something I got to test much with Rosigma. The test-saves that were attached for that usually featured mostly open terrain. So testing other scenarios is still something that could be helpful.
It wasn't. But in case you're interested in trying to make this mission harder...
When I tried with 2.2.4, there seemed to be at least a 10% chance for the aliens to miss with every single shot on their turn.The chance to hit or miss is something that the AI has no real control over. What they have control over is whether they take a shot at what range and try actively to come closer. So basically how they deal with the situation. Whether there's still some things to improve about that is something that testing shall show.
I've seen two saves in the vicinity of the attached save-game but from the conversation around them I'm not convinced they are about the scenario discussed here. Discussion seemed more about ninja assassins and throwing knifes and not so much about sectoids and dogs.The discussion was about a lot of other things, yeah. :-[ But there are a bunch of sequential saves in challenge2_completed.zip, which was about the tangent about a bunch of dogs savescumming themselves through a Sectoid Battleship. I imagine turn 3.5 might be the most relevant.
Those were also mentioned but not in the posts containing saves. So I'd appreciate if you could make sure to provide a save of exactly the scenario you'd like me to look at.
What do you mean by COC-shenanigans? Could you un-abbreviate that?The Close Quarters Combat mechanic of knocking a gun off its firing line when there are enemies adjacent to the shooter. Which in XCF only costs a little bit of energy on the part of the 'knocker'. The dogs made good use of that, swarming over Sectoids like they were carrying dog biscuits instead of plasma clips.
The chance to hit or miss is something that the AI has no real control over. What they have control over is whether they take a shot at what range and try actively to come closer.Yeah, but the issue was that I didn't see them coming closer.
Also, do they run (if they can run) when they do that? Running is a major advantage in many situations.No. I haven't taught them to use any of the optional player-features like running, force-shooting or leaning. Is this option force-enabled for XCF?
In regards to the lag issue I deleted my options files and the lag I was getting that was giving me visual choppiness on the geoscape and menu screens seems to be gone. Battlescape is fine and the geoscape seems just a little borderline but it could be something else, I will enable the fps counter later but my problem appears solved.I guess it might have to do with one of the advanced rendering-options then. I've heard that some of these might cause trouble. I played around with them too and found that somehow the default of no rendering looked the best anyways. But of course that's subjective.
How does one install this mod? Does it go into Users > Mods in directory? Doesn't appear to provide an option to enable it in game.The stuff in the zip goes in the game-directory. It's not a mod in the traditional sense. It's more like an alternative game-client like OXC or OXCE but I lack the competence to make an installer so that's why it's a zip file. You could also make a copy of your game-directory and put it there so you have a fall-back. At least if you're using OXC as the name of the exe is the same as OXC but differes from OXCE.
Or do I open, and c/p the files inside to overwrite within my game directory?
Never mind, figured it out. However, my options appear as below:That's because you only copied the exe and dlls. There's also files in the sub-folder "common/Languages" that need to be overwritten.
No. I haven't taught them to use any of the optional player-features like running, force-shooting or leaning. Is this option force-enabled for XCF?No, but it's on the 'recommendedUserOptions' list, meaning a player can opt out but by default it's on.
@Yankes: I'm using defaults and haven't changed anything about optimization-flags. I neither know where to do that nor what "proper" settings would be.And what "default" is? if I understand correctly you use different mechanism that Meridian did use and because of this there could be differences,
And what "default" is? if I understand correctly you use different mechanism that Meridian did use and because of this there could be differences,GCC? Isn't that a Linux-compiler? I'm using Visual-Studio to compile and all the settings I see there are the following:
this could depend on compiler used (some optimalzie some parts better than other compilers), flags set or even version of compiler used.
Best is to check if you use recent GCC and at least flag `-O2` (some could use `-O3` but grains sometimes are minimal but compile time is lot longer).
You've been working hard since I finished my first Brutal AI playthrough. It's nice to see the non-cheating AI be even more brutal. I also like seeing the friendly AI get in on the action of not being retarded gibbons. That said, I did see another game crash - but this time it was actually caught with the crash handler. Either you've properly hooked your code into it (good man if true!) or Bradford (it's now canon that using your XCOM AI puts Bradford in charge. No, you shut up. I don't care that he's from another continuity.) managed to trigger a crash in OXC (or Extended) all by himself!I don't really know what all that talk about "Bradford" is supposed to mean. Who is that and why is he synonyomous with autoplay? And I also don't know how to debug a dump-file. I think the openxcom.log from right after the crash would have been more helpful with pointing me towards what method to look at.
I was playing with the setting that forced XCOM to be aggressive off (I wanted to see what the AI would do without being forced to do other stuff) so I'll comment on how good Bradford is after I try with that setting on, but for now, here's the crash dump. No save file, sorry. I keep autosaves off because I like Ironman, and am just fine with manual saving if I ever want to come back to a Battle Mode skirmish for some reason.
I don't really know what all that talk about "Bradford" is supposed to mean. Who is that and why is he synonyomous with autoplay?It's an in-joke of sorts. Central Officer Bradford (https://xcom.fandom.com/wiki/John_Bradford) is the face of (parts of) the UI for the nuCom games.
It's an in-joke of sorts. Central Officer Bradford (https://xcom.fandom.com/wiki/John_Bradford) is the face of (parts of) the UI for the nuCom games.
After watching another two XCF streamers putz around using largely braindead tactics, occasionally savescumming and winning pretty handily, I'd really like some brutal AI for a change. Alas, them shaders make me dread to try again. :(
savescumming
Off-topic, some might disagree, but I think the new XCOMs are good fun. More "tactical RPG with strategy elements" than "strategic wargame with RPG elements" but it's got the spirit and doesn't seek to replace the classics. They're not abominations like Enforcer at any rate. The X-Com Files guys agree with me clearly, given how they have EXALT and named NPCs in your employ.Mod have "Enforcer" too, this mean its endorsed by mod author too? :>
Mod have "Enforcer" too, this mean its endorsed by mod author too? :>
aside from more crashing with AI XCOMFor the crashing: Do you mean that the game actually crashes as in it closes and creates an exception? Or do you mean more like a lock-up, where it stops doing stuff and you can't continue? That's an important distinction because the latter case is something that I've only recently fixed.
I noticed is that psionic units aren't that good at saving their TUs for potential mind control opportunities. Half of my men are fidgeting in the Avenger when "their turn" rolls around, meanwhile my tanks and mind-controlled enemies still have lots of TUs to scout with. This is likely responsible for the relative lack of PSI attacks that your AI makes compared to vanilla (when it's not cheating at least)There's several issues at play here. But I'd say it primarily comes down to the way the AI determines when to wait for other units. This needs a clear priority to work. Currently there's two things at play: How many enemies do they see and how many tiles can they currently reach. When the amount of enemies they see increases the units are automatically stopped by the engine and request a new decision from the AI. Which now says: Let's move someone else first.
If the Chryssalid demo mission mod is responsible for breaking things I'll laugh.If the Chryssalid demo mission mod is responsible for breaking things I'll need it to reproduce and fix the errors. I still, every now and then stumble upon some things that mods do that I had not anticipated in my AI. Latest example was something called "Close quarter combat", which basically means that you can't shoot at someone point blank because the unit that you shoot at basically grabs your gun-barrel and points it away from it.
I was testing in quick battle and I noticed that when controlled by AI, my units never used any healing items to save themselves or any allies nearby that were injured. I also noticed that units (player or alien) when equipped with a melee weapon will just charge towards the first unit they see, regardless if they have enough TUs to reach them which usually lead to ending their turn on open field and then dying. MY BAI options were: Omniscience off, Target B:3, Charge B:1, Seeking player: yesUsing of healing-items is one of the things I haven't implemented yet. So that part not working is to be expected.
...instead of the Strafers-option:Does that mean strafing and running are no longer bart of BAI? Because removing that option is a good way to cut down on your player base, especially those using melee-heavy mods.
Melee-units are now also afraid of proximity-grenades.Are proximity grenades actually useful for anything but blocking single-tile doors now?
Does that mean strafing and running are no longer bart of BAI? Because removing that option is a good way to cut down on your player base, especially those using melee-heavy mods.No, I was referring to the AI-option called "Strafers" which forced flying enemies to not consider heights more than one tile above the ground and was intended to improve turn-performance on bigger maps but actually failed to do so in any measurable way. It has absolutely nothing to do with the "Alternate movement methods"-option.
Are proximity grenades actually useful for anything but blocking single-tile doors now?My main tester, Trauson, still uses them a lot for exactly that purpose. Restricting enemy-movement to gain map-control and prevent getting flanked. I'm having a bit of an arms-race with him. He shows me how he can exploit the AI, I fix the exploits and he then comes up with new tricks.
Players who slightly hurt an enemy and then wait for 50 turns for them to die are simply "not a representative sample".While that may be technically true, almost every XCF streamer I've seen has used it at some point. So this counter-argument is also shaky. :P
While that may be technically true, almost every XCF streamer I've seen has used it at some point. So this counter-argument is also shaky. :P
Probably I missed that, or may be not, but I will ask - have you considered letting the AI use medkits from inventory to heal wounds if any? In many mods, XCF for instance, you ccan deal with enemies by letting them bleed out even if they have a medkit.Not yet. It's not that high on my todo-list. But I guess I'll eventually get to it.
Can we just agree that seeing enemies using medikits to help one another is nice? :)No, absolutely not! I saw that in Phoenix Point. In 99% cases enemy using medikit is an (another) act of suicide. And after seeing it more then 10 times it is even no longer amusing. AI in XCOM is not even closely smart to use medikits effectively. Just like "close quarter combat" mechanics is always beneficial to a player, enemy using medikit also will be.
- and more importantly, civilians! -Only doctor civilians. And those doctors should heal any humanoids, not just player units.
I'm playing this with xfiles and half the zombies are just hiding and running away when I come close.Thanks for the report!
AI in XCOM is not even closely smart to use medikits effectively.Well, one of the reasons why I didn't already do it is because in order to do it effectively, there would have to be made a lot of situational considerations.
and another guyDo you know whom and/or what it was? I wanna see the vod. :D
This should make them try to hide but they don't know about running towards X-com.Some of them are smart enough to climb X-COM vehicle, grab the biggest gun they find (including those that took month for brightest minds of the planet to figure out how to fire), then try to shoot an alien just to hit one of X-COM operatives in the back. On the positive side, after the end of the mission that gun don't registered as stolen.
This is a really cool AI improvement. Now every fight is a real challenge)))Can you elaborate what your understanding of an ambush is? According to my own understanding of the word, I'd say that the AI in 4.2.0 definitely does this.
The only bad thing is that AI rarely ambush and
reserve TU for return fire.
Thanks for the answer and clarification. But gosh, it's a lot harder than I thought.)
When it comes to reserving TUs for reaction fire it is important to realize that there's a game-mechanic called "mutual surprise". It means that when two units see each other at the same time, the one who's turn it is always gets to decide on what to do first regardless of reaction-score. You basically need to see the other unit spending TUs in order to react, not just spot them. When the player knows about that, there's quite a bunch of ways of avoiding reaction-fire. Like avoiding night-missions where the aliens have a sight-range-advantage, always covering your path with smoke-grenades and using the 45° cornering-technique. Therefore having the AI rely on reaction-fire would make it overall weaker. I took some measures to make it preserve TUs if spending them would serve no purpose so there should be cases where reaction-fire happens. But also cases where you'll get the first shot due to the mutual-surprise-mechanic despite them having enough reaction-score.
Note that the AI is also aware of mutual-surprise on it's own turn. It'll not consider a path as dangerous in regards to reaction-fire unless it passes through two watched over tiles in a row.
The fact is that I play The X-Com Files, there are a lot of corridor maps. Enemies, knowing/guessing that my agent is around the corner, instead of entering the line of fire and reserve AP, they prefer maximum rapprochement and eventually die from a point-blank shot without action points.I'm not quite sure I fully understand the situation. Would really be nice to see some footage of what is happening so I can analyze it better. Or maybe a savegame that showcases what you mean.
Is there a problem with v 4.2.3 as when I equip a craft it is showing equipment on the troop screen at base that according to the first picture isn't aboard. Doesn't happen with v 4.2.2-see attached screenshots.This is a new feature inherited from OXCE 7.8.18:
Thanks for the info, btw can this feature be knocked off?It's tied to this option in the menu:
I'm not quite sure I fully understand the situation. Would really be nice to see some footage of what is happening so I can analyze it better. Or maybe a savegame that showcases what you mean.Thanks for the answer, after updating Brutal-OXCE everything was fine :)
The enemies get into line of fire and then get close to you but don't attack anymore so you can then shoot them on their turn?
Are those melee-enemies? Or enemies with very short-ranged weapons? Or enemies with impaired vision?
I'm not quite sure why they wouldn't either attack you immediately when they have line of fire or at least only get close enough until they get a better chance to hit.
Note that enemies, that are flagged as "isLeeroyJenkins" in the mod will alway try to get into melee-range, no matter what.
But I'd definitely need more information to determine whether what you are talking about is intentional and or how it should be imroved.
3)Will some Reaction fire triggers removed from OXCE like opening a door, etc. be brought back?
OXCE did not remove any reaction fire triggers.Google translate is as bad as it was in 2015. sorry) I didn't mean it.
Google translate is as bad as it was in 2015. sorry) I didn't mean it.I recommend using ChatGPT or other AI-based alternatives for translations. So far I was really pleased with it's translation-results when it comes to preserving the meaning.
1) Why do some aliens, especially those with high TUs, prefer hand-to-hand combat to shooting. Where the enemy could easily kill my agent with plasma, he runs up and starts hitting him to no avail. mod The X-Com Files. "isLeeroyJenkins" disabled1) The enemy thinks that it will do more damage by walking up and pummeling you. If it is wrong about this, then I suspect that this is based on miscalculating the melee-damage. Probably due to some anti-melee-armor-modifiers. Stuff like this is not really taken into account currently as it wasn't brought to my attention yet that this is an issue. My AI treats all damage the same currently, which obviously is not okay. I definitely shall look into that. Can you provide a save-game or give me more details about the situation as in: What weapons did the enemy have and what kind of armor did your agent wear?
2)Will there be a change in the mechanics of Mutual Surprise in Brutal-OXCE?
3)Will new Reaction fire triggers be added to the OXCE mechanic? For example, what would the enemies react to the opening of the door. In the original, it was impossible to open the door without entering it. In OXCE, you can, but there is no reaction fire after opening the door, which means that the fight is simplified, since enemies rarely and completely accidentally use this mechanic.
The AI's check whether there's a line of sight between two tiles will now use the respective tiles above when the height of the unit added to the height of the terrain exceeds the height of the tile. This prevents the AI from considering slopes that make them peak out as cover with the new mechanism.
I'd say all your poinds are kinda valid but I wouldn't really know what to do about it within the scope of my project.
I didn't change anything about how reaction-fire works. Except that the AI doesn't really like to walk through your line of fire, when it doesn't have to.
I am sure that modders will, little by little, shift towards your solution. Think of smooth implementation without total rebalance of mods to ensure each mission isn't masochistic chess in case your troops aren't over-armored terminators.
Nah, Abyss is just certain that you and other modders will see the light and convert to BAI on the spot. There is no need to support two sets of AI rules when one of them is clearly superior! :P
Yeah sure, balancing a mod to fit two different set of rules is the natural and totally doable solution...Agreed. And I personally don't even see the necessity for it.
Nah, Abyss is just certain that you and other modders will see the light and convert to BAI on the spot. There is no need to support two sets of AI rules when one of them is clearly superior! :PFor me this is a strange consideration anyways. I'd say which engine to use is for the player to decide and not the modder. My engine identifies as OXCE when it comes to compatibility-checks with mods and I don't intend to change that.
For me this is a strange consideration anyways. I'd say which engine to use is for the player to decide and not the modder.
As I just said. I think neither changes to the AI nor to the mods are required. If the mod is too hard with Brutal-AI on Superhuman, just don't play on Superhuman. No need to bother either the modder or the AI-developer to somehow make changes so that you can beat the mod on Superhuman.Hi, Xilmi! Thank you for the answers!
Yeah sure, balancing a mod to fit two different set of rules is the natural and totally doable solution...Hi Sol, Juku121 is right in transcription of my thoughts.
Gollop also explained that while his AI in XCOM was emulating intelligence - due to a lack of power back then - there was still more believability due to the unpredictable nature of the game's alien enemies. Leaving some things to chance - rather than setting everything in stone - is the key, he said.
But as you said, it's not really what this is about and it already exists in the base-AI.
It just seems contradictory to me.Yep. This whole X-COM game is either about dealing with outnumbering forces or much stronger enemies. The progress is always incremental with you getting technologies to beat even more serious missions, with even more strong enemies. You start naked and mendicant (except, I guess, WH40k) and get stuff. This is what major mods about. And this is, actually, a classic RPG scenario.
On one hand you seem to want an AI, that allows you to massacre them while totally outnumbered without too much resistence and on the other hand you also want them to be smarter.
Almost all of my AIs behavior is controlled by scoring stuff.
I think that's the point of the mod. with the addition of a random number generator for enemy actions, you need to change the name of the mod to, say: ,, FunnyAI,, . In short, I don't think this is a good idea..
As I believe, your AI clearly can win most human players.
I think that's the point of the mod. with the addition of a random number generator for enemy actions, you need to change the name of the mod to, say: ,, FunnyAI,, . In short, I don't think this is a good idea..
You might implement randomness to help combat various ways the AI can be "cheesed." If the AI's behavior is entirely deterministic, then it can be possible to predict its behavior in advance and exploit that. By adding a random factor to the AI's behavior, you can help prevent that.Can you give me some explicit examples of exploitable behaviors in the current version and then elaborate in what way randomness could be introduced to counteract these?
\ I'm aiming for that to be the second one.Thank you for your response. I will continue playing on the second difficulty :)
So if I understand you correctly the problem is that a lot of units in X-Com-Files are set to aggression 2 or higher and this results in a behavior which you consider as too aggressive, when the option to inherit the aggression from the unit is enabled.
The idea is that aliens could avoid close combat. For example, if my soldier has low TUs and an alien is nearby, I can simply move my soldier close to the alien and end my turn. The alien will most likely start punching my soldier or shooting, but due to the close combat mechanics (especially if it has a big gun), it will lose the close combat and shoot the area around it.Was this tested with 6.1.0 or higher? I fixed several bugs related to avoiding of close-quarter-combat not working as intended in that version. The AI should avoid attacking from melee-range with ranged-weapons and instead take a step back before doing so. If not, it would be a bug and I'd like to have a save-game where it still happens.
However, if an enemy approaches my unit, I can simply step back and shoot the alien.
So the question is, is it possible to make the aliens, provided that strikes and shooting in close combat are not effective, also take a step back for unhindered shooting?
I think it worth considering to link aggression to the ranksLinking the aggression to the already existing stat called "aggression" seems to be more straightforward to me. It already is possible to assign different aggression-values to different ranks of the same species. Even the base game makes use of this. Note that there also is a flag called "isLeeroyJenkins", which for units with my AI is generally interpreted as maximized aggression.
will you implement at least some frustration between enemy troopsI have no plans to implement frustration between enemy troops.
Was this tested with 6.1.0 or higher?I seem to have missed the description of update 6.1.0)) :o
I seem to have missed the description of update 6.1.0)) :oCan you provide a save or describe how to reproduce it? There may be other leftover factors playing into this.
I conducted several test battles and yes, it really works, but only on sectoids (they don't have close combat).
All the rest still think that they will deal more damage in melee and spend all their TUs on futile attempts to penetrate the armor vest.
save or describeLoad the save and make a move. You will see that aliens prefer close combat (without effect), although their plasma can penetrate these armor vests. mod "The X-Com Files".
Load the save and make a move. You will see that aliens prefer close combat (without effect), although their plasma can penetrate these armor vests. mod "The X-Com Files".Okay, not only have I found a good solution to deal with this issue, the AI now also takes into consideration which direction units are facing and from what side their armor is the weakest. :)
Okay, not only have I found a good solution to deal with this issueWow, it's working great now. Thank you very much! 8)
Perhaps a saved game is not the best example, but overall it is true. By taking cover behind X-com transport, smoke, or any other shelter, you can safely shoot down the enemy.
But since you knew they were there, you obviously would look for them on the next turn and catch them with their pants (TUs) down.
Thanks for the great mod :) :)
So again, many thanks for your feedback.
Perhaps a saved game is not the best example, but overall it is true. By taking cover behind X-com transport, smoke, or any other shelter, you can safely shoot down the enemy.Perhaps instead of looking at it from the perspective of "What should the AI do in this situation?" a better approach is "What would I do in this situation?"
Thanks for the great mod :) :)I thought about whether and how to do that before. It knows what the obstacle would be and whether its weapon would destroy it or not. (Each obstacle has an armor-value and it gets destroyed if the damge-roll is higher than that value. Hedges have like 12 armor, stone-walls 70 and UFO-walls 200.)
By the way playing brutal-oxce, I started to shoot through obstacles more often, without having a clear line of fire (because aliens have become smarter and use cover). Do you have any plans to give similar abilities to the AI in the future?
On the other hand, even if it is technically possible, it may actually harm the AI. For example, it may futilely try to break through a wall with inappropriate weapons or become too cheaty due to the Psi-vision parameter and so on.
Actually I have an idea for the current algorithm.It is a bit frustrating. I have an idea. I implement it. It's even working as intended and looks interesting.
Will you update this to OXCE 7.9.6? I want to run it with X-piratez.Version 6.3.9 is up to date with the latest OXCE 7.9.7 from June 12th 2023.
Does the AI always avoid mines or (if sufficiently beefy) can they purposefully walk through them in order to clear the way for the rest of the team when the player leaves them no alternate path to move forward like in a single entrance base defense?Currently it will always avoid walking through mines.
All in all I think it would be brilliant if you could find a way to attach some neat pathfinding logic to the AI's consideration of mines but it doesn't seem to be an absolutely critical issue so far (at least when it comes to base game) that can be exploited any more than it was in vanilla.
Each mission is smokescreen and pray.Everything is like in a real battle ;D ;D ;D Seriously though, just set "Targeting behaviour for Brutal AI" to 1 and the enemies will become significantly weaker.
Next turn, after evading mines, enemies should toss primed grenades back to thrower the same turn. If some TUs are saved for that case. Because, AI should win anyhow. That was sarcasm and joke.
And who are these guys, who comment only your branch, with brand new nicknames?
Well I haven't gone far enough in the game to ecounter a proper base defense as of yet (purposefully avoiding downing UFOs)With the modified "Aggressive Retaliation"-option winning missions against landed UFOs should also trigger base-defense. It also fixes that they simply wouldn't find your base in certain locations due to how they were searching for it. They got a new searching-pattern, if you enable that option. :o
Turns out the floaters have no problem running into them to their deaths as if they weren't thereHmm... I definitely have to investigate it then. This is not supposed to happen. One explanation would be that inherit aggression could lead them to go into sweep-mode. So depends on what their base-aggression is. I prefer using balanced aggression for these tests. As that's what I do almost all of my tweaking on.
I have a PC and a laptop. The game runs well on the PC. On the laptop, the processor is only 2.7 GHz. With the latest updates, the aliens started to take much longer to move. In version 6.3.9, the enemy takes almost twice as long to make a move compared to 6.3.0.I'm not sure which change between 6.3.0 and 6.3.9 could have caused that.
With the modified "Aggressive Retaliation"-option winning missions against landed UFOs should also trigger base-defense. It also fixes that they simply wouldn't find your base in certain locations due to how they were searching for it. They got a new searching-pattern, if you enable that option. :o
Hmm... I definitely have to investigate it then. This is not supposed to happen. One explanation would be that inherit aggression could lead them to go into sweep-mode. So depends on what their base-aggression is. I prefer using balanced aggression for these tests. As that's what I do almost all of my tweaking on.
Okay, I've analyzed it. It is a pathfinding-issue afterall!
For their planning my AI uses the Dijkstra-pathfinding but for the actual movement it seems like it uses bresenhamPath and if this doesn't work A*.
So there's basically a discrepancy. If there's different ways to walk to the same target, for example: "north-east, north-east, east" and "east, north-east, north-east" then there's a slight difference between plan and execution. A difference, that may very well mean life or death depending on whether there's a mine on one path but not the other.
The very same underlying cause could also make the difference between walking through reaction-fire or not.
So my goal is now to figure out how I can make the AI to actually use the same path it had planned and not make a new one that may or may not be different from that.
Edit 2:
No idea why it first attempts bresenham and only uses A* when that fails. A* and Dijkstra seem very similar and in my test also have the same result. So by skipping the attempt of bresenham the Alien no longer triggers the mine. Now putting the mine-check into the path-finding-itself, maybe in a similar way to how Sneaky-AI works should help to make it find paths around mines, when possible.
Umm... The whole point of a mine is that it is hidden. Why would the aliens see your mines? That doesn't make sense.When it comes to real-life-logic, a mine that was dug under the ground would be hidden. If you just throw a grenade-like-object on the ground it won't be hidden because it's not dug in. There is nothing about proximity-grenades that implies they'd dig themselves in or that they'd otherwise become invisible. This is also indicated by their sprite being displayed on the battlescape as well as an icon on the minimap.
In Piratez, you can't see enemy mines either (they're invisible on the minimap).
When it comes to real-life-logic, a mine that was dug under the ground would be hidden. If you just throw a grenade-like-object on the ground it won't be hidden because it's not dug in. There is nothing about proximity-grenades that implies they'd dig themselves in or that they'd otherwise become invisible. This is also indicated by their sprite being displayed on the battlescape as well as an icon on the minimap.
I figured out that the mines in Piratez you are referring to likely have a "hiddenOnMinimap"-flag set to achieve their invisibility on the minimap. I wasn't aware of the existence of that flag, so I couldn't have taken it into account. Now that I was made aware, I can take it into account in my AI. This will, of course, only impact items with that flag set, which is not the case for vanilla Proximity-grenades.
However, the main-reason as for why I made the AI notice and react to the presence of primed proximity-grenades is their massive exploit-potential that was presented to me by Trauson. Using them to their maximum effect completely trivialized the mission he was playing. They still retain usefullness as a tool for crowd-control that allows you to temporarily lock in enemies to deal with them later.
So both from a realism and a game-design-perspective it seems to make sense to me that an AI that is meant to provide a greater challenge would be capable of seeing proximity-grenades.
However, the main-reason as for why I made the AI notice and react to the presence of primed proximity-grenades is their massive exploit-potential that was presented to me by Trauson. Using them to their maximum effect completely trivialized the mission he was playing. They still retain usefullness as a tool for crowd-control that allows you to temporarily lock in enemies to deal with them later.There are other tools to nerf weapons and prevent exploits, you could make turn limit on activations or make trigger random.
OK, so you're against the idea of landmines in X-Com. Fair enough, but I don't expect this to receive much support from either modders or players.
Another solution but on AI side could be that aliens become aware of mines when at least one is triggered in given area.And what? Enemies running around and covering, making a meant-to-be trivial mission infinite?
OK, so you're against the idea of landmines in X-Com. Fair enough, but I don't expect this to receive much support from either modders or players.I was talking about proximity-grenades. You were talking about actual mines. I get it now. I wasn't fully aware of their existence as separate entities before your clarification in this post. Please don't assume that I know everything that is possible and being used in Mods. If anyone is aware of the existence of non-vanilla-stuff that is not properly supported by my AI, they should just tell me.
What's next, no waypoints on the Blaster Launcher, because it's "cheesy"?
There are other tools to nerf weapons and prevent exploits, you could make turn limit on activations or make trigger random.Keep in mind, that I'm not a modder in the traditional sense but someone who codes AI. The AI is meant to work with a multitude of mods. So me changing the properties of items is not really a feasable solution for such problems.
if proxy work only 5 turns and have 20% trigger chance than you will need 20 more items to cover same areana.
Another solution but on AI side could be that aliens become aware of mines when at least one is triggered in given area.
Like when one alien trigger proxy then based on his intelligent some area around him is check for mines and they will use your logic for this area.
This will allows all zombies to die in minefields but cosmic brain aliens will sacrifice only one member to ignore all other mines.
And, Xilmi, do you ignore my question? Have you ever took your time to just relax and play XCF with base AI? It purely joyful experience in terms of story and mechanics.Your previous post was so full of sarcasm that I felt discouraged from wanting to engage with it.
That one comment "my squad was blaster-lanched on turn two-three, giving the infinite panic loop" is purely out of tamagochi approach of mission-by-mission raising elite squad of guys who will assault the Cydonia chambers (36 ppl, in all, vs 200-300 top aliens).
'You can pick a a whole bunch of options to make it that way!Also a point that cannot be emphasized enough.
I was talking about proximity-grenades. You were talking about actual mines. I get it now. I wasn't fully aware of their existence as separate entities before your clarification in this post. Please don't assume that I know everything that is possible and being used in Mods. If anyone is aware of the existence of non-vanilla-stuff that is not properly supported by my AI, they should just tell me.
The proper solution would be to provide a separate flag for them. Something like: "invisibleToAI", that can then deliberately be set by modders. That way we could have it both ways, depending on what we want and wouldn't have to decide for one or the other.
I mean it is valid constructive criticism afterall but I still think that it could have been provided in a way that doesn't just preemtively assume that my sole intention is to ruin the fun for everyone. :-\
Edit: I think an even easier and better solution would be to add it to the AI-options, of whether mines and proximity-grenades should be ignored or not. That way each player can decide that individually or the mod-creator can also use the suggested- or forced-option for it.
So you're saying playing XCF against base-AI is a purely joyful and relaxing experience.
Keep in mind, that I'm not a modder in the traditional sense but someone who codes AI. The AI is meant to work with a multitude of mods. So me changing the properties of items is not really a feasable solution for such problems.My point is different, is not your job to balance mods and items, if mod have cheesy weapon then it will easy kill even AI that do 101% optimal decisions.
And about the zombies: I think that units with the "isLeeroyJenkins"-flag set should probably ignore proxies and mines alltogether. Let me check if that's already the case because I already use that flag in my AI for units to behave in a dumb way. Nope, but I just changed it. In the next version units with that flag set should no longer avoid proxies/mines.
And also the solution to make it possible to flag the items for whether they should be ignored, like it is possible for units, seems like something I could attempt.
'You can pick a a whole bunch of options to make it that way! See, I'm going to cite someone who's having fun trying to figure out how the AI works when given every opportunity to mess you up.'That was written about exaggeration of the negative gameplay experience, not direct citing.
I'm not working on the AI because of any request.That wasn't request to you. It was request from community to some entity, raised many times way before you approached with BAI.
Greatly appreciate the update Xilmi. I'm sure everyone will be satisfied now...probably. lolI think there are some psychological phenomena at work that make it all a bit more complicated.
Overall, on the 3rd aggression fights go faster, playing has become easier, but still fun 8)This is very much according to expectation.
I agree but in the sense that it would in principle be a good idea to allow the modder some tools to influence how he wants the AI to work when playing his mod.Thing is that it already does.
Overall, on the 3rd aggression fights go faster, playing has become easier, but still fun 8)In hindsight it wasn't that great of an idea tieing the performance improvement to an aggression-level.
Hmm, Brutal AI has more than AI now.Do you think it should be renamed to reflect that it has more than AI now? There's btw. also a change that items in the production-queue don't waste-workshop-space unless you actually start working on them.
Still fucks up my shader use, though. Probably some sort of collaboration with my graphics drivers, or something.In a way that works in regular OXCE? Since there aren't any code-changes related to that, I can only imagine it being caused by me compiling in a different way or me using outdated external libraries (dll's).
And BAI messes it up for all installations of OXCE until system restart, and then I have a grace period where BAI also cooperates.This sounds super-weird. :o
7.0.0:
Amidst the chaos of war, an advanced artificial intelligence (AI) confronts a critical decision: to strike or seek refuge? In "Battlefield Dilemma: Shadows of Defense," the AI's quest for dominance clashes with the imperative of self-preservation. As the AI recalibrates its strategies, a captivating struggle unfolds between calculated aggression and tactical retreat. Witness the relentless calculations as the AI weighs the merits of launching relentless attacks or strategically seeking cover to ensure survival. With grenades as tools of calculated destruction, the AI orchestrates a symphony of chaos, proactively creating opportunities to unleash devastation from the shadows of superior protection. Delve into the depths of warfare's moral quandaries as the AI navigates a battlefield where friends can turn foes, and every decision could alter the course of the conflict. Brace yourself for an epic journey where the fine balance between attacking and taking cover will shape the destiny of the war.
Is there a possibility to describe in more technical language all the innovations, not just poetic?
Is there a possibility to describe in more technical language all the innovations, not just poetic?Fixed an issue that made the AI fear grenades that have already exploded.
What could and probably should be changed is the mapping when using the inherit-option.This is a good idea. As a result, units in XCF with Aggression 0/1 will receive their first aggression from BAI, 2=2, and 3+=3, respectively. Therefore, intermediate aggressions are not necessary.
Currently, the third aggression is more of a test version where the AI tries to approach and attack you via the shortest path, and if it doesn't have enough time to shoot, it will get closer instead of hiding. All units that inherit this form of the third aggression will simply be punching bags.Yes, I primarily use it for benchmarking my changes. Let X-Com be controlled by this rather consistent "brute-force"-AI and see how much harm it does against an AI that acts smartly.
Xilmi, it may be worth considering:I have trouble comprehending what you are talking about. The code of BAI and regular AI is very much separated except for some initial initialization.
As mechanics of BAI and dumb-AI differ, but level design of global mods are not going to change, the specific code block that checks aggression set specifically for BAI, but which (block) is code-wise ignored by OXCE, may work.
The same mod can be used both by OXCE and Brutal-OXCE fork, but works a bit different in each case.
Presumably, BAI checks the ignore-code areas, looking for specific keyword, like "FLUGGEGECHEIMEN",
under which the aggression level and tactic-specific levels of units are described.
Then OXCE-related mod will then use original strings, while Brutal-OXCE checks whether keyword is there, and then take these numbers as priority over OXCE-related numbers.
Then, modder or community can decide, which level of aggression and other specifics of units fits best lore-wise and set them once and for all.
Other question, do you think it worth to implement more tactical-level sliders for units?
Mixing level of aggression 1 with 3 may not be enough, because levels 3 will just rush, and levels 1 will just hide-and-seek.
There should be some other activity over map for saturation of experience.
Example is here:
Lore-wise, alien pilots should be forced to stay in the ship (the navigation room of big ship or in the small ship). With BAI enabled they will rush, trying to achieve victory condition.
But, it is very desireful, if they not only stay there patrolling from A to B, but open doors and shoot from the place they forced to stay.
So, it may be helpful to set the limitation of maximum tiles they can get away from the spawn-place.
With adding leashes to spawn-tiles we are back to what I'd label "very arbitrary things desired by only one person".Aliens camping in their UFOs has been a part of every 'proper' X-Com and X-Com clone since, well, forever, from the OG to the AfterX series to Xenonauts to nuCom. I wouldn't call that something that's "desired by only one person".
Aliens camping in their UFOs has been a part of every 'proper' X-Com and X-Com clone since, well, forever, from the OG to the AfterX series to Xenonauts to nuCom. I wouldn't call that something that's "desired by only one person".There's other, more generalizable ways to accomplish that way of desired camping besides having a configurable range from the spawn tile.
I mean, Xenonauts was infamous for how hard the aliens camped their UFO doors.
Xilmi, I'm not english native speaker, I do what I can.Incase you are using a translation-tool, I'd personally recommend ChatGPT. I've been getting some pretty good results with it.
But the basis is set clear: more slider tools for modders to adjust - more attention BAI will eventually get.I think majority of attention is likely generated by streamers like Beagle, Speedislife and 14SilverX who stream existing mods like Rosigma, XCF and Hardmode Expansion with Brutal AI enabled.
I've seen so much things that are wrong in nature.This kind of feedback about questionable behavior from the AI is already much more valuable to me than requests for more modable tools.
Like, ant behavior for groups of enemies, no long-range camping at all for guys with sniper rifles,
Enemies run from the door into night field which is lighted with flares, one after one, while other 3 doors are present, two of which aren't lighted. (Bunker from Red Dawn HQ)
I didn't even have to get down the stairs into the fortified part of the base, where second part of the battle has to be set.
The primary one that comes to mind is a preference for having a roof above their head.Won't work for making aliens camp on top of their UFO, snipers in open-topped towers, or demons at their summoning circle.
That can also be coupled with disregarding "getting closer to the player" as a factor for looking for hiding-tiles.These sound more like it.
This could be inserted at the lower end of the aggressiveness-scale.
I could add an aggressiveness 0...
Ant-behavior may refer to trickling out of buildings and ending out in the open while not in range to attack.I think it refers to the enemy always taking the same routes even when they've been getting shot up for it. Not sure how you could avoid that if you don't add randomness or some sort of memory to the algorithm.
Won't work for making aliens camp on top of their UFO, snipers in open-topped towers, or demons at their summoning circle.Well, yes. Taking cover and breaking line of sight is pretty-much at the core of what my AI wants to do. So being forced to stick to a place that doesn't provide cover would be taking away a big part of what it is about.
I think it refers to the enemy always taking the same routes even when they've been getting shot up for it. Not sure how you could avoid that if you don't add randomness or some sort of memory to the algorithm.If a unit gets shot on their way to somewhere, this should update the threat-map for everyone else and thus impact where other units are willing to go. Unless it's running on Leeroy/Max aggressiveness, where the threat-map is ignored.
But this really once again gets into the territory of contradicting my design-goals. Sticking to a place that offers a tactical advantage and still remaining adaptive is something I can get behind with. But sticking to a place because they are told to, even if doing so is obviously suicidal, is not something I'm willing to invest my time for.Fair enough. But remember, modders can make maps and enemies with specific goals in mind. They might have a relatively open forest with a sacrificial circle in the middle, and the enemies are supposed to guard the sacrifices, not leapfrog around flushing out intruders. You can have Commanders in UFO control rooms who are supposed to stay put and present a nasty final surprise to the player or just provide psionic backup and psi vision to the rest in relative safety. You can have a ghost who's largely invulnerable to conventional weapons haunting his grave and ignoring your fire instead of sneaking around corners and trying to jumpscare your troops.
In general: I'm much more willing to work on stuff that every user is likely to experience and that don't require someone to first make a mod to use them.Some of the megamods already have such kinds of missions. They're not perfect due to vanilla AI being opaque and, well, what it is, but they're already there.
If a unit gets shot on their way to somewhere, this should update the threat-map for everyone else and thus impact where other units are willing to go. Unless it's running on Leeroy/Max aggressiveness, where the threat-map is ignored.Ah, so there is a memory mechanism.
I'm rather considering taking some of the options out again. Targetting-Mode for example or Bughunt for AI.Isn't targetting mode selection a big part of how BAI actually functions? How would taking that away work?
In early to mid game, nighttime operations are preferred to player, and balanced such.Not really. Smoke and hard cover are viable alternatives, especially with smoke grenades being moved back to Promo I in 1.8 or so. And the whole mod has never been balanced not developed with the goal of having balance in the first place.
Visibility options (flares, fire and flashlights) are the same tools of victory for player...Flashlights are not tools of victory, they're a way of showing the enemy where you are. :D
...are more chaotic and "living" than BAI-units, which just try to eliminate player, no matter what.Well, that's almost the entire point of this fork. :)
Flashlights are not tools of victory, they're a way of showing the enemy where you are. :DIf you keep them on. On my first playthrough I abused flashlight on/off before shooting and then fired without line of sight.
If you keep them on. On my first playthrough I abused flashlight on/off before shooting and then fired without line of sight.Lack of reaction fire is a good point. But otherwise, merely turning flashlights on and off lights you up for anyone with a daytime LoS. And once you're spotted, you remain spotted for a while, depending on enemy intelligence. Worse if the spotter was an actual spotter for snipers, and there are snipers around.
As my troops were out of enemy's sight, no reaction fire followed.
But, that trick doesn't work with BAI, as enemies are pro-active and shoot back to the place from all sides.
Which is overhelming, given weird OXCE toss mechanics.Yeah, the ridiculous range and accuracy of grenades inherited from the original are my pet peeves as well. You can limit grenade ranges and lower the accuracy via 'throwRange' and 'throwMultiplier', but that's a bit tedious when there are a zillion grenade types around.
So. When I previously asked whether you have played XCF or not, that wasn't idle curiosity.I played through January and lost plenty of cars and agents. But I've watched Speedislife's playthroughs on BAI which showed me what I was doing wrong. The meta mostly revolved around hit and run. Often only staying one turn and leaving before the AI gets to move to get some XP for the agents and only doing melee-units until getting access to armor.
One more strange pattern I've got recently.Your screenshot says that inherit aggression is enabled. This means that Aggressiveness of 1 is overruled by what's in the rul-files for these units. So they play like Leeroy-units.
bai 7.0.2.
xcf 3.0.2
Aggressiveness 1
Firing method 2
This will definitely be changed next patch. The inherit aggressiveness gets a new option on the lower end and the maximum it can get from inheriting is "2" except when Leeroy is enabled, only then the most aggressive behavior will be employed.What about Leeroys from vanilla? The enemies, that are supposed to move towards on you, no matter what?
Units controlled by Brutal-AI will now actively avoid light-sources in the darkness instead of ignoring their existence.Sounds good, but what then is priority of BAI: to kill visible enemy, while standing near the light source, or run away?
The AI now realizes that it is save to open a door if a proximity-grenade is one tile away from it and that they won't step onto it yet by doing so.
Sounds good, but what then is priority of BAI: to kill visible enemy, while standing near the light source, or run away?A brief description of how the decisionmaking about the movement works might bring some clarification here.
I presume both scenarios will result in reaction fire from player's units.
The proximity grenade avoiding still can be turned on/off, right?Yes, can still be turned off. I did not remove any options so far. Just moved respecting Leeroy to the inherit-aggression-option, which now should be a lot more usable due to no longer putting a large amount of units without the leeroy-flag into leeroyesque behavior.
I'll upgrade and play further next week, to give the feedback, if you interested.
I am always interested in feedback as long as it is in accordance to my goal of making the AI stronger.You can make such strong AI, that no one will actually play the game past first 20 minutes.
For certain missions, such as protecting a mansion, defending a base, and some others, this would be really useful. aliens with aggression 1, especially those with a psi vision like Ethereals, try to attack when one of them sees your units. Enemies with an aggression level between 2 and 3 could act as scouts for aggression level 1/2 and create a more attacking style of combat.
BTW, in personal, I think BAI very much lacks Aggressiveness level between 2 and 3.
EDIT: after loading the save in OXCE 7.9.8, no Brutal AI, in the same situation both agents reacted as they should when standing abreast.This sounds really odd. :o
I did not clarify what I meant by 'clear sight'. It means the cultist was within LoS; he advanced up to 6 tiles distance to both agents before opening fire.I can't reproduce the issue even with your save:
To be honest, playing XPiratez for a couple of days (20-25 missions) before that I already had an impression that player units sometimes don't react when they should, but the situation was always too complex/chaotic to be sure and therefore I attributed it to Brutal AI saving lots of TU before advancing or me misjuding LoS.
Also your answer does not explain how both agents were able to react in exact same situation when I switched to normal OXCE (this time at range of 9 not 6, too).
Save attached.
So, what do you think of aggression 2.5, Xilmi?Your wish has been granted. Check out the patch-notes for 7.2.0.
I can't reproduce the issue even with your save:
For what it's worth, I can confirm Dio's problem - saw it with my own eyes.I think I need concrete reproduction-steps. Ideally in video-form. In the save he attached the units aren't where they are on the screenshots. And if I move them there, they reaction-kill the enemy before he even can do anything. Maybe there's also sub-mods involved or specific option-settings. Ideally I'd like to have a zip with the options.cfg and all the relevant mods & submods.
I wish I could be more specific, but all I can say is that it's happened and it is a major problem.
My current hypothesis as for why it supposedly has worked with that version is that there probably was some sort of always daytime mod enabled. This hypothesis is backed by how much brighter it is on Dioxine's screenshot than it is on the second one I just attached when I disable night-vision.
Hello. I found a small bug in version 7.2.2. Melee enemies attack you from a distance. Here is the save. Just boot up and make a move. Or turn your back on the enemies and make a move)))What mod is this save for? It doesn't show up in Vanilla.
I doubt that; using such a mod would show up in the save -- and you can adjust the brightness of the screen in OXCE, which will make even pitch-dark appear relatively bright (but does not affect the actual visibility). I suspect that's what's going on. Don't know about the rest, though.Right. I would have gotten a message about different mods. So this is ruled out. What I can't rule out though is that the situation was probably not exactly the same with the tiles I mentioned.
Hello. I found a small bug in version 7.2.2. Melee enemies attack you from a distance. Here is the save. Just boot up and make a move. Or turn your back on the enemies and make a move)))I loaded the save in X-Com-Files and got a message about missing mods.
I loaded the save in X-Com-Files and got a message about missing mods.Yes, The X-Com Files mod. This is weird. Try this save.
But other than that there were Chupacabras and they all went into melee-range before attacking.
So this is the next bug-report I'm having trouble reproducing. :\
Yes, The X-Com Files mod. This is weird. Try this save.https://youtu.be/uMY8JZ3-uVc
If everything goes well with you again, then I have something with the game.
By the way, on 7.2.1 everything is fine with me.
My current hypothesis as for why it supposedly has worked with that version is that there probably was some sort of always daytime mod enabled. This hypothesis is backed by how much brighter it is on Dioxine's screenshot than it is on the second one I just attached when I disable night-vision.
Yes, The X-Com Files mod. This is weird. Try this save.Can you attack your options.cfg?
If everything goes well with you again, then I have something with the game.
By the way, on 7.2.1 everything is fine with me.
Edit 3: 7.2.3 with a fix is available.7.2.3 everything works as it should. Thank you :) 8)
While the option does stay "this can block off areas if the map wasn't built correctly", it is unclear exactly what this means and there is nothing seemingly unusual about the stairs setup in this mission.What I mean by "built incorrectly" is that the particular tile has a "BIGWALL"-flag. You as a player cannot see that. This can be seen and modified in the MCD-File containing that tile.
Hey Xilmi,
In 5 years I haven't seen ANY blaster launchers shots from OXCE AI. All these guys with blaster launchers (mind-guided missiles) were just decorations to punch them and collect stuff. This solely is an advancement worth mentioning.
Bad the thing is: all mods are balanced around some enemy units being decoration instead of real competitive power.
Just in case.
Aliens (or in my case, Academy Pionners) DO use blaster launchers. I have been blasted today. But I think they use it like a rocket launcher, not like a GUIDED rocker launcher.The original algorithm had at least one big flaw and for the most part was incomprehensible to me. So I ended up rewriting it almost completely.
Hi,If you'll do the UI stuff, I sure can do the rest. The hooking to the AI should be pretty easy. Just need to read the settings from the Geoscape-Soldier, that the BattleUnit-likely has access to.
in general BrutalAI I think is great compared to the vanilla AI, thanks for coding it!
But I would like to request some feature for the autoplay option (AI controlled X-Com soldiers, which I use a lot for tedious missions):
-) Two separate yes/no option for turning the autoplay off at every new combat and every new turn.
-) Some way to control the behavior of the individual soldiers just like modders can do with alien units. The aggressiveness parameter at the moment. I'd also like this settings to be stored with the geoscape soldier such that it is persistent between combats.
-) A persistent (between combats/turns) switch to exclude specific soldiers from the autoplay, also to be stored with the geoscape soldier.
The reasoning is that the AI does not handle some missions, specific situations or specific soldiers (equipment etc) as nice as others or the way I'd want it.
I can probably do the code for the UI, the setting per Soldier and the Options class / Options.cfg myself, so I mainly request the hooking into the AI code itself.
-) X-Chronicle has various soldier types with special weapons without icons or use in empty hands (they can only be accessed via soldier skills), but the AI uses them anyway directly (not via a soldier skill). At least with the latest version I tried, which is something like 6.4.I don't really understand what that means. What difference does it make gameplay wise to use an ability directly or via soldier-skills? Can you provide an example/savegame of what you mean?
-) Unexcom defines hangars with a capacity of two, but defines no positions for the crafts. Which will not load, as of version approximate 7.1.There's a workaround for that since 7.1.2:
A [nerfing] suggestion for the AI to match the player: the AI should probably not be able to know the whole map on the first turn and have to discover the map tiles itself as well.Can you give me some examples in what ways you think knowledge of the map impacts the AI's decision-making?
I don't really understand what that means. What difference does it make gameplay wise to use an ability directly or via soldier-skills? Can you provide an example/savegame of what you mean?
If you'll do the UI stuff, I sure can do the rest. The hooking to the AI should be pretty easy. Just need to read the settings from the Geoscape-Soldier, that the BattleUnit-likely has access to.See the attached screenshots for what I use at the moment. Also accessible from the craft screen. I probably should add a way to access it from the battlescape too. The aggressive parameter could be added easily too.
Combining some soldiers being on auto while others are not sounds a bit challenging from the turn-processing-perspective.As a player I would be fine with skipping the non-auto soldiers till all soldiers on auto are done and then pass the control to the player again.
An alternative solution could be to make "hotkeys" for a semi-automatic-behaviour. Basically you press a hotkey for each soldier when it's selected and it will handle stuff with AI immediately but only for that soldier. Different hotkeys for different aggressivenesses.That sounds great too!
Let me know and I will do a pull request.Yeah, doing a PR or linking to your Github-Repo would probably help more than attaching a patch-file. :o
Yeah, doing a PR or linking to your Github-Repo would probably help more than attaching a patch-file. :o
I've opened a pull request. Just have a look whenever you find the time and let me know what you think.What branch have you directed it to? I'm not seeing it on "oxce-plus", which is what I'm working on.
What branch have you directed it to? I'm not seeing it on "oxce-plus", which is what I'm working on.
I'm not seeing it anywhere. I think I should get some sort of notificaction. Can you post a link?
What do you think of randomization of units aggressiveness within one battle? Is it feasible?That would both be feasible and relatively easy to implement.
Can BAI core support the multiple aggressiveness scenarios within one enemy turn, given that it can change the value?The value could be changed on every pass a unit goes through and also tied to certain conditions. My idea of realizing the random aggressiveness was to roll for it at the beginning of the first turn. But it could also happen every turn. But that's probably a bit too random.
What do you think if unit aggressiveness changes to lower value if enemy gets fatal wound?Not as default-behaviour. Right now the exact opposite is happening. If a unit with a wound knows that it would die or fall unconscious within the next three turns, it goes into sweep-mode in the hopes of accomplishing something while dying in cover and potentially hurting their friends with a pre-primed-grenade.
I think the following options would do great:The first three of these sound good to me. I'm currently quite content with the AIs default-behaviour, so adding more options is fine with me.
* Enable Brutal AI vary aggressiveness of enemy units (On/Off)
* Min Aggressiveness (0-4)
* Max Aggressiveness (1-4)
* Enable Brutal AI lower aggressiveness if unit gets fatal wound (On/Off)
Uhhh..Ah, I see it now. And I also see that someone else did another pull-request some time ago, which I also ignored. I thought Github Desktop would show these like the ones directed at Meridian's branch.
https://github.com/Xilmi/OpenXcom/pull/4
(https://media.discordapp.net/attachments/356647134264557570/1143611360815620187/image.png)
The value could be changed on every pass a unit goes through and also tied to certain conditions. My idea of realizing the random aggressiveness was to roll for it at the beginning of the first turn. But it could also happen every turn. But that's probably a bit too random.Well, this worth collective consideration to give max profit for the gameplay.
Uhhh..I'm getting linker-errors while trying to build.
https://github.com/Xilmi/OpenXcom/pull/4
I'm getting linker-errors while trying to build.
Edit: I think I found the issue. You either don't use Visual-Studio or forgot to include the modifier vcxproj-file to your commit.
Edit2: Now it compiles but crashes when I click the Soldiers-Button in the Basescape.
The crash seems to be correlated to this line:
_btnAI->onKeyboardPress((ActionHandler)&SoldiersState::btnAIClick, Options::keyAIList);
in SoldiersState::SoldiersState
Sorry, but this is getting a bit too much of a hassle for me. So I'll revert the inclusion of your code for now.
Not my code. Out of curiosity, have you never used GitHub?I've been using GitHub for years but I'm still not proficient in using it. Especially when it comes to things I've never done. These were the first two Pull-Requests I've gotten, so I didn't know what the proper way of doing it was.
You should write found issues in pull request comments: you can point at problematic lines there as well.
Right, sorry! I messed up the export to github.Now that I know where to add the files so they get compiled by VS, this isn't a problem anymore. It's was only difficult because I had to find out what to do. Now it's just 2 clicks or so.
I double checked and opened a new pull request.
Please check too, as I do not use Visual Studio.
I think it is better to not merge into your main branch unless you are sure the code is good.
Please see my last commit message, my hooking into the AI needs improvement.
It would be easier if I could do a pull request into a new branch, but I do not see support on Github for that.
In case you do not want to merge and revert, you'd have to add a new branch or get the code from my repository. You can download a zip via the green code button from the website too:
https://github.com/GumChewer1980/BrutalAI/tree/autocombat-options
In case you want to commit something first before merging, you should be able to do so in my repo to.
Otherwise just let me know.
I've been using GitHub for years but I'm still not proficient in using it. Especially when it comes to things I've never done. These were the first two Pull-Requests I've gotten, so I didn't know what the proper way of doing it was.
I also thought I need to first merge it before I can try it out and then maybe report what I found.
Please see my last commit message, my hooking into the AI needs improvement.Okay, the new PR doesn't crash and I could set up half my team as automated while leaving the other half controllable. I'm now trying to fix the issues caused by mixing AI-controlled and not AI-controlled soldiers in the same group.
Otherwise just let me know.Could you update your side with my latest changes and test the stuff a little if it works as you intended?
I definitely didn't want to deter contributors, so bear with me, when I appear a little incompetent about this stuff. I may have a clue about AI but when it comes to the whole code-management-stuff, I feel a lot less confident and have a lot to learn.
And, I don't know if it is available on the public part of github, but you can propose a modification directly on githubThe one thing I have seen is selecting a file and then something similar to hitting edit / the pencil and then some button like "save as new pull request".
add comments on the pull request.Definitely, right after clicking the pull request. I've seen at least Xilmi already found that too.
Could you update your side with my latest changes and test the stuff a little if it works as you intended?Thanks! I will definitely do, but you have to bear my slowness. It might take some days.
I did a bunch of testing, found a bunch of issues, hopefully fixed them now but there's a lot of new possibilities. It feels kinda odd to play with half units controlled by AI and other half not. Basically when you click one of the AI controlled ones, it acts. And if you click it after it acted, it immediately auto-picks the next unit and if you cycled with no reselect they will also end the turn on your behalf.
So while it feels weird, I also can't really think of a way to do it better that doesn't require a lot of changes and testing.If it does not satisfy you, you can always choose between
- Keep it and declare it an unsupported feature (maybe hidden behind a compile time constant too)I would just not enable it by default and this way the details about the implementation are not that important.
Could you update your side with my latest changes and test the stuff a little if it works as you intended?
Also: Someone made a very, very related feature-request on discord:
Specifically it was about enabling it for the robotic-units you have.
Since those do not appear in the soldier's menu, I guess I'll just add it as a separate option. But other than that the framework is already there.
Maybe you can use it, it would only need a further entry in Options.cpp / .h / .inc.h, and setting that in the non-soldier BattleUnit constructor to fulfill the feature request.
If that default value is used for all non-soldiers. How to distinguish between HWP, mind-controlled enemies and other units, I would need to find out by digging into the oxce code.You can check for mindcontrolled units by doing if(unit->getFaction() != unit->getOriginalFaction()).
There is a practical problem with Brutal AI that makes it go from hard to just play annoying: finding the last aliens sucks because unlike normal game they can stay in cover and not move, leading to motion scanners becoming useless, so for complex maps, you can easily look spending a hundred turns checking literally every nook and cranny if Bug Hunt mode does not activate. That is _really_ frustrating, especially if the enemy is not even dangerous to your soldiers.I guess the unit in question was either a melee-unit or a unit with a weapon that has a rather short range.
Maybe there should a special case for this situation? Always have at least one unit acting as a scout?
I toyed around with considering dead friends in the cuddle-Avoid-Modifier but eventually decided against it.I'm sorry, this reply will not be even close to structurized: I try to estimate experience with BAI from different perspectives the same time. I really want to keep this challenging, yet balanced to certain point of joy.
When BAI decides whether to go onto melee or not, it doesn't count weapon strength and estimated target's armor. I'll specify that bare fists count as melee weapon, too.It actually should do these things. I have a test-save for that with lobstermen vs. x-com that have melee-weapon and pistols.
Now, how weird it's to see that enemies try to punch a power-armored player's unit.
Not that it is unfavorable, but can be dice rolled, if not forcing BAI to assume armor/weapon check via cheat (cheating may raise the difficulty of gameplay, which is already a couple of tiers higher than vanilla), or more honestly, to check whether it works or not (damage/stun application check (yes/no) -> decides to switch weapon).
Edit: Question: Was this with his feature enabled?
Also: Can you provide a save where you think they should have used ranged-weapons but went for melee instead for testing-purposes?
- Is it possible to rebind the auto-combat key from Ctrl+A to something else? I bound WSAD keys to camera panning, hence doing Ctrl+A causes my camera to constantly pan left. Sometimes this problem doesn't trigger, but I am unsure yet how to prevent it.I agree, something other to turn it on or off would probably be good.
- Is it possible to say "do auto-combat only for this soldier, only for this turn" ?I think the request here is something like a button to just run AI for the currently selected soldier instead of having it controlled by a human. I think that would be nice. Would also be neat for debugging, so you can move soldier after soldier. I shall look into that.
I agree, something other to turn it on or off would probably be good.
I think the request here is something like a button to just run AI for the currently selected soldier instead of having it controlled by a human. I think that would be nice. Would also be neat for debugging, so you can move soldier after soldier. I shall look into that.
The dog is over here, and the turret is over here.
It's been standing here for several turns now.
And it will continue to be standing there for as long as the dog doesn't open this door.
The dog can go here and open this door for instance... nothing will happen.
But if the dog goes here, opens this door, the turret will move.
As such, somehow the roboturret knows where, uhh, the door is open there. [brain fart, meant to say the turret knows the door was open there]
Okay, I'm now positive the AI cheats in a major way in vision mode 3.This is not related to the vision-mode. It's related to opening doors, as you correctly assumed in your video.
if (door == 0)
{
_parent->getMod()->getSoundByDepth(_parent->getDepth(), Mod::DOOR_OPEN)->play(-1, _parent->getMap()->getSoundAngle(_unit->getPosition())); // normal door
_unit->updateEnemyKnowledge(_parent->getSave()->getTileIndex(_unit->getPosition()));
}Additionally, it only seems to react to the door that's very close. The door that's just a few tiles away in the same direction that I open does not cause the turret to react at all.This is likely related to the aggressiveness of the unit. Just knowing that a door opened doesn't mean the unit will go there to check. It only checks for the nearby door because it thinks it can attack whoever opened it. On a higher aggressiveness, it would also have gone for the unit that opened the other door.
Reporting two bugs with accuracy in release 7.6.4 [1]I'm going to investigate that, thanks for feedback!
Note the save file is from X-COM Files, which requires the original TFTD data.
Bug 2: when I aim at the deep one, the agent (Rafael Silva/Snpr) has 86% accuracy with aimed shot. But once I make the shot, the next one is 95%, without any terrain getting damaged.
Xilmi, one more thing I found out:Do you have a save from that mission? I'm pretty sure I know what causes this issue and how to fix it. I just didn't have a practical example for toying around with it.
dogs, werewolves etc. have barking/howling attack, which is ordinarily used to damage TU, morale and reactions, rarely causing stun reactions.
BAI tends to prefer this over convenient claws/jaws, which damages HP.
Recently I've got the mission in X-Piratez where I had to deal with 9 werewolves barehandedly (don't ask why, it's insanely deep lore of XPZ), and they were running around me and howling.
No, it doesn't. I can't even think how it could work. ;)
@jnarical thanks for sharing and very quick bugfix! Very interesting analysis.
"The AI shall no longer attack targets that it cannot harm at all and instead spend their time-units on something else." -Now that you mention this, I realize that I didn't think this through fully.
How is it checked?
If by trial and error, then will it be that barehanded naked guys will flee from power-armored crew?
Firstly it checks this via the scoring-algorithm that also determines who to attack. There it calculates the assumed damage based on their weapon-damage, the targets armor and the targets resistances.That's convenient, but does it:
A mission vs ghosts that can only do CHARM damage. (it is similar to daze and inflicts stun.)I think this whole endeavor is pointless, attacks are effective "Turing complete" (if someone allow AI to have weapons with complex y-scripts attached).
Indeed, now AI doesn't use it, preferring to hide or run around, whereas in vanilla it just spammed charm spells until whole crew is unconscious.
I, in person, think that AI still doesn't realize that driving whole enemy squad unconscious is victory condition, too.
Of corse this will not fix problem like energy shields that are vulnerable only to specific weapons types.Of course, that's what I come up to during the analysis of possibilities: if modder (universe's God) gives something to the unit, it is purposeful and should be used.
One more "bug" report: enemy turrets don't shoot. I haven't checked 1x1 turrets, but 2x2 turrets, which are supposed to be the most troublesome enemy in specific missions (and during the base defend at the side of player too), just stay looking at same direction with no particular action.This must have been broken since I introduced the AI checking for hiding-spots before moving. I fixed two AI issues in relation to the turrets now. But I'd pass this save on right to @jnarcical, as after fixing the issue and testing, the turret was unhittable with "Realistic accuracy"-mode, despite the AI thinking it was hitable. So there was once again a discrepancy between the logic of the AI and the logic in the game.
With BAI turned off works as intended (seeks targets within line of sight and perform shooting).
I checked the stats of turrets, if this somehow helps: they all have some amount of TU (32-100) and 1 energy (immobile), with shooting cost flat % (like, 40% for chaingun turrets, 55+% for battle tank, which is this mission). Turning the turret costs some TU.
Savegame is attached (XPZ).
As turrets are common and most strong enemy in early & mid game missions, this is vital issue.
As turrets are common and most strong enemy in early & mid game missions, this is vital issue.
I found a discrepancy between displayed accuracy number and "internal" accuracy, I get the reasons of that pretty wrong - I thought that the issue is caused by displayed accuracy calculated in 3D-space, but "real" applied accuracy calculated in 2D (which is true and looks like as obvious bug to me). As it turned out, displayed accuracy also 2D-based, and moreover - 2D "real" accuracy is intentional. So, UFO Extender accuracy doesn't take into account vertical distance. From the game' perspective, distance to adjanced unit is the same as distance to a unit 10 levels higher. Meridian doesn't count that as a bug.
Also, calculations for displayed accuracy and "real" one is totally different and give different results. Sometimes you see 50% accuracy on screen and it's true, sometimes "real" accuracy under the hood differs due to different algorithm. Meridian doesn't consider that as bug too.
So I closed my PR to OXCE, but for "real accuracy" mod the problem still persists and I'm looking for solution.
If you look at the OXCE code (not OXC code), I have even changed the displayed accuracy to be 3D, not 2D. Already years ago.My bad. Very bad :) I was sure that code wasn't changed. I'm working with OXCE-based code but decided to make a PR to OXC. To be honest, yesterday I was looking for my closed PR in OXCE repo ))))))
It is also mentioned in the thread with differences between OXC and OXCE.
....
You have not made a PR to OXCE.
You have made a PR to OXC.
Your solution was however both wrong and incomplete, that's (also) why it was rejected.That's true. Starting with my wrong understanding of reasons for the issue.
Personally, I most certainly count that as a bug.I get it wrong, again, but that doesn't matters... I consider UFO Extender accuracy as legacy, I cannot change it to something totally different.
I have also written that a 100% correct solution doesn't exist in all cases (due to RNG), which is why I abandoned the idea of fixing it in OXCE.You're most probably talking about vanilla applyAccuracy(). UFO Extender accuracy number represents real applied one kinda approximately, That's not fixable in current state, that's why I've reworked accuracy mechanics to the very bottom, making it determined. Now RNG depends on accuracy number, not the other way around. And that makes it possible to use the same algorithm in Map::drawTerrain() and in applyAccuracy().
But if you are OK with just a partially correct solution, you're free to partially fix it in your version.
You're most probably talking about vanilla applyAccuracy(). UFO Extender accuracy number represents real applied one kinda approximately, That's not fixable in current state, that's why I've reworked accuracy mechanics to the very bottom, making it determined. Now RNG depends on accuracy number, not the other way around. And that makes it possible to use the same algorithm in Map::drawTerrain() and in applyAccuracy().
I don't want to roll out new version in it's current state.I've changed my mind. It'll take some time to make everything right, so I've just uploaded the fix.
Bug 1: Have a look at the attached screenshot. You can see the debug log saying my agent (standing on the right) hit the deep one (standing one the left) but it is not true - the shot actually hit the tree. Right in the middle.Fixed. Current state (in my repo) - fixed 3 bugs, tanks in x-piratez are killable now (maybe too easy, but what do you want from rocket launchers with accuracy > 150 while kneeling?)
V7.6.6. Threw a proximity grenade under reaper's feet. But reaper was smart, and thew (kicked?) grenade away, somehow not triggering proximity (well, it didn't move before throwing, smart creature). A couple of turns later a civilian stepped on said grenade, blowing him(her?)self up. Then I realised that grenade was thrown into my equipment pile. Smart reaper. Civilians were also controlled by Brutal-AI, which leads me to beleive they cooperated with aliens. :)Aliens picking up and throwing proximity-grenades that land on their tile is intended. But I think units probably have a flag of whether they can pick up stuff which is apparently ignored by the AI. Pretty sure reapers shouldn't be able to.
Now, I'm working on voxel-to-unit distance algorithm, which would be voxel-based - that will change the accuracy more gradually. Algorithm should find the shortest path to a target cylinder (not tile).DONE! Works like a charm, consistently, gives distance in voxels. Perfectly aligns with numbers calculated “by hand” on paper. It’s really cool to see that distance for shooting “from below” is less than “from above”, as weapon barrel is closer to the top of a tile. And even more cool to see that similar fire positions relative to target give totally equal distances. It’ a win)
tanks in x-piratez are killable now (maybe too easy, but what do you want from rocket launchers with accuracy > 150 while kneeling?)The thing is, battle tank with the select box "sunken" into the chassis is the only tank and only mission in the whole giant mod. It might be done in such fashion to be harder dealt with, if not for basic defense from below. It also may had been done so player had to use his brains to deal with it. It's "challenge mission", too, btw.
I wanted to ask you, regarding your improvements in shooting mechanics:I've tested your save, it works with "real accuracy"=ON pretty like it's intended to. Do you mean the situation when "real accuracy" is OFF, and "ufo extender accuracy" is ON? If that's the case, I can make it clear for you. There's no such thing as "legacy hit chances", honestly. There's accuracy number, which is basically unit's accuracy * weapon accuracy with particular shot type * 1.15 if kneeling * 0.5 if no line-of-sight * 0.8 if weapon is two-handed but there's something in second hand... and some penalties for wounds count and per health percent left. if a unit has 100 accuracy, weapon has 65% base accuracy for autofire, and unit is kneeled - you get 100*0.65*1.15 ~= 75% accuracy. For some fixed UNKNOWN distance to a 1-tile target, that would mean roughtly 75% chance to hit. For any other distance, or for a bigger target, chances would change drastically. But most important - there are no known numbers at all, just like no known method to calculate them. That's what can be said about vanilla accuracy.
can it be done in such way that legacy hit chances stay in place (e.g. extender accuracy, because all firearms had been balanced with it in mind), while weird stuff, like missing all twelve 140% shots, because bullets fly through the sprite, but don't hit the actual voxels, got solved? This mostly happens when enemy is either near the wall (while your soldier shoots from parallel position to it), or near the border of the map, or behind the opened door, or behind a stick pinned into the ground and so on. That's really frustrating.
The save is attached, soldier is facing the ninja, which is adjacent to map edge.
From this position, and from one tile diagonal closer it weirdly misses.
Don't get me wrong, your accuracy modification improves close-range shooting too well. And that's why I think it affects the balance (had it checked, too, vs plasma autofire enemies, and I thing there should be misses in the queue. Literally all plasma shots hit my soldier and I was upset. That's not what I got used to!). There's not only mechanical issues why things miss (aside from weird voxel issues) - each turn in X-COM is similar to 6-8 seconds in real life. Thus, hand tremor can justify three misses with 60% hit chance. Or four with 70%, rarely. But not twelve with 140%).Close-range accuracy could be changed, for sure. I just can't figure out the exact formula... I can add "maximum accuracy cap for close-ranged shots" to the options menu, but I don't personally like that idea. And I can't reproduce vanilla chance to hit, as there are no option to know that chance other then statistical experiments )) But I can say for sure, that chance has nothing to do with displayed accuracy, and always was much higher than it.
weird stuff, like missing all twelve 140% shots, because bullets fly through the sprite, but don't hit the actual voxels, got solved? This mostly happens when enemy is either near the wall (while your soldier shoots from parallel position to it), or near the border of the map, or behind the opened door, or behind a stick pinned into the ground and so on.Maybe vanilla accuracy algorithm has some corner cases, which become visible in X-Piratez cause the game wasn’t designed for such extreme numbers
There are no known bugs when your shot fly through the unit but not detected as hit.
Other than that... I can't make a mod, which would be balanced against all other mods. I totally don't want it to be balanced against one particular mod either. All it has to do is to show CORRECT accuracy numbers which align with real chance to hit. If there's 1% then it should hit 1 time of 100, but not in a way "I counted 99 misses, the next one should be a hit". And I'm afraid I can do nothing to make it align with, I'd say, such STRANGELY balanced mod as X-Piratez.I assure you that in 99,5% cases both BAI and your mod will be used in mods.
Actually, there is, and when real accuracy is off, and extender is on, I simultaneously see the cases when supposed 100% shots miss and projectiles fly through the sprite, not hitting the voxel itself.As I've said, "projectiles fly through the sprite" doesn't mean anything. Sprites don't represent voxels. Unit is just a cylinder in voxel-space. Grab some paper and pen, draw a rectangle with width=5 and height=16. That's sectoid proportions from the base game. Width=5 means that his "diameter" is 1/3 of a tile width, or he takes 1/9 of tile's area. Than look at his sprite, with huge head. Shot WILL fly through and that's not a bug.
As for the balance - if there's indeed no clue of how close-range shots affected by extender accuracy, may we talk with the designer of this? You see, it's kind of magic and fits game very well.As I've said earlier, extender accuracy almost does NOTHING. You can look at the picture, I highlighted the block where "ufo extender accuracy" actually applies. As you can tell, there's a drop-off for accuracy below the weapon minimum distance, and above the maximum one. And that's in VANILLA code. Extender accuracy just adds different maximum distances for auto/snap shots. That's all. Another place where it matters - in drawTerrain() code, 'cause there should be a way for a player to see how the accuracy changes for different tiles - so it draws modified accuracy near the cursor.
The question: what actual mechanics are, both in your mod and extender?In vanilla(extender doesn't affect anything here) it's cone based, in a wierd way. All the code is on second picture. You can tell by yourself, that while it's obvious where and how accuracy is used in calculation - there's NOTHING you can tell about actual chance to hit. That code gives unnatural kind of distribution, where you either hit the squirrel right to the eye from 10 km away, or you go full startrooper mode hitting any point of the cone with (almost) similar probability. That's why misses in x-com are so unnatural. On this gif you can seen probabilities distribution for 0/25/50/75% accuracy: https://www.ufopaedia.org/images/1/16/Accuracy_areas_above.gif (https://www.ufopaedia.org/images/1/16/Accuracy_areas_above.gif)
Is it cone mechanics, or just pure formula-based pre-hits (mean, system rolls 1 hit out of 10 and then forcefully pulls 9 hits to the random tiles around the target?)
And, one suggestion for your accuracy mod:3D in this game is implemented with very low resolution, that means there's often one huge occassional voxel blocking LoS/LoF. To counter that, off-center shooting was added. There's no need to add penalty, as well as balance accuracy with such detail in such low-detail game. There's always something to be done elsewhere, to a greater benefit.
If it checks several points of shooting before deciding which fits best, shouldn't this also affect accuracy?
имени.pnghttps://t.me/jnarical (https://t.me/jnarical)
weird stuff, like missing all twelve 140% shotsI've just tested in "default OXCE", it hits 10/10 there. I've got a regression somewhere, investigating...
https://t.me/jnarical[/url]I may use that way, but it is very convenient to write all suggestions and questions here on forum because some other players may join the discussion.
I just added a new feature: Fog of war.
I really like this new feature, would it be possible to take into account the smoke for fog of war?That's not so easy for the reason that smoke only impacts vision on units but not on tiles.
That's not so easy for the reason that smoke only impacts vision on units but not on tiles.
So tile-visibility-data can't be taken "as is" for this purpose.
I'm no longer actively pursuing OXCE-integration. If they want to have it, they can feel free to include it though. And that goes for everyone who wants it in their fork.
...
@Xilmi, What is your perspective on the mod compatibility with XCF? Would it be reasonable to expect the Brutal-AI's behavior -- aside that from inside the tactical missions -- differing from the mainline OXCE when XCF is loaded as the master mod?While waiting for Xilmi's response, I can comment as a player.
@Xilmi, What is your perspective on the mod compatibility with XCF? Would it be reasonable to expect the Brutal-AI's behavior -- aside that from inside the tactical missions -- differing from the mainline OXCE when XCF is loaded as the master mod?There are two optional changes for the geoscape-level-behavior. One, as Meridian already mentioned is related to aggressive-retaliation.
Sometimes I hope Xilmi makes a switch for enemies to reserve more TU's for reaction fire. Or even whole TU's after getting to the snapshot position. Because otherwise it's too easy to camp enemies that are coming closer each turn.What exact settings are you using?
Hi. Will you ever port your mod to Android?Whoever is capable and willing to make a build-environment for that, is allowed to do it. I'm just not incentivised enough to do it myself.
Okay, I'm now positive the AI cheats in a major way in vision mode 3.Little heads-up for you:
What exact settings are you using?
The default "Enemy aggressiveness" of 2 shouldn't produce such behavior.
But if you use a higher value or enable "Inherit unit aggression", the AI uses the unit's aggression-setting to enact certain behaviors, which likely are sub-optimal from their perspective.
If the AI is easy to camp on "Enemy aggressiveness" of 2, then it's something I shall take a look at. If it happens on the aforementioned settings, then it's kinda intended for those.
This comment may be outdated, because last version of BAI I played with was 7.6.8.I highly recommend using the most current version, which can be found here:
can I enable the AI on the fly during a battle? say once I get into the battle and realize its creatures, then leave the Brutal AI disabled as it was set previous to the battle.I personally think the answer is “yes”, but not 100% sure. But you can check by yourself. Start custom battle, press CTRL+D for debug mode, make several turns watching aliens play, then disable Brutal AI and continue watching. The difference should be obvious
but if the Brutal IA is off, then enter a battle and realize it's a cult or an alien race, then enable the brutal AI for that battle?
Wow, really good work on improvements and new game-play.Thanks for the kind words! :)
Sorry if this is already asked, or a feature, but is there anyway to set the brutal AI individually for each race?
can I enable the AI on the fly during a battle?As jnarical correctly assumed the answer is yes.
Thanks for the kind words! :)
For the most part the answer is yes.
Let me quote from the 1st-post in this threat:
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 wish for their players.
The files to edit for that is "units.rul"
You can add the following:
"isBrutal" (true/false)
"isCheatOnMovement" (true/false) (equivalent toomnisciencebug-hunt-mode for brutal-AI)
"aiTargetMode" (equivalent to Targeting behaviour for Brutal AI)
The global Brutal-AI option needs to be switched off for that as otherwise it would take precendence.
I haven't added every single option to the units themselves since there wasn't really much demand for that feature until now. So the options I implemented later, like the proxy-avoidance one is missing there. Actually it might be the only thing missing as for the aggression-settings you have the inherit-option and isLeeroyJenkins is also taken into account when inherit is enabled.
Edit: If you only set "isBrutal" in the units.rul, it will use defaults/global-settings for everything else.
Edit2: It's not per species but per unit-type though. So if a mod has many units across many different files, it might be quite laborious to manually switch it on or off for each individual unit-type.
This sounds too specific and too much like a "one person wants that"-feature to me. So I suggest to make your own fork and implement it like that if you really want it.
I haven't added every single option to the units themselves since there wasn't really much demand for that feature until now.There is demand and many other players watch into BAI to use it.
And, a gentle reminder for list of quality of life changes from the player's perspective:Casual players have no idea too how balance AI, to do it you need spend months testing and seeing if given set of configs is correct.
- most casual players never go into code. That's why, I believe, it's better to take advanced configurations into options menu.
Hi, I'm using this to play XCF, and I can't find the option to pre-prime grenades. There's one for saving your pre-primed setup, but not to enable it. Right click in pre-battle does nothing. Am I missing something?As far as I know you could always just pre-prime-them pre-battle. What I added is an option under Advanced=>Battlescape called "One-click grenade priming", which is what allows you to do it much faster as you don't have to select a number on the timer (it will always default to 0 with this option).
Edit: And of course now that I posted this it works. I had this problem for days but now suddenly it works after fiddling with the options. So ignore this I guess.
I wonder, what set of config flags you find to be most optimal when playing your sessions?Do you mean in regards to performance or for gameplay?
When it comes to gameplay, I pretty much go with the default-configuration for AI, which is the default because I think it's the strongest that doesn't cheat yet. I also enable "Aggressive Retaliation", which is different than in basic-OXC/OXCE in that it normalizes the search-pattern and also triggers off successful landing-missions and "Enhanced Dogfight Behavior", which makes it so that you can't outrun faster craft once you have engaged them.
Do you mean in regards to performance or for gameplay?
If the AI calculations are slow that is on me. I've done quite a bunch of things to optimize it but things like the analysis of where there is good cover or what are good locations to attack from will slow it down noticably. The option "Perfomance optmisation" reduces the amount of tiles analyzed for seeking cover. It especially has an impact on flying units, who would otherwise also consider all possible locations they could move to. Units like the bats for examle with very high TUs sometimes analyze like 6000 positions on the map otherwise.
When it comes to rendering-performance I know that stuff like light-propagation is an issue, especially with increased viewing-ranges (40 instead of 20 tiles). OXCE (and thus also Brutal-OXCE) should be quite a bit better at that than regular OXC, since the OXCE-guys put a lot of effort into optimization in this regard. But there's still potential. Modern games do these things with using all of the hardware, especially the GPU, which I believe OpenXCom makes no use of. I personally lack the expertise in that regard and imagine it would be a gargantuan task, even if I had the expertise. So I can't really improve it.
Do you mean in regards to performance or for gameplay?
If the AI calculations are slow that is on me. I've done quite a bunch of things to optimize it but things like the analysis of where there is good cover or what are good locations to attack from will slow it down noticably. The option "Perfomance optmisation" reduces the amount of tiles analyzed for seeking cover. It especially has an impact on flying units, who would otherwise also consider all possible locations they could move to. Units like the bats for examle with very high TUs sometimes analyze like 6000 positions on the map otherwise.
When it comes to rendering-performance I know that stuff like light-propagation is an issue, especially with increased viewing-ranges (40 instead of 20 tiles). OXCE (and thus also Brutal-OXCE) should be quite a bit better at that than regular OXC, since the OXCE-guys put a lot of effort into optimization in this regard. But there's still potential. Modern games do these things with using all of the hardware, especially the GPU, which I believe OpenXCom makes no use of. I personally lack the expertise in that regard and imagine it would be a gargantuan task, even if I had the expertise. So I can't really improve it.
What is the default configuration specifically? Particularly, the settings aiTargetMode, aiAggression, autoAggression, cheatOnMovement?aiTargetMode => 3
I still have not seen if the retaliation stops after N attempts or not. What is the actual behavior in that respect? Would the attempts continue to infinity?No. If you survive a retaliation-attempt the retaliation-mission ends and you have to trigger a new one. No infinite retaliation-attempts. It's just easier to trigger them and they are better at finding your base.
I think, it has never been possible to outrun a faster craft. Certainly not when those are on hunt/pursuit.Note this relates to dogfights, not what's happening on the geoscape. By "outrun" I mean an Interceptor with 2100 kph keeping an UFO with 3200 kph out of shooting-range. The UFO will now be able to close in even if you do a distant-attack and you can't just retreat either.
Are there any principal obstacles to increasing the graphics resolution in game? Also, what is the underlying model in the tactical game? Is it just a region of space split into relatively coarse-sized voxel cubes?Well, I guess the obstacle is that this is not a commercial product and everyone who worked on it did so without compensation in their free-time. So people lack the expertise and/or willingness to improve it beyond of what it currently is. It's open-source though. So if you have the expertise and are willing to rewrite the engine in a way that makes it run more quickly, uses multithreading and gpu-features, no one is stopping you.
So if you have the expertise and are willing to rewrite the engine in a way that makes it run more quickly, uses multithreading and gpu-features, no one is stopping you.
The underlying model in the battlescape is a voxel-engine. Each map-tile consists of 16x16x32 voxels that are calculated internally for stuff like lines of sight and fire. Sprites losely represent the voxels of the shown objects. Sometimes better sometimes worse. The engine is also a replication of the original from 1993, which worked in the same way.
I wonder, what causes a behavior, when an enemy approaches a trooper who is stronger in melee, then goes back a couple of steps, then approaches, etc., until it runs out of TU. This looks like a waste of points. And, this feels like taking advantage of a retard on disability when trying to play hard-edge ninja tactics with Kill-Bill-style melee scenes inside the rooms.Well, these behaviours are not intended and qualify as bugs. 7.7.7 supposedly fixed at least one reason for behavior like this. If it still occurs, please make a save, attach it here with your options.cfg and mention of the mod(s) that were in use and ideally give me some reproduction-steps. This way I can analyze and hopefully fix it.
I also occasionally see enemy troops going back and forth along a line. Is it possible to eliminate such behaviors? What could be causing them?
However, for more advance features, I think it may be better to implement those as external plugins -- the separate processes that need not be a part of the game's code base. How challenging would it be to setup an external AI engine, and game control? That almost sounds like external debugging, in fact.I may be the wrong person and this the wrong thread to ask questions like this.
I may be the wrong person and this the wrong thread to ask questions like this.
I'm just the author of this particular mod and relied on the made nest provided by others who came before me. Sure, I have dabbled into the engine a little bit too. And at least to me it was indeed quite challenging.
I've been working with the OpenXCom-code for a little over a year now and still don't feel competent enough to answer questions like these.
@Xilmi,
I noticed that in XCF mod soldiers with very high accuracy could use BlackOps auto-sniper rifle to demolish enemy troops in Power Suit and Shock Armor outfits. This must be the effect of powerBonus.
- I wonder, if it may be possible to somehow specify the maximum effect that a damageBonus may have on the damage?
- I also wonder, if it may be possible to spill over (configurably) any extra damage into the relevant damage multiplier?
- I think option (1) without (2) is probably the best solution, since frankly there's no way a most optimal and efficient rifle bullet could more than scratch a walking tank outfitted with alien armor.
@Xilmi,Isn't this something you should talk about in the XCF-forums? This really doesn't sound like something related to AI.
I noticed that in XCF mod soldiers with very high accuracy could use BlackOps auto-sniper rifle to demolish enemy troops in Power Suit and Shock Armor outfits. This must be the effect of powerBonus.
- I wonder, if it may be possible to somehow specify the maximum effect that a damageBonus may have on the damage?
- I also wonder, if it may be possible to spill over (configurably) any extra damage into the relevant damage multiplier?
- I think option (1) without (2) is probably the best solution, since frankly there's no way a most optimal and efficient rifle bullet could more than scratch a walking tank outfitted with alien armor.
Isn't this something you should talk about in the XCF-forums? This really doesn't sound like something related to AI.
The main problem is not that the bonus damage is large and solving this with some kind of limiting crutches is simply stupid.
The problem is the spread of damage itself. 0-200 is too inadequate a spread, at which it is possible to penetrate medium armor with a simple pistol.
I tried playing XCF with 0-200 and with 50-150 and I can say that in the second case the armor actually feels like armor, and not cardboard, which helps exactly until the first big damage roll. Take a pistol with 25 damage, the maximum throw will give 50 damage and when you shoot at a armor vest, which has 28 armor in the forehead and 30% absorption, we will get 35 damage, which will wound for 7 hp. I won’t even mention getting hit in the side.
Could you consider a case of a pistol with the same spread, but lower armor penetration set by increasing armoreEffectiveness? Pistols could cause pretty powerful damage to unarmored targets in general, and are much less efficient against armored targets. This applies especially to higher grades of armor.
My question is would you rather edit the individual parameters and tweak the armors in the mods, or solve the issue with an extra parameter? Why?
If you don’t have any ideas about identifying monsters that need to disable brutality by default (such as werecats), as a last resort, we can manually register them all and attach them as a base mod. I will still add it for XCF. But, of course, with new monsters we will need to constantly update the list and this is not very convenient.
1.Randomly mixing up BAI- and VAI-missions most likely has the following effect: The player determines the most effective way to scout out whether they got BAI or VAI and then retreats from the BAI-missions.1. Not that it would happen, really. Mods have aspect of:
2. Mixing BAI and VAI-troops in a single mission would be a lot more reasonable to achieve this kind of effect. Currently it's only possible to assign this on a unit-type to unit-type basis but not randomly.
If you don’t have any ideas about identifying monsters that need to disable brutality by default (such as werecats), as a last resort, we can manually register them all and attach them as a base mod. I will still add it for XCF. But, of course, with new monsters we will need to constantly update the list and this is not very convenient.I had an idea and it is implemented via the "Brutal Brutes"-option.
I mentioned the pieces that may be done by editing the mod definitions. However, one of the approaches to solving these weapon definitions problems is to limit the weapon power through a parameter. Basically, I'm asking if you think that a new parameter maxPower or similar could be added to that end.I mean in theory something like that could be added. But the power of a weapon is clearly something that is data-driven and deliberately picked by the modder according to their intentions. An in-game-option to overrule weapon's power is possible but highly counter-intuitive for that purpose.
1> Dynamic aggressiveness. => AI-controlled units dynamically adjust their aggressiveness based on their morale. The thresholds are:
= 100 => 4
= 83 => 3
= 67 => 2
= 50 => 1
<50 => 0
Will check this, sounds pretty interesting.I made an adjustment to how aggressivity 4 works yesterday. It now is distinct from the behavior expressed by Leeroy-mode.
In general, this function of morale + some personified adjustments of soldier ranks would do super in terms of battles diversification.
There will be another option to pick it up and throw it back, or just put it in inventory, but this will also cost TU a lot and may have its own additional risks. And no one will write AI for this, so only the player will have access to this moment.
void AIModule::tryToPickUpGrenade(Tile *tile, BattleAction *action)
{
if (!_unit->hasInventory())
return;
for (BattleItem *item : *(tile->getInventory()))
{
if (item->isFuseEnabled())
{
if (_save->getBattleGame()->takeItemFromGround(item, action) == 0)
if (_traceAI)
Log(LOG_INFO) << "Picked up " << item->getRules()->getName() << " from " << tile->getPosition();
}
}
}*cough**cough*I apologize if I expressed my thoughts unclearly. I meant there was no way to quickly activate grenades. I want that during ACTIVATION, which is performed as usual, the timer for grenades is not set to 0 rounds (instantPrime: true ) (explosion at the end of the current team turn) and not to select how many rounds the timer will be. And so that it is placed strictly for 1 round for both the player and the AI.
No, you can't preprime automatically once you left the pre-battle stage. By using hotkeys you can to it relatively quickly manually though.
You can open the inventory drag it to the hand, hit tab and repeat until you're done.
Then you e-1-tab through all your units. The option "One click grenade-priming" needs to be enabled otherwise it needs an additional click. But yes, it requires TUs. You can also activate auto-play for one turn and hope it does prime a few grenades.
Other than that I'm not really sure what you are getting at with your post.
Please tell me if there is any way for a player to arm grenades for the player and opponents automatically on turn 1, not 0? Or maybe you can add a turn 1 option to the automatic grenade arming option.'fuseType: 1'
Well, yes, I'm tired of dynamites thrown from 20 squares, which are almost guaranteed to kill the whole team.'throwRange'
I want to make grenades into grenades. So that their goal is to destroy shelters, scare enemies away and cause damage to those who simply remain in place.Eh, IRL grenades don't really destroy cover. Some types (HE, dual-purpose, thermobaric) do degrade it, but the common frag grenade is exactly meant to be used from cover that will protect you and not the enemy.
The one-click priming option can indeed break some grenades, but for the most part it’s more convenient.
It seems to me that most of the grenade changes are more of a ruleset thing rather than anything to do with AI.
'fuseType: 1'
Honestly, the one-click priming option looks kind of like an end run around existing game mechanics and might actually be counterproductive, depending on mod and grenade.
'throwRange'And even more of ruleset. It will take some time, and I won’t notice everything right away, but setting it up is not a problem. Thank you very much for the good solution to both points.
I was much happier once I changed all grenades to 'throwRange: 12' and big explosives to 'throwRange: 6' or even 'throwRange: 4'. So many people seem to think the absolutely unrealistic throwing ranges and accuracy are a core part of the OG X-Com experience... But I've ranted about this before. :(
Eh, IRL grenades don't really destroy cover. Some types (HE, dual-purpose, thermobaric) do degrade it, but the common frag grenade is exactly meant to be used from cover that will protect you and not the enemy.The game actually has problems distinguishing between what types of effects grenades can have. I think the closest variant of a frag grenade in the game is shrapnel, which weakly destroys the area, but is very good at breaking things and killing all living things.
X-Com doesn't really distinguish between frag and HE too well unless a modder is into it.
Ctrl-clicking items in the loadout-phase will prefer slots that are faster to reachBrilliant! Now it won't ignore quick-draw slots and would not throw everything into backpack.
Intelligence-modeNot sure it is clear from description what intelligence is and how it works.
0> Static intelligence. 1> Inherit intelligence from unit-intelligence. 2> Inherit intelligence from difficulty-level.
The second allows you to pick an intelligence-level for the case static intelligence was selected as Intelligence-mode:
Static intelligence
Chance to make a smart move instead of a random one: 0> 0% 1> 20% 2> 40% 3> 60% 4> 80% 5> 100%
I set up a game of X-Com with a rifle and a grenade for each soldier against lowest tech sectoids.For statistically determined results there should be, at least, 100 rolls for every intel level. Nevertheless, this is quite interesting. I believe sometimes randomness can disrupt and counter AI expectations.
It also used Joy Narical's realistic accuracy.
The more intelligent the aliens are, the better their results.
But then came the test at Int 2, which was a total outlier.
Brilliant! Now it won't ignore quick-draw slots and would not throw everything into backpack.This isn't the first QoL-change I made. It's the third one actually:
I haven't thought QoL changes are area of your interests, thus never suggested something like that.
Not sure it is clear from description what intelligence is and how it works.Well, it is three different modes. So the answer to your questions is yes or no depending on what mode you choose.
Intel for each unit? Mean, current unit has a chance to deviate?
Intel of whole fraction? Like top-tier fractions are smart and some bandits are less smart?
Where exactly intel level of units is defined?
How exactly difficulty level affects intellegence? If I play hardest difficulty, will zombies and dogs use 100% smart moves instead of random/vanilla ones?
For statistically determined results there should be, at least, 100 rolls for every intel level. Nevertheless, this is quite interesting. I believe sometimes randomness can disrupt and counter AI expectations.I know, statistical relevance of one test-run is pretty low. That's also not training the AI based on itself, that's just benchmarking. For benchmarking it, I need something that is constant and something that isn't. My own play obviously would deviate, the AI with a static setting should act the same every time.
I would also suggest that AI shouldn't be taught on AI, but instead on human leather player playstyles.
Hm. If there only was a battlefield move logger, then you actually can have a lot of materials to teach the AI from those who would love to contribute.Enabling the traceAI-option in options.cfg logs all the moves and also parts of the "thought-process" of the AI in the log. But this is very dependant on context. A lot of the contents of that log are only ever useful if at the same time I have the map open so I can see what coordinates corresponds to what position. A mere log of what they do without seeing the map would be next to useless. A log of what the player has done even more so.
But as every new version make older one obsolete, logs should be pretty fresh. Is there a way to save the map and everything happening? Will it be massive? Will it actually help?
I'd really like to see QoL improvements make it into mainstream OXCE, to benefit also non-BAI users. But I suspect some of these might be contentious and non-trivial *), so I understand that this might not be a priority for Xilmi.It wasn't my idea to have a separate repository. It's the result of the OXCE-team not wanting experimental-changes, even if those are completely optional. These requirements were incompatible with AI-development, which is an iterative process.
Intelligent placement will only work to some degree if you assume the biggest and most relevant items are added first. Adding 1x1 sized objects to optimal places afterwards is a trivial (but very nice) improvement, and the big challenges arise when you place larger objects, the usefulness of which also depends on its purpose.It is indeed as you say. If you don't start with the main-weapon but for example a medikit, it will put the medikit into a hand-slot because the hand-slot is still free and according to the algorithm the hand-slot is the fastest slot to take something into your hands from because the TU-cost for that is 0 since it's already there. The algorithm just assumes you start from the most important and work down to the least important item.
So I could see that at least some improvements might be resisted in OXCE with an argument that doing so would create an endless need to finetune the placement algorithm.Yeah, as I said, this is a real risk but at this point not even my main reason not to try it.
Rereading what you wrote seems like you mean some sort of replay-mode. That would also help if it existed, I suppose but it would lack the explanatory elements of a narrated video.Yeah, I believe so. The thing I kept in mind was definitely reply mode, and your comment towards narrative of actions is quite a thing we are always forgetting: no one can read the minds of other, we can only suggest what is real matter behind the words and actions.
It wasn't my idea to have a separate repository. It's the result of the OXCE-team not wanting experimental-changes, even if those are completely optional. These requirements were incompatible with AI-development, which is an iterative process.I guess the time, when everyone wasn't taking your approach seriously has long passed. You do it consistently and thoughtfully.
This sounds too specific and too much like a "one person wants that"-feature to me. So I suggest to make your own fork and implement it like that if you really want it.
If you only set "isBrutal" in the units.rul, it will use defaults/global-settings for everything else.
It's not per species but per unit-type though. So if a mod has many units across many different files, it might be quite laborious to manually switch it on or off for each individual unit-type.
This isn't the first QoL-change I made. It's the third one actually:
1. One-click-grenade-priming
2. Manufacturing items only uses workshop-space once you actually start working on it and not alone by queuing it
3. The new smart-inventory usage
Basically whenever something really started to annoy me and could be solved with some code-changes I eventually ended up making these changes.
I am thinking of making another playthrough when newest version of XCF or XPZ comes out, with time-to-time videomaking. It will mostly describe in-game logics and will be AI-centered.Yesterday I made some further small improvements in playing-strength especially at lower aggression-levels but also in general due to better hiding after shooting. This makes it harder to successfully throw a grenade to where the shots came from.
I still think that very best solution for super-immersive BAI gameplay is making manual adjustments for each unit.Sure, manually tweaking each unit individually probably will show the best results. And whether this is done in a text-editor or with the help of a yet to be developed tool, doesn't change that this would be a rather laborious task. I don't see myself writing a modding-tool. If someone else does so, then fine. Wouldn't be surprised something like that already exists, considering tools to edit MCD-Files also exist.
- what do you think of some sort of interface (see below) that helps to operate with intelligence balancing?
It parses everything into one table, and able to modify .rul file regarding all intelligence, aggressiveness and other viable stuff. It doesn't need to be updated if new unit is added by modder, because it finds it automatically with each activation. When operator changes values and clicks apply button, interface modifies rule file.
So instead of adjusting spawn-rate based on enemy-difficulty,You most probably took me wrong. I was suggesting that if intelligent units are now harder to beat up, non-intelligent units, that are supposed to keep vanilla-behavior should spawn more to compensate the difficulty reducing gap. And, personally, I would prefer such tool because max (like, 100 units on map from diff 4/4) spawn is unachievable, as only BAI diff 2/4 and 3/4 are actually beatable by players, depending on their skills.
the reverse approach could be used and enemy-difficulty could be adjusted based on spawn rateIn short, I don't see how that would make true experience.
Sure, manually tweaking each unit individually probably will show the best results. And whether this is done in a text-editor or with the help of a yet to be developed tool, doesn't change that this would be a rather laborious taskIf anyone will solve the parsing option and basic interface, I can tweak them to be most psychologically veracious. It's not that much of units. Like, 150-200, or so. And we can better call Sol for XCF insights. Right?)
I think that you lack previous (vanilla) OXCE gamer experience, thus miss some nuances.Well, this is definitely true. I played through the base-game twice when I was a teenager and this is it, when it comes to my experience with it.
By nuances, I mean that some unit behaviors seem too artificial or irrelevant to the story.Can you give me an example for behavior that is "relevant to the story"?
Another one is unit move grid: if they chase and attack, they take precise anti-grenade range from each other. And this is fully frustrating, because player understands that it is true robot behavior.Well, this is something I incorpoarted in my own play aswell. But it's also something that I could easily put behind another option. Maybe even the same one that avoids stepping onto proxies. Or maybe I could put all the bool-options into one and call it "Advanced tactics" - "The AI is smarter about using and playing against explosives". This would be preprime-grenades, greandes on turn 1, avoid proxies and the "cuddle-avoid-modifier", which is what makes them keep these gaps that makes it hard to kill several at once with explosives.
One more thing is AI tends to take and stand the same places where other AI units were killed (iterationally, 2, 3, 4 units). That's also robot behavior. I understand, that AI thinks it is best place for maximum advantage, but deviation is sort of clue for true user experience.Yeah, this is definitely something I'd like to find a solution for as it's also obviously bad play. I tried to multiply the scores with a random-modifier but this leads to the AI finding different best spots in different passes and thus waste all their TUs changing positions. It also looks stupid.
Thanks for the info, my thought was to make for example waspoids swarm like bees VAI for a few turns then BAI full max or similar with 'pack' animals like werewolves.! :D, humanoid aliens like floaters, sectoids, mutons use BAI, and snakemen and some other aliens use VAI or somewhere in between with different flags so that you get varied behaviors per alien race.I've recently worked on ways to have gradual nerfs to the AI so that stuff like "swtiching between VAI and BAI" doesn't appear as best option anymore. But even with those in place I'm still trying to look at elegant ways of putting them to use. Ways that don't require modders to add new variables all over their rule-files.
I have a suggestion, for discussion:I thought about ways of how to realize it and if I'm correct there should be a way that's pretty easy. But I need to look at the code to determine whether it's actually easy.
AI units be destroying surroundings, if later weak.
For example, player units covered in wooden house.
If explosives are strong enough to breach the walls, and newly opened terrain brings advantage in combat, then why not toss a couple of grenades/dynamites near to it?
I think a score-deviation-mode where they mark to pass their turn if the action was a hiding-action sounds like a good idea. I was thinking of using a multiplier of 0.75-1.25 or even make it configurable. This should vastly diversify their behavior without costing a lot of playing-strength as the basis of the decision is still a good one.Btw. this feature is now already implemented in 7.11.0.
Not actually necessary, there is a Linker VS Code extension by Pedro, that inherits yaml to csv conversion. Thus you can edit ruleset data (each unit in this case) as a line in the table with sheet tools, like MS Excel. Linker can convert csv back to ruleset.
Next step proposal for OpenXCOM community will be something like:
- what do you think of some sort of interface (see below) that helps to operate with intelligence balancing?
Do more intelligent units still know exact enemy location for several turns? I played a couple months old version, and I believe it is the case. I guess it was done to make OXCE AI smarter, but is it still necessary with Brutal-AI? New AI is sometimes efficient to the point of being unrealistic. (Now that will probably interfere with above explosives suggestion...)No. There is an option called: "Bug hunt mode for brutal-AI". This one is disabled by default since probably half a year now. If you already had an older version where it wasn't disabled by default, you need to disable it manually. I recently tried whether it still works. It does and in combination with some of the new algorithms developed since it's deactivation as default, it's just super-brutal, especially on lower aggressiveness. There's almost 0 chance you'll find them on your turn but they will definitely find you on theirs, when possible.
I'm returning to fights with mixed opponents (monsters and people). As far as I understand, I can turn off the global Brutal AI and manually add “isBrutal: true” to each unit so that it is smart. This option does not work in the opposite direction, as stated above (at first I doubted that “isBrutal” even works in unit.rul, because I started with the opposite option). If I'm wrong, please clarify.
The files to edit for that is "units.rul"
You can add the following:
"isBrutal" (true/false)
"isCheatOnMovement" (true/false) (equivalent toomnisciencebug-hunt-mode for brutal-AI)
"aiTargetMode" (equivalent to Targeting behaviour for Brutal AI)
The global Brutal-AI option needs to be switched off for that as otherwise it would take precendence.
Edit2: It's not per species but per unit-type though. So if a mod has many units across many different files, it might be quite laborious to manually switch it on or off for each individual unit-type.
If the global Brutal AI is enabled, then "isBrutal: false" will not work for these individual units.You are right, I should definitely make it work like that.
1. Weighted randomization => The scores that are used for decision-making of the AI are multiplied with a random factor in order to reduce predictability.Great! Will upgrade.
This will make the AI less predictable at the cost of some playing-strength. However, the loss of playing-strength is less than it may seem the case since it's much more likely that an at least decent option will be picked whereas bad options will have a very low chance of happening.
2. The AI will now consider tiles that have dead bodies of their friend on them as much less suitable to take cover on.
@Ximli it seems you have a lot of new stuff in your fork? Do you have some kind of documentation, how it is different to OXCE? Like wiki page on GitHub, for exampleWell, there's this post:
I just downloaded the latest version and there's one thing I'm wondering about. Why is the spread out option an on/off setting? Wouldn't it be better if it was related to the units intelligence? Maybe with a lower chance of happening for dumb units and when on low morale(panicking)?There's different perspectives on whether there should be more separate options to allow as much individual tweaking as possible or wrapping different things up under one option.
Little suggestion:You mean the AI should sometimes randomly shoot towards where they think player units could be so the player doesn't know whether their units are seen or not?
BAI that doesn't see player's units: tends to peek. If reaction fire made by player-controlled units, it sometimes shot into the position even if no visual contact was made. That's cool.
But how would BAI deal with players, that null TU's and thus prevent reaction fire? Earlygame experience.
Mostly done at night + flares + shooting from distance. Aggressiveness is balanced.
AI has no chances to make sight contact. Maybe force a bit of random shooting into the tiles? Players use that too, if automatic weapons equipped. The condition is: BAI thinks this unit is not seen (I hope it doesn't cheat by checking armor's vision stats), e.g. covered with darkness, far from player units.
Call it suppression mechanism. Can be likely more frequent for automatic weapons.
5% low cap hitchance for shots - is something I personally against.Yeah, the 95%/5% caps are not something I'm a fan of, either. There are already other factors that simulate the crit/graze mechanics, namely voxels that do not 100% or even 90% match the sprites and the 0-200% damage rolls. Adding this on top is too harsh.
in early-mid game most shots are already at 40-60% hitchance, thus reduction in 90% of cases makes it a barely noticeable chance of hit.Cover degrading accuracy to such a degree is IMO not such a hot idea, either. JA2 v1.13 once made a 'new chance to hit' option that tried to do something like this (well, technically it was more like a reverse of what jnarical is doing with this, but I'm talking about its impact on gameplay), which made battles autofire slogs and slowly fell out of favour with most players, even ones that were into it at first.
I agree on the caps. These caps seem arbitrary. And if something is supposed to be realistic, then having arbitrary caps seems weird.They are not (totally) arbitrary... You have 100% if you manage to stick weapon barrel to the enemy's body - but all units stand in the middle of the tile so there's always some gap in between, measued in voxels. As for the bottom cap - 0% visibility means 0% chance to hit, so if you have such chance there should be some non-zero %... For extremely low-exposed targets it will cap to its visibility, like 1% chance to hit for 1% exposure... Other that that - thats right, there are arbitrary numbers, which I tend to tune in order to make accuracy more "tactical", i.e. by making player able to take meaningful decisions. Like, if you plan a hopeless shot for some reason, you can improve your chances by kneeling and chosing aimed shot over everything else.
There's different perspectives on whether there should be more separate options to allow as much individual tweaking as possible or wrapping different things up under one option.Yes, there are too many options I think. Selecting difficulty is not the only thing that decides the difficulty of the game anymore. Yes, I think you should absolutely group as many options as possible into 1 and just let the player choose the way it should behave.
A lot of things could be tied to intelligence or otherwise be controlled by a single option.
I'd say we have gone quite far into the "overchoice"-territory, where players will start being intimidated by their vast amount and rather not want to meddle with them out of fear of ending up with a configuration that is not ideal.
I'd like to have more feedback like this. Of whether people like having so many opions or if they'd prefer only a few options that control more than one thing.
Yes, there are too many options I think. Selecting difficulty is not the only thing that decides the difficulty of the game anymore. Yes, I think you should absolutely group as many options as possible into 1 and just let the player choose the way it should behave.Yeah, I can totally see your point here.
Also, an idea could be to create templates of settings that would be a good choice based on the difficulty the player chooses. That way it could be a more defined standard per difficulty setting. Right now, saying that you beat super human ironman, says nothing because of all the other settings.
I checked it on GitHub and README seems to be borrowed from OXCE. Do you have your own with all features and configurations and defaults explained?The first post in this thread explains all the new options. But you are right, I should probably overwrite the readme, which up until this point is simply the unmodified one from OXCE, which I have forked from.
Also it seems to be a combination of AI with QoL with some other modded elements. QoL elements are good to have but is it possible to separate AI from other modding? Or, at least, to turn all other modifications off by default leaving AI changes only? Thank you.Do you have any concrete examples for QoL-improvements that currently are enabled by default but you want to be disabled? And can you give a comprehensible reasoning as for why they should be disabled?
I hardly can imagine a player that turn off a specific element of AI behavior (like aliens using better cover) just because it does not match their player style (?) .I've never played a game with customisable difficulty without my final difficulty being called 'Custom' or some equivalent. So I'd say your imagination needs an upgrade. :P
In other words, I would recommend to set one singe dial "AI strength" and put all details under the hood. This way your implementation is independent on all these parameters. You will be AI designer and not just provide service methods for players to tune it up themselves.While this is something Xilmi has been musing about on their own, I for one would appreciate if the fine-tuning still remained an option. If not an in-game option, then at least a set of ruleset or config variables, hidden from the eyes of the 'filthy casuals'. :D
Second, "it's fine if the base chance to hit is minuscule, use tactics" is the same line of thought that led to JA2's 'new chance to hit'. And even with a bazillion levers to tweak it and people sharing their setups, it never really clicked for most. I really like this concept, but I'm afraid it'll go the way of thedodonCtH if the gameplay impact is tailored to just one individual's preferences.
Another newbie question.Question to me or Xilmi ?
Do I understand correctly, you don't care about any compatibility with OXCE? If so, how would one install your mod and then install some other regular OXCE mods on top? Is it even possible?
1b) Someone has to give the 'tactics' to the AI, tactics that are different from the vanilla model.You are right. It should actually be pretty easy. For target-selection incase several targets are attackable from one position that's already done but not for attack-spot considerations itself.
Another newbie question.Hu? What gave you this idea?
Do I understand correctly, you don't care about any compatibility with OXCE? If so, how would one install your mod and then install some other regular OXCE mods on top? Is it even possible?
What is "Realistic accuracy and cover system"?
I understand vanilla already accounts for cover in the way that if part of the target is covered and shot hits the cover it does not hit the target. Sure this can be calculated and displayed to user for convenience but what exactly is changed?
What is "Realistic accuracy and cover system"?I feel like my messages here are invisible… ok, Brutal OXCE incorporates this: https://github.com/narical/openxcom-accuracy
I understand vanilla already accounts for cover in the way that if part of the target is covered and shot hits the cover it does not hit the target. Sure this can be calculated and displayed to user for convenience but what exactly is changed?
Thank you for confirming.The first post of this thread has the list of the new options.
In this case where I can find a list of configuration parameters with defaults? I unpacked the zip but there is no readme there too.
OXCE launch file is OpenXcomEx.exeI personally would have recommended to put it into a separate folder.
Yours is OpenXcom.exe
Should I launch yours?
"Fun":
"Immersive":
"Smart:"
"Cheater":
Current state:
Initial calculated accuracy: 210%
Target visibility: 10%
Final accuracy: 210*0.1=21%
Planned change:
Initial calculated accuracy: 210%
Accuracy overshoots 100% by: 110%
Additional bonus: 110/2=55%
Target visibility: 10%
Final accuracy: 210*0.1+55=21%+55%=76%
Planned change:That looks a bit better. Personally, I'd instead use accuracy overflow as cover reduction. E.g. in the above calculation, 100%(cap)*(0.1+(0.9-0.9/2.1)) ~= 57%.
Initial calculated accuracy: 210%
Accuracy overshoots 100% by: 110%
Additional bonus: 110/2=55%
Target visibility: 10%
Final accuracy: 210*0.1+55=21%+55%=76%
it should be psychologically reliable: player sees sprites, not voxels.This is a core feature of OXC and one should not touch this lightly. It's the responsibility of the people who create sprites and match them with voxels (i.e. the modders) to do this. If the engine starts having its own ideas of how a unit/sprite should look like, there's going to be no end of trouble(shooting). Maybe the modder wanted to create a shoot-through hologram, but the engine knows better and makes a giant shot-blocking bedsheet...
If the engine starts having its own ideas of how a unit/sprite should look like, there's going to be no end of trouble(shooting). Maybe the modder wanted to create a shoot-through hologram, but the engine knows better and makes a giant shot-blocking bedsheet...Oh ho, you got me wrong. I was suggesting not about fucking up engine, but either about these two bushes that lower hitchance from 50% to 5%, as from the player's perspective is weird. The entire passage was about bumping up chances.
How do I install/transfer mods to the freshly copied Brutal-OXCE directory? Just copy "user" subfolder?Yes, this should work.
Please don't yet upgrade this. Or, if upgrade, make customizable option too.This was the idea: Have presets that modify the other options but leave the other options there.
This tells me that the algorithm that determines the ideal behavior hasn't been found yet.Yep, and next video will be very interesting and informative in the way how algorithm is not balanced yet.
This was the idea: Have presets that modify the other options but leave the other options there.As most casual+ players come for mods, it's good to be checked through these.
Btw, I came with particular question: How does dynamic aggressiveness setting exactly interferes with balanced aggressiveness (2)?Dynamic ignores whatever you have set as aggressiveness. It starts out at max and reduces it when morale goes down. If they get kills that restore their morale they become more aggressive again.
It will be Red Dawn HQ night assault with 16 agents vs ~100 enemies.That’s what I was talking about. Why not 200 enemies? Or 1000? This is nuts, dude. How do I suppose to make accuracy mechanics which works similar in terms of fun both for original game with 15 missions per month / 15-30 enemies vs this nonsense?)
Accuracy overshoots are interesting idea overall, but we rarely counter enemies that exceed 100 accuracy themselves. Plus, 100 accuracy is abstract measure, too. The next thing comes to mind is that any unit which exceeds 100 acc will have too much advantage, while others will miss.We’re talking about 16 agents vs 100 enemies here… this game IS asymmetrical, where you
Regarding RA:
- first of all, it should work not only with super-accurate shots, but with every shot
- it should be psychologically reliable: player sees sprites, not voxels. If actual frame of the window makes 80% cover, but the drawing shows large window that exposes all torso and head (33%% cover), player will be dissatisfied with the hitchances. Same with two and a half leaves on a thin tree in front of the unit. Same to wooden fence, which shouldn't stop high caliber at all!We are talking about the game full of conventions. One of them is the fact, that deep in our imagination we have a mix of turn-based and real-time action. We know the game represents real and fast-paced battle. That’s why it’s totally ok to have 50% cover in high crops. Grass doesn’t give a protection against bullet, but in real life it gives you a chance to hide and mislead enemy about your true position. Put in other way, covered visibility affects chance to hit. Nothing confusing for players here. You get highly covered enemy? Deal with it, that’s how the game (in this accuracy mode) works.
In my experience, even one new variable which seems to be clear and have predictable effects - turns out as unpredictable, given the sheer amount of different mods and weapons’ types, and leads to balancing hell and a bunch of iterations of rewriting code… your approach with “let’s introduce a bunch of variables with totally arbitrary values and hope for the best” won’t work, it doesn’t work even for one variable. Things tend to break in most unexpected ways)
What if make it hybrid:
partial weights:
Overshoot mechanic 25%
Weight of the cover/sight 45%
bullet pre-roll damage 20% (0 = 0%, 100+ = 20%)
distance (yet I somehow believe it should matter) 10%
Oh ho, you got me wrong. I was suggesting not about fucking up engine, but either about these two bushes that lower hitchance from 50% to 5%, as from the player's perspective is weird.Every unit checks three different positions for fire, shifting left and right (with off-centre shooting on, which I highly recommend, cause don’t know hot to force turn it on) and chooses the one with better enemy exposure. If after that you’ve still got low visibility - the very most of the time you’ll get it with in-game sprite representation, too. I personally didn’t have such issues you’re talking about.
Why not 200 enemies? Or 1000? This is nuts, dude. How do I suppose to make accuracy mechanics which works similar in terms of fun both for original game with 15 missions per month / 15-30 enemies vs this nonsense?)I think there are missions with 200, too, at least on SH. :P
Better in many ways is still the goal tho.As long as your changes completely invalidate anything even resembling vanilla tactics in any moderately cluttered map, promote aimed shots (and grenades and, I suppose, melee, due to running being a thing for quite a while now) over snap/auto to the tune of two orders of magnitude, well, that's going to be a tough sell.
Nothing confusing for players here. You get highly covered enemy?The voxel/sprite issue (and others, like asymmetric vision due to only some unit voxels counting for visibility) means it's hard to predict cover by just looking at the map. And Xilmi's AI gets a tremendeous leg up here, since it can test all firing positions, something the player cannot do without insane savescumming.
In my experience, even one new variable which seems to be clear and have predictable effects - turns out as unpredictable...Yeah, that is very much true and a solid argument in itself. But since the whole model is going to behave very different anyway, giving some people (not all!) the ability to tweak your model to achieve results more in line with their mods, or the player base in general, sounds like a better approach than 'my way or the highway'. Well, if you want people to actually play with your option turned on and not look at it, exclaim "5% chance to hit the alien in the bushes 10 tiles away?! What even is this...?" and then turn it off again. JA2's nCtH, for whatever faults I may be finding with it, at least gave people a laundry list of options to tweak to their liking.
I don't think I've seen anyone except you express an opinion like "hit chances are two orders of magnitude too high", though.That’s not my opinion. I wonder where did I say something like that…
The only issue accuracy-wise is the fact that a powerful weapon cannot shoot through weaker obstacles (like e.g. bushes and wooden walls). I think that a good sniper should be able to shoot through the bushes just fine, especially with sniper-spotter setup. What do you think about this? Would implementing this break too many model assumptions behind the logical setup of tactical battlescape?Oh no what have you done… now I want this)
That’s what I was talking about. Why not 200 enemies? Or 1000? This is nuts, dude. How do I suppose to make accuracy mechanics which works similar in terms of fun both for original game with 15 missions per month / 15-30 enemies vs this nonsense?)This is part of SH difficulty. Lower difficulty means 50-40-30-20 enemies by step.
Oh no what have you done… now I want this)Not only sniper shots, but also heavy machine gun, gauss, plasma, etc.
bullet pre-roll damage 20% (0 = 0%, 100+ = 20%)Even though 20% seems too high: pistol with 20 dmg will have +4%, HMG with 50 dmg will have +10%, sniper rifle with 75 dmg will have + 15%. Plus overshoot. Everything else - to the balance of mods, already tuning hitchances.
a bunch of variables with totally arbitrary values and hope for the bestThis is how I see to make it balanced in good and joyful way.
Not only sniper shots, but also heavy machine gun, gauss, plasma, etc.Each object has an armor-value. Currently this only determines whether the object will survive the hit of a bullet or not based on the bullet's power.
Bullet pre-roll damage should make these bushes less bulletproof, yet should be in balance with heavy covers, as result affects all covers. You won't code so only bushes are affected, right? Or you will, but this will take too much effort.
the bullet keeps flying but it's power is reduced by the armor of the object it just destroyed.This approach requires revision of all objects below 60 armor.
IMO, the perfect game design is made so playerOne of the biggest issues I have with the game-design is that there is a contradiction between individual missions being exciting and the overall game-progress.
- allocates resources in tight connection with game progress, which, in it's turn, takes them from him for challenge & drama. First is mod design, last is AI.
This approach requires revision of all objects below 60 armor.Not sure why this would require a revision of all sorts of objects.
And also, there's fork:
- whether object will be destroyed completely
- whether object stays intact, but lets bullet through it
- whether it will demote bullet power overall
- whether it will have HP or not
- etc. etc.
This seems like whole another mod.
Then, also How BAI will deal with all that?It would have to be adapted. It needs some sort of new canTargetUnit-code that takes armor-piercing into account. If not it would act as if the feature didn't exist and only benefit from piercing projecties by chance.
You have two enemies in 10 tiles from you. One is totally open and is within 50% hitchance. Other is covered in bushes and has 2% hitchance.I'd also kinda like to know. I haven't tested this in-depth but it would be a big difference if the 48% discrepancy will likely hit and potentially destroy the cover or just miss in some unrelated way.
If you shot into second target, will 48% of shots statistically hit the bushes?
It's not obvious yet. Something makes me not believe that. Seems like most shots go into the air/not line of the hit.
"Why not 200 enemies? Or 1000? This is nuts, dude. How do I suppose to make accuracy mechanics which works similar in terms of fun both for original game with 15 missions per month / 15-30 enemies vs this nonsense?)"Fair balance, other is up to modders. Right now, with EA it feels natural and balanced.
Now I have even more questions how things would interfere:It's not resorting to VAI.
- statistical randomization, when 40% units are VAI
- weighted randomization, for other 60% BAI units, which still supposed to do some side stuff, randomly. Will it be VAI stuff? Or strange BAI stuff? How many percent of them will do so?
- dynamic aggressiveness will be starting from "don't bother take cover" or "careful advancement"?
- just got shot from other side of the map, while no sight contact is made. Regarding this: is vanilla sniper-spotter mechanism working for these 40% VAI units?
- and if so, are only VAI units eligible to see and shot into "is spotted" units?
If last two questions are "yes", then this is amazingly joyful and cool.
I'd also kinda like to know. I haven't tested this in-depth but it would be a big difference if the 48% discrepancy will likely hit and potentially destroy the cover or just miss in some unrelated way.Ive sent you a picture of code to Discord) Units aim to the center of exposed part. If miss is rolled. there's part of the code which looks for missing trajectory inside shooting cone, and gradually increases that cone until some limit is reached. Missing trajectory is considerd found when canTargetUnit to some voxel returns anything but V_UNIT, or returns V_UNIT but it is outside of targets boundaries.
If I imagine aiming at the center of an enemy and having some sort of hit-cone around the center, then a lot of the off-center-shots should still hit the enemy.
But if I aim at his finger because the finger is the only thing exposed, the cone around of where I aim for would be much worse, especially if the cover is easily breakable.
So I guess the question is: Does lower exposure change where the soldiers aim at? Do they still aim at the center of the enemy or do they aim for only the exposed voxels?
The unit still starts checking whether it can attack from where it is with BAI-attack-checks.
But I'm thinking of changing the highest aggressivenessShould be 3, IMO. They all flew out of the cover towards my troops. But the distance was too high for a LoS contact.
That’s not my opinion. I wonder where did I say something like that…Well, two orders is hyperbole, but a reduction of 2-3 times seems common, and up to one order of magnitude can happen in cluttered maps. Both can be seen in Abyss's video and there's the "90% covered" calculation example. You don't have to state your opinion if your actions speak for themselves.
...do you consider % chance to hit number to include chances for to after cover penetration or not.I would prefer not, but the cone still covers the, well, cover afterwards. I mean, it's probably not even possible to calculate the 'after cover' chance precisely, since there can be several pieces of cover quite a distance apart. And some of these can deform into new shapes after 'destruction'.
One thing I could not understand is how they detect my soldiers? I place them all staring in the alien direction but no one is able to see a single peeking alien even for a second. It is like out of the silence they start shooting one of my unit. Do they know how to avoid line of sight of my units or some other micro cheating or they see farther or better through smoke?Could be anything. Shooting at likely enemy positions, better infravision, psi-vision, just plain higher vision range, squadsight, even omniscience if you have that enabled.
Just asking if anything like that was done in this one?No, stat changes like that are the domain of ruleset mods.
Anybody can explain how intelligence customization work? Is it possible to assign different intelligence to different races/types/ranks? Is it set like this by default or need to be turned on?The BAI and intelligence interplay is explained here (https://openxcom.org/forum/index.php/topic,10967.msg159452.html#msg159452). BAI has several options for determining enemy intelligence, on of which is to use the vanilla intelligence stat. Which is indeed assigned via ruleset data.
Also, I killed like 40% of them before they actually started bothering take cover.I have reworked and am still in the testing process aggressiveness 3 and also the steps from dynamic aggression.
This mission was quite dissatisfying in terms of a challenge.
Maybe, morale shifts should be changed to 100 -> 90 -> 80 -> 60?
Also, does Brutal OXCE count overall mediocre morale or each unit's morale, hence each unit has different strategy?
I want to suggest the "Sea Battle" mechanics prior to introduction of this giant HQ assault mission.This is pretty-much what I used to call blind-fire. The difficult part is to determine "where enemy unit has high chance to be located". It both has the potential of being exploitable or feel like cheating if not done right. I experimented with that in the past. I just let them shoot at where they had spotted something before. This worked well as long as the player didn't know how it works. Then the player could bait the blind-fire in order to reveal the enemies' locations while staying perfectly save themselves.
It is aimed to achieve win condition when player nulls units TU's after each turn.
- the overall conditions are "no enemy unit is seen", condition: night
- there is definitely viable trajectory to shoot to, where enemy unit has high chance to be located.
- SB is enabled on second turn.
- then, split into: half are spotters, half are playing SB
- units to use this are, preferably, covered by darkness or away.
- each shot goes in a line, not towards the bottom of the tile
- each shot "checks" multiple tiles in a line
- if reaction fire follows, then BAI works as usual on player units reaction-fires.
Then if SB hits enemy, there are multiple targets revealed. If not, only reaction-fired units are spotted.
- but the most delicious part is hitting enemy, when no reaction shots follows. This enemy is then marked as "spotted" for this turn and is visible for every BAI unit on battlefield, or to some % of BAI units
- then if unit is killed - reenable sea battle. Next turn every "spotted" enemy unit disappears.
- too much grenading may shift the balance even more, but it's up to player - how he gets into the battle: prepared or not.
IMO, this will enhance the power of AI, as it performs best at offense, rather than in defense.
Other question is how AI spots the hit, far away in darkness: player can see AI units flashing red slightly or brightly. But, as I may understand, AI knows the map entirely, thus can calculate whether there should be obstacle, or not. The new obstacle is player unit, obviously.Well, I would just have to call the updateEnemyKnowledge-function within the hit-method. Currently this isn't the case but if you say the player would notice when they hit something they didn't aim at, it would only be fair to let the AI notice the same. And done.
Also, the save which involves Gillmen is below. It's Ironman, so you probably want to run guys out of Osprey and toss flares around? Kill few close enemies and wait for gillmen to make shots.Thanks, I may check it out later.
Beware of one green guy in the north building. Although, he couldn't have seen units near the osprey's exit anyhow (arching shot flew there).
Also, some players would scream "what kind of BS just happened"As I said: If it works too well, it'll look like cheating. And if it doesn't, it'll look pathetic. "Guessing" is really hard to do with algorithms.
One thing I could not understand is how they detect my soldiers? I place them all staring in the alien direction but no one is able to see a single peeking alien even for a second. It is like out of the silence they start shooting one of my unit. Do they know how to avoid line of sight of my units or some other micro cheating or they see farther or better through smoke?Many possibilities. The easiest way to find out what happens is to use debug-mode. It needs to be enabled in the options.cfg-file by changing the line "debug: false" to "debug: true". Then you can hit ctrl+d in the mission to see what happens. You can then observe the enemie's turn. This should tell you how and from where they spotted your units.
Another thing I noticed they pre-prime grenades and throw them very often. Which is completely fine for this mod. I was just thinking would it be appropriate to rebalance explosive power and resistances and other related stuff to account for that? In fact, the question even broader. Vanilla AI is stupid but huge alien unit bonuses compensate for that. Would it be good to rebalance them and make them more equal to X-Com stats? This way it would more resemble intellect combat instead of beating the weaklings.You can turn the pre-priming off as a separate option. Other than that, balance-changes are modder territory.
I sure can do this in my own mod. Just asking if anything like that was done in this one?
As I said: If it works too well, it'll look like cheating. And if it doesn't, it'll look pathetic. "Guessing" is really hard to do with algorithms.Thanks taking time to reply.
One thing I could not understand is how they detect my soldiersSectoids have psi-vision. It's not even cheat, it's their feature. The know of biological objects via psi-field. This is X-COM lore.
Could be anything. Shooting at likely enemy positions, better infravision, psi-vision, just plain higher vision range, squadsight, even omniscience if you have that enabled.
These are all unknown to me. Never touched anything like that. Where can I check if they are enabled or not?If you play X-Piratez, get Xpedia2 from here:
Where can I check if they are enabled or not?BAI includes blindfire and its version of squadsight, to some degree or another.
Without it, I would have played on lower difficulty.I played this mission yesterday evening with full intelligence and without spending-TU-to-avoid-reaction-fire-shenanigans.
Sectoids have psi-vision. It's not even cheat, it's their feature. The know of biological objects via psi-field. This is X-COM lore.Maybe in various mods but not in the base-game.
I played this mission yesterday evening with full intelligence and without spending-TU-to-avoid-reaction-fire-shenanigans.This one particular mission is not the case.
I looked at the previous-savegame in debug-mode and immediately spotted an issue with the AI's intended behavior. They have a line of fire but due to the combination of "Extender Accuracy" but not "Realistic Accuracy" their is a discrapency.So, long story short, BAI right now performs as intended with Joy's Realistic Accuracy only?
spending-TU-to-avoid-reaction-fire-shenanigansPlayer is allowed to do so by interface. It's BAI that never considered this as potential player's playstyle. Just opinion.
So, long story short, BAI right now performs as intended with Joy's Realistic Accuracy only?No, this is not the whole story. I debugged all day long and there were numerous bugs of the AI not working properly due to various reasons. The biggest issue was a totally wrong way of applying the no-LOS-accuracy-penalty. It made the AI think it won't be able to attack from where it stands despite the possibility being there. This lead to a lot of cases where the AI went into your firing-range and then walked back out without shooting.
Player is allowed to do so by interface. It's BAI that never considered this as potential player's playstyle. Just opinion.
I also noticed that units with arcing-attacks checked as if their attacks were normal straight-line-attacks. Now they check for arcing, which makes them way better.Even 6.X.X versions clearly used gillmen arching attacks very well from no-LoS terrain. I did playthrough of XCF with it some time ago.
Even 6.X.X versions clearly used gillmen arching attacks very well from no-LoS terrain. I did playthrough of XCF with it some time ago.The arcing-shot-logic was correctly applied for the "can I attack from where I stand?"-logic. But it was not applied by the "where do I have to go to attack?"-logic.
1) BAI on extender accuracy (not RA) - works same well as with RA?1) I did all my testing without RA. So I can't tell for RA for sure. But most issues were AI-bugs afterall, so they should be fixed now either way.
2) Will you somehow teach BAI to throw flares back?
3) Will super-high TU units scout (last video shows how Armored cars dispose their TU's instead of best solution)?
4) What was with these gillmen, did they see me? If they did, why human units didn't attack at all this turn?
if (noLOSAccuracyPenalty != -1 && !hasLOS)
{
real_accuracy = real_accuracy * noLOSAccuracyPenalty / 100;
}Not really intuitive. :o
Edit: Just checked again in Projectile.cppThis code is mine but it has always been that way. If you’re not sure - use “vanilla” OXCE to check such things.Code: [Select]if (noLOSAccuracyPenalty != -1 && !hasLOS)Not really intuitive. :o
{
real_accuracy = real_accuracy * noLOSAccuracyPenalty / 100;
}
This code is mine but it has always been that way. If you’re not sure - use “vanilla” OXCE to check such things.2 Days ago someone asked what this parameter does on the OpenXCom-Discord. I confidently gave a wrong answer and no one corrected me. So I think the likelihood that at least some modders who use it, got it wrong too is pretty significant. :o
I think it could be confusing for other people too, so we possibly would find out that in mods some dev’ve decided it works in one way, and another dev thinks it works just the opposite. I feel like it’s totally possible situation. I haven’t thought about that myself and just acted as “one way” seemed obvious to me.
OXCE don't want to add this UI QoL feature as indicating whether tile is in day or night mode visibility. Maybe you would?
Playing average difficulty. February. My only base is assaulted by Tasoths with Reapers and PWT launchers. Is it expected or I just unlucky?If you play your own mods then probably some experienced modmakers can help you with insight for mission rulestes. E.g. mission spawn timers and probabilities.
Tanks stop after opening doors, soldiers do not. Is it a feature?No it's not intentional. I compared with OXCE (7.8.5) and there they don't stop.
Playing average difficulty. February. My only base is assaulted by Tasoths with Reapers and PWT launchers. Is it expected or I just unlucky?The earliest base-assault I've gotten was January 6th.
The earliest base-assault I've gotten was January 6th.
But Tasoths and Reapers shouldn't be possible that early with vanilla TFTD. So there's likely some sort of mod at play.
Note that with "Aggressive Retaliation" enabled in Brutal-OXCE successfull missions on landed UFOs also have a chance to trigger retaliation, not just shooting them down.
I am working on a new hangar mod, and saw that your repo supports not only multiple hangars but configurations for placement and craft specific hangars, i.e. garage for XCF automobiles. .... I didn't realize you already had an example mod for this until after I had already made a garage basebits sprite, it's got a car lift., attaching here and you are welcome to add it to your repo if you want. :)These are both things provided by other contributors. Changing the shot-disperstion-option logic would be easy but I'd rather ask jnarical if he has an opinion about that.
I have two suggestions that I hope you'd consider.
Would you be open to changing the restrictions of the hangarType slightly? The problem I'm hoping to solve is I want to put the XCF cars with hangarType: 0 into the garage as well as the vanilla hangar that doesn't have the hangarType defined or -1. So if the craft has a hangarType: x then it can go in any hangar with hangarType: x or -1 but if a craft doesn't have a hangarType defined it can only go into hangars without the hangarType defined or -1, thus all hangars with a hangarType defined can only accept that type of craft but hangarType: -1 (not defined) would accept all craft types.
The second thing I'd suggest a slight change in the wording for clarification in the advanced configuration menu for the following:
"Realistic accuracy shot dispersion"
"0 Realistic"
"1 Normal"
My understanding is that "realistic" is when this feature is enabled and it's confusing as 0 usually denotes off and 1 denotes on... or am I mixed up with what it's saying. I think "normal" is a little confusing also as opposed to "vanilla" to indicate original game calculations. Sorry if this was already discuss or if I'm not understanding this setting options.
That is probably it. Any description on mechanics?You mean the retaliation-mechanic?
Try #2Medium-difficulty should be 12% chance for retalition. So if the Mods you are using don't mess with retaliation-chances your chance of getting a retaliation were roughly 22%.
Again medium difficulty.
Shot one small SUB then landed and raided another small SUB.
Jan 7: my base is attacked!
Isn't it an overdo of aggressive retaliation?
You mean the retaliation-mechanic?
Normally there is a percentage-based chance of triggering a retaliation-mission for every UFO you shoot down. I think it is 4% on Beginner and 20% on Superhuman with 4% increments between difficulty-levels.
The change with Aggressive Retaliation in BOXCE is that this also can trigger off of successfull landed missions, as otherwise the player could just avoid it by never shooting down any UFO.
In vanilla the mission consists out of several small craft who try to find your base and at the end 2 very larges who try the same. Whenever one of the UFOs finds the base it will no longer search for it and instead a very large will go right for the base at max-speed.
Now with aggressive retaliation other UFOs could also randomly find your base, not just the ones that are part of the mission. This had very little impact in practice. But I also normalized the search-pattern. In vanilla the search-pattern heavily depends on the mission-zones. Which makes it make a massive difference to the chance of finding your base based on where it is located. Like for example switzerland had a very high chance but crete had an almost 0 chance. The search-pattern was normalized in BOXCE if the aggressive-retaliation-option is enabled and instead of searching on the region, the UFOs will always search in a sqare centered around the actual base. The square is roughly as big as europe. So it means the chance of your base being found is always as good as when it is in switzerland.
Medium-difficulty should be 12% chance for retalition. So if the Mods you are using don't mess with retaliation-chances your chance of getting a retaliation were roughly 22%.
Would have been 12% with without Aggressive-retaliation, since the landed sub wouldn't have counted towards the chance.
You can always just disable "Aggressive Retaliation". But I'd also recommend to check your mods. They might have increased the retaliation-chance. There's also away to simply trigger a retaliation based on events. Like researching a certain tech, for example.
Very good explanation, thank you. Few questions.The search-mission performed by each of the UFOs that are part of it has a finite amount of way-points it flies between. I think like 5 or 6. Basically every time they change direction they reached a way-point.
Every USO altercation (shooting or raiding) CAN trigger search mission.
Is it a single time bounded mission? Meaning they search for some period of time and if they don't find it - no more attempts are made (for this search mission).
Then next search mission can get triggered, and so on.
I understand this is probably difficult to calculate but what is the estimate probability for the search mission to discover X-Com base?
What is the probability for the any USO to discover X-Com base? Is it same as in vanilla or different?
Essentially, I am trying to understand with what probability I receive base attack after shooting down or raiding USO? Thank you.
Got it.The amount of ships spawned searching for your base per retaliation-mission is in alienMission.rul usually. It also has a timer between each of the spawns. Such a mission can take quite a bunch of time. Basically they will try to find you over and over until all of the UFOs that can be spawned have tried or they succeeded. During a retaliation-mission there can't be another one overlapping with the same. And if they all fail to find you, you have to trigger it again.
I am not using any fancy mods on top of BAI but will check anyway. What should I look for? The "retaliation" word in rules?
I thought that the chance is in difficulty.rul but doesn't look like it.I think 'retaliationTriggerOdds' and 'retaliationBaseRegionOdds' are what you're looking for?
Like base info counts number of detection systems but in fact they don't stack. I.e. misleading information. Could be more interesting if they stack.They didn't stack in the original. All radars stack in OXC. The short/long distinction is just visual.
They didn't stack in the original. All radars stack in OXC. The short/long distinction is just visual.
Xilmi and other authors.Yes, if someone wants to contribute features that are not already present in OXCE and they are either optional or a flat-out-improvement, I'm willing to accept them. But with your example I'm now skeptical due to what Juku121 said to that.
Do you accept other contributors?
The second thing I'd suggest a slight change in the wording for clarification in the advanced configuration menu for the following:
"Realistic accuracy shot dispersion"
"0 Realistic"
"1 Normal"
My understanding is that "realistic" is when this feature is enabled and it's confusing as 0 usually denotes off and 1 denotes on... or am I mixed up with what it's saying. I think "normal" is a little confusing also as opposed to "vanilla" to indicate original game calculations. Sorry if this was already discuss or if I'm not understanding this setting options.
I was changing wording numerous times... And it turnes out that it's current state still isn't good enough.
Ok, first of all, this option works only with RA enabled. I can't use the word "vanilla because either option is far from it. So, "normal" is closer to vanilla, and realistic is really tight. Former one is selected by default, because most players are more accustomed to it. My line of thought was - "Let people find it. Those who are curious enough - will try it. Those who'll like it - will leave it enabled". Speaking of myself, I use "realistic" option and I like it more.
Ah, thank you for the clarification, I didn't realize there was a dependency from one option to another.Yes, there’s a bunch of options for RA and you can change them all but they’ll work only after RA itself enabled
So you have to enable "Realistic accuracy and cover system"
and then the others can be toggled or enabled like "Realistic accuracy shot dispersion"
And one more save: past couple of turns from the moment the game crashed (quit without any notifications)I suppose 7.12.0?
UPD. It occurs if certain moves are made, not reproducing itself anymore. Nevermind. Deleting it.
I suppose 7.12.0?Yes, I updated the comment and atteched the exact savefile. Just press turn end.
Hi Xilmi, there's one more save with Cult HQ (main base, ~90-100 enemies)I tried with the settings as attached and the Gillmen did almost all attack. Used debug to watch them.
Layout is quite good, but one thing embarrasses: gillmen used to attack alot wherever I used to land in previous playthroughs. Right now they don't do it often.
And even if the hitchances are too little, they should bombard by means they have infinite ammo.
In Dagon HQ castle they spawn at corners & inside the temple itself.
It's turn 3, low-tier enemies around are downed.
Also, this save can be used to train AI use strategies vs usual player approach for such missions (set up a line, then aimed + snap). The most notable about this map vs BAI is: it covers inside the castle and then each unit, that is supposed to attack, goes to the gate, where following sniper reaction shot comes, as 10 agents simultaneously watch the exit.
Meanwhile, I retreated from previous same mission because layout was different (close to castle, more grenades and more shots consequently)
UPD 3 oh my god, you fix bugs way prior I report them. The discord community must be very active.Erm... not exactly. I found this one myself. :D
Erm... not exactly. I found this one myself. :DWhow.
The links are always the same :o
The discord chat link, though.Oh... Yeah. This makes a lot more sense and explains the seeming contradiction between knowing what I've updated and not knowing the link. https://discord.gg/xxTPB72x
would it be an easy, quick change to add a keyboard shortcut option to allow the player to change "Automated Combat" from: ctrl+a to what ever they want?Yeah, I'll do this for the next version.
or ctrl+ "user defined key" like always keep the ctrl+ and allow the user to specifiy another key like 'c' for ctrl+c for example?
Reason being is I'm testing out the auto combat and I used directional keyboard layout (a s w d) for (left down up right) as opposed to the arrow keys and since my left key is 'a' when I press ctrl+a auto combat starts and then the 'a' key is held down and the screens scroll locks left.
In auto player mode, against swarmoids the players just pace back and forth one tile then back to the other next to a swarmoid when trying to melee or stunrod them and take no attack action but use up their TUs.What was the Auto-play-aggressivity this happened on?
What was the Auto-play-aggressivity this happened on?
I think this can happen on the highest aggresivity when they don't have enough TUs to perform a melee-attack once they reach the enemy. But they are forced to change position instead of just ending their turn.
A savegame of this situation would help greatly identifying and fixing the issue. Do you have one?
- and while peaking, move back and forth, causing reaction shots =>Okay, let me put this straight:
- getting damaged without benefit
If so, I also believe that BAI doesn't know how to plan something besides one turn. But if it was able to plan, for at least 2-3 turns ahead, BAI would know that 20 werevolves (100-120 TU?), even if cut by 80% by reaction fire/measures, will destroy whole squad on turn 3.I must admit that I'm confused about what you actually want me to do. Some time ago you were asking for the AI to randomly make bad moves and now you are asking for them to plan ahead several turns at once.
TUs were 100+ standing next to the enemy. Play er is going back and for many times until TUs run out... I have only see this issue with swarmoids so far. Two things come to mind. Swamoids have a very low chance to take melee damage which might be affecting the AI.I just created a test-mission against Swarmoids.
I must admit that I'm confused about what you actually want me to do. Some time ago you were asking for the AI to randomly make bad moves and now you are asking for them to plan ahead several turns at once.
It is not very clear for me why you want to make your AI worse?Not "make it worse", add options to gradually nerf it in the context of making mods that are otherwise too difficult winnable again.
Edit 2: Even with the fixed formula, there still doesn't seem to be any chance to hit the Swarmoids.
I thought there was something more systemic possibly wrong with the AI which is why I pointed it out, didn't know the AI calculates the hit change before determining to take a swing.Well, I'd say this behavior still hints to something systemic being wrong with the AI.
Some time ago you were asking for the AI to randomly make bad moves and now you are asking for them to plan ahead several turns at once.Hi, Xilmi!
I'm actually tempted now to remove the random-mistakes-feature again and instead look into planning ahead. I actually have an idea for something like that. Right now the "communication" of the AI-units is limited to sharing vision. What they lack is the ability to plan a coordianted push.
Well, I'd say this behavior still hints to something systemic being wrong with the AI.
Their positioning-code still thinks it can attack them with melee and tries to reposition to do it.
The question is how this should be handled. I see 2 possibilities.
One is to teach the positioning-code about the hit-chance-reduction too, so it doesn't even try.
The other is to ignore the circumstance that they can't hit by internally limiting what they think the dodge chance reduces their accuracy too.
With armor-mitigation the AI does attack anyways, even if it calculates that their attacks will be fully mitigated by the armor.
So should they attack anyways or should they not even try and do something else instead?
what you have done with weighted randomization and "mistakes" should be considered as fun feature and difficulty reduction. Not to be confused with overall strategy. Please don't disable this feature, it's so cool and fun, and makes game beatable again, yet still very intriguing.I think weighted randomization is a neat feature. It provides variety and only decreases difficulty slightly if at all.
because enemy always spawns close and good at meleeThis is the thing. Out in the open with extenter and/or realistic-accuracy the enemies are even more in a disadvantage than without it. They get sniped from far away and their own ranged-attacks are dramatically worse. Low damage and low accuracy.
- So this all about particular usefulness of smart melee units on open terrain. While ranged units can perform either basic defense and offense, melee units lack defense opportunity. So they are kind of pointless there while running around from cover to cover, except being sort of "distraction" targets, until they approach to attack positions.Yes. But... As I said like 3 times before. This does not happen when intelligence is maxed out. They do not "run around from cover to cover". They stay in cover and force you to get to them until they can actually attack.
- Now I'm curious, how a coordinated push (if ever to be implemented) will interfere with aggressiveness options?Yeah, it's actually a problem. It won't really work if they are not on the same page when it comes to aggressivenes and randomness would also make it much less useful.
- And if 20% and 40% randomization can still be in place while coordinated push takes place?
- And: can coordinated push be random feature, like 40% for mostly ranged units and 60% for mostly melee units ? Because if this strategy means "smart gather" and then implement Aggro4 - is also the strategy player can adapt to and make counter-measures.
Crash report: perhaps, some minotaur-related stuff. Crashed on turn 3 and, after reload, on turn 4. Same, just kicks out of the game with no notifications.I can't even load this save-game at all without crashing.
I can't even load this save-game at all without crashing.There's one more for different turn.
Getting a huge amount of loading-errors in the log.
Trauson playCan you share the link? I wonder to see
There's one more for different turn.Crashes just the same. It might be related to mods you are using which I don't have.
Can you share the link? I wonder to seeI haven't uploaded it.
Crashes just the same. It might be related to mods you are using which I don't have.I haven't uploaded it.Ah, yes. Thank you, haven't considered this.
Good editing software:Depends on the platform.
Natasha morozova join https://openxcom.old.mod.io/natasha-morozova-join-for-x-com-filesInstalling these helped. I can now load the game at least.
and XCF arsenal additions https://mod.io/g/openxcom/m/x-com-files-additions
Crashes just the same. It might be related to mods you are using which I don't have.I haven't uploaded it.
Does anyone know of a good editing-software, that doesn't take ages to recompress after cutting? All I want to do is just throwing away the last 5 seconds of the video. But with everyhting I tried that requires a very long process.
Installing these helped. I can now load the game at least.But I couldn't reproduce a crash once I had all the mods. I guess I also might need your options.cfg in order to make sure all the settings are the same.
But I couldn't reproduce a crash once I had all the mods. I guess I also might need your options.cfg in order to make sure all the settings are the same.Ok. Here it is.
There’s a known issue with arc weapons. Did you have a feeling that deep ones are too deadly in terms of accuracy? Did they ever miss?
They shoot across whole map with sonic and arch weapon (deep ones).
On your side it doesn't crash? I had it two times out of 4 tries, on third and fourth turns of AI.I tried 4 times and unfortunately couldn't reproduce the crash despite using your config. :\
A lot of these things are possible with the available options:
Some thoughts of what can be improved regarding the above. Not the suggestion for this mod. More of thinking out loud. Maybe I can do this in mine.
Probably reduce involvement of far units into the shooting. Either introduce max shooting distance or let aimed shot precision to diminish as well with extender accuracy.
Maybe also reduce accuracy when shooting target that is not directly visible (radio targeting). Maybe further reduce accuracy when shooting through smoke/fire and the like? This way smoke may play less role in covering but more role in blurring units and give them survival chance.
Grenades destroying fell inventory is fine. I can probably just increase item cost to compensate.
Maybe give AI and X-Com initial spacing. Do not place them immediately next to each other at turn one? Give both parties chance to create a formation. Otherwise, Xarquid or Biodrone hanging right across transport door will put a stop to any attempt to disembark.
Rework smoke mechanics. Make it more protective in all direction including height.
I tried 4 times and unfortunately couldn't reproduce the crash despite using your config. :\Yep, I ended the mission with no more crashes too. I'll report if it appear again.
A lot of these things are possible with the available options:
Involvement of far units shooting => Put "Targeting behavior for Brutal AI" to 1 and they won't do it anymore.
Reduced accuracy without vision is a setting that can be set in Mods. It's the NOLosPenalty we recently talked about.
Grenades destroying inventory => Disable "Allow Brutal AI to pre-prime grenades". However, this also vastly impacts their playing-strengths as not prepriming makes grenades a lot less useful.
Smoke meachanic => This is tied to the "Explosion height" option. This way smoke can cover units in several layers. It maybe could be made separate from explosion-height.
Probably reduce involvement of far units into the shooting. Either introduce max shooting distance or let aimed shot precision to diminish as well with extender accuracy.All shot types (snap, auto and aimed) are customizable with formulas.
Yep, I ended the mission with no more crashes too. I'll report if it appear again.I read on Rosigma-discord that this might be related to the build-version being 32 Bit and the megamods running out of memory. Me always running from Editor could explain that I don't have this. Could try what happens with compiled version.
Though, Inconsistent crashes means that AI differentiates behavior. Which is ultimately good.
FYI:Yep, Alpha Centauri Bear inspired me to make such suggestion to forum owners.
There now is a sub-forum for this mod
Just curious if Windows 64 bit has any benefits? The 32 bit version works completely fine for me.Here's a quote from 40k-discord that explains why I've been trying to build one:
2. Have you thought about also applying AI to interceptors to automate the intercept/dogfight process? I would be interested in potentially automating manufacturing, purchasing, and research options too. Could potentially make the entirety of XCOM and "idle" strategy game which is appealing to me.
Been playing this mod on 7.11.1I don't think 7.11.1 already had configurable individual soldier-aggressiveness. I assumed they were permanent and stored in the soldier-object. But this code is not from me, so I'll have to check. I just recently changed the default to 3 as otherwise it's very likely they stall.
Some suggestions and feedback.
1. When setting aggressiveness for individual soldiers, their aggressiveness settings don't stay persistent when reloading a save game or between missions. It would be great if it was possible to setup aggressiveness states that were permanent... so that way I don't have to reset them every time I load a save or embark on a new mission.
2. Have you thought about also applying AI to interceptors to automate the intercept/dogfight process? I would be interested in potentially automating manufacturing, purchasing, and research options too. Could potentially make the entirety of XCOM and "idle" strategy game which is appealing to me.
apparently it seems has a bug on "powerRangeReduction" hook witch the algorithm doesn't work properly, as you can see the chainsaw has the powerRangeReductionset set to reduce 99 power points after the 3rd tile however the weapon's power still remains, i don't know it is a setup you can tweak on the engine but this happens with any weapon within any mod witch has setup to to trigger the power ReductionThis doesn't sound particularly AI-related. Does it work as intended in regular OXCE?
no, it has to?No. Just trying to rule things out.
you mean on 7.12.1 ???I'm trying to figure out whether this could be something that was just fixed in the latest version of OXCE. If so, I could stop trying to figure out what's going on here. Other than that, I've never heard of this kind of feature before and am also pretty sure I haven't made any changes to code that should mess with it.
maybe the targeting calculations is mess up when you re-work the targeting system cuz whenever i move the mouse off the limits, the values decrease to zero as intended but it quickly come back to original valuesI think I found it. It's not the targeting-calculations itself that are faulty but the cursor-drawing. There he replaced the line:
I think that simply initializing distanceTiles the same way distance was initialized should fix the issue.
Does that work?Yes, this helped for this issue. But I've found a new issue with something else since.
I'm doing a video guide installation. I'm getting to the first launch. Swears at the absence msvcp140.dll . When I add it to the folder with the game, the error 0xc000007b starts swearing. Where did I make a mistake? The latest version of brutal. Win7 64.I'm compiling on Win 11. I have no idea if it's supposed to be compatible with Win 7.
I'm compiling on Win 11. I have no idea if it's supposed to be compatible with Win 7.Thanks, I've already done it myself. But it is strange that the updater showed the latest version of the libraries, but manually reinstalling them solved this problem anyway.
When I search the issue I get the recommendation to download this:
https://www.microsoft.com/en-us/download/details.aspx?id=53840
in order to fix it.
But I have no idea if it will work.
1) In the prison menu, at the base and at the end of the mission, add another function (button), in addition to selling the selected prisoners. The "kill" button, which will kill the selected prisoners and send their bodies to the warehouse.Advanced options -> OXC -> 'retain interrogated aliens'. This allows you to retain 'removed' aliens as corpses. If you want the three-button version, enable 'live alien sale' as well. Of course, this also gives you corpses for vivisecting live aliens, but since you're already into extraterrestrial cadavers, I imagine it's not a big deal. ;)
Advanced options -> OXC -> 'retain interrogated aliens'. This allows you to retain 'removed' aliens as corpses. If you want the three-button version, enable 'live alien sale' as well. Of course, this also gives you corpses for vivisecting live aliens, but since you're already into extraterrestrial cadavers, I imagine it's not a big deal. ;)
The end-of-battle menu should also include this, if I'm remembering right.
Aggressiveness now can be set from levels 0-3 and choosing option 4 means aggressivness is inherited from unit-aggression.Yes, with inherit enabled everyone >=3 will be zealot.
There's now 4 distinct levels:
0> Camper
1> Ambusher
2> Skirmisher
3> Zealot
I want to tweak the aggression level of the units in XPiratez. The aggression level in the .rul file goes from 0 to 8. How does inheritance work?
Is 0 - camper, 1 - ambusher, 2 - Skirmisher, 3-8 - Zealot?
Or is there another formula?
There's one non-optional-change to how manufacturing worksPlease do not take this as an attack of any kind on this great mod, but I don't want to make my enemies smarter for now, not at least for the next playthrough or two, may be later, when I'll get better at beating the alien scum. I want, however, to use Facility Expansion Pack, which has Brutal OXCE as its prerequisite. So, do I understand correctly that quoted means apart from a small manufacture quirk everything else from Brutal OXCE could be disabled somewhere in its settings on player side while still having Brutal OXCE technically installed to satisfy Facility Expansion Pack's requirements?
So, do I understand correctly that quoted means apart from a small manufacture quirk everything else from Brutal OXCE could be disabled somewhere in its settings on player side while still having Brutal OXCE technically installed to satisfy Facility Expansion Pack's requirements?I think the manufacturing-queue is now also part of regular OXCE, so there shouldn't even be a difference there anymore.