Raf

Attaching miz. The first unit should become active as soon as the second appears (at T+10sec). It's an uncontrolled craft already present, the second one instead is a late activation one. Triggers activate them both and sets an AI task push 'start' on the uncontrolled one. Works OK in 1.2.6, not in 1.2.7 UncontrolledTest.miz

This instruction was working fine for me (groupobj being the group object): groupobj:getController():setCommand({id = "Start", params = {}}) It's in my auto-script stuff. Although not going in 1.2.7... Commands have changed?

Are some of you using an hosting provider for the VPS? Which one if so?

Is it really in a paused state? AFAIK, the triggers are continuously checked. Since it's never empty, there's always a player: the one hosting the game. That's why I'm going to make my missions trigger free, and see if there is a difference. I believe the lua interpreting is sort of a VM inside DCS, or either spawns stuff, and based on my programming experience, that's quite an overhead in long terms. If that's true, that is. But still my intuition tells me there's something there off place. With my flight group, we're experiencing almost constant crashes when we fly missions with 12+ players after a couple of hours. Those are generally trigger intensive, in fact. Generally it's a long term issue (2+ hours of intensive flight/fight), so it's some kind of issue that builds up in time.

Can't edit attachments? so strange, but OK... Test.miz

Yes, that's what I'm waiting to be fixed. It works though, and by the way, as for now at least, we're making the game master create lots of spawns at once to reduce attempts, and then disconnect/reconnect to view the new units. Will attach a sample mission too.

Here is a thing I've worked the last weeks. It's a tool to be loaded at startup, and it requires MIST too, before it. It should save time for triggers and radio items creation on the mission editor. How to load it, I'm attaching a screenshot. As for how to use it, this is how it works. The script scans all the zones/groups searching for particular 'tags', basically identifiers bracketed by double-underscores, and based on the identifier used, does something specific at them. __ACTIVABLE__ : a radio item will be available to activate the group (you still need to check the LATE ACTIVATION on the group) __AIOFF__ : this group will have the AI off at script loaded __SPAWNZONE__ & __SPAWNGROUP__ : one for a zone name, another for the group name. You'll have a radio item to spawn all the spawngroups into the spawnzones, selectable. __RESPAWN__ : automatically respawns the group after a determined period of time. Example: I can create a fighter Ai group, named "__ACTIVABLE__Bandits #001", in LATE ACTIVATION, and i'll have a radio item to activate it, with no triggers to write. By default the script enables the radio items only for the red coalition, since I'm used to put game masters there, but some of the variables can be customized, just as the DEBUG variable in the screenshot. To check which, read the top of the script file. autoscript_v2.0.lua

Same, would come handy to programmatically clean wreckages. Especially since I'm going to respawn them... in the same spot. Wasn't there a time within they were cleaned, anyway?

I'm currently cloning ground units and having the same problem, I'm just waiting it to be fixed, anyway. Didn't find anything else atm.

I'm trying to read waypoints with scripting. So far I've got something good, as in I can get them using MIST functions. Though my main objective was to get not only the mission editor defined ones, but also the ones that a game master is able to set to Combined Arms and ground units. It seems, from the map, that it gets overwritten somehow, even because the unit changes its course, but I still keep getting the same old waypoints. Is that data available somewhere?

Dagli una botta e vedrai che tornano normali. Quando stai volando livellato per troppo tempo tendono ad andare in quella modalità. Dagli una scrollatina di aileron, tieni d'occhio il DSMS e vedrai che tornano verdi.

@Hekktor: I was talking about the TEMP folder, not the pagefile. Putting the temporary files folder on RAM is also a best practice on linux. I suspect that since mouting a RAM disk on windows has never been so easily accessible (need 3rd party software), it never has been a convention.

What were the difference between the two?

Retook my last mission where I had a vehicle stopping that was making a crash. Crash is not there anymore but now the stop condition (did I write it correctly?) is not triggering. Test.miz

There is still a mission editor bug (acknowledged and said it will be fixed in next update) that will make DCS crash, I've posted it. Although it's a rare thing to do in mission editor, involves AI TASK SET and HOLD action. Crashes are there but just for this reason to me, which is already known. @Psyrixx: which was your scripting error?

