flightcontrol-master / moose Goto Github PK

Create a system in which the HQ/AWAC/C&C unit on the map keeps track of taskings similar to the dynamic detection system now (or even using that system), but also utilizes existing AI on map that are available for tasking and assigns them the taskings.

This could be done by issuing messages to those AI. The AI would parse the message (regex) and assign themselves the tasking (Task SEAD, Task CAP, etc.).

The AI would also respond to queries by the client and/or HQ as to their BRA from bulls, current tasking (if any), loadout, etc.

Need to update some logic in the SCHEDULER class. Right now, each SCHEDULER:New call will result in a new scheduler function being created, which is fine.

However, if there is a one-pass schedule, then after the schedule has been processed, the function should be removed...

Also, when the schedule is started again, a new schedule function should be created.

In repeated loops, an existing schedule function should be kept, and with the function timer.setFunctionTime(FunctionId functionId, Time time) the schedule should be rescheduled...
once the repetition is finished, the removefunction should be called.

Build a InitRandomizeZones() API, taking an array of zones with a probability factor per zone.

ACG_IronJockel has posed a requirement on the eagle dynamics forums: http://forums.eagle.ru/showpost.php?p=2758890&postcount=94

Hi Sven,
Thank you for this awesome framework!
I think this is the way to go with mission scripting etc.

I'm trying to create a function that blocks people from despawning midair to prevent kill denying. So what i currently think I need is a method that prevents people from despawning what I enable via an event handler.

Alternatively, some kind of punishment mechanism that blocks people that did despawn midair to spawn again for n minutes.

you're idea is similar to what i was thinking about if the block of despawning doesn't work. I think a kick is a bit to harsh. To prevent em from spawning for n minutes if they do it would be something appropriate. I gonna check what i can do with the scoring class, and reply next week.

Add an option to SpawnScheduled.

There are two modes for incorporating MOOSE: dynamic and embedded. By default the former is favored. This makes sense from the POV of Moose development. However, for mission builders using MOOSE or developers who are developing scripts that rely on MOOSE but not actually editing the MOOSE code base, it probably makes more sense to use rely on embedded MOOSE. I think favoring this approach in the MOOSE documentation will greatly increase adaptation rate, as people will find it easier to understand and do (as it follows how, e.g. MIST, CTLD or other scripts are used).

In any case, I suggest two templates bundled with MOOSE: (1) the current one, which allows for easy switching between embedded/dynamic based on a flag value; (2) a embedded-only one, which allows for mission builders who just want to use MOOSE to easily build missions.

Both (1) and (2) should, of course, need to be updated every time the MOOSE library is updated. This can be a PIA, I know! But I am thinking in the future we could maybe have some support utility scripts that unzip the template mission file, replace the embedded MOOSE lua file with the new one (generating it first if needed), and then zipping it up again? Don't know if this is feasible or robust, but I could look into it in the future ....

1. Operator overloading... It will allow to add or remove objects from the set using + or - operators....
2. Synchronous and asynchronous iterators... My previous implementation was based on coroutines, but unfortunately, DCS is not able to handle garbage cleaned coroutines... Dcs crashes when it believes there is still a coroutine alive from within their c++ code... So, I'll have to implement my own stack using tables... It'll work... Wait and see...
3. Enrich the methods with more unary functions where SETS can be integrated...
4. Improve the documentation and make example missions...

Could we have a new SPAWN initialisation method based on userflag?

if a flag # is true then spawn the new group
spawn the units until flag # reach a set value or is set to false/true

I need to enhance the event logic and the event dispatcher.

Right now, each class object, that implements an event function will receive the event, even if the event was not meant for that object.

f.e., if i have 2 SPAWN objects, SpawnA and SpawnB, and a crash event occurs of a unit belonging to SpawnA, then both SpawnA and SpawnB will receive the event.

However, DCS for certain (not all!) events include the UNIT name of the event.
I need to do a good analysis which events are related to units, and add event dispatchers for units, so that when the event is received within the dispatcher, it can immediately dispatch the event to the correct object that should receive the event, instead of letting each object decide if the event is for him...

This work can be done, but i want to encapsulate the event complexity by provide in the BASE class for each event type an API. So, this development will require some good analysis of the events being triggered by DCS in all possible scenarios, and then write an ecapsulation API around that in BASE.
Then, i need to REWORK in the class hierarchy of MOOSE the different event implementations to use the new API. So, i'll start with that and create a branch...

The mission template:

https://github.com/FlightControl-Master/MOOSE/blob/master/Loaders/MOOSE-Template.miz

is prepopulated with units. Should that be the case? Should it not be empty except for the triggers that load the MOOSE library?

Load Moose dynamically with the *GameGUI.lua method...

A logic to be added in the DATABASE class, to scan also the AIRPORTS...

For the SPAWN function if we use late activation unit we cannot use the function IsAlive() to detect if the unit /group has spawned or not.

This is due to the way DCS work. A late activation unit is alive even if not activated yet

A work around at the moment is to use trigger.misc.getUserFlag

• Wrapper classes. These are classes that Wraps a shield around existing dcs objects, and provide more functions around that... examples are GROUP, STATIC, AIRBASE, UNIT, CLIENT...
• Utility classes: These are classes that you can use to implement advanced technical functionality, like POINT_VEC3, POINT_VEC2,
• Abstract classes: These classes provide a base of functions for other classes to be derived from... Examples are BASE, DETECTION_BASE...
• Task and Process classes: These classes implement a "long lasting" business processes or tasks, using a state machine implementation.
• Technical classes: These implement technical "building blocks" to do advanced technical things... Like SCHEDULER, MENU, EVENT...
• Functional classes: These are classes that implement a defined functionality... Like AIBALANCER, AIRBASEPOLICE, SPAWN, DETECTION_DISPATCHER, DETECTION....

