MOOSE Framework - DETECTION and TASK DISPATCHING

[FlightControl]

Hello,

 

From the MOOSE framework community, we are excited to introduce you with the underlying presentation, walking you through some of the concepts and developments done to enable automatic detection and grouping of targets and automatic task dispatching and task assignment.

 

In other words, a capability that opens the door for really dynamic mission design, where tasks are assigned based on a changing tactical situation, this in real time ...

 

The concepts explained and developed were initiated by an active member of our moose community: Mechanist, and on top, lots of active members of the MOOSE community has been advising and helping with the refinement of the concepts, the future different tasks types that will be developed and added in this framework. I would like to thank the 123 server team, the TAW team and individual contributions of MOOSE community members.

 

Just a small warning, the release as of today of this capability is in alpha. There will be further fine-tuning, and bugs are still within the system. But the purpose of this early release is to demonstrate the concepts behind, so that early feedback can be incorporated in the developments.

Note that the developments done is a "framework", meaning, it allows for future expansion and more task types and more detection methods and task dispacthing methods will be implemented in the future.

 

We really hope that you will enjoy the below video, and you can expect a demonstration video later this week. May I appologize in advance for my non-native English and sometimes having to search for the right words during the presentation ....

 

[ame]https://www.youtube.com/watch?v=CoLFqiyZJLo[/ame]

 

Note that you can try out yourself the demo test mission, which is located here:

https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Test%20Missions/Moose_Test_DETECTION_DISPATCHER

 

The concept will allow you to quickly setup missions, without much development knowledge. Note that some form of scripting knowledge is required to utilize MOOSE. There is a learning curve, but we believe it is worth it, as the framework allows you to make more dynamic and compelling missions.

 

You are also kindly invited to our first workshop tomorrow on Teamviewer 11.

 

Have fun, and, interested in your feedback!

 

FC & MOOSE community members

Edited July 20, 2016 by FlightControl

[ViFF]

I just watched the video in total amazement.

 

This is one step closer to an auto-generating ATO (Air Tasking Order) in a persistent world à la Falcon BMS dynamic campaign engine.

 

This has some amazing potential to create a dynamic environment that generates missions for a predefined number of airplanes sitting at an airbase.

 

Thank you for this!

[FlightControl]

I just watched the video in total amazement.

 

 

 

This is one step closer to an auto-generating ATO (Air Tasking Order) in a persistent world à la Falcon BMS dynamic campaign engine.

 

 

 

This has some amazing potential to create a dynamic environment that generates missions for a predefined number of airplanes sitting at an airbase.

 

 

 

Thank you for this!

 

 

 

Yes... And this is just the beginning. More functions to be added once people get creative... Note that the framework will allow you to create complex missions in no time. Bye bye triggers, flags, complexity. Hello simplification, creativity, enjoyment... Note that if you combine this with spawning, ai balancing, other tasks and discuss capabilities, ... Things will get funny... Talk to you tomorrow.

 

Sent from mTalk on Windows 10 mobile

[EntropySG]

amazing.

following this very closely

 

:)

[FlightControl]

A nice side effect. At night or at dawn, the detection done by the FACs is much less accurate. So, when you build a mission, lets say starting at early dawn, the detection accuracy of the FACs will slowly increase as time moves on...

 

Also added a JTAC capabilty now. During a CAS or BAI, the FACs can lase the targets with a set laser code... You can turn them off as well. Targets are categorised per Area and Threat Level.

So, many many many targets can be requested to perform a JTAC upon. HQ will coordinate the JTACs with the FACs. The closest FAC to an area will perform the lase.

While FACs are lasing, the active units (players) of the group will receive a message from the FACs every x seconds that it is lasing the target(s) you wanted it to lase...

 

And again, no coding required from your end to coordinate all this...

Edited July 21, 2016 by FlightControl

[FlightControl]

Just published the promised demo video of the DETECTION & TASK DISPATCHER capability.

 

Have a look if you're interested.

 

[ame]https://www.youtube.com/watch?v=-kEDxQs3jHQ[/ame]

 

FC

[Dudikoff]

Looks pretty impressive so far.

 

Couple of things I've noticed:

 

