Active Alien Geoscape AI - has anyone ever taken a stab at this?

[Meridian]

To include to my branch (Meridian could have different criteria for his branch) I would like that overall default behavior will stay same (same time for dogfight and geoscape is detail that can be changed).

No, my criteria are basically the same.
I want that OXCE+ can be used with vanilla ruleset and have the same mechanics.
Most (if not all) of my features are:
1. either optional, i.e. activated by mods
2. or QoL improvement without any effect to game mechanics

The only exceptions I can think of are:
a/ the default experience training for throwing accuracy... but I plan to make this optional in the future too
b/ arcing shot miss fix... which was removed for now, but will be re-introduced sooner or later
c/ turned off crazy CGA flashing epileptic 1 frame effect on explosions... I hope nobody wants that shit back!
d/ going to Mars is possible only with 100% fuel
e/ alt, shift and ctrl cannot be used as hotkeys

PS: @Yankes: I hope that your new lighting changes in OXCE 3.3 will be optional too, and won't affect performance negatively

[Yankes]

PS: @Yankes: I hope that your new lighting changes in OXCE 3.3 will be optional too, and won't affect performance negatively

This will depend how it will work on other people machines. First will be always enabled and I will try optimize it further if someone have bad performance.
If I do not manage to fix it, I will disable this feature for default and add option in ruleset to enable it back. I simply need some feedback to fine tune it.
You can be first beta tester if you want Right now most costly part is light from fire, especially when you set whole map on fire.

[Hobbes]

• A disgustingly artificial limit of 4 dogfight participants per side.. but required so as to not have to design a whole new dogfight UI.

I think the 4 craft per side limit is quite sensible. Having to control dozens of craft might sound nice but the more craft you add, the more playability will suffer because of all the micromanagement involved.

[Stoddard]

An update.

Prototype flight model is partially implemented. What's missing is the code to have them behave at close ranges.

• Altititude is tracked in meters
• Acceleration plays a big role:
• units are assumed to be 1G
• one unit is needed to maintain straight level flight (air resistance is not taken into account, might be later)
• the rest are allocated for acceleration/deceleration
• thus no instantaneous speed/direction changes, that's what surplus acceleration is for
• this all is limited by the max speed from rules, which is now 'never exceed speed'. This rule is waived
  for the topmost altitude band (>50km) where speed is not limited, but they can't go below that if their speed is over the limit.
• Existing altitude scale is broken up like this (meters above ground level):
• <1 - STR_GROUND
• 1-1000 - STR_VERY_LOW
• 1000-5000 - STR_LOW
• 5000-10000 - STR_MEDIUM
• 10000-25000 - STR_HIGH
• 25000-50000 - STR_VERY_HIGH
• 50000-100000 - STR_MESOSPHERE
• Actual mission flight level is random there somewhere depending on the mission definition.
• Anything above 100km is not tracked.
• Ufos that mysteriously appear/vanish at start/end of their missions are instead considered leaving/entering orbit
  and thus their trajectories have the descent/ascent glued in at the ends.
• Since they all do this for now, most of the missions are to be redone to have cities, bases, mansions, towers, warehouses, whatever
  to be the origin/destination points
• Interception is implemented in that:
• Each faction has its detection facilities, for now it's their bases, their ufos and the cities
• Player craft is tracked per-faction and interception craft is launched randomly
• If the interceptors have enough accel and favourable position, they line up with the player craft.
• Interceptors appear landed at their point of origin and sit there for the same 60 seconds as player craft do.

Todo list for the first playable release is thus:

• Fix terminal guidance so that the ufos equalize speed and heading nicely.
• Force open dogfight UI when that happens.

Next things would be:

• Make ufo weapons use the same slot/type/rate/range/damage model as the player craft. Ammo limits too.
• Implement fuel contstraints on the ufos.
• Tie radar detection ranges to the light-of-sight (target altitude) and maybe speed, which would increase the chance.
• Increase radar scan frequency and make it so that the hyperwave decoder detects transmissions
  only, where the transmissions are more-or-less not guaranteed to happen (depending on the faction alert level or something).

[Solarius Scorch]

This is going to be a revolution.

[Hobbes]

And I've decided to give this thread another bump since this is something that really interests me for my future plans

[HelmetHair]

Sheeeyit.

Any progress?

[KBGhost]

Bump. Is Stoddard still working on this?
And if not can someone else pick this up?
It looks very interesting but I have no coding knowledge.

[Hobbes]

And another bump, since I've started pushing the Terminator total conversion for an alpha release, and I've been long wanting to include this feature.

[Stoddard]

The short story: prototyping AI in C++ is masochism. Even adding trivial features like the leeroy-jenkins mode is, well.., it took way more time than expected. So..

So I wrote bits and pieces of an 'AI' (but mostly ufos moving around on a geoscape, some data structures to extend their 'awareness', pure python junk code piles). That was promising.

I then embedded a Python interpreter in the game, since the previous approach of communicating with a separate process running the alien AI was a) very high latency, slowing the game like 10+ times, b) hard to maintain api/protocol-wise.

See https://openxcom.org/forum/index.php/topic,5519.msg84269.html

As it says there, the UI is the hardest part in the game to control/define an exported api/this kind of thing. Still quite straightforward if a bit boring.

And it's also the first part that has to be done, since new AI requires debug (which is better done via UI) and also UI as such.

Since July I was settling in at a new job, so there wasn't any progress. I think in September there would be some.

[Hobbes]

The short story: prototyping AI in C++ is masochism. Even adding trivial features like the leeroy-jenkins mode is, well.., it took way more time than expected. So..

So I wrote bits and pieces of an 'AI' (but mostly ufos moving around on a geoscape, some data structures to extend their 'awareness', pure python junk code piles). That was promising.

I then embedded a Python interpreter in the game, since the previous approach of communicating with a separate process running the alien AI was a) very high latency, slowing the game like 10+ times, b) hard to maintain api/protocol-wise.

See https://openxcom.org/forum/index.php/topic,5519.msg84269.html

As it says there, the UI is the hardest part in the game to control/define an exported api/this kind of thing. Still quite straightforward if a bit boring.

And it's also the first part that has to be done, since new AI requires debug (which is better done via UI) and also UI as such.

Since July I was settling in at a new job, so there wasn't any progress. I think in September there would be some.

I was hoping but not expecting for a reply. Sweet

One of my wishes for the Terminator TC is to have Hunter-Killers conducting aerial patrols in regions and intercepting Resistance craft. I've already been modifying some of the missionZones used to determine the flight paths of UFOs since this might require some specific waypoints

[Meridian]

Don't want to steal this thread, so I opened a new one with some pre-alpha hunter killer footage: https://openxcom.org/forum/index.php/topic,5717.0.html

It doesn't have any big ambitions, just allow UFOs to attack xcom under some conditions and allow alien bases to spawn such hunter killers too.