Users are able to use the spawn class to spawn groups into a zone. Using the function SPAWN:SpawnToZone() it should be possible to use the scheduled function as well as the limit initializer.

A great benefit would be, to even have the SPAWN:NewWithAlias as an initialization, because that way it should be easy to set up GROUP_SETS by the name given as alias.

So u could end up having a single Group (Unit) Template in the mission designer, and spawn this one to a zone e.g. 20 times. If those grous (units) die, they would respawn in the given interval and thus be filled up to the given limit.

In order to make MOOSE more accessible to mission designers, I need to rework the documentation, and the naming of the MOOSE_Embedded.lua file. It is not accessible enough.
A normal Moose.lua file would suit better. Will do this before the next release.

Need to ensure that the first and the last point are connected. Need to review the algorithms and test.

Escort message class could just as easily be used as an "escortee" class, ie, a clint fighter could escort an AI strike. The wording of the ESCORT message would need to be changed though.

in DCS\MissionEditor there is a templates.lua file which contain all the templates created in the mission editor.
It would be useful to some of us if the Spawn_Templates_Visible could look into this file to extract potential templates.

Add an initialization to SPAWN in order to spawn units with AI off.

Embed SCORING in other classes by making and using SCORING APIs to add scores of a certain type upon certain events.

Task functions should not execute the task... They should return a task description... A string.... Some Task functions are however executed immediately, which is confusing! One standard. This change will have an impact to existing missions and users. So it must be well communicated.

There is a potential DCS bug with waypoint actions... It seems that a function call from within a waypoint action is not working anymore. We need to test PATROLZONE and check if the patrolling of the planes is still functioning...

Make a SMOKE class and a FLARE class.
Define colors in SMOKE and FLARE classes and define useful methods.
Use the methods throughout the code and clean up crappy implementations.

Do the same for light bulbs and explosions...

3 tries of setting up a clean dcs world environment including sl mods running a moose scripted mission ran into the following failures.

[string "C:\Users\DCS-SE~1\AppData\Local\Temp\DCS.openalpha/~mis0000324E"]:7: attempt to index global 'debug' (a nil value)

[string "C:\Users\DCS-SE~1\AppData\Local\Temp\DCS.openalpha/~mis0000324E"]:12: attempt to index field 'Files' (a nil value)

As sl mod is a widely used mod for hosters, it would be great to resolve this issue.

A database set to be created, which models the airbases belonging to a certain coalition. Note that this implementation can be tricky, as databases can be conquered by other coalitions. So the events must be carefully monitored...

Clients and Units are basically the same. Now they are in 2 separate hierarchies.
CLIENT needs to be derived from UNIT.
But there is a special trick, CLIENT does not need an alive DCSUnit, while UNIT does.
So I need to add a new constructor in UNIT and change the DCSUnit behaviour...
In this way, CLIENT can be derived from UNIT and it will work.

This to have the naming convention that a normal Vec3 would be a { x, y, z } structure. A PointVec3 would refer to a POINT_VEC3 object... I need to have this done to properly be able to finish the POINT_VEC3 class implementation...

To display messages within time intervals (flash) and update the message while the message object is alive...

Some retards find it funny to shoot their own groups of their coalition. I can make a class that destroys at least missiles being fired at their own coalition members ...

There seems to be an issue with the CLEANUP class. The groups are not destroyed when almost touching the ground. Need to check this.

The New function should also have the group documented.

There seems to be an error with the PICKUP_TASK logic, due to rework of the core of moose. Need to retest and rework the code a bit. Should be easy.

Make the naming convention clear throughout the code, that:

• Variables referencing a POINT_VEC3 are named (with the suffix) PointVec3.
• Variables referencing a Vec3 are named (with the suffix) Vec3
• Variables referencing a POINT_VEC2 are named (with the suffix) PointVec2.
• Variables referencing a Vec2 are named (with the suffix) Vec2.

Define consistent functions where POINT_VEC3, POINT_VEC2 can be used to perform vector operations.

After AI have done their task they land and park just fine but never deactivate. I suggest a cleanup routine that cleans out parked AI when speed is 0. TAG the aircraft as finished with task so you don't terminate AI that is holding short waiting for other aircraft's to land. The same function can be done on AI that is stuck on airport (two AI meeting) but there you have the same problem for not removing waiting aircraft's holding short. You can possibly remove "stuck" aircraft's after like one minute if they don't have the TAG that they have finished their task. Some functions to make this work but I believe it is possible.

Build a class that manages ground units AI on\off behavior when there are no enemies nearby. This to save processor resources...

This is probably not a big deal for most developers/users, but if anyone is working with the files remotes, or even need to transfer the files, many transfer protocols and programs (scp, rsync) find spaces a major problem, especially when over multiple file systems (e.g., Linux/OSX to Windows and back, which is my case). There are many work-arounds, from quoting to escaping, but as I have discovered when developing on my primary system (Linux) and pushing updates to a Windows deployment system, these are fragile and, worse, vary depending on protocol and tools. I think if the spaces are not strictly necessary, underscores or hyphens would make for a much more robust code base.