chromium

You can do that by a very-very-very ugly solution. You need a code to be placed as an "hooks" file that: 1) as soon as the mission is loaded, unzip the .miz file you loaded, read the "mission" file and load it as a table 2) create the new day, month, year and start time value from os time, and replace the values into the loaded mission table 3) save the mission table as a file overwriting the previous one 4) repack everything into a .miz file that has a different name than the one you opened. 5) load this file. I temporarly did that to update current weather but then I left those solution cause it was really extremely ugly and only static weather could be updated from a real single location and then applied to the entire map (ugly itself): DCS do not have a callbacks that allow you to do this thing BEFORE loading the file, so you will see a loaded mission and like instantly after the loading it will load again the new file (if everythings works correctly).

I know why spawning is important, but I prefer ai off / ai on could help a lot keeping low impact on performances. Anyway I prefer a low-units approach but with full fixed orbats (<1000). Don't read it as a "no I don't want" spawning, I only would like to do not track them. I.e., I prefer a dismount script that associate "n" infantry to a vehicle that could freely move embarking and disembarking them as required (See MBot dismount script) only when enemies are nearby, and within certain limits. About events handlers I prefer to use them instead of ricursive checks but I strongly try to reduce calculation overhead at any event... i.e., I might only populate a table or record the very first hit in a group instead of every unit hit to reduce a lot calculations when using area weapons over multiple targets (like the "rockets on infantry" nightmare). Most of those choices depends on the objective you need to achieve: for my current one it's better my approach. Instead, if I would like to run intensive server with a lot of AI life going on, I might prefer a spawn/despawn approach to keed mess as light as possibile.

@About persistance the main issue is to decide how to get out things from the mission scripting environment. With DAWS and a lot of other solutions you need to workaround the sanitization module in missionscripting.lua. While it's easy to automatize this step (SLmod did it in 2011...) it's also like an hack. After many "feasibility studies" involving also current DCS performance I beliebe that the proper way should be this: - use as less as possible spawning to simplify tracking and persistence of the units; - track as much as possible with non-overheading event handler functions (nothing that works at any frame or similar); - exporting everything at mission end (or host disconnection), not before. - do most of the maths and processes ouside the mission environment (using hooks file). But, you know, It's me that don't like exotic solutions like external software... others did that with success I believe :) @About DAWS: main reasons was to lack of time with constant updates and the need to implement compatibility with Normandy and WWII units, while ensuring compatibility with at least CTLD... cause about MOOSE there was that strange issue related with MIST. And salso ometimes bugs due to the fact that many people have issue with "RTFM" :D (some do not remove write protections, some load mist anyway, etc etc).

given this: local strAirbases = Integratedserialize("tblAirbases", tblAirbases) local completeStringstrAirbases = "tr_tblAirbases:" .. tostring(strAirbases) trigger.action.outText(completeStringstrAirbases, 1) local strDeadUnits = Integratedserialize("tblDeadUnits", tblDeadUnits) local completeStringstrDeadUnits = "tr_tblDeadUnits:" .. tostring(strDeadUnits) trigger.action.outText(completeStringstrDeadUnits, 1) local strDeadScenObj = Integratedserialize("tblDeadScenObj", tblDeadScenObj) local completeStringstrDeadScenObj = "tr_tblDeadScenObj:" .. tostring(strDeadScenObj) trigger.action.outText(completeStringstrDeadScenObj, 1) local strUnitsUpdate = Integratedserialize("tblUnitsUpdate", tblUnitsUpdate) local completeStringstrUnitsUpdate = "tr_tblUnitsUpdate:" .. tostring(strUnitsUpdate) trigger.action.outText(completeStringstrUnitsUpdate, 1) trigger.action.outText("controltext", 1) If I launch this all into a function, only the "controltext" is printed out in the mission. Not the others... but I checked that tables are there.... I can't understand why it's not working.

search for net.dostring_in function, usable via hooks code (better than the export environment). but it seems that you can't get out data from the mission scripting environment using that solution... for now. PS dato che sei di milano se mi scrivi poi via pm ci parliamo in lingua. nel caso, sappi che non sono un programmatore... solo un pazzo patito di mission editing da 8 anni che ha imparato qualcosa di lua: 90% ne sai più di me se sei dell'ambiente.

only way is to modify missionscripting.lua to allow io and lfs to work into the mission scripting environment (make a search). Then you can do almost everything.... but I didn't want to alter DCS core file. If you need examples, look at DAWS free code here: https://forums.eagle.ru/showpost.php?p=3662544&postcount=195

Didn't work but i found a very ugly but viable solution printing the table serialized into a trigger message, and then reading and loading it via 'ontriggermessage' callback. That might be possibile for me only cause i need this export at mission end only. Inviato dal mio SM-G920F utilizzando Tapatalk

