chromium

DAWS weather basic functions merged in DAWS Package ;) https://forums.eagle.ru/showpost.php?p=3576493&postcount=144

Hope it works as expected and also the weather update thing is something quite good. You should extract directly in DAWS Package folder itself... oh god, what a ****ing mess making those stupid zips.

Mod updated with two main new feature that you can choose in the options menù: - Automatic server restart function - DAWS Weather integration: automatic weather update based on current real-time metar (DCS static weather system): at each server restart it will update weather.

trying to check this by an event dead ?

Quel momento in cui l'AMI può dichiarare che l'F-35 è talmente figo che può operare in posti che per gli altri velivoli "non esistono proprio".

Non credo che calcolino molto l'F-18 per la "stable", in quanto è siglato come WIP . Peralto molti da quando F-18 è fuori usano la openbeta e basta... ma è una scelta dell'utente. Al solito, se si vuole usare un prodotto finito e bug-free*, meglio aspettare la release. *Bug free = in cui un bug importante è cmq presente ma puoi cazziare il produttore liberamente perchè non dovrebbe esserci nella release, tipo il Ka-50 :D

O forse, nel caso si tratti di una manovra eseguibile nella stessa maniera dal velivolo reale, provare la fedeltà del modello di volo in circostanze non ordinarie (che sono quelle che generalmente creano più casini a chi programma). Ovviamente è un'ipotesi.

you might want to run a getLife() function: if returns less than 1 then is dead

I tried to ask this with no luck. As far for my test with "ammo" crates, it doesn't provide a warehouse addition.

Well, not exactly solved but... I managed to save the mission with a different name and then load it with a scheduled ontriggermessage event. I don't like this solution but I can't see any other thing that could act before mission loading. The ideal thing would be an API callback that act after the "launch" button (when the mission path is known) but before accessing the file so that it won't be write-protected.

Hello, I need to edit weather table in a mission using DCS API script before server start. But I noticed that the earlier callback is onMissionLoadBegin... which is anyway too late, cause when I try to write down the mission it stop (I can't overwrite a file in use... makes sense). Also I would like to do not change the name of the loaded mission, or this might broke something else in DAWS autorestart function. I'm thinking about a call that every time I launch a mission it stops itself (DCS.stopMission()), so that I can edit, and then restart the mission again (net.load_mission). But then... the callback of onMissionLoadBegin should be "called" again and repeat the action in an infinite loop. Suggestion? is there an API callback that can be used before the mission file is loaded (given that I still need miz file path9?

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

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)

ad una marea di roba che non ci sono cazzi di elencarla sia per il tipo (aggiunti edifici, paesini, strade, alberi, etc) e che giustificano le dimensioni dell'update.

I strongly disagree: you should not force a behaviour to meet your idea by altering the simulator code, while the issue you describe is in the head of the mission builder. Some other might write your opposite: to separate strongly MAC airframes from DCS FF airframes to do not allow "easy players" to be in the same environment as "hardcore simmers". IMHO you should never consider a "restriction" or "forcing" a behaviour when you give instruments to the mission builders: cause them would always try (and often get) to do what they need. Cause as a mission builder I want to be able to allow full fidelity or low fidelity or both, and not be "forced" in any direction. The mission editor it's an instrument: the more freedom you allow to designer, the more you will get from them.

Confirmed negative, no logistic effects by crates.

+1 For who do not use full fidelity DCS and new potential customer that aim to something simplier that "n modules + n sceneries + n complexity levels"... it's a very good thing imho.

Potreste anche immaginare che non sia dedicato a voi (e me), che siamo interessati principalmente a moduli full-fidelity o similare, quanto ad un mercato più leggero e facilmente un ordine di grandezza più numeroso con cui fare vendite. Ad investimento quasi zero, hanno tutto pronto. A me pare un'ottima operazione commerciale. PS: la notizia seria nella newsletter è quella del dedicated server però... abbiamo una data indicativa.

No no, dubito possa esistere per un mezzo WWII un team apposito che nasce e muore su quello. Pensavo più al team che sviluppa moduli WWII e che ha rilasciato lo spitfire per capirci... e soprattutto che in genere tengono lievemente slegate o in capitoli diversi le nuove su WWII e moderno.

In tal caso avevo interamente frainteso il senso del tuo messaggio e mi scuso di conseguenza: avevo erroneamente colto che stessi parlando della ED.

Concordo, e penso tu abbia proprio citato i prossimi due. Ma fino ad annunci ufficiali... PS: il P-47 è WWII, il team di sviluppo non era diverso da quello che segue gli altri moduli?

Minchia raga, se non fanno un modulo subito oddio oddio stanno abbandonando, se lo programmano con anticipo oddio oddio è troppo presto XD. Scherzi a parte anche se hanno sviluppato SDK e quant'altro... hornet ed A10 hanno uno sviluppo di oltre 5 anni cadauno, veramente pensate che possono fare un 16 in un anno? Ce ne vorranno minimo 2 o 3... e ne consegue che i tempi saranno più che maturi. Sul confronto con BMS non mi pronuncio, perchè tanto il confronto è già attivo ora con il 18 e nonostante sia openbeta ed assolutamente incompleto e DCS World non abbia una campagna dinamica, non mi pare gli stia andando malissimo... ma è presto per parlare.

Non è detto, hanno solo dichiarato che l'F-16 è prioritario ad esempio rispetto all'F-4 poichè hanno una forte sensazione (indagine di mercato?) che l'utenza lo gradirebbe maggiormente. Però un conto è l'F-4 che Belsimtek rispetto al consueto aveva annunciato quasi subito, un conto è ad esempio il Mi-24P su cui avevano già una base di lavoro alle spalle. Chissà come procederanno.

Negative, the issue is that DCS can't load the same file in use. Anyway, you might need to: 1. stop the server 2. disconnect 3. reopen it. so I think a completely different piece of code... but I like the Idea, so I will investigate. good point.

No. but that's exactly what I achieved before in a previous, never released I believe, version. As said, it's tricky cause you have to cycle between 2 differente autosave files or, else (and that's what I think I was doing) work like that: - Autosave every n minutes - Copy command in DAWS that create a copy of the autosave file, like DAWS_autosave_toload.miz - function that autoload the mission after "n" hours that will load the "toload" file. I will evaluate if I could add that again in the future. EDIT no negative I was cycling between 2 files cause the point is that you can't overwrite the loaded file. So you need to make a DAWS_autosave_a, then a DAWS_autosave_b, and load each time the different one. Not extremely complicated, only time consuming to create.