All Activity

Heyo, please download the attached .miz file with the fix You used the "condition" field witch is a LUA statement and the number "30" is not valid LUA lol nothing todo with the previously attached "GPS_GNSS.lua" enjoy Syria Operation Lizard Phase #1 .miz

Nice job almost destroying that server. Will you be on alert 5 on Monday at 7 AM just to be on the safe side if the phone rings? The timing with this thread is impeccable. Got a story to share as well. So I run a few Linux servers, and I have a hand written script that anonymizes IP addresses from their log files so I don't get in trouble with the GDPR. It's hooked into the logrotate daemon as a prerotate script. Super simple thing. I'd noticed a while ago that one of the servers takes unusually long to process the log files and is under heavy load every night. Well, the websites shouldn't have that much more traffic than those on other servers, but it's probably some AI scraper crap that's filling them up again and again day by day, forcing the server to go through countless lines of logs to scan for IPv4 addresses and replace the last 2 octets with zeros before the backup runs. Not ideal, maybe I should optimize the script. Maybe tomorrow. You know, the "that was 6 months ago" kind of tomorrow. Last week I found a smart article about optimizing backups and creating transparent snapshots using Linux filesystem hardlinks. Cool, I'm going to implement that. Start with this server first, it's got the least valuable data, just on the off chance I might mess something up. Nah, worked okay, except... the daily snapshot on the backup server was about the same size as the previous one. They should appear to have the same size, but the copy should really be tiny. But the file system was filling up big time, something apparently wasn't properly hard linked and instead copied. I checked a few random files, couldn't see anything wrong. Same file, same content, same inode number, proper hard linked. One thing I noticed while looking at this snapshot snafu was the server took 2:30 hours to get backed up. Similar servers took 2 minutes. That's... odd. Same OS, same software, same version of rsync, same custom backup script. Why on earth does the server insist on copying 400 GB of data every night when there's hardly any changes in the file system...? Ran a few more du -h to figure out where the largest amounts of data were hanging around. Err... the web host log file directories? Gigabytes over gigabytes of log data? That can't be right, there's no way I get so much traffic that the logs are this big day in and day out. Well. Turns out I had two custom config files for the logrotate daemon here. One from another server, and the one adapted for this server. I had forgotten to delete the old one after adapting. Wasn't a big deal until almost exactly one year ago when I changed the location of my IP address anonymizer script. Put the proper location into the logrotate prerotate hook - but only in the "correct" config file. I hadn't noticed that extraneous config file. That one still had the old path to the prerotate script, this path no longer existed, but by virtue of alphabetical sorting, the old and now wrong logrotate script was run before the correct one. For almost 365 days, the logrotate daemon failed to rotate any of my webserver logs on this server, dutifully logged the failure to syslog every night where I never bothered to check, and so I have amassed numerous gigabytes of access_logs, dwarfed in one particular case by an error_log that has grown to 352 gigabytes on this server. Since the logs get a few new lines every day, they need to be unlinked and transferred in the backup process, blowing snapshots completely out of proportion, and the oldest entries have had their logged IP addresses dutifully anonymized almost 365 times. And all it takes to fix was to delete one extraneous config file. As I write this, the IP address anonymizer should go through its gargantuan task one last time before the log rotation - hopefully - compresses the log files, rotates them, and now I can't wait to see my daily snapshots rotate those old logs into oblivion. You can probably tell I should also invest some time and effort into a more robust monitoring solution. On the plus side it seems I didn't need to dig into this server's Apache logs in at least a year, or else I might have noticed they're a little bigger than they need to be.

Is this "USS Forrestal #3 Cat Bug" issue (poster above), something that Heatblur will pick up and solve? And, if so, will there be notification, as the carrier is in mothballs until it is resolved. Great product otherwise. Please advise. @IronMike Bowie