- why are MBT's at threat level 5 (or so)? unless IFV's are counted here, IMHO they should not have such a high threat level being armed with hand controlled 12,7 mm machine guns at most (except some rare exceptions) so basically they're at level of M113's which are at threat level 2 if I remember correctly from the video; IFV's with fast firing higher caliber guns (20-40 mm) and high angles of fire should be much more deadly for low-level flying aircraft

 

- does the limited night detection capability depend on the FAC unit being equipped with e.g. thermal sights? these could be filtered by some fixed list of thermal-sight equipped unit types

 

- in the example video above, I've noticed that Patriot STR and launchers are assigned to a CAS mission? Perhaps I'm mistaken, but I think this should be a DEAD mission linked to the SEAD one, not a CAS as these SAM units are not a threat to friendly ground units

 

- getting updates from the HQ on the course towards the assigned targets and range from them might not be realistic if the HQ doesn't have an up to date update on the plane position (e.g. no friendly EWR coverage or something); perhaps an option could be added to report target offset from the bullseye or some IP waypoint for that flight

Edited July 22, 2016 by Dudikoff

[FlightControl]

This is exactly the kind of feedback i was hoping for! Thank you very much for having watched the video and your inouts!

 

 

 

 

- why are MBT's at threat level 5 (or so)? unless IFV's are counted here, IMHO they should not have such a high threat level being armed with hand controlled 12,7 mm machine guns at most (except some rare exceptions) so basically they're at level of M113's which are at threat level 2 if I remember correctly from the video; IFV's with fast firing higher caliber guns (20-40 mm) and high angles of fire should be much more deadly for low-level flying aircraft

 

 

Ok. I understand and you have a point. I'll put MBTs at level 3 and I'll move the IFVs up a level or two.

 

 

 

 

- does the limited night detection capability depend on the FAC unit being equipped with e.g. thermal sights? these could be filtered by some fixed list of thermal-sight equipped unit types

 

Yes. Basically the detection uses the built in DCS detection capability, but consolidates the results of the FACs and filters it. Further custom filtering options are planned to be added. F.e. If near a forest area, the detection should be almost 0.

 

 

 

 

- in the example video above, I've noticed that Patriot STR and launchers are assigned to a CAS mission? Perhaps I'm mistaken, but I think this should be a DEAD mission linked to the SEAD one, not a CAS as these SAM units are not a threat to friendly ground units

 

Ok. What is a DEAD mission? What are the conditions or rules to be applied? Also, are there more anti radar missions like this?

 

 

 

 

- getting updates from the HQ on the course towards the assigned targets and range from them might not be realistic if the HQ doesn't have an up to date update on the plane position (e.g. no friendly EWR coverage or something); perhaps an option could be added to report target offset from the bullseye or some IP waypoint for that flight

 

Point well received! Will work on that.

 

 

 

A couple of things to note:

 

1. The framework will provide the means to create more processes and tasks like the ones already added. Most of the time, the development to add new tasks or variations on tasks will be fairly easy now, as the framework is doing the work...

 

2. It really comes to a good understanding or creativity on the different patterns or tasks that can be executed.

 

 

 

Thanks for your feedback. Anybody else?

 

Sent from mTalk on Windows 10 mobile

[Dudikoff]

Ok. What is a DEAD mission? What are the conditions or rules to be applied? Also, are there more anti radar missions like this?

 

I'm no expert, but in general, compared to a SEAD (suppression of air defenses) attack which is performed with anti-radiation missiles (so the potential targets are only radars at the SAM site), DEAD means destruction of air defenses, so with the use of bombs (like e.g. cluster bombs would make a good choice) so the primary targets in addition to radars also include launchers and such. Basically, like what you already have in the mission as SEAD and CAS tasks on that Patriot area, but I think if the target area revolves around a SAM site, I think it should be classified as a DEAD strike rather than CAS.

 

I'd expect the DEAD mission to be flown together with a SEAD mission; e.g. one flight element would perform a SEAD mission and suppress any tracking radars with HARMs while another element might move in for the kill.

 

But, in your example the Patriot site is rather undefended from close range attacks, while in reality it would probably have some short range systems for defense so perhaps the threat level could be expanded to indicate such things (i.e. the types of air defense present in the area). In such cases, it might be that a SAM site in that area is too well defended so a DEAD attack (and perhaps a SEAD strike as well) might not be feasible. But, if a friendly CAS, BAI or other tasks are made in the range of these SAMs, perhaps a SEAD escort flight should be generated for these.

 

