TGW

I too have the same problem, upon first start (verified and logged in to DCS), I can select the multiplayer option to get the retrieved serverlist for online multiplay. Upon leaving from a connected MP server, when I return to the DCS serverlist it is blank, I have waited for over 10 minutes without the serverlist repopulating itself. On the same computer and same installed drive location, I can run the single-threaded version of the program without this problem.

Thank you!

To anyone who can help, Please excuse my ignorance, but I am missing something to turn off the F2 'camera sway'? Thank you in advance!

.

I am successfully running v2.7 under Win 8.1 with very good (frames) performance (better than 2.5.6 under Win 7). I made no changes to my hardware config (other than drivers) under Win 8.1. This is a viable option!!

As with any config changes in the aircraft (fuel tank dump, ordinance drop, acft damage, flap & sbrake deployment) are automatically trimmed in the FCS. UNLESS, there's a FCS channel failure, then you would use manual (trim buttons) for flight vector stabilization. . .

Any possibility of a texture template (PSD) in the near future??

I see this applies to the 'current' update, FM is completely borked in v2.7 (vs. v2.5.6). Induced drag values are waaaay to high , and turn rate is horrible, not even comparable with NFM-220 manual documentation, sigh.

True in the above point. But your airspeed @ max-G will vary according to weight (wing-loading) of your aircraft at any given point in time (heavier=faster). This in turn (pun-intended) will also vary your 'turn diameter', which is another factor to be monitoring while performing BFM with an opponent. Yes, this is expected, as each aircraft has a differing lift-to-total drag (induced + parasitic) profile!

PB mode for HARMs will be nice too, so they actually LOFT properly to the RF emitters!!!

AIM-7P is current and there have been rumors of an R model . . .

Anyone notice any changes in the Hornet's FM today? . . . again . . .

Unfortunately, with the suggestions you made, its not an issue of 'checking the models' or 'correct textures'. Taking snapshot images is not of a consequence either (as this does occur frequently on servers with this option enabled) . For this 'blatant' coding manipulation of the vehicles, there needs to be a progressive affirmative action, either permaban and/or legal (EULA violation) action. I hope this clarifies my position.

Is there a way, or even the idea of using a SHA1 hash algorithm for the purpose of authenticating the validiation of all of the flight models of the DCS aircraft while on multiplay servers? I have a (growing) list of players with aircraft that have exceeded their modules FM performance by more than 10%. This is really starting to be annoying and frustrating for the investment I have made into this simulator and being undermined by some individuals who think their shortcut in life is 'to cheat'. I know I speak for a crowd of people who are also tired of this manipulation and dishonesty. Is there a way for you to incorporate the SHA1 hash algorithm into the server module to verify and authenticate the flight models of your current (and future) fleet of aircraft? With an end result that the server would reject these hybrid aircraft (or other vehicles) from joing the multiplay session. For those repeating attempts to connect, the server would log the account ID and IP address. Included with the option of this 'log' to be sent DCS, so that ED (if they seem fit) would either cancel the violators account and/or pursue legal action with a EULA violation of your products and disruptive gameplay of others while using the simulator. I know Electronic Arts a few years back had instituted a similar policy like this in their EULA, and the hacking and disruptive gameplay dropped "considerably". Just a thought . . . .

Agreed!

I have 'fannywaxed' a few from this squadron on the JDF servers with ease. Back to 'the basics' [HVY]!

.

Agreed . . .

Check out this thread for more info on what is going on . . . https://forums.eagle.ru/showthread.php?t=281336

@Figaro9 +1!

DrHay you are correct, but for the most consistent testing you would need to run the aircraft through a preplanned script to obtain the most accurate flight performance results and, then the input curves profile would be nulled . . .

Interesting, upon looking at the GAO document ID (pg.86) posted above which directly refers to a NAVAIR document (making a comparison of the C/D vs. E/F models) shows the following data for the F/A-18C. Configuration: (2) AIM-9 (2) AIM-120 Total Drag Index: 8.0 [sidenote, (2) AIM-9 underwing on LAU-7 launcher has an index of 6.0] (100%) Cannon ammo (60%) Internal fuel GW=33,325 lbs. Gives the following speeds at Ps=0 (sustained): ~M1.28 @ 10Kft ~M1.45 @ 20Kft ~M1.65 @ 30Kft

Actually, this would have no bearing on the performance of the jet (assuming you have allowed full output to the control surfaces) as the curves function only provide a logarithmic (a finer response on smaller inputs) output to the control surfaces. So, unless you have damped the output to something less than 100%, then this would make no difference in flight performance measurement.

Would you like to share which unclassified documentation you based the Hornet's 'over-performance' with? Would you like to share your EM data that you created so it can be peer reviewed for accuracy? Please also list the 'real world' documents you used for your comparisons. Were your testing methods by the use of scripts (very accurate) or, were they 'hand flown' (non-precise) to arrive at the assumption(s) you have made? @wilbur81 +2 :)

@ airea +1