CoreMods\aircraft\AircraftWeaponsPack GR66IZ (No implemented, Beluga Submunitions) GR66EG (No implemented, Beluga Submunitios) CoreMods\aircraft\chinaassetpack\shapes\vehicles GD-Load-PL5 (No implemented, GD-20 Lift Truck cargo, Missing vehicle cargo funtionality?) GD-Load-PL8 (No implemented, GD-20 Lift Truck cargo, Missing vehicle cargo funtionality?) GD-Load-SD10 (No implemented, GD-20 Lift Truck cargo, Missing vehicle cargo funtionality?) ZTZ59 (Type 59 tank, No implemented) CoreMods\aircraft\chinaassetpack\shapes\Weapons

I took from another's strike fire in the downloads section, now I can't find the file, then I ran across your script here. I will post to here, I believe this enhances yours! Strike Fire V1.1 – Mission-side utility script for DCS that lets you call precision launcher strikes via map marks ([FIRE] / [CLEAN]), with smart target selection, budgets, cooldowns, and no client mods required. Strike Fire V1.1 is a mission script that lets you call in launcher strikes by dropping a map mark like [FIRE]. It automatically finds valid enemy targets near the mark, picks the best available launchers (HIMARS, ATACMS, Iskander), and assigns them to fire one missile each. New in V1.1: Prevents rapid double-triggering (flood lock). Tracks per-unit cooldowns and ammo budgets (persist through mission). Smarter target choice (SAMs/artillery/armor first, no shooting too close to friendlies, no crazy mountain shots). Marker overrides (e.g. [FIRE R=800 B=10 FAMILY=GMLRS]). Safer ROE handling (won’t break AI settings). Expanded compatibility (vanilla + mod launchers). [CLEAN] resets all state and clears spawned units. Practical use in-mission [FIRE] → Default strike package around the mark. [FIRE R=500] → Shrinks search radius to 500m. [FIRE B=12] → Allows up to 12 shots per launcher family, per unit. [FIRE FAMILY=GMLRS] → Only task HIMARS with GMLRS. [CLEAN] → Clears all internal state and spawned groups Strike Fire V1.1.lua

I feel like we're missing modern medium utility/cargo helicopters. Troop transport, CSAR, SAR, Maritime patrol, and even more civilian type operations like HEMS, Police work, Firefighting (?). The Huey and Hip fill the role, but are better suited for an early cold war/vietnam era. The UH-60 mod currently fills this niche a bit, but given the large variety of helis in use today, why are we limited to these 3? Would anyone else be intrested in some modern versatile multirole helis? I'm thinking something like: EC-135/145 AW-139 AW-109 AS365 H225 NH-90 Modern Hueys I know many of these have civilian variants with extensive documentation available, while others are obviously more classified (NH-90 my beloved), but I feel like we're missing on a lot of really interesting operations right now.

Ship Disposition/Formation Save for Way-points: Like the preloaded Aircraft formations, but modifiable/saveable for ships. A mission Carrier Strike Group will typically operate on a 1+15 Cycle (75 min.), and consist of the following disposition: 1 - Carrier (center/guide) 1 - CG (300°R at 3,000 yds) 1 - Plane Guard DDG (171°R at 4,000 yds) 1 - Lead Destroyer DDG (010°R at 14,000 yds) 1 - Picket Destroyer DDG (090/270°R to Threat Axis at 30,000 yds) Fine for Foxtrot Corpen and the initial launch/Recovery phase of the cycle. But, after the 180° turn and sprint down wind to regain sea for the next cycle? - Carrier is fine, on reciprocal heading. - CG is on the opposite side but corrects quickly. - Plane Guard follows and corrects fairly quickly. - Lead Destroyer is 28,000 yds out of position to a Carrier sprinting at 27 kts away from it. - Picket Destroyer is 60,000 yds out of position and racing Away from the Threat Axis. A Waypoint Disposition Change - would allow: - Carrier to proceed. - CG to proceed, or remain on the same side. - Plane Guard could become Lead Destroyer, now only 10,000 yds out of position and ahead of the Carrier. - Lead Destroyer could become Plane Guard, now only 10,000 yds out of position and behind the Carrier. - Picket Destroyer could remain on the Threat Axis and simply reverse course. Pretty slick. Please consider. Bowie

RCtrl+RShift+Num2 or Num8 should allow you to move your camera up/down. Otherwise you'll find a full list of camera controlls/view controlls in the settings-> Controlls