Also, perhaps the task generation could be made dependent on the specific airplane group types available (e.g. by their assigned mission type).

Edited July 22, 2016 by Dudikoff

[tordillo]

Hi FlightControl, great work, I downloaded the test mission but I couldn´t the lua file. How can I download it?

Thanks

[71st_AH Rob]

I'm no expert, but in general, compared to a SEAD (suppression of air defenses) attack which is performed with anti-radiation missiles (so the potential targets are only radars at the SAM site), DEAD means destruction of air defenses, so with the use of bombs (like e.g. cluster bombs would make a good choice) so the primary targets in addition to radars also include launchers and such. Basically, like what you already have in the mission as SEAD and CAS tasks on that Patriot area, but I think if the target area revolves around a SAM site, I think it should be classified as a DEAD strike rather than CAS.

 

I'd expect the DEAD mission to be flown together with a SEAD mission; e.g. one flight element would perform a SEAD mission and suppress any tracking radars with HARMs while another element might move in for the kill.

 

But, in your example the Patriot site is rather undefended from close range attacks, while in reality it would probably have some short range systems for defense so perhaps the threat level could be expanded to indicate such things (i.e. the types of air defense present in the area). In such cases, it might be that a SAM site in that area is too well defended so a DEAD attack (and perhaps a SEAD strike as well) might not be feasible. But, if a friendly CAS, BAI or other tasks are made in the range of these SAMs, perhaps a SEAD escort flight should be generated for these.

 

Also, perhaps the task generation could be made dependent on the specific airplane group types available (e.g. by their assigned mission type).

 

The difference is not in weapon type but in the expected results. Suppress vs Destroy. It may sound like I'm being Capt Obvious but the differences are nuanced.

 

Briefly:

 

SEAD is not normally the primary mission but a supporting task given to an element in the way an ESCORT task is to achieve a mission.

 

SEAD could be carried out by EW

 

SEAD could have a defined area and time

 

SEAD missions may never drop ordnance and still be successful, the threat keeping AD assets from firing being enough.

 

DEAD must result in the destruction of en capability that was defined in the mission

 

DEAD could be the primary task of a mission.

 

as an example, the Air Component Commander orders the destruction of a bridge in the en rear area because he wishes to cause an effect on the battlefield in support of the Ground Component. The mission is assigned to Unit A would be a type of strike mission against the power plant. The Commander of Unit A will examine the problem and determine that he needs to protect the strike element by assigning an ESCORT task to an element to protect against air to air threats and a SEAD task to protect the STRIKE element from surface to air threats along the route.

 

The en air defenses only will need to be suppressed long enough to get to the target and back.

 

The known air defenses at the power plant could be suppressed or destroyed depending on the desired effect. I would generally expect that in the modern age of IADS DEAD would rarely be used against a sophisticated en. The payoff would rarely be worth the resources required.

 

 

Caveat emptor, I teach at the Army Staff College not the Air Force Staff College but I do have a good grasp of these mission verbs.

[FlightControl]

Hi FlightControl, great work, I downloaded the test mission but I couldn´t the lua file. How can I download it?

Thanks

 

You can find all sources here:

https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Test%20Missions/Moose_Test_DETECTION_DISPATCHER

 

You can embed this code into your mission with the following script:

 

local Scoring = SCORING:New( "Detect Demo" )

local Mission = MISSION:New( "Attack Detect Mission", "High", "Attack Detect Mission Briefing", coalition.side.RED ):AddScoring( Scoring )

local FACSet = SET_GROUP:New():FilterPrefixes( "FAC" ):FilterCoalitions("red"):FilterStart()
local FACDetection = DETECTION_AREAS:New( FACSet, 10000, 3000 )

local AttackGroups = SET_GROUP:New():FilterCoalitions( "red" ):FilterPrefixes( "Attack" ):FilterStart()
local CommandCenter = GROUP:FindByName( "HQ" )
local TaskAssign = DETECTION_DISPATCHER:New( Mission, CommandCenter, AttackGroups, FACDetection )

You should familiarize yourself with the MOOSE framework. Lots of great functions in there and object oriented.

 

