[Missions] [0001] Review and establish missions such as the following

[mwpowellhtx]

Basic Information

Mission version: v0.98.dev-s9 Map used: Altis

Short Issue Description

Review the missions module for readiness. Look at transferring the missions over, including new ones we came up with.

• [ ] Convoy intercept
• [ ] FOB hunting
• [ ] Search and rescue
• [ ] Human trafficking liberation
• [ ] Escort civilian informant, which may in turn trigger,
• [ ] Neutralize high value target
• [ ] Capture and interrogate enemy prisoners
• [ ] Counter attack, which is triggered by capturing metropolis areas
• [ ] Ambushed
• [ ] Reinforcements can, from time to time, be called in to support engaged metropolis sectors
• [x] Added a fire drill example mission (we have issues filed for these now, so there are checked accordingly)

Expected Behaviour

Create separate issues enumerating each one. Some of them are new-ish, or at least a better factoring from before, such as counter attack, also ambushed.

[mwpowellhtx]

Picking this one up next, part and partial because we think that this will at least partially if not entirely also inform how we setup cross cutting mission concerns, i.e. logistics ambush as a mission.

[mwpowellhtx]

Currently we think that these are "created" given a tuple of details... Parsing through each of these bits, how much of that is necessary, or could be refactored to namespace, etc...

[
    ["_missionName", "", [""]]
    , ["_condition", {false}, [{}]]
    , ["_eventMission", false, [false]]
    , ["_cost", [0,0,0,0], [[]], 4]
    , ["_minTime", 0, [0]]
    , ["_randomTime", 0, [0]]
    , ["_missionStart", "", [""]]
    , ["_missionAbort", "", [""]]
    , ["_picture", "KPGUI\res\kp512_CA.paa", [""]]
]

And then... We also think there should also be a mission state machine that potentially watches for running or on going missions, etc. As well as the usual mission change orders, etc.

[mwpowellhtx]

These are just a few leading considerations.

• _missionStart and _missionStop appear to be string compile ready code; could just be CODE for that matter.
• _cost should rather be dubbed _debit appears to be [_supplyDebit, _ammoDebit, _fuelDebit, _intelDebit].
• _minTime, _randomTime, not sure what these are, however, any reference to time, timers, etc, should just leverage the timers module.
• _picture is just the picture, but really, we might like to support something more descriptive like formatted text, kind of a debriefing of sorts.
• Some missions are bought by players with permissin to do so, i.e. FOB hunting; whereas other missions might be triggered by conditions, i.e. Ambushed, etc.
• All missions should have setup and tearDown comprehension
• Missions may have start, startEntering, abort, abortEntering callbacks, which do the typical pre-check and follow through activities.
• Missions should be specified in terms of CBA namespace variables should be named KPLIB_mission_xyz.

[mwpowellhtx]

In addition to the above, there should be the usual namespace support, verification therein, and conversions to and from tuple arrays, especially for serialization purposes, display in a missions manager, etc.

[mwpowellhtx]

Starting from the 0800_mission module that was sketched in, as indicated above. We will separate that out into several key modules:

• 0800_missions, the core API supporting missions, namespaces, tuples, conversions between, verification, etc; also handles serialization and such, when applicable.
• 0801_missionsSM, statemachine, which governs their triggers, start and stop conditions, so on and so forth.
• 0802_missionsCO, responsible for handling client server change order requests.
• 0803_missionsMgr, the client side missions manager dialog, responsible for presenting available missions, and any on going or active missions.

Should be able to rinse and repeat the sort of approach we took concerning logistics and production with good effect here as well.

[mwpowellhtx]

The following are the set of mission variables that make the namespace what it is.

• KPLIB_mission_uuid, templartes do not have a unique identifier, they are templates
• KPLIB_mission_templateUuid, templates themselves must be uniquely identified
• KPLIB_mission_args, missions may support arguments for use during its evaluation
• KPLIB_mission_cost, missions support an optional cost in the form, [SUPPLY, AMMO, FUEL, INTEL], default is zero
• KPLIB_mission_pos, missions typocailly occur starting at a position
• KPLIB_mission_radius, missions also typically involve an activation or awareness radius, default is KPLIB_param_sectorCapRange
• KPLIB_mission_status, the current status, default is KPLIB_mission_status_standby
• KPLIB_mission_timer, a timer used to measure time sensitive missions, default KPLIB_timers_default
• KPLIB_fnc_mission_onEnterMission, callback invoked when entering the mission for the first time, typically invoked by source actor, player, or subsystem
• KPLIB_fnc_mission_onAbortMission, callback invoked by player, typically, to abort the mission
• KPLIB_fnc_mission_onMissionSetup, callback sets up the mission parameters, deploys assets to the area of operation, etc
• KPLIB_fnc_mission_onMissionEntered, analog to CBA statemachine onStateEntered, and is invoked as such
• KPLIB_fnc_mission_onMission, analog to CBA statemachine onState, and is invoked as such
• KPLIB_fnc_mission_onMissionLeaving, analog to CBA statemachine onStateLeaving, and is invoked as such
• KPLIB_fnc_mission_onMissionTearDown, callback invokved after mission complete, performs any remaining cleanup, garbage collection, etc, required to tidy up the area of operation after KPLIB_mission_status_completed status

Note, all callbacks default to a singular "no-operation", does nothing, returns false placeholder. Highly suggested, of course, that individual missions bundle their own unique callbacks.

In addition, we may support an internal status as a periodic health and monitoring check:

KPLIB_mission_status_standby    =   0;
KPLIB_mission_status_template   =   1;
KPLIB_mission_status_running    =   2;
KPLIB_mission_status_started    =   4;
KPLIB_mission_status_engaged    =   8;
KPLIB_mission_status_aborting   =  16;
KPLIB_mission_status_success    =  32;
KPLIB_mission_status_failure    =  64;
KPLIB_mission_status_completed  = 128;
KPLIB_mission_status_gc         = 256;
KPLIB_mission_status_system     = 512;

[mwpowellhtx]

Should also consider mission-specific status reports, telemtry, etc.

[mwpowellhtx]

Wrapping up the initial phases. I expect this is not fully resolved, there are gaps concerning system template for example, but we know this. When there is opportunity to consider system templates, then we will cross such bridges. There are also suspected improvements concerning how, or when, to localize string table elements, but this is potentially much broader scope than just missions. There are probably a handful of cleanup efforts concerning no-op callbacks, return values, so on and so forth, but for now, we're marking this resolved, and will follow up specific issues later. We must also refer to this issue for purposes of planning specific mission efforts.