WytchCrypt

Thanks everyone for the great suggestions! I've been flying the Su27/33 since the DOS days, but the Hornet will be the first US bird I've flown...so much to learn :thumbup:

Hi all, I'm in the process of getting a new laptop so I can better run DCS 2.5.x and specifically the Hornet - had no idea 2.5 high quality required my entire existing SSD! I have a few days waiting for it to show up and was wondering the best place to begin studying how to fly the Hornet? I have Chuck's FA-18C Hornet Guide and have taken my first pass through it...wow, there's a lot to learn! Is that the best place to start or is there a specific thread or other guide I should be looking at? Thanks :smilewink:

Thanks to all who contributed their expertise to my questions :thumbup: I've decided I've got nothing to lose and everything to gain by jumping back onto DCS and buying the Hornet (especially since Eagle decided to implement offline mode in the way I was hoping for - it was being hotly debated when I left). I've been flying the Flanker (mostly the Su33 variant) since the 90's and love that plane and taking off on the Kuznetsov ramp...but...I've always really wanted to fly the Hornet off a carrier catapult and as I'm a little too old to ever become a Navy pilot, this is the closest I'm ever going to get so it's time to make it happen :smilewink:

So without the ground radar, I'm guessing the only ground attack capability is rockets/unguided bombs? Also, does that mean no laser lock/smart missile attack of ground objects? Any ETA on these additions? Thanks!

Hi all, I've been away from DCS for a couple years and have just returned to check out where things are at in Hornet land. I began flying the Su27 in the old DOS days, and I've been patiently waiting years to get in the seat of a Hornet! I want to find out if now's the time to make the move. It appears the Hornet is still in 'early access'. I have some quick questions - apologies if these have been addressed elsewhere...I couldn't find the answers :smilewink: 1) Is the Hornet complete and functional enough to the point that it's time to jump back in, download DCS 2.5 and buy the module, or is there still a sizeable amount of work to be done? 2) I notice on the Hornet 'Buy' page it says it requires DCS 2.5.2. I also notice at the bottom of the 'Buy' page it says it will fly on DCS 2.5. Can anyone tell me which DCS I really need? If it's 2.5.2, how stable is that release? I'm guessing I just d'load 2.5 then patch up to 2.5.2, correct? 3) I only play offline mode and spend my time creating missions and recording the results for playback. With the Hornet in early access, will additional ongoing updates to the Hornet ruin any track files I create with a previous release? 4) Can anyone comment on the status of the Nimitz. I noticed on the Hornet info page it says it comes with the USS John C Stennis. Is the Nimitz going to be an add-on for purchase or will it be included in an incremental DCS world update? Thanks!

Can't really comment on DCS track replay accuracy these days as I've been exclusively flying FC2 the past couple months, but I've noticed what appears to be a consistent situation. I've recorded about 50 track replays in that time and starting a mission in the air with the Su33 or Su25T often leads to a bugged replay (especially with the Su33); however, I haven't had a single problem when beginning missions on the ground or carrier. This includes recording heavy time compression on the replays :thumbup: That said, my missions are generally very simple with very few enemy AI moving parts, so I don't know if I've found a magic bullet that would make any difference in DCS, but it seems to be true in FC2...so far anyway :lol:

Thanks for the reference. Read the whole thread and saw your posts reporting that after their silly recommended start up procedure it still doesn't work. Very frustrating! I loved the idea of having 3 separate button maps available with the 3 way toggle (I originally built 1 map for navigation, 1 for combat, and 1 for views/track recording) but it was so unreliable I've had no choice but to scrap the whole plan. Now I'm setting up the buttons with CTL, SHFT, ALT, etc variations so I do have multiple functions per button, but of course now it's a 2 hand operation as I have to hold down CTL, SHFT, ALT, etc with one hand while pressing the Eclipse button. It works great and is solid...not as cool or elegant as the 3 way toggle, but better than nothing and I don't have to do a full reboot at least once a day :smilewink: I wonder if CH is ever going to build a solid Control Manager for Windows10 :music_whistling:

CH Eclipse user on Windows 10 here. I've noticed this problem with Control Manager and I'm wondering if you've heard of it or know of a fix. The problem got so annoying that I stopped using the Control Manager software completely and now just fly it in non-programmable mode where it works perfect. I used the Eclipse both with CMS scripting and straight 3 mode switch operation and have the same problem. Just about once every day the Eclipse seems to "lose focus", or in other words just goes dead at random times. When I look at the USB game devices it still shows up, but when I bring up Control Manager it doesn't "see" the Eclipse. Refreshing devices makes no difference. The only way to fix it is to completely reboot my laptop. Since I stopped using Control Manager a couple weeks ago and have operated the Eclipse in standard configuration it hasn't lost focus a single time. I've read many people on the CH forum begging them to release a Windows 10 specific Control Manager. Anyone else seeing this or know anything about this same problem?

Got ya...no argument here. I just keep a simple text file with my keys in it on the desktop. If Starforce wants me to reverify for whatever silly reason, I just open the file and cut and paste. Doesn't make it less annoying, but makes it less painful to get around :smilewink:

Ya, you're right. I was just hoping that by trying many different approaches I could make some sense out of why a track goes bad to know how to work around it. I was just messing with this more today and while I'm sure it's not the magic bullet, it definitely seems my replays are more likely to be inaccurate if I start the mission in the air rather than taking off from a land based airfield :smilewink:

Wanted to follow up something interesting I've noticed, this is specific to FC2 though it may also have carried through to DCS. I've been testing track recording on a very simple mission with an Su33 and the Kuznetsov, no AI units in the mission. 1) Simple mission with Su33 beginning in the air, already lined up with carrier and landing: Track recording incorrect virtually 100% of the time...successful traps consistently become the Su33 lined up about 10 meters wide of the carrier. 2) Same mission as above but with AI rather than player assigned to Su33: Track recording correct 100% of the time. Time acceleration makes no difference, track always records properly. 3) Player controlled Su33 takes off from land base and then lands on carrier: Track recording correct 100% of the time! Time acceleration and extreme control inputs have no negative effects on recorded track. I haven't tested every possible thing obviously, but it sure seems that carrier traps from a player controlled land base record much better than traps beginning in the air. Also, it's been said the development team uses tracks as a debugging tool. Since incorrect tracks seem to have begun in the first FC release, the team has likely spent hundreds of hours dealing with this and it would be incredibly helpful if someone from the development team could share their experiences on what things make the track recordings inaccurate :thumbup:

Hi all, I exclusively fly the Su33 and notice that in previous releases (FC2, LOMAC etc) the ADI "Required Pitch" & "Required Bank" indicators are much easier to see, especially at night. In DCS, I can barely see them which is a huge problem when I'm flying in a dark cockpit. Could be a combination that the indicators are very thin now and that I'm color blind as a bat :smilewink: Anyway, does anyone know where the bmp that defines this can be found and what dds it lives in? I'd love to thicken it up and give it a color I can actually see :thumbup: Thanks!

I mentioned in another recent thread that it's very disappointing that tracks are still inaccurate in the newest 1.5.8.x. I guess I understand all the reasons why this is the case, but was curious just how far back in the "Flanker" timeline that this was an issue. It seemed to me that in the early days, track recordings were solid. I tested FC2 and even simple, short missions (perfectly lined up 5Km away from carrier landing, perfectly lined up runway rocket attack, etc) played back wrong. Even without time compression or unusual weather, same thing. Sometimes the exact same track played back correctly once and then incorrectly the next try...maddening. I tested LOMAC 1.0.2 and the replays were solid and always correct. I even tried my best to break them recording a carrier landing mission. I began about 20Km away and flew a crazy side to side, up and down zig-zag pattern with extreme control inputs, finally lining up and landing with 5Km to go. On track playback I used extreme time compression and constant view and pan adjustments...still a perfect landing every time. Before LOMAC, I also flew Flanker 2.5 and the original DOS version and while I can't test them now, I don't recall any track inaccuracies... I guess a question is, when did other long time Flanker pilots first notice track playback problems? For me it appears they were introduced with Flaming Cliffs. While others may not use tracks much, for me they're a major part of my enjoyment of flying (The IL-2 ntrk system is an example of how things should work). I really wish the team would sort this out or introduce a new track recording system that reliably works. As others have mentioned, I won't be investing in further modules until the long standing issues with track recording are corrected :( Don't get me wrong, DCS is an amazing achievement, but if the track recorder is really just a debugging tool then it shouldn't be presented as anything more. If a track recorder is considered a DCS feature, then it needs to work properly :smilewink:

Sounds promising. Very excited to hear how this will be implemented :thumbup:

I understand from a technical standpoint why replays from previous patches wouldn't work going forward. Any object behavior or FM that gets updated would now perform differently even with the same control input and starting object position, I just wish a track created in release x.x.x.x would still work properly in x.x.x.x :smilewink:

So I've noticed with the new 1.5.8.x that track replays remain inaccurate. I've done extensive research going all the way back to the Flanker DOS days, and it appears the root of the problem is simply the way tracks are implemented. It appears they are a collection of object locations at the start of the mission, replays of game events, control inputs by the player, and random events generated in the game. Since this is the basis of how a replay plays back, it's really no surprise that inaccuracies occur. My question is, since this appears to have been a known issue since the Flaming Cliffs days (I personally never saw an inaccurate track replay from LOMAC or before), will the team ever really tackle this problem? Actual recording of the video output of a mission has many obvious drawbacks (file size, sound sync, inability to change views during playback, etc) so I'm wondering if the imperfect track method we have had for many years is just the way things will be going forward? On the one hand, since the Flanker engine has gotten more and more complex with every release, it makes sense the track system gets a little more inaccurate with each release and keeps limping along patched with duct tape and plastic wrap. On the other hand, I'd love the old accuracy of the Flanker 1.5 through LOMAC track system, but perhaps it's just not possible with the current complex environment. Or maybe I'm the only one out there who cares about having accurate replays :smilewink: Any thoughts?

