OpenXcom Forum
Contributions => Programming => Topic started by: karvanit on October 29, 2012, 10:26:06 pm
-
I am trying to implement a new (event-based) system for the Geoscape AI.
The basic idea is to have a central GeoscapeAI object living attached to (pointer owned by) GeoscapeState.
Every "interesting" event in the Geoscape will post an event to the AI, which will decide what to do with it.
So far I have an AI that takes 5 files to just do the same random time-based spawning as the current code! But what I did for the long runis turn each event handler into a virtual function call on the AI, with the event as an argument. So it's very easy to add new events, just detecting them and posting them when they happen, then letting the AI take care of the details.
I will keep moving functionality from GeoscapeState into GeoscapeAI, by adding new event types and their (default) handlers. Eventually I plan to have different GeoscapeAI implementations, for the different difficulties.
-
Here is the current state of things:
- One event is generated every 30 game minutes.
- I am still using the time-based random chance code that was in GeoscapeState for UFO spawns and Terror sites.
In the immediate (near) future I will implement events and keep current behaviour for the following:
- Detect total destruction of UFOs.
- Detect crash landing of UFOs.
- Detect expiration of mission sites.
- Detect XCOM winning / losing a mission.
- Detect arrival of UFOs to destination.
The code is live, compiles and does not crash (minimal testing) on my 'devel' branch in GitHub. Comments in either place are more than welcome.
-
Disclaimer:I probably don't understand what you're doing very well but if I understand this correctly.
that said
In the immediate (near) future I will implement events and keep current behaviour for the following:
- Detect total destruction of UFOs.
- Detect crash landing of UFOs.
- Detect expiration of mission sites.
- Detect XCOM winning / losing a mission.
- Detect arrival of UFOs to destination.
I think modders wanting an event based AI would want events for things like xcom bases being built, ufo's being detected by xcom, ufo's being engaged by xcom craft, bases being detected (x-com or alien), research/manufacture completion, funding changes, etc.
examples:
- Mod adds a type of artifact site mission for the aliens that the aliens only launch after x-com researches a pre-requisite.
- Mod causes supply missions to spawn from north pole instead of south pole when an x-com base is created in Antarctica and x-com has less then 4 bases.
- Mod causes battleships on 'alien research' missions to land next too an x-com base for 48 hours every time x-coms balance goes negative at the beginning of the month.
- Mod causes a new terror mission to be launched every other time X-COMs funding increases at the end of a month, but with a battle-ship instead of a terrorship.
- Mod causes all infiltration missions to take place in regions where x-com has a base (xcom has built more bases then x-com has lost).
I'm not saying anyone would actually do those exact things with a mod, but I would expect modders to want to use geoscape events other then attacks on aliens, even though a true alien AI would only need to react to things that the aliens should know about.
-
I am watching this topic with great interest as i would love to be able to specify new mission types to be spawned at schedules that suit me, you build what you think is right and then i will ask nicely for what i think is missing :P
-
That is the idea, everything that happens on Geoscape also triggers an event.
I'm simply starting with existing things, to make transition smoother.
-
I hope SupSuper will release 0.4.5 soon, and then we will see your changes in main branch ;)
-
i'm gonna merge your geoscape ai with my branch tomorrow and see how it goes.
in the meantime, since you're developing the geoscape, may i submit my efforts for your approval?
things i've done that may be of interest to you:
- psychic training menu - working like vanilla (i think?)
- live alien capture and research - haven't done "bonus" topics for ranked aliens yet, but works to an extent
- ufopedia - working like vanilla (sort of) still needs some fixing.
- alien bases - working like vanilla, except the trigger that spawns them (need battlescape AI for this)
or should i fork it and do it that way?
-
I am setting up the ruleset right now, the code in GitHub will compile but won't really do anything different.
I had planned to implement the alien missions in the following order:
- Research
- Harvest: once Research type is done, this is just more ruleset data.
- Abduct: once Research type is done, this is just more ruleset data.
- Terror
- Base
- Supply
- Retaliation
- Inflitration
So I will try to pull in your alien base parts after I finish Terror missions.
Working in a single feature at a time makes for cleaner merges and better pull requests, so I don't want to clutter my development branch with stuff that should rightfully be different features. I'll get the rest after they go upstream.
You are of cource free to fork, but I don't think it's worth it right now.
PS: Isn't Ufopedia working already fine in upstream?
PS2: Could you prepare a branch with your alien base changes only? Branching either from upstream or my devel branch is fine.
-
I am doing a much better / cleaner reimplementation so expect my devel branch to become reset and lose history!
-
aw dangit, and i literally JUST finished getting it all in :(
gonna fork your project later today and add bases if i can figure out how github works.
-
...if i can figure out how github works.
It is possible it will take several hours. :)
(and not because of your abilities :) )
-
Real-Life(tm) has caught up with me, the rewrite may take some time,
Until I do get back on it, here is a sample of the rules for missions, to get your comments / suggestions (numbers are fake) (numbered lists are sequences, unordered lists are maps):
- mission: STR_ALIEN_RESEARCH
- races:
- afterMonth; 0
- racChance:
- STR_SECTOID: 60
- STR_SNAKEMAN: 10
- STR_FLOATER: 30
- chances for next period
- waves:
- ufo: STR_SMALL_SCOUT
- minTime: 120
- maxTime: 240
- flightPattern: [ 0 0 0 1 0 0 1 ]
- next wave
Flightpattern is a sequence of numbers, to be interpreted by the mission object (0 = waypoint, 1 = land for now).
-
The proper event skeleton is now under the (rewritten) devel branch on my GitHub. It's going to have a stable history from now on, sorry for any inconvenience.
(Still working on the AI stuff.)
-
how about something like this:
- type: STR_ALIEN_BASE
scoutList:
- STR_SMALL_SCOUT
- STR_MEDIUM_SCOUT
- STR_LARGE_SCOUT
- STR_BATTLESHIP
minScouts: 1
maxScouts: 3
minScoutTime: 120
maxScoutTime: 240
scoutFlightPattern: [ 0 0 0 1 0 0 1 ]
missionShip:
- STR_BATTLESHIP
minMissionTime: 80
maxMissionTime: 300
missionFlightPattern: [ 0 1 2 0 ]
spawnOnComplete: STR_ALIEN_BASE
points: 100
month1:
STR_SECTOID: 30
STR_SNAKEMAN: 20
STR_MUTON: 0
STR_ETHEREAL: 0
STR_FLOATER: 50
month2:
etc.
i could probably have all that being read from the YML in usable format by later tonight if you'd like?
quick explanation:
scoutlist: the alien AI should keep track of how mad it is at the player, the more mad, the bigger the scout.
flight pattern: 2 is "mission complete" - spawn the event in the spawnOnComplete field (ie terror site or alien base) and apply points to the alien activity score.
the rest should explain itself.
-
I was reading the mission info from https://ufopaedia.org (https://www.ufopaedia.org/index.php?title=MISSIONS.DAT). My understanding is that no actual escalation of scouts is happening, you just move back the time of the next spawn. Could you (or anyone interested really) check at https://ufopaedia.org and get a more definite answer?
My way of storing the race choices for each mission allows changing at different intervals, not just fixed. Easier to extend.
I like you idea of '3' meaning 'mission complete, do whatever the spawnOnComplete says'. It's easier to extend than my idea.
Another question: Are the waypoints in vanilla in the same region as the mission or all around the map? Or any other pattern?
-
as found on:
https://www.ufopaedia.org/index.php?title=UFOs#UFO_Behavior (https://www.ufopaedia.org/index.php?title=UFOs#UFO_Behavior)
UFOs will ALWAYS head to their mission locale (as listed in the Hyper-Wave Decoder information) at top speed and then initiate one of the following behaviors depending on the mission
so the first waypoint is in the mission area, any additional waypoints would probably be generated within the borders of the target region (country?) or a radius of the original waypoint, until "go home" is triggered (-1?)
If you are successful at preventing lesser UFOs from doing their jobs, the aliens will eventually send Battleships to do the dirty work, hoping you won't be able to attack them. (They will not participate in Alien Research and Alien Terror missions, though.)
translation: shoot down scouts, aliens get mad and send bigger scouts and eventually battleships as scouts, or even as the mission ships themselves. (in certain cases, hence why we define it in the rulesets)
see also:
https://www.ufopaedia.org/index.php?title=Terror_Mission#UFOs_with_Terror_Missions (https://www.ufopaedia.org/index.php?title=Terror_Mission#UFOs_with_Terror_Missions)
If you are consistent and successfully destroy the scouts, the aliens will start sending out heavier UFO classes as scouts. This will gradually increase until you finally have Battleships and Terror Ships as scouts during the last few UFOs in the Alien Terror waves.
-
what vanilla are you talking about?
ufopaedia doesn't have too much info on how waypoints work. but this info was properly reversed and was given to oxc developers. waypoints are limited to regions. each region actually have its own set of waypoint zones for each trajectory stage.
-
what vanilla are you talking about?
ufopaedia doesn't have too much info on how waypoints work. but this info was properly reversed and was given to oxc developers. waypoints are limited to regions. each region actually have its own set of waypoint zones for each trajectory stage.
Good to know. The published OpenXcom does not have waypoint information right now, all waypoints are random coordinates. Could you provide a file or page with this information, so I can take advantage of it?
-
translation: shoot down scouts, aliens get mad and send bigger scouts and eventually battleships as scouts, or even as the mission ships themselves. (in certain cases, hence why we define it in the rulesets)
see also:
https://www.ufopaedia.org/index.php?title=Terror_Mission#UFOs_with_Terror_Missions (https://www.ufopaedia.org/index.php?title=Terror_Mission#UFOs_with_Terror_Missions)
Yes, but on eg Terror info from MISSIONS.DAT (https://www.ufopaedia.org/index.php?title=MISSIONS.DAT#Terror) it appears only 4 ships will take part in the terror mission. Two scout and two terror ships.
So, how does it work? How do we want to encode it so that at least the vanilla behaviour happens for 1.0? How to encode it so that additional things can be done just by tweaking the ruleset?
-
each mission row in mission array referred to predefined craft+mission table trajectory type.
there are 10 trajectory types.
each trajectory type can have maximum 8 stages, and each of it have its own speed %, altitude and globe site.
globe sites are taken from huge table of 720 random squares. it devided on 12 zones (actual game zones). each zone have 6 different sites, and each site consists of 10 random areas. when game choose location - it takes random location from one of these 10 random areas.
some of sites actually have width=height=0 (which is city location). which are used for terror missions (and for city rendering as well).
https://pastebin.com/SUDr1YF0
you can see them visualized with my globe editor https://www.ufopaedia.org/index.php?title=User:Volutar (second list at right)
-
minScouts: 2
maxScouts: 2
MinMissionShips: 2
MaxMissionShips: 2
also, i'm done with the code to read in the ruleset as per your requests, gonna attempt to merge now.
here's the basic structure for the ruleset:
missions:
- type: STR_ALIEN_HARVEST
scoutList:
- STR_SMALL_SCOUT
- STR_MEDIUM_SCOUT
- STR_LARGE_SCOUT
- STR_BATTLESHIP
minScouts: 1
maxScouts: 3
minScoutTime: 120
maxScoutTime: 240
scoutFlightPattern: [ 0, 0, 1, 0, 0, 1, 0, -1 ]
missionShip:
- STR_HARVESTER
- STR_BATTLESHIP
minMissionShips: 1
maxMissionShips: 3
minMissionTime: 80
maxMissionTime: 300
missionFlightPattern: [ 0, 1, 2, 0, -1, -1, -1, -1 ]
points: 100
races:
- STR_SECTOID: 50
STR_SNAKEMAN: 20
STR_MUTON: 0
STR_ETHEREAL: 0
STR_FLOATER: 30
- STR_SECTOID: 50
STR_SNAKEMAN: 0
STR_MUTON: 0
STR_ETHEREAL: 0
STR_FLOATER: 50
- STR_SECTOID: 30
STR_SNAKEMAN: 0
STR_MUTON: 30
STR_ETHEREAL: 0
STR_FLOATER: 40
- STR_SECTOID: 10
STR_SNAKEMAN: 0
STR_MUTON: 40
STR_ETHEREAL: 0
STR_FLOATER: 50
- STR_SECTOID: 30
STR_SNAKEMAN: 0
STR_MUTON: 30
STR_ETHEREAL: 0
STR_FLOATER: 40
obviously not all these values are the PROPER values, i just needed something to read in to test it, but it should have all you need available.
-
@volutar: Great information, thank you. Could you also add the region and zone for each area?
@Warboy1982:
Races should be a sequence of maps, like so:
races:
- afterMonth: 0
distribution:
STR_SECTOID: 10
STR_MUTON: 5
- afterMonth: 3
distribution:
STR_SECTOID: 10
STR_FLOATER: 20
STR_MUTON: 50
Taking the info Volutar has uncovered, I think we should either have a table of trajectories common to all missions (and use trajectory number / id) or replicate the trajectory information per type (scout / mission). I'm leaning towards common list and using ids myself, less typing / cut-and-paste. This means the flightPattern is not needed as we discussed.
-
i can't figure out github.
i have the changes ready to push, but i don't think i forked it properly, nor do i really see any option to.
little help?
or you want me to post... what i've changed... somewhere?
edit ---
https://dl.dropbox.com/u/47596892/Changes.rar (https://dl.dropbox.com/u/47596892/Changes.rar)
because i can't find the "fork this" button
-
The steps to do to prepare a clean pull request are:
- Add my repository as a remote (let's say karvanit).
- Create a local branch from the branch you want to get merged in eventually. (my devel)
- Work locally until you are satisfied (making logical and nicely commented commits!).
- Push your changes to a new branch on GitHub.
- Make the pull request.
In command line git the commands are (assuming your GitHub remote is origin:
- git remote add -t devel karvanit git:https://github.com/karvanit/OpenXcom.git
- git checkout --no-track -b for-karvanit karvanit/devel
- ... (many git commits later)
- git push origin for-karvanit
If you are using a GUI tool, I'm sorry, but you'll have to figure the proper way to do steps 1,2 and 4, I have ABSOLUTELY no experience with them.
-
I now have code to read / write (incomplete) alien mission rules in 'devel'.
Only the racial distribution is stored for now, and I'm not actually using the rules yet.
-
and this is the point where i say "forget the whole thing" and move on to something else.
you've got my code, whether you use it or not is up to you, github has made this whole process about 1000x more painful, frustrating and downright confusing than it needs to be.
github is about as user friendly as a bicycle with no seat, no handlebars and no wheels.
good luck with it.
-
karvanit, what do you mean by "region and zone for each area"?
There's also race/mission/month distributon data (https://pastebin.com/4wCVZ36G) .. that's all.
I suppose all this table/distribution data should be somehow unwrapped into uniform ruleset structure.
But I have no clue how to do that, considering the fact, that there are number of crosstables over there, and it can be unwrapped in different priority, like race as main structure, or mission as main structure, or zone.. or something else. Trajectories probably better to be defined in separate ruleset.
There is another way. We may totally unrwap whole hierarchy, and "mission setup" way from the start, and re-invent this.
-
Warboy1982: You are speaking from my heart. :)
But don't give up so easily!
-
so i finally get github "figured out", sit down to take a look at your code, and you've used completely different methods in ruleAlienMission than in... every other ruleset in openxcom.
i'm at a loss here. i just don't know what to do.
should i rewrite it? should i try to figure out wtf you're doing and try to do it that way?
-
karvanit, what do you mean by "region and zone for each area"?
I mean, of the 720 areas, which belong to each region (eg North Americe) and which belong to each zone (eg North America zone 0)? Is it just by position (offset) in the table?
I have already set the race/month/mission distribution data according to the data in Ufopaedia.org as data in the mission rules.
For the rest (trajectories, UFO types etc) we need a way to represent it in the ruleset. I think trajectories (zones and areas) should be a different ruleset, as well, but the rest (UFOs and spawning them) should be part of a mission's rules. That's what we should be trying to figure out.
We need a way that can:- Handle all the vanilla data. It needs to give as close toi same behaviour as we can get.
- Allow easy modification.
- Allow extension (eg new mission types) with minimal of extra coding, only ruleset changes.
-
First of all, thanks for the clean pull request!
so i finally get github "figured out", sit down to take a look at your code, and you've used completely different methods in ruleAlienMission than in... every other ruleset in openxcom.
i'm at a loss here. i just don't know what to do.
should i rewrite it? should i try to figure out wtf you're doing and try to do it that way?
Besides the I/O (which I have now brought more in line with the rest of OpenXcom) the RuleAlienMission only has two functions, one to get the mission type and one to select a race. These are the only mission parts I have in the ruleset so far. I have hidden the 'chose a race from among the possibilities' behind a separate class that can be used to select based on weights, because this is common functionality (choose mission type based on region, choose region for mission, all these are the same).
-
Is it just by position (offset) in the table?
Sure. It's the only way xcom adresses any data.