oldcrusty
-
Posts
2417 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by oldcrusty
-
-
2 hours ago, Recluse said:
My experience has been similar to the OP. I can bring up the FLIR screen on another MFD, but if I move the TDC to it (SCS toward that screen) it immediately takes over. As long as the TDC isn't there, the Radar remains the sensor. I usually use SEA or GMT radar with AGM-65F to designate a target and bring up the FLIR to make sure I have what I want. I can fire at range. With Laser Guided Ordnance, sometimes including AGM-65E, I find that you can lose the target as you get too close or otherwise out of radar GIMBAL limits, so it is useful to switch to a FLIR designation. For movers, this is always kind of a pain with a lot of heads down activity to lead the targets JUST RIGHT to get a PTRK.
I had to come up with my own ways to deal with this issue. When using Ir Mavs, one method was to pre-configure the FLIR to max zoom on RDDI then switch to GMT on the same DDI, find and lock the track, switch back to FLIR on RDDI and watch the radar track the mover. It would track nicely provided I didn't touch the FLIR function buttons. When within 12 or 15 nm, depending on weather, time of day etc, I would ground stabilize the FLIR reticle right in front of the target vehicle and as it passes under the dot, I'd change to PTRK. The LDDI was reserved for IR Mav. I always set them all to NAR FOV ahead of time. Now... the target hand off is another story lol but it's doable.
-
Thanks for the heads up. I didn't have any stutter though on 546.29 (Reverb G2 in native res. @ 90Hz, MSAAx2, sharpening .7 - no other 'fancy' new stuff). I'll update anyway.
-
On 12/5/2023 at 9:50 AM, Recluse said:
I can confirm this.
This has been a problem for a long time. I tried to search for the previous Bug Reports, but have come up empty. I know they are there somewhere!!
At one point, switching to the TGP MFD retained the Radar Lock, until a DESIGNATION was made on the TGP. Then at some point it change to the behavior shown above where just SELECTING the TGP caused the Sensor to change from RADAR to FLIR.
FOUND IT!
In my experience, switching to FLIR from A/G radar will not change the sensor priority but as soon as you touch the FLIR screen to say change the zoom lvl, the radar drops off.
-
1
-
-
8 hours ago, norman99 said:
I've just been practicing lofting Mk82s and found mine all went long, so
.
I plan on doing some more drops tomorrow, so I'll see what I get.
What you will get is more of the same. Currently, diving deliveries hit short, level deliveries are reasonably accurate and 'lofting' (auto - w/o any pullup cues) hits long. A while back lofting was the most accurate... at least for me.
-
1 hour ago, Sepp666 said:
Sometimes Software development looks that complex to me: It feels like as if you change the tires of your car and because of that the Bluetooth connection of the radio to your cell phone doesn't work anymore...
On top of that it seems like the bug carousel still keeps rotating and bringing back 'fixed' issues... on occasions.
-
1
-
-
Is the boat always moving exactly 180deg in the opposite direction or some random direction?
-
O for all IT guys and gals here: Would running Wireshark (or some better stuff
) be helpful to narrow it down a bit?
-
I'm not surprised some people are hesitant to trust any company these days with all the pressure from global tech 'advisers'.
Since I'm not exactly a cyber genius and I love open and clear communication I'd be extremely happy to learn how the module trial system was abused for educational and preventive measures. CVE on Virustotal? lol. I imagine 2FA countermeasure would suggest some ID shenanigans.
As far as any personal data being collected and sold and re-sold... that battle has been already lost for me long time ago. Now, I simply focus on keeping AI totally confused and not being able to make any coherent profile on me... other then an nutcase
. More restrictive you get, more flags pop up. No Tor browsers, no de-googled phones, etc. Besides, if I ever tried to do any of that, it would not be to hide something but simply to piss these controlling buggers off 
Back to standby...
-
1
-
-
LOL, whatever. I'm already cross-device fingerprited, 5fa-id'd, have pegasus running at full blast, my alexa talks sh** back to me, my monitor uses speakers as a mike, what else...
I just want my Hornet finished and fully VR debugged.
-
1
-
-
6 hours ago, VR Flight Guy in PJ Pants said:
Watch this and makes me worried regarding ECM
Sorry if it was the wrong thread regarding this.
Wrong thread or not... I'd like to see some sort of dedicated ECM platform (AI's fine). I wouldn't worry too much about lack of RW docs... however it all works, we know it wreaks havoc on all electronics 'around'. ED could use their imagination as much as they want, :D. Here's a sample: https://youtu.be/v1zxH369Bm4?t=322
-
2
-
-
23 hours ago, Napillo said:
You do understand that cars of the past (which, depending on the time of the mission in DCS could be realistic) had incandescent lights. Incandescent lights used tungsten filaments that are heated up to 4600F (around 2500c) which will produce significant IR. Some cars still use those, and military vehicles old enough to be in DCS certainly had them.
Around the immediate area of the lamps, not as a reflection on the surface 30m away.
I'm currently on vacation from DCS so I'm not sure what's going on in that department, MT or ST.
-
2
-
-
1 hour ago, Aaron said:
nullI'm trying to run DCS in Ubuntu 22.04 LTS using Wine. I followed the process described here: https://github.com/TheZoq2/dcs_on_linux#getting-it-working-manually. I first tried the Lutris method, but Lutris does absolutely nothing on my machine.
Unfortunately, when I try to log in, I get an error 500 "No saved authorization found." The DCS documentation says that this is caused by an incorrect date/time/timezone, but they're all set correctly in my OS. Maybe Wine isn't syncing correctly?
Any suggestions?
I'm not sure how Wine does it. One thing I know is Windows time base was local, Ubuntu is UTC. When I had a dual boot setup on my rig (Ubuntu's Grub as bootloader), logging in to Windows after using Linux always caused time shift to UTC. All I had to do is sync it again. I got tired of this so I my buddy ChatGPT to show me the command line fix for this... not a big issue.
Something tells me that this error 500 would still pop up
-
-
On 6/9/2023 at 4:24 AM, Swiso said:
Rudel, could you check please when these two files were last modified on your install?
X:\Program Files\Eagle Dynamics\DCS World OpenBeta\CoreMods\aircraft\C-101\bin : C101Core.dll
X:\Program Files\Eagle Dynamics\DCS World OpenBeta\CoreMods\aircraft\Mirage-F1\bin : MirageF1Core.dll
Mine, now are from the 8th of June.
Early this morning, the 2 files in question ( that were reported as a virus) were listed as last modified on the 9th of June.
Not sure it had to do with false positive.
After deleting them and repairing DCS, now they look ok and no more warnings from Bitdefender.
So, the modified file from the 8th was still giving you the warning? Yes... I know, you already 'repaired' and running. Just curious.
-
13 hours ago, MickV said:
Mine's all sorted and working well. Frustrating, but I'm grateful ED sorted it out promptly.
I'd be even more grateful if one of the internal testers pretended they are like the rest of us and before each update link up to the same d/l servers that we connect to and do a test run, before making updates available to the public (the real OB testers
)
-
1 hour ago, Predator-78 said:
This inconvenience is the practical demonstration that if the ED server stops working, all of us cannot use the purchased modules, so we don't own anything. I consider it a serious enough fact and the ED must allow all of us to be able to use the modules even when their server is down! Provide all the security systems you want, but I must be free to use my modules.
Like the baldie from davos said: 'You won't own anything and be happy'! I just had to...
-
2
-
-
I'm glad I held off from updating. Whether it's bogus or real... they need to straighten their s*** up. Well, I'm going to extend my little vacation from DCS
-
1 hour ago, Tholozor said:
Try switching the position-keeping mode on the HSI from POS/AINS to POS/GPS, see if there's any noticeable difference.
I actually did some of the test runs within seconds of each other: say, level run at 4k ft AGL, 480kts, followed by a quick climbing turn in the oblique, back toward the target, rolling out on a 40 deg dive, release at 4k AGL, 500kts (on rails). FLIR ranging in level, AGR in a dive. If any gyros were out of whack, it would be obvious in both drops.
So, you don't see any issue with this on your rig, Tholozor?
-
6 hours ago, BuzzU said:
Thanks for the answer.
I guess i'll have to do some testing in all conditions to convince me.
OK BuzzU, we are all going in circles here, lol. I was never comparing accuracy of AUTO mode (Hornet term) vs. CCIP. I simply stated that using CCIP gave me an option to use my clumsy, fat thumb to release the bombs a split second late, in 30~40 deg dive. This way, instead of hitting short, I was correcting for inaccuracies of AUTO release cue computations (DCS thing).
All systems aligned, GPS autocorrected (always on), AGR or FLIR ranging.
Again, releasing the bombs from a LEVEL flight using AUTO mode, produces no error. Just about all hits dead on. I have no idea why the Hornet's computer can't do the same for dive or loft attacks. If the bombs get effected by the release angle, the computer should know that.
Well BuzzU, the testing is on you now... take as long as you need to. My DCS install has to go TDY for a little while. I'll be checking the forum.
-
1 hour ago, Gunjam said:
I'm glad it's being worked on, but I am apprehensive about this reflection/glint talk going on. Spotting range is extremely exaggerated with the dots right now. The last thing we need is some gamey glint/reflection which is guaranteed at all angles and hours of the day and at silly ranges. How much chrome and reflective surfaces do you see on fighter aircraft.. hmmm
I'm with on that one... instead of silly dots, maybe some better (darker?) transition texture. This reminds me how hard it is sometimes to spot a grey jet from the ground or even the air, at around 3 ~ 4 miles away, in the sunny, blue sky. Sure, looking at the right part of the sky we can spot a small (non-smoking and non-reflecting) jet from a descent distance, look away for an instance and it takes a few seconds to spot him again, if lucky and a 10/20 vision
, had it for a while... not anymore.
-
1
-
-
On 5/19/2023 at 5:56 PM, twistking said:
Friday's newsletter mentioned improved (night) lighting of Viper/Hornet in the current OB.
The patch changelog didn't have anything about aircraft lighting though. What did change concerning lighting?
Has anyone on Open Beta discovered any improvments to aircraft lighting? Maybe (hopefully) light visibility distance finally improved?
I'm on stable, so can't test myself.Just checked it, in the bright daylight. The Hornet with its position and strobe lights on, still looks like a glowing orb from miles away. I'm not talking about the strobe flashing on and off. The strobe is actually invisible from distance, overpowered by a 'blend' of steady position lights, especially annoying in VR.
Dots or no dots... just tell the Hornet drivers to keep their ext. lights on and the spotting is no problem, even in bright daylight.
-
1
-
1
-
-
5 minutes ago, BuzzU said:
Out of curiosity. Does this all apply to the Hog too?
I don't know. I haven't flown the Hog in years, stubbornly sticking to Hornets. I might fire it up some day... gonna have to configure the controls again, from scratch.
-
There is also another reason why using AUTO in the current version of OB gives us advantage over CCIP, TD box on the target. Some time ago, we had an option to use CCIP over ground designations... very useful feature. The guns in CCIP mode can still be used on designated targets. Some people claimed that this can't be done in RW Hornet... for whatever weird reason.
Having an option to switch to CCIP and still have a TD box visible was a tremendous help with SA. Why would I want to switch? Simple... AUTO mode was and still is causing short hits when diving. In CCIP I could press the pickle just right to compensate... As mentioned earlier, we do what we have to do to go around bugs. Now, at least in my tests, the level release is the winner (AUTO or CCIP) hence the title of this thread. Well, we're way beyond that, which is fine.
A few OB builds ago, lofting in AUTO was the most accurate for me (at around 500kts). I liked it since I was able to sneak in and throw the bombs up at the target and drop down again quickly.
ED makes these discrete changes without any notice and we have to play test pilots to find out.
-
4 hours ago, amalahama said:
I ond't understand your point? You followed the ASL, the bomb dropped at the exact moment, you scored the hit. Where is the issue?
I don't understand myself sometimes either... I just imagined some basic trig. What if the mission computer gave you a crab angle at some point after initial that would put you on a steady path (course) that would guide you toward the release point (already calculated roughly with ASL glued to it) for your a/s. Now, hell if I know how this worked in the ol' Hornet
.
One thing for sure, RW or game. In very rough weather, this type of weapon and attack direction would be iffy at best.
Ground moving target AGM-65F + POD
in DCS: F/A-18C
Posted
I just tested this, well at least I tried. The attack direction didn't quite workout the way I planned. When approaching the movers head on, I ended up a bit to one side and the sunlight was slightly hitting the sensors. Hot summer afternoon in both cases.
When approaching the targets from behind, I was able to persuade the MavF's to lock. It seemed like the FLIR was updating the Mav's seeker on occasion, making the seeker 'jump' toward the target. The FLIR was tracking the first vehicle in the convoy but the Mav locked on the second. I wasn't going to waste time to correct just as long as I remembered which vehicle I fired on already...
On the second test, approaching from a head on direction the FLIR was tracking for a while but the Mav never acquired. When the FLIR finally lost track I undesignsted and used the Mav seeker on its own. It was shaky but it worked. I'm not sure if this test helped to answer your question. Personally I think there were other factors, including of course the current modelling.
https://youtu.be/TWeF_N9MIw4?si=QWkK9vJNEbIJRmTs