Logistic concept for sequential mission

[chromium]

Hi,

 

I'm writing to ask a feedback about a planned update of DAWS. In the next DAWS release (coming hopefully soon) will be added 2 features:

- Server auto-restart every "n" hours updating objects, time, hours and date of the simulation.

- Every restart static weather will be updated with the current METAR of a defined airport.

That set down the minimum loop requisite for a persistent scenery whitout the risk to loose

everything at sistem start.

 

Given that I'm starting to think about logistic and I really would like to interact with warehouses... I know that it's currently not possibile to add or remove POL/ammo from warehouses by script (directly).... and I thought something different: I can edit warehouse table outside the simulation, when saving the file, but I need to keep it simple.

 

Therefore, I could do something like this:

 

1) do not rely on the inbuilt "resource delivery system", but only warehouse storage capability. Logistic item transfer will be set-up as described in the following points.

 

2) set up physical transport by spawning small convoys of POL & ammo that make A/R trips from main warehouse object to local warehouse object... every time a delivery is completed, the delivered ammo/POL is added in the next mission or server restart (let's say 6-8h);

 

3) each time an ammo/POL crate is delivered by helo within 50-100 m to an ammo/fuel storage, the crate is despawned after 1 min and the content is added to the warehouse in the next mission. Crates would be "spawned on request" nearby a warehouse via radio menù if available.

 

4) ground logistic movement will be always following this logic:

- "few" main warehouse (100 km to delivery points) that hold the initial and finite resources of the scenery.

- each airbase/FARP will have linked local warehouse: 1 for ammo and 1 for POL, that feed FARP object every minute.

The DAWS logistic system will provide link by convoys and crates from the main warehouse to the local warehouse.

 

The entire system should not require any mission editing needs from a mission to another BUT the first scenery setup (that will need the inbuilt resource system setup, whitout warehouse dependancies from each other). Obviously if someone WANT to add or remove somthing he should simply have to edit warehouse content in the mission editor before re-launching the server.

 

 

I have a couple of main question, one for everyone and one for mission builder:

 

- Are you willing to fly in a scenery where logistic is a necessary thing to take into account? Cause if someone destroy a warehouse... no more resources available. Let's say that you have 300 AIM-120 in 2 warehouse, one with 50 and one with 250. If someone is successful bombing the 250 warehouse... you will remain with 50 AIM-120 only in the next mission.. and so on. That is a BIG limitation: you might find yourself with available F-15 in an airbase but only a coulple of sparrows... , but also a BIG leap forward for utility helicopters and strategic available targets.

 

- I'm going to handle convoy spawning and request in a simplier way: each FARP/Airbase will have a minimum "initial" setup hardcoded in an editable txt file. When the mission is loaded this initial amount is not met, therefore the local warehouse is "starving", a convoy will be created from the main warehouse to the local one. Do you think this should be robust enought whitout having to code a weapon tracking system? (Too complicate)

Edited July 19, 2018 by chromium

[feefifofum]

Hey Chromium. Very excited to see both the return of real world weather and your work to have deliverable crates by helo.

 

We run extended missions in the 355th (DCS stability permitting) that function very similarly to the manner in which you're describing, only up to this point we've relied on setting up captured airbases with no warehousing and requiring players to ferry aircraft and ordnance to forward fields.

 

We use a finite number of enemy airframes, with a single type at each base and warehousing that draws that type only from other fields in the area, and a respawn function to incorporate a facsimile of realistic attrition of enemy forces. This way any A/C of type that lands at a different field is pulled back to the main base for that type, and once all A/C of that type are destroyed the spawn no longer functions because the warehouse is empty.

 

I can tell you there is absolutely interest on our part for the functionality you're describing, and I'd imagine other groups would enjoy it as well. :thumbup:

[chromium]

Thanks for the feedback.

 

First I will have to complete weather auto-update, release and get bug free feedback about server auto-restart and weather feature. Then, to be honest, the next step is much more about auto-tasking of ground units (including a modified version of a popular script here in the forum), cause at every restart DAWS reset ground units routes (triggers stay there, if placed).

 

So, at that point, we should have a dynamic persisten scenario in place... the subsequential step will be finite logistic implementation.

 

If you like to give some details about what issues you found using your logistic solution it would maybe help me to point in the right direction for the future, trying to overcome or bypass them

[feefifofum]

The main shortcoming was that aircraft types could only be present at one field so that all AC of that type could be drawn from surrounding airbases to the home warehouse...the inability to ferry ordnance by any means other than directly flying it there on a pylon was also a little bothersome but it sounds like that's exactly what you're looking to fix. :)

We encountered no issues with the storage of ordnance or aircraft once ferried.

 

Since we mainly fly Western aircraft we could load captureable fields with millions of missiles to ensure enemy AC never ran out of ordnance but our jets still had to ferry equipment. I'll be happy to PM you one of the ops if you'd like to take a look. The 1.5 stuff got borked by the Caucasus update but I have an NTTR map that's probably still solid. :thumbup: