Pizzicato

Ugh. i inadvertently got my explanations of Do Script and Do Script File the wrong way around. I was writing on my phone just before bed, and my first thought when I woke up this morning was "Oh crap... I think mixed up the explanations." Sorry for any confusion. I've fixed my note now.

Do Script (using dofile to load your script) reads the Lua script from your HD every time you run the mission. This means that every time you tweak the script and save it, it's automatically updated in the mission. This is perfect while you're writing, testing, and iterating your scripts. The downside, though, is the mission won't work for anyone else because it'll be looking for a Lua file that only exists on your HD. Do Script File is the exact opposite. It embeds the script into the mission, but it doesn't update it unless you reimport it. This makes it perfect for sharing, but horrendous for testing and iterating your work. The takeaway is use Do Script while you're writing and testing your mission, then switch to Do Script File when you're ready to share.

All of your assumptions are correct (with the caveat that trigger zone checks are actually really.cheap, and therefore have minimal performance impact anyway). If you wanted to control the trigger zone checks in the ME, you could just use a flag start/stop the checks. Setting the trigger type to Once would ensure that it's only checked until it becomes true and then stops checking. You can also use Time Since Flag conditions to control how often the check runs (e.g. Every 5/10/30/whatever seconds). If you're scripting, you can get more clever and use finite state machines to control when the checking process stops/starts, and coroutines to control how many zones are checked per frame.

What are you trying to do with Bomb in Zone? It's just a Condition, so it just checks every second (if the Trigger is set to Repetitive) to see if there's a bomb of a specific type falling within the zone. If there is a bomb of that type falling within the zone at that moment, the Trigger check is true and whatever Actions you've defined will occur. The issue with Bomb in Zone is that it only detects bombs in flight - not bomb impacts. The issue with that is that you could create a zone that encompasses a runway and set a Bomb in Zone condition with the intent that it'll trigger when the runway is hit by a bomb. What'll actually happen, though, is that the condition will Trigger as true the moment a bomb of the defined type is within the zone - even if it's at 20,000ft and ultimately explodes a mile outside of the zone you defined. Does that help?

Just flew a dusk mission into Iran out of Al Minhad in VR. The return leg as the light was fading and the various towns, cities, highways, airbases and airports lit up was absolutely outstanding. Easily the most immersive, impressive, and convincing night flying I've ever done in a sim. Now we just need Vulcan, multicore, dynamic campaign, proper ATC, and improved AI and we're away to the races. Incredible work on the nighttime lighting, though.

I've had three sets of lenses from VR Optician (most recently this week, by strange coincidence). Really excellent in all regards. Highly recommended.

Ah, OK. Good to know.

Not 100% sure, but this toggle might give you what you want. Selecting it will limit the available units to those that are historically correct for whatever date you've set for your mission. I don't know if that applies to weapons, too, so you'd have to have a poke around. null

On a related note, an Su-27 will happily spot and engage an F-15E at 166nm.

Yep, I know. Like most sane people, I typically delete the CAP task as the first step of any A2A group's setup. This was more just about a raw exploration of what;s going on under the hood and how the AI behaves in its default state.

I've spent the afternoon running tests on how various factors affect the AI's behaviour (skill level, altitude, target type, target size, etc.). It turns out that the Hornet still detects and begins to engage large targets such as the IL-76 from 370 nm away. Given that the AI should be subject to the same constraints (i.e. a radar screen that only displays out to 160 nm), that's pretty problematic and immersion-breaking level of advantage over the player. It's also problematic from an AI fuel conservation standpoint, as the Hornet immediately goes to full afterburner in pursuit of its very distant prey. Mission and screenshot attached. (The screen shot shows the moment at which the Hornet detects and starts to maneuver towards the IL-76. Test CAP 01.miz

In the interests of adding a little variation and replay value to each mission, it would be good to add the ability to randomise weather and time of day within set constraints, e.g. Set a time window for the mission, e.g. the mission can start anywhere between 1200 and 1800 hours. Set a range of valid cloud presets for the mission, e.g. just the Light Scattered and Broken presets. Set a range of min/max wind values. Set a range of min/max wind directions. All of these additions would instantly add to the unpredictability and replayability of any given mission.

Simple persistence would be massively valuable for both single (repeatable) missions and campaigns. Just tracking dead groups/units and removing them (or spawning them as burning or burnt out husks) at mission start would be huge: It would provide a sense that the player's actions (beyond the canned objectives) have meaning and value. It would add significant replay value to any given campaign. It would allow single missions to serve as simple, self-contained campaigns. It would increase the sense of immersion by significantly reducing the "canned" feel of the missions and campaigns. It would provide a safer alternative to "dirty hacks" to the MissionScripting.lua to allow OS, I/O, and LFS functionality. This one addition would instantly unshackle mission creators, and provide a massive value-add to the player experience.

Thanks! I'll do that.

Hey guys, I just got a Reverb G2 a few days ago, and encountered a very noobish issue tonight that my Google-fu is failing me on. Basically, I paused DCS, walked away for a few minutes, and then - when I came back - my headset had gone to sleep. I was able to wake it up via the prompt in the Mixed Reality Portal app, but then I couldn't figure out how to actually get back into the sim. I could see it running/reprojected on my desktop, but I couldn't get out of my VR home and back into the game within the G2. What really stupidly obvious thing am I missing?

FFS. This is ridiculous (and deeply infuriating).

Probably redundant at this point, but I figured I'd just to the voices noting the VR issues. I've been running a super-simple mission all week (just the Caucasus with one wingman) while I learn the Apache and setup Voiceattack. It was running beautifully in VR (i7-7700k, RTX 3090, Rift S) until the update, but it's now a laggy, stuttering, micro-pause-filled, headache-inducing mess. Not fun.

Bit late to the party, but this is AWESOME news! Really hope this makes it into the upcoming 2.8 patch.

Have you checked your controller assignments to make sure that rudder isn't taking multiple inputs? (By default, my collective was also controlling my rudders - collective goes up, heli goes 'round)

Necroing an 11 year old thread. Outstanding!

Looks absolutely outstanding. Can't wait to relive my old EF2000 nostalgia. If only we had a Norwegian fjords map...

Great catch, Schilling. That's great news!

I didn't know about that, either. Great info. Thanks Rokkett.

The dev team is Russian. They don't break for Christmas until January.

Great to know. Thanks for the info, Flappie.