Note that the DETECTION_DISPATCHER and DETECTION_AREAS classes are in ALPHA development. Meaning, they still contain bugs, but are now more or less functional.

 

Sven

[FlightControl]

The difference is not in weapon type but in the expected results. Suppress vs Destroy. It may sound like I'm being Capt Obvious but the differences are nuanced.

 

Briefly:

 

SEAD is not normally the primary mission but a supporting task given to an element in the way an ESCORT task is to achieve a mission.

 

SEAD could be carried out by EW

 

SEAD could have a defined area and time

 

SEAD missions may never drop ordnance and still be successful, the threat keeping AD assets from firing being enough.

 

DEAD must result in the destruction of en capability that was defined in the mission

 

DEAD could be the primary task of a mission.

 

as an example, the Air Component Commander orders the destruction of a bridge in the en rear area because he wishes to cause an effect on the battlefield in support of the Ground Component. The mission is assigned to Unit A would be a type of strike mission against the power plant. The Commander of Unit A will examine the problem and determine that he needs to protect the strike element by assigning an ESCORT task to an element to protect against air to air threats and a SEAD task to protect the STRIKE element from surface to air threats along the route.

 

The en air defenses only will need to be suppressed long enough to get to the target and back.

 

The known air defenses at the power plant could be suppressed or destroyed depending on the desired effect. I would generally expect that in the modern age of IADS DEAD would rarely be used against a sophisticated en. The payoff would rarely be worth the resources required.

 

 

Caveat emptor, I teach at the Army Staff College not the Air Force Staff College but I do have a good grasp of these mission verbs.

 

 

 

The challenge that i am having now is ... how to translate that into a DEAD task assignent through "automatic dispatching".

 

So what rules should be followed to detect if a DEAD task needs to be created. And i do mean bits and bytes :-) the logic, black and white.

 

It is a bit hard for me to deduct the right logic from the explanations given.

But, I'll try ...

 

If there are SAMs (long range sams)? in an area with LR SR and TR, then a DEAD task needs to be constructed that will task the elimination of the "other" sam units (not LR SR and TR), like launchers etc?

 

And the SEAD will suport the DEAD task?

 

And... If there are no LR SR and TR or any other MR sam unit in the area, then the task becomes a CAS (or BAI)?

 

Please verbose ...

 

Sven

[Dudikoff]

The challenge that i am having now is ... how to translate that into a DEAD task assignent through "automatic dispatching".

 

So what rules should be followed to detect if a DEAD task needs to be created. And i do mean bits and bytes :-) the logic, black and white.

 

It is a bit hard for me to deduct the right logic from the explanations given.

 

I think that depends on the general objectives and available resources. E.g. you wouldn't attack every detected SAM site on the map at once. If you only have one strike in it's range, it might be cheaper to just generate a SEAD escort for the strike. But, if it's in the way of your strategic objectives (which can be some installations, logistics, ground units, etc.), you'd have many strikes venturing to the area, so if possible, a DEAD strike should be generated. I guess placement of recon units along some axis could represent the strategic objectives in a mission, so targets outside their range would not be detected and thus engaged via tasks generated by this script.

 

So, you might use the number of generated strikes in range of the SAM site as a criteria if there are available resources. The successful DEAD task (or perhaps a SEAD task sent ahead of the strike packages) should also be a precondition for other tasks in the same area then.

Edited July 23, 2016 by Dudikoff

[Dudikoff]

The known air defenses at the power plant could be suppressed or destroyed depending on the desired effect. I would generally expect that in the modern age of IADS DEAD would rarely be used against a sophisticated en. The payoff would rarely be worth the resources required.

 

Thanks for the official clarification.

 

In my poor defense, I have to note that I hinted at the lack of feasibility of the DEAD tasks against a proper SAM site, unlike the one presented in the example mission. My post in general was written from the DCS World perspective where EW platforms are not really available, the SEAD mission types usually need to get their targets or target areas assigned beforehand in general (unless the escort type works well in the game against long range SAM's? given the relatively short ARM missile range, I wouldn't think so) and the radars won't get switched off (unless some clever IADS script is used), hence when I wrote SEAD "attack" mission, I meant planes equipped with anti-radiation missiles in DCSW attacking the STR's (rather than just suppressing as a successful hit is rather likely), though granted it's a poor choice of words and in that case the difference between SEAD and DEAD becomes somewhat moot so perhaps going for a hard kill with proper bombs and including the launchers in the target set (for DEAD) might be the distinguishing mark between them in this script.

 