The value should be only one, a string of text of the serialized table. What happens now is that it returns always "" if the function is called ok, or worse error. I'm trying to think something different but at the moment no luck. I'll try your solution anyway. :) thanks!

always check if you have write permission in the main DCS folder. That option was activated by default.

Hi, since seems impossible to get out data from the mission scripting environment, I'm looking for a way to track dead events (S_EVENT_DEAD in the SSE) from the hooks environment... is there a way? Seems that onGameEvent "kill" tracks only players actions and not ai to ai things. PS: else, if you know how to retrieve entire table from mse to hooks environment, I'm asking help here: https://forums.eagle.ru/showthread.php?t=223747

Hi, I'm trying to export a serialized-to-string table from the mission scripting environment to the "hooks" scripting environment using this function, called in the hooks file: function get_tblDeadUnits() local tdu, tdu_err = net.dostring_in("mission", [[a_do_script("tblString = tblSerialized")]]) if tdu_err then return tdu else return "errore" end end local tString = get_tblDeadUnits() the tblSerialized table exist correctly in the mission scritping env, but it's readed "" (not nil) in when the function work in the hooks environment. Any suggestion?

il link è un messaggio di 3 gg fa, e questo update per la stable non è altro che l'implementazione del precedente update sulla opebeta. https://forums.eagle.ru/showpost.php?p=3671393&postcount=82

I'm starting now tring to do the same thing, but I didn't even connect the socket... could you explain how did you connect DCS via luasocket?

uhmmm thanks, I'll check. But please, when and if you get to your PC consider sending something here if I don't already answer with a "Hey solution found" ;) I can't look now, I will this evening likely

do you have a socket example that might been read into the mission environment whitout having to modify missionscripting.lua? writing and reading a file is my current solution, but i'm looking for a way that won't interfere with the current sanitization thing.

+1, osservazione corretta.

Evidentemente... ma certo non è responsabilità ED se altri fanno campagne per altri velivoli, no?

Ragazzi... ma avete almeno letto che non è un prodotto ED ma di una terza parte? Secondo voi, onestamente, vi pare che se una terza parte propone un prodotto valido la ED gli dice "no guarda, prima devo trovare qualcuno che fa una campagna per i velivoli dell'asse, poi diventa di nuovo il tuo degli alleati"? La ED ha i suoi prodotti e le sue campagne (su cui eventualmetne ha senso rompere i cojoni) ma dovreste intendere che le terze parti non lavorano su commissione della ED. Sono le terze parti a proporre un prodotto, che se la ED ritiene interessante, valuta ed eventualmente approva. Mo quindi perchè degli appassionati decidono di produrre delle campagne per un modulo (magari perchè gli piace, vedi Gregkaz e i greci con la campagna Argo dello Huey), la ED avrebbe l'onere di svilupparne altre per gli altri moduli che se no restano indietro? Se ci fate caso vi risentite per le mancanze in ambito WWII come se il tutto fosse prodotto da una sola casa, indipendente, che controlla e gestisce lo sviluppo, come invece accade in BOS. Fateci caso: tutte le campagne dello spitfire che vedete oltre quella base non sono della ED.

Is it possible? I'm looking for a way to pass the loaded mission path as a text variable (got by DCS.getMissionFilename() ) to a script that is running into the mission (loaded by "do script file"). thanks

again... is it possibile? I might need some of them in a script, and I would like to know if it's possibile to overcome this whitout using external software or modifing that specific file. by hooks script, where they are free, is possibile something?

Posso comprendere la disattenzione nello scritto, o che magari scrivi da cellulare, o che magari un te frega nà mazza di come viene letto il tuo messaggio. Ci sta. Io provo a leggerli come sono scritti e mi tocca sempre tirar fuori il ventolin, ma li leggo. Però questo no. sinfredi, no. è cultura di base. ma base base, cazzo! (e mai esclamazione fu più contestuale).

è un onore :v:

ammetto che ne sai parecchio evidentemente, ma volevo comunque segnalarti un corso che potrebbe interessarti a questo link.

raga io ho capito che, viste le lamentele sui problemi con lo scorso update, hanno fixato in modo da non dover rifare tutto. Il che implica per forza toccare nuovamente gli stessi file... ovvero se voi avete rifatto tutto per lo scorso update, ci sta che dovete rifare ancora. Se avete da parte le "vecchie" config (quelle usate fino al penultimo update), magari vanno.

O forse è un problema rilevante, ma che non possono correggere ora come ora (magari per implicazioni su altro codice) io suggerirei di fare un report nella sezione bug, provvisto di track e quant'altro, e vedere se lo aggiungono.