Got it :smilewink: I find it interesting that all the years I flew LOMAC (and Flanker 2.5, 2.0 & DOS versions before that) I never recall a single time my recorded track file played back incorrectly...not once. Then again, DCS certainly appears to be much more complex as far as the number of objects that can be moving around, not to mention the triggered events that can effect the outcome of a track so I guess track inconsistencies are somewhat inevitable :unsure:

Thanks Art-J, makes sense, I had a feeling it was something like this :smilewink: It's really bizarre though, any mission that begins in the air or on the carrier replays accurately, any that begin on land end up a few meters off the carrier for landing...oops, I should say splashdown! Anyway, you mention not expecting tracks to work at this time. Is there an effort to tighten up the track creation and playback processes in the future?

Hi all, I wanted to try the new 1.5.8 beta because I read that it fixed a problem with the Su33 airbrake indicator lamp. I opened a command window and ran, "DCS_updater.exe update 1.5.8.12162.404 openbeta" and it updated as expected. I tested and it indeed did fix the Su33 airbrake indicator lamp issue; however, it introduced some odd problems into track recording. I decided openbeta isn't for me and reverted to the previous stable release by running, "DCS_updater.exe update 1.5.7.11762.396" and it updated as expected. All good, except now many of the track files I originally created before testing the 1.5.8 openbeta now playback incorrectly! It seems to be restricted to my "carrier qual" missions where I take off from a land base and land on the Kuznetsov. On the replays, I consistently ditch in the water about 10 meters to the left of the carrier instead of making a clean landing on the deck as originally recorded. Oddly enough, the track recordings of my "carrier qual" missions that do not involve taking off from a land base are still perfectly correct. Has anyone experienced anything like this? It doesn't make any sense why the mission recordings originally made on the stable 1.5.7 of late September 2017 would no longer playback correctly on the stable 1.5.7 of early December. Was there a significant change between them that might account for a few meters difference in land base location or something? Thanks!

I figured that. My point was why make a thread (and poll) that affects every DCS user to ever purchase a module appear under a title that seems to only affect those that purchased the AV-8B :smilewink:

Logged in this morning to check on this thread and found it has been moved from, "Eagle Dynamics New DRM Expiration Period Limit" to "AV-8B COPY PROTECTION CHANGE" and I'm curious why? Seems to me since this thread has mentioned several times that ED plans to retroactively convert existing modules to this new DRM approach, that this thread should be titled in a way to reach as many current module owners as possible, not imply that it only affects those purchasing the AV-8B module :huh: A plan to change the DRM approach for all module owners should invite all module owners to learn and comment :smilewink:

My experience of statistical analysis in a manufacturing arena simply showed ignoring data cost a company $$$. I would believe the lesson learned would apply to any company that ignores adverse quality results or direct customer feedback. As far as the current poll, I would agree that the number of people voting for 90 days is not directly representative of the general population of DCS users. Why? Because I would bet everyone who voted 90 days actually did so only because the "never" option was not present :smilewink:

Wow! Thanks for this flashback to 1984 as a QA statistician at Apple in the early days of the Fremont CA Mac factory...and yes, Apple actually did all their manufacturing in the US once upon a time :lol: Constant arguments with the manufacturing guys. I'd tell them our sample inspection and reliability analysis showed there was a 95% probability we were shipping at least 10% defective Macs out to the field that would fail within the first 1000 hours of use. Their response was always the same: unless you can tell me it's 100% true, I'm not doing anything about it. So they didn't...and 20% of the early Macs came streaming back with heating failures :doh: Of course, that had absolutely nothing with the fact that a certain Mr Jobs completely refused to put cooling fans in his beautiful Mac :smartass: The moral of the story? Ignore statistics at your peril :music_whistling:

Very clever...thanks for the tip :thumbup:

Hi Monnie, at the time of the incident I described we were running our credit cards through Intuit Merchant Processing. I'd physically run the cards myself, but it would be through the Intuit online portal or as part of a Quickbooks entry. We've recently moved on to Elavon for a much lower merchant processing fee and luckily have not had another "chargeback". I really can't complain though, 12 years running cards and only 1 fraudulent charge makes for a pretty good average :smilewink: I think I see what you're getting at. Perhaps if we were paying a third party to do our processing, that the contract would be written that they would take the hit on fraudulent charges? Dennis