Pikey

I've now got a prototype RTS conquest map using this, where these are spawned by CTLD, from crates picked up from airfields via a C-130. Just about to test slot saving and I'll be set to conquer the world. I like this new ED that gives us what we want, it's awesome

would love to have these please, have a virpil with two very similar knobs that are begging to be volume knobs for SRS. Many other plane modules have bound volume.

Regarding the Friday news: Maybe I missed the post that says thanks for adding in elements that weren't ever stated they would be in the Syria terrain module, but from myself, since I asked so much about them, I want to say thank you, because it (will) make the map absolutely amazing. Cyprus adds a Greek-Turkish possibility and turns the sea into a contested oil zone, future proofing the interest in the module being relevant to a broader amount of countries. It makes Turkey stand as potenital friend or foe on the map. It add the British base which is used in this theatre quite a lot, by other nations too. Greece becomes relevant country faction to create simulations with, which i'm sure the Greek guys are delighted about. WHen the Eurofighter comes out, it will have a home and we can plan modern misisons that we've seen in the last few years. Dier-e-Zor was the scene of most of the late war ISIL strikes, on the Euphrates and in terms of missions, key and featuring often. It makes 350nm between Akrotiri and Deir E Zor across the map. Shayrat and Tiyas' omissions were very obvious from the begining. Tiyas being strongly connected to Iran and both involved in several airstrikes, both being active, militarily. I missed them when looking to make real scenarios. If anyone was on the fence about the Syria map, get off and get your credit card out, it's beyond worth it, its got the highest number of unique model buildings on any map. Just Damascas alone - I recently made a mission to attack the Ministry of Defence and found I could use real world pictures for the brieding, because it was recognisable that clearly. Again, thanks Ugra.

Britain is a small country but, in terms of invention, a massive target for poking fun at. You could have picked any one of dozens of stupid designs created or excercised in the realms of aviation, in that period and we could have had a giggle. There are some truely hideous creations that barely flew. But, instead, you threw the dart at the board and missed the wall. Opinion is fun and all that, yes, you are welcome to it unreservedly. But the empirical data is very much at odds with your opinion. And it's an awful lot of combat data. Since it wasn't difficult to use the aircraft, for at least the majority of the pilots who used it successfully, we can only conclude that it's just difficult for you. That's a shame for you. And very brave of you to let us know. :)

I have no idea what this thread is going on about. It flies hands off. And, very easily. It's super stable. Whats more, after I got my friend flying it, 5 minutes after take off I asked him, OK, trim it for hands off and see how stable it is. He told me he'd already trimmed it and was hands off. He's an F-18 FBW guy.

People say that synchronous development of 2 or more seperate modules must make it longer to produce only one. Whilst that is true, it's so narrow minded as it considers only one module ever and not the larger picture of multiple, or indeed a continuous pipeline. Let's use some rough figures. 5 years to do the Hornet features mostly to release. You could say that doing any other similarly complex aircraft also takes 5 years. Then we have the copy-paste effect, which is actually not copy paste, but experience. Developers need to be familiar with the topic. Generally you forget things fairly fast. Does it make sense to do two similar-but-not-the-same radars at the same time or do one, wait 5 years, then do another? It does to me. Keep the skills current, od as much in parallel, even if it lengthens out the first module (which I dont actually think it really has, but whatever). I would argue this is the vital part people completely miss in their undertanding of (software) development. At the core of it, there are humans, with memories and skill. 5 years is a long time in someone's life. 5 years ago, I was doing very different things with different skills. You can see plain examples of how they release similar things together and move on to new topics. The A-10C II was a classic. Next you have the JHMCS for the Hornet. It's not a random occurence but part of a plan. The only problem here in the way ED are doing it is that they didnt quite tell you how long it might take. You have to figure that out. You have to figure out, as a customer what early access means to ED, not what you think EA is because <insert company here> does/did. This takes a long time. It shoudl be obvious by now :) The Hornet is a good benchmark for everything to follow. I would rather they had the F-16 out and you can fly around and shoot things down, but its woefully gutted on it's features, than the alternative, which is "nothing". That is your choice. Nothing, or something. And the guys that choose "nothing", you can have that too! So really, no one loses at all and this entire discussion is a waste of time.

Stars twinkle as an effect of atmospheric disturbances and imperfect heat. It will change from place to place and weather to weather. The current rendition I like, feels more realistic than no twinkling.

I've been considering an update for a very long time. I originally said I wouldn't edit this but there are two compelling reasons to, especially since I have used my own templates so well, since I made them, in whole or in part for missions or training. 1) A chap approached me with adidtional helpful information about the Incirlik Patriot site and layout. We nerded for ages on the topic but the outcome would have been a realistic attempt to template the Incirlik site, especially the Patriot battery in all its various configurations over the years, but additonally with the point defence Rapier sets which surround the site. I balked originally at the effort vs reward because the site wouldnt have any substantial differences in its capability in DCS and would add a small load with new unit types. 2) The new Desert skins. Holy crap... this would not be a simple task. The fastest way to swap all the green for Desert liveries post that release would be programmatically in the file. And I'm a bit tired of doing that with the sim, what with all the testing I already do, running a small group and finding time to actually fly. No guarantees but I'm warming to an overhaul consisting of those changes, but not quite yet because I've alot on my plate and I need energy and time to go through 900 units :/

the TF-51 is the free plane that comes with DCS, not sure why you woudlnt have access to it or how you can even uninstall it, but if my memory serves correctly, there was an old bug about this. I'd suggest troubleshooting that bug, the miz doesnt require additional DLC.