same DLL is showing in the crash. try this. find C:\Users\Nick\Saved Games\DCS\ and rename it to C:\Users\Nick\Saved Games\DCS.bak run DCS. close DCS. go back to C:\Users\Nick\Saved Games\DCS.bak\config\Input and copy all the contents of the folder to the newly created C:\Users\Nick\Saved Games\DCS\config\Input (these are your controls!) run DCS to check results. also i am unsure if it will affect your issue but you have parked cores. 2025-09-01 21:33:08.922 WARNING EDCORE (Main): CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores)

After years it's time to shake off the dust from my Harrier and take it off the hangar. Tks for your material!

I don't understand how to adjust the camera seat height?

If you're not providing updates and you're not giving owners of early access modules a response when they ask what development is being done, then the module is effectively abandoned. This module is dated before its even been completed. Why should people keep buying EA modules if this is how development is going to go. It's the same with the supercarrier, just endless early access.

i have the AI bombing from 50 - 100 ft. AGL using the bombing Advanced Waypoint action and bombs with 11 sec fusing (in BOTH ends or they will not be delayed!!! - plugged in the nose and 11 sec in the tail is not working). in the bombing action you need to set "Altitude Above" to the altitude you want the AI to deliver from. I have it set to 98 ft. and they will drop from 98 ft. AGL. I think the functionality is miss labeled and should be called "delivery altitude"

AI will only drop 2 bombs on an Advanced Waypoint (Bombing) even if the action is set to either drop ALL or drop 4. This is also valid if the AI flown mosquito has 4 similar bombs (2 in bay and 2 on wings) They should be able to drop all bombs no matter type or fuse settings in one go if that is selected.

Here is the latest Log file. I looked though it but can tell what item might be related to the crash. Thanks! dcs.log

So SSAO on VS off looks the same to you? And yes it is 100% a QV issue. However I'm quite surprised that SSAO "on" made no change on your end.

Just flew M10 again today. Wingman died again. At some point after ordering him to attack the convoy he attacks with his mavericks, runs in another one with guns and at some point just flew away and than died/disappear. I could RTB and finish the mission. Shadow will be back

What you say is true, and I still need to do more testing to see if the reduction in base frame rate and added input latency is worth while. However my main purpose for both smooth motion and DLSS frame gen (in MS FS) is to improve the smoothness and clarity of looking around the cockpit and moving scenery for my pancake display. I have an IPS LCD which has more visible ghosting at lower frame rates. The difference between 30, 60, 120 and even 144 (res limited) is astounding, like a completely different display.

@ChillNG that’s awesome news! I loved FIWOS and LOWOS

I would have NEVER told you this in Feb 2024 when I built my rig but TODAY, in Sept 2025 you should be OK. From my chair the problem stemmed from Intel's neglect in setting the Intel defaults for the Motherboard manufacturers and instead of perfecting the Microcode themselves, they left it to the motherboard manufacturers to do it. This ended up with the most base default setting driving up the CPU voltage and heat creating a level of degradation that wasn't normal and would basically kill these CPU's in 6 months to a year if left unaddressed. As it stands, Intel forced all the manufacturers to follow the same template for the microcode so that the advertised and labeled "intel defaults" really were safe parameters set by Intel. All that to say, you should be fine. - Now if you are looking at another CPU and MB combo, I'd also recommend AMD's 9800 X3D.... If I had waited long enough I would have opted for that build.

There are mods who take care of that. Run a search, and you’ll easily find them.

That will be difficult to say without a track or video. From my experience watching people debug user reports regarding Shrikes almost on a daily base, I can say that the weapon is very tricky to use and most user reports end up being incorrect usage on their side. For example the SAM site turning off their tracking dish or tracking another player instead. Or you (or whatever the SAM targets) not flying in a way anymore that the shrike rides down the radar beam anymore but sidelobes instead... really complex topic.

I flew the F-4 a few hours ago, and sounds are normal on my end.

Does it work if you disable this setting again? The soundscape is usually optimized and mixed for it being off. Other users have not mentioned such a problem yet, so sounds odd.

Just tried that; No joy. BUT. ..it was the quadviews. But with QW off, it is even more jittery and swimmy.