I was not aware that there would never be a specific non-escort SEAD mission, though?

Edited July 24, 2016 by Dudikoff

[FlightControl]

For those who have tried the DETECTION classes, i've done some severe bug fixes, so loading the new version of moose.lua is recommended to use in your missions. I've tested the bug fixes.

[FlightControl]

Thanks for the official clarification.

 

 

 

In my poor defense, I have to note that I hinted at the lack of feasibility of the DEAD tasks against a proper SAM site, unlike the one presented in the example mission. My post in general was written from the DCS World perspective where EW platforms are not really available, the SEAD mission types usually need to get their targets or target areas assigned beforehand in general (unless the escort type works well here?) and the radars won't get switched off (unless some clever IADS script is used), hence when I wrote SEAD "attack" mission, I meant planes equipped with anti-radiation missiles in DCSW, though granted it's a poor choice of words and in that case the difference between SEAD and DEAD becomes somewhat moot so going for a hard kill with proper bombs and including the launchers in the target set might be the distinguishing mark between them in the game.

 

I was not aware that there would never be a specific non-escort SEAD mission, though?

 

@Dudikoff...

 

My friend, no need for defense. What you initially wrote was a superb explanation.

 

 

 

@Rob. Thanks for the help. Just may i comment on your statements of another person writing in this post to help out. May I ask you what roles should I apply for HQ to dispatch a DEAD attack? I am not looking for realism, but for "near" realism, meaning:

 

- how to decide

 

- how to communicate

 

- are there criteria where missions would be cancelled

 

...

 

 

 

May I also ask, what other attack types would make sense to 'dispatch'?

 

 

 

Fc

 

Sent from mTalk on Windows 10 mobile

[Ramsay]

The challenge that i am having now is ... how to translate that into a DEAD task assignent through "automatic dispatching".

 

So what rules should be followed to detect if a DEAD task needs to be created. And i do mean bits and bytes :-) the logic, black and white.

A DEAD task would be created where the PRIMARY objective is to destroy the enemy air defence target. This could be a large or small system.

 

A SEAD task would be created were there was a AD threat to friendly aircraft operating in the area, the PRIMARY objective is to protect the friendlies (much the same as a CAP).

 

Initially I imagine a 'simple' HQ dispatcher creating

 

• 
  
• DEAD tasks where the Su-25T, etc. is attacking AD targets in a zone, no other friendly aircraft are in the zone and mission success or failure depends on the destruction of the AD asset.
  
• SEAD tasks where there are other missions/tasks in the zone/nearby and AD targets that require destruction/suppression
  

Perhaps later, the HQ dispatcher can build 'packages' for missions were SEAD, ESCORT and STRIKE groups work together (or sequentially) and the mission can be scored for the PRIMARY objective and take losses into account.

[Mechanist]

Please keep in mind all you see is work in progress.

 

Current SEAD task aims only to use of anti radiation missiles to destroy your targets. In the future it will evolve with some more features against IR SAM and AAA-s

 

Threat level also in the proof of concept stage. There are lot of scales you can measure threat of a hostile unit or activity, initially threat to airplanes and helicopter was chosen to be present at the alpha.

As HQ logic will evolve threat level might considered in different ways as well.

[Dudikoff]

Threat level also in the proof of concept stage. There are lot of scales you can measure threat of a hostile unit or activity, initially threat to airplanes and helicopter was chosen to be present at the alpha.

 

Yes, it's readily apparent that the threat level relates to air units, but please consider a combined threat rating based on the presence of medium and short range SAM's in the same area. If the SAM site is well defended, it might make sense to only generate SEAD tasks against the main radar threats (if feasible with long range ARM missiles) or perhaps modify the flight routes of the CAS/BAI tasks to avoid such areas or perhaps even to put such tasks on hold until the main SAM threat is taken out.

[FlightControl]

Yes, it's readily apparent that the threat level relates to air units, but please consider a combined threat rating based on the presence of medium and short range SAM's in the same area. If the SAM site is well defended, it might make sense to only generate SEAD tasks against the main radar threats (if feasible with long range ARM missiles) or perhaps modify the flight routes of the CAS/BAI tasks to avoid such areas or perhaps even to put such tasks on hold until the main SAM threat is taken out.

 

 

 