Same, log out, log in, went. not sure what is going on there.

After testing it does seem so. So basically without the server install, you will get a 10min delay no matter what.

I wouldn't bother touching the main installation for things like that. The way DCS works is that the profile (Saved Games\DCS\) overwrites the settings in the install and the miz file overwrites the config, thus you have three layers of inherited settings. That's how your mission can overwrite your user settings which overwrite your games default. :) TLDR; in the \username\Saved Games\DCSfolderYouActuallyUseNotYourLegacyReinstallFromWhenever\Config\autoexec.cfg

Similar issue. Can I confirm that ALL CLIENTS connecting to a DS server that does not have Tacview installed have a mandatory enforced 10 minute client side delay added, regardless of what the client sets? On a server with no Tacview installed but which exports and also has the Tacview variables defined, clients have the message, "Applying playback delay of 10 minutes to prevent cheating". Since this is our squadrons persistent server we don't have a cheating issue to solve but we do dislike waiting ten minutes to disconnect to evaluate dogfighting. It appears (and it's really tough to understand this after reading and using this software for so many years) that, you must have Tacview installed on the server for clients to bypass the 10 minutes delay, which can be a nightmare to setup for servers with multiple installations and profiles - we really don't want to add any burden to the servers for performance, hence this is why we put the debt onto the clients to take their own Tacview. Hope that makes sense, is this unavoidable?

Checked on HP Reverb. Shared parser it was on all cockpit floodlights and lamps, I removed the line and they were all shown in both eyes normally. 100% this is shared_parser

Are these with or without shared parser in the config?

This has been requested for some time now, the problem is always you guys were never supporting the report of these issues at the time. There are so many reports of lighting related issues, especially the dots that if we cannot create super threads of customer wishes together, we lose traction. This has been an issue since March and release of 2.5.6 with the dots. The other lighting stuff I will bump again though. It's all tied into object distance and display. I beleive that once the object goes out of display range, its associated light is lost and thus, no ambient light = weird compensation required for ambience.

I tried a few versions but theres a minor bug with the process detection still in the current release. Depending on how DCS was closed the App doesnt recognise that the process stopped and then treats DCS as running but here's the issue: 1. When it thinks DCS is running it locks off the app from running DCS.exe again - rendering the app dead as a launcher 2. Force terminating the ghost dcs process via the app results in a JIT script crash 3. Restarting the app has no effect, this is cached for some reason and doesn't clear off. The problem is really no.3 because it prevents working around the problem. I'm not sure how or why the process is detected as running when it is not, the process and pid are tracked perfectly in WIndows, a simple query will never give a ghost result, so it just needs some tweaking here. Otherwise.. couldnt live without it. Thanks.

I found http://www.spitfireperformance.com/spitfire-IX.html which probably gives the answers but doesn't help me understand the physics and the why.

It's not often I ever needed to go high, but I am struggling to find out where the Spirtfires 'happy altitude' is. I know that altitudes depend on pressure, high level winds and such but generally higher is better for jets. Props are a tad more complex, so where is the Spitfire mk9's cruising best performing altitude? I read that the LF.IX was 404 m.p.h. at 21,000 ft. and this was the altitude at which it's top speed was at that day. Does this mean 21,000ft is also a good goal for cruise? Just to be clear, the purpose would be distance and speed rather than fuel performance but if someone could provide one answer for distance and loiter/fuel it would help me also to understand.

For those of you Mudhen lovers that only want it and don't care about other things..."Todays Harrier is tomorrows Mudhen". If RB do not give the complexity of the AV-8B serious time and effort it spells disaster for something as complex as an F-15E. That they care about it, is by far the most important message in this post, whether it addresses all the points raised by the EA purchasers or not, it does at least give the TPOD a good going over which was a primary concern. Thanks for the update.

We've seen this for the last 9 months by reproducing with MOOSE GCICAP type scripts which make heavy usage of "RADIO" altitude. It's often easy to get this to happen via scripting. I've no idea why RADIO is even useful at high altitude, it should probably be deprecated as it causes problems that will cause AI to stop responding to instruction, get pegged at 30 degrees AoA and climb slightly until runnning out of fuel. Really the AI should be refactored to use "RADIO" (AGL) when flying very low and "BARO" when their line of sight is unobscured. AI still avoid terrain, its really only useful for getting helicopters to go down into valleys and fly noe, that's it.

Create a new thread sir. Your issue is not related to this one which has long been fixed.

With two F-4, with AIM7 and AIM9M head to head 20nm both with CAP task primary and RETURN FIRE ONLY as second task in adv wp actions, neither of them shoot (as expected) As soon as I removed the return fire from one of them, it shot and the other responded. Seems to work as expected?

42VFG is now expanding to the WW2 arena. We are regularly having fun with the Spitfire on the Channel map, with the assets pack. WW2 is making leaps and bounds recently, if you haven't checked it out in a while, now is the time! Our WW2 stuff is less process oriented and less hardcore. However, when revisiting WW2 we steal something from modern processes, like AREO calls and good solid brevity which translates back and forth very well. But it doesnt mean we don't sometimes lean out of the cockpit in VR, into the slipstream and try to shout over the wind... ok?! :) (We fly throughout the week, casually but aim to do an organised session on Saturday nights)

http://www.atlantikwall.co.uk/atlantikwall/fpc_gris_nez_luftwaffe_audembert.php Audembert was the closest airfield and home of JG2 for a bit. I think the Channel DLC map is missing this and it's also quite relevant to the map.