Perform Task > Land, "on land" option

[Bearfoot]

I could not find info on this in the DCS manual.

 

In the "Advanced Waypoint Action", "Perform Task", "Land" option, there is an "On Land" checkbox with what looks like a date/time option: 0:5:0/0

 

(a) Am I right in thinking this is the length of time that the aircraft stays on land for?

 

(b) What does the number to the right of the slash mean? I am guessing that I would read the above as 5 minutes? How would I specify, 30 seconds? "0:0:30/0"?

[Grimes]

Yes it is the duration it lands for. I think it might start counting from when the task starts and not when the aircraft actually touches down. Simple experimentation should tell you which it is though. The number to the right of the slash is days. Note it is the same UI element that defines start time and pretty much any other time measured entry in the editor.

[Bearfoot]

Yes it is the duration it lands for.

 

Thanks!

 

I think it might start counting from when the task starts and not when the aircraft actually touches down.

 

Ah, this might explain some weirdness with my experiments that led to the question! Thanks!

[Bearfoot]

Another weirdness.

 

It seems from experiments that if a single element in a group does not complete the task (e.g., if one aircraft from a 2-ship group is shot down), then the remaining elements of the group never continue on to the next task (e.g., the remaining aircraft of the 2-ship group will never take off).

 

Really annoying! Only work-around I can think of is not to have any multi-unit groups ...

[Grimes]

That is likely a bug. I'll have to test it out.

[FlightControl]

Another weirdness.

 

It seems from experiments that if a single element in a group does not complete the task (e.g., if one aircraft from a 2-ship group is shot down), then the remaining elements of the group never continue on to the next task (e.g., the remaining aircraft of the 2-ship group will never take off).

 

Really annoying! Only work-around I can think of is not to have any multi-unit groups ...

 

 

 

Hi Bearfoot & Grimes,

 

 

 

I use the onland option extensively in my gori valley mission. Helicopters transport troops. When these helicopters land, they will spawn the troops and continue their flight. It was time consuming to get this working but I finally did. I specify also the duration how long the helicopter needs to be on land (f.e. One minute). The landing task needs to be separate from the sequent tasks (spawning), otherwise the groups get spawned before the helicopter lands. When one unit gets destroyed during the landing action (helicopter), and there are two helicopters landing or onland in the same group, the landing task completes normally for the remaining unit. However in the second spawn task I may only spawn troops from the remaining helicopter, which I am testing. Seems to work well, this scenario.

[Bearfoot]

Hi Bearfoot & Grimes,

 

 

 

I use the onland option extensively in my gori valley mission. Helicopters transport troops. When these helicopters land, they will spawn the troops and continue their flight. It was time consuming to get this working but I finally did. I specify also the duration how long the helicopter needs to be on land (f.e. One minute). The landing task needs to be separate from the sequent tasks (spawning), otherwise the groups get spawned before the helicopter lands. When one unit gets destroyed during the landing action (helicopter), and there are two helicopters landing or onland in the same group, the landing task completes normally for the remaining unit. However in the second spawn task I may only spawn troops from the remaining helicopter, which I am testing. Seems to work well, this scenario.

 

I could be wrong about an incomplete group resulting in non-takeoff ... that was just my best inference.

 

In your situation, the landing was an advanced waypoint action or a scripted one?

 

Also you say that the unit was destroyed on landing. In the situation I have, the unit was destroyed before getting to the landing point. Don't know if that makes a difference or not. Will check again.

[FlightControl]

A scripted one... Would it help if we look into a demo?

[Bearfoot]

Ok, I cannot seem to RELIABLY replicate the problem! Last several runs, as I was trying to generate track ... worked fine! Typical. But it definitely occurred with the same, unchanged mission.

 

Another thing I should note is that, in all these test runs, I have time speeded up to its maximum. Wonder if this has something to do with it?

[FlightControl]

Time speeding should not have an impact.

 

So, happy you got that problem fixed. I also suggest you have a closer look at my moose framework. My Gori Valley mission is my test case where i combine all the MOOSE classes into one mission.

 

When you download the mission, have a look how i developed the landing and deployment logic in the gori valley.lua file...

 