Makes a lot of sense! Will try to implement that.

 

 

 

Guys, is there any view on the type of G2G tasks we would foresee in the engine?

 

 

 

And A2A?

 

Sent from mTalk on Windows 10 mobile

[Dudikoff]

There is a pretty good script available which used EWR radars and even borders to detect intruders and either direct existing CAP patrols (generated by the script) or launch new interceptors at them.

 

http://forums.eagle.ru/showthread.php?t=120325

 

Something in those lines would be nice to have in this task script.

 

Any chance you'd consider incorporating some parts of that script in your libraries for SP (given the author's permission)? It would be very handy to have functions such as EWR detection events, generating CAP patrols and intercept sorties, etc. for SP missions.

Edited July 25, 2016 by Dudikoff

[FlightControl]

There is a pretty good script available which used EWR radars and even borders to detect intruders and either direct existing CAP patrols (generated by the script) or launch new interceptors at them.

 

 

 

 

 

 

 

http://forums.eagle.ru/showthread.php?t=120325

 

 

 

 

 

 

 

Something in those lines would be nice to have in this task script.

 

 

 

 

 

 

 

Any chance you'd consider incorporating some parts of that script in your libraries for SP (given the author's permission)? It would be very handy to have functions such as EWR detection events, generating CAP patrols and intercept sorties, etc. for SP missions.

 

Ohhh.. This development had crossed my mind since the start of the design of the detection and detection dispatcher classes... I've designed the development as such that implementing an EWR will be a piece of cake (take that with a grain of salt, however) ... Because as you say, A2A is essentially the same process pattern, but without areas, however, what about sectors in the air?

 

Other tasks will come also, like transport, rescue...

 

For G2G, we need more creativity... Thinkin about the flexibility to allocate battle zones (dynamically) that need to be conquered, just like in other popular commercial war game series... In a similar fashion, strike missions could also be developed, although these are more strategical...

 

The open question for everybody to think about is, what 'kind' of G2G tasks exist, and what is the scope of these tasks? Could some of it be included as "task dispatching?"

 

Also, there is a difference in tactical and strategical tasking for targetting I think... Tactical would mean basically no setup and almost no coding. With strategical task setups, configuration will be required, either in the ME, or with extra coding, or both... Strategical means that the task becomes only relevant at a certain time, or event, or combination of events. Tactical can happen any time and is dynamic, based upon prescribed rules.

 

For those reading this post, please have some thought about the above written. There are no stupid answers. Any idea can be a good idea, and we believe in sharing thoughts, so that the developments are shared in the community and are aligned with the expectations.

 

Sent from mTalk on Windows 10 mobile

Edited July 25, 2016 by FlightControl

[FlightControl]

A DEAD task would be created where the PRIMARY objective is to destroy the enemy air defence target. This could be a large or small system.

 

A SEAD task would be created were there was a AD threat to friendly aircraft operating in the area, the PRIMARY objective is to protect the friendlies (much the same as a CAP).

 

Initially I imagine a 'simple' HQ dispatcher creating

 

• 
   
  
• DEAD tasks where the Su-25T, etc. is attacking AD targets in a zone, no other friendly aircraft are in the zone and mission success or failure depends on the destruction of the AD asset.
   
  
• SEAD tasks where there are other missions/tasks in the zone/nearby and AD targets that require destruction/suppression
   
  

 

Perhaps later, the HQ dispatcher can build 'packages' for missions were SEAD, ESCORT and STRIKE groups work together (or sequentially) and the mission can be scored for the PRIMARY objective and take losses into account.

 

Thanks Ramsay... Cool feedback from you side . If you find the energy for it, please have a look at the previous posts in this thread... If we start the complete development, it is important to have a broad view, so that we design it in such a way that things like tssks or detection methods are flexible to be added in future stages. Any views on G2G tasking?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Sent from mTalk on Windows 10 mobile

Edited July 26, 2016 by FlightControl

[StandingCow]

Quick question, will you have the ability to have JTAC call in strike coordinates in MGRS (a 9-line)? I did watch the video but may have missed that part.

 

Really promising! :)