Thing, is, i have an SSD.

Se ti può essere d'aiuto, io quando avevo cambiato scheda video, DCS andava quasi sempre in schermata blu. Che è anche più grave di quello che fa a te. Ho risolto aggiornando il BIOS della scheda madre, che a quanto pare era necessario per la scheda video nuova, probabilmente era stata prodotta molto dopo la mobo. Occhio che aggiornare il BIOS è un'operazione delicata... si rischia di bruciare l'hardware. Inoltre il BIOS c'è anche nella scheda video, pure quello da aggiornare. Sempre con lo stesso rischio ovviamente.

While I was playing and keeping an eye on a second monitor, it was happening very fast, there had been quite some temp files (5 to 6), named with numbers and a dollar symbol it seemed, then gone just as quickly. I'm not doing the same as you, what i'm ramdisking is not the DCS folder, but the Temp one. The difference here is reading instead of writing stuff. Stutters for *bandwith* in multiplayer of course may still happen. Or perhaps it's even the server that stutters and reflects this to the clients. I've based my tests in the single player mainly, because it was happening even there, and that's why I found it strange at that point.

This mission is crashing on me, as soon as the delayed trigger (10 seconds) tries to stop the vehicle with the AI TASK SET. Anyone has the same problem? Test.miz

No, doesn't raise the FPS. It just avoids DCS to pause in certain moments when it needs to write/read some temporary stuff quickly to disk. This doesn't exclude it to pause it anyway though, don't know how it works lowlevel or if some other cause is summed to this, only developers do.

Is this week update came out? There were still problem with triggers rending missions not working.

This is something that has solved my stutter problems. It works only if you have plenty of RAM to spare. For my case, i have 16GB of RAM and I'm sparing 1GB for this. I've used a RAMDisk software to save my windows temp folder, imdisk in this case, http://www.ltr-data.se/opencode.html/#ImDisk but you can find others here https://en.wikipedia.org/wiki/List_of_RAM_disk_software It seems overall that DCS goes writing quite some temporary stuff there, along temporary track recordings and other files... Here is how I use it: - at startup I create the ramdisk, by putting a .bat file in my startup folder (in windows menu -> all programs) - the batch has inside the instruction to create a physical ramdisk drive of 1GB for drive letter F (you can change these parameters) and format it automatically to ntfs: imdisk -a -t file -m F: -o rw,hd,awe -s 1G -p "/fs:ntfs /q /y" Then, I went in the environment variables of windows, and set all my temp dirs to "F:\" BEWARE to set it to a correct path and remember to revert it back to the original if something doesn't work for you (SAVE IT BEFORE MODIFYING). This is a way of doing it: http://ask-leo.com/how_do_i_change_the_location_of_windows_temporary_files.html Similarly on windows 7, right click computer (on start menu) -> properties -> advanced system settings -> environment variables The variables are both system and user scoped: - TEMP - TMP The content of the RAMDISK will be ALWAYS DELETED at reboot/shutdown!!! For a temp folder, that's fine, but don't put other stuff in there, cause you're not gonna find it anymore! For the record, I'm already using an SSD(Intel X25), so my HD is not poor performant. But still I needed this, so I believe there's something strange happening while DCS is running... I'm curious to see if this can solve the problem for the other people that have it.

Vsync on, full screen. But again, so far, I seem to have solved my issue.

I've tried this yesterday and my stutters stopped so far: I've used a RAM disk software (specifically, imdisk http://www.ltr-data.se/opencode.html/#ImDisk but theres a list https://en.wikipedia.org/wiki/List_of_RAM_disk_software) to create a ram disk (let's say F). Then I've pointed all the TEMP directories of windows (by environment vars) to that disk ("F:\"). Fled for hours yesterdat (even multiplayer) and never had any freeze. Just in the initial cockpit loading but that's normal, i mean no freeze while flying. I also often cycle all the runways with F11, too. So it loads stuff. Seems that DCS makes quite some use of temporary files...

What about tracks recording? Can those be shut off? It's still constant disk access anyway... I'll try with a RAMDisk too sooner or later, loading everything there.