Nothing is embedded and hidden anymore in the miz file. Everything is scripted and in ONE file...

 

The GROUP class encapsulates all the different structures for the Tasks... It also encapsulates the controller etc. In other words, with some nice function calls you can command groups with a bunch of tasks and let them execute with :PushTask( Task ) ...

 

have a look close look from line 109 till 205 (this models the landing and deployment of the MI26 helicopters loading and deploying troops within the battle zone):

 

https://github.com/FlightControl-Master/DCS-World-Missions/blob/master/Free%20Georgia%20-%20Gori%20Valley/Gori%20Valley.lua

 

greetz,

FC

 

 

 

 

for your reference:

[Bearfoot]

Time speeding should not have an impact.

 

So, happy you got that problem fixed. I also suggest you have a closer look at my moose framework. My Gori Valley mission is my test case where i combine all the MOOSE classes into one mission.

 

When you download the mission, have a look how i developed the landing and deployment logic in the gori valley.lua file...

 

Nothing is embedded and hidden anymore in the miz file. Everything is scripted and in ONE file...

 

The GROUP class encapsulates all the different structures for the Tasks... It also encapsulates the controller etc. In other words, with some nice function calls you can command groups with a bunch of tasks and let them execute with :PushTask( Task ) ...

 

have a look close look from line 109 till 205 (this models the landing and deployment of the MI26 helicopters loading and deploying troops within the battle zone):

 

https://github.com/FlightControl-Master/DCS-World-Missions/blob/master/Free%20Georgia%20-%20Gori%20Valley/Gori%20Valley.lua

 

greetz,

FC

 

 

 

 

for your reference:

 

I am definitely very, very, very, very, interested in learning to use MOOSE! I just posted a "recipe" on how to build an air assault mission using MIST and CTLD here:

 

http://forums.eagle.ru/showthread.php?p=2758768

 

As I noted, I think the mission can be greatly enhanced with MOOSE in a number of ways (but perhaps most prominently in the control, command, and co-ordination of the various flights), or might even be nice to reimplement from scratch using MOOSE. However, it is going to take me some time to learn to use MOOSE, especially for the latter (i.e., a full air assault mission). I know you already probably have examples of such missions or more complex ones, but there is a large distance between an example and a "talk-through" recipe that goes through all the steps, and, as I also noted, a recipe-based approach is the one of the best ways to get a particular software or technology adapted because it is one of the best ways not only to showcase what something can do, but, from the user perspective, one of the best ways to learn how to do it! If you have the time to write up some simple recipes in MOOSE that would be great! Maybe show how you built up the Gori Valley mission step-by-step. I, for one, and I am sure many others would greatly appreciate it! Otherwise, when I eventually figure out how to use MOOSE to do a simple air assault along the lines of what I describe in the above thread, I will post a recipe on that thread. Unless, as I say, you beat me to it ... (hint, hint :) )

[FlightControl]

What i suggest you do:

 

First have a look at the following videos:

https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg

 

First look at 'development', then i suggest you have a look at spawning and the escort class. The videos for the other classes are to be finished soon.

 

I need to make other videos during the weeks to come, maybe i'll follow your suggestion and do a walk of the Gori Valley mission and explain how it was made (with many many many iterations over time )...

 

Send me your email so i can invite you to the moose slack.com channel. You can send the email as a PM.

 

Sv.

[Bearfoot]

What i suggest you do:

 

First have a look at the following videos:

https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg

 

First look at 'development', then i suggest you have a look at spawning and the escort class. The videos for the other classes are to be finished soon.

 

I need to make other videos during the weeks to come, maybe i'll follow your suggestion and do a walk of the Gori Valley mission and explain how it was made (with many many many iterations over time )...

 

Send me your email so i can invite you to the moose slack.com channel. You can send the email as a PM.

 

Sv.

 

Sounds good!

[FlightControl]

As I noted, I think the mission can be greatly enhanced with MOOSE in a number of ways (but perhaps most prominently in the control, command, and co-ordination of the various flights), or might even be nice to reimplement from scratch using MOOSE. However, it is going to take me some time to learn to use MOOSE, especially for the latter (i.e., a full air assault mission). I know you already probably have examples of such missions or more complex ones, but there is a large distance between an example and a "talk-through" recipe that goes through all the steps, and, as I also noted, a recipe-based approach is the one of the best ways to get a particular software or technology adapted because it is one of the best ways not only to showcase what something can do, but, from the user perspective, one of the best ways to learn how to do it! If you have the time to write up some simple recipes in MOOSE that would be great! Maybe show how you built up the Gori Valley mission step-by-step. I, for one, and I am sure many others would greatly appreciate it! Otherwise, when I eventually figure out how to use MOOSE to do a simple air assault along the lines of what I describe in the above thread, I will post a recipe on that thread. Unless, as I say, you beat me to it ... (hint, hint :) )

 

Hi Bearfoot,

 

The MOOSE framework isn't finished. The goal is to create OO classes, that can be used to orchestrate missions. Right now, the only real useful classes that are made are SPAWN, ESCORT and SEAD, PICKUPTASK and DEPLOYTASK classes, together with early versions to do some MEDIVAC or TROOP transport type of missions.

 

It is required to make much more classes in MOOSE. If you think about it from a design perspective, the goal is to create ATOMIC classes, so that mission designers can use these classes to combine these objects to create missions. Unfortunately, to design such classes, hard work is required...

 

Other classes in my mind to create are:

- EWR (detection of enemy units through radar unit groups). Once units are detected, triggers would be launched that can trigger functions used by other objects..

- GROUND INTERCEPT

- MEDIVAC (an extension to the already made PICKUP and DEPLOY tasks available).

- SAM defense systems and SAM control.

- DYNAMIC BORDERS

 

So you see, a lot to be made still. There is no magic hat that will create these classes, they are required to be made with creativity and sharing ideas and collaboration, and ... lua development ...

 

If you want, you can join the GITHUB MOOSe site so that we can further discuss there...

 

Right now, i am creating some further building block classes to embed within the future MOOSE classes. Currently in progress is a new DATABASE class, that is tracking alive units and dead units based on defined filter parameters ...

 

Next is the development of a SCHEDULER class, which will shoot triggers upon a timer event ...

 

kind regards,

Sven

[Bearfoot]

Hi Bearfoot,

 

The MOOSE framework isn't finished. The goal is to create OO classes, that can be used to orchestrate missions. Right now, the only real useful classes that are made are SPAWN, ESCORT and SEAD, PICKUPTASK and DEPLOYTASK classes, together with early versions to do some MEDIVAC or TROOP transport type of missions.

 

It is required to make much more classes in MOOSE. If you think about it from a design perspective, the goal is to create ATOMIC classes, so that mission designers can use these classes to combine these objects to create missions. Unfortunately, to design such classes, hard work is required...

 

Other classes in my mind to create are:

- EWR (detection of enemy units through radar unit groups). Once units are detected, triggers would be launched that can trigger functions used by other objects..

- GROUND INTERCEPT

- MEDIVAC (an extension to the already made PICKUP and DEPLOY tasks available).

- SAM defense systems and SAM control.

- DYNAMIC BORDERS

 

So you see, a lot to be made still. There is no magic hat that will create these classes, they are required to be made with creativity and sharing ideas and collaboration, and ... lua development ...

 

If you want, you can join the GITHUB MOOSe site so that we can further discuss there...

 

Right now, i am creating some further building block classes to embed within the future MOOSE classes. Currently in progress is a new DATABASE class, that is tracking alive units and dead units based on defined filter parameters ...

 

Next is the development of a SCHEDULER class, which will shoot triggers upon a timer event ...

 

kind regards,

Sven

 

I've gone through the various tutorials etc., and really like the potential of what I see!

 

I've got some ideas for a range of interesting missions (to be put together in a campaign) that can use a lot of the functionality present (in some unique/different ways) as well as well might require some new ones, which I would be happy to help/contribute in developing.

 

Will set up a dedicated GitHub developer account (to keep things separate from work!), join your group, and PM you details so you can add me to Slack?

[FlightControl]

Great man. Send me your email address in a private message. I'll send you an invite to join slack. We have time. Dcs world 2.5 will only be released in 2 years. (just kidding)...