DD_Fenrir

No it doesn’t, particularly if you read back across the previous posts. Ironmike has said that the current random appearance of these Forge elements is a test bed only; eventually you will be able to define which forge elements appear in an individual jet by what skin is loaded, in the early stages at least, where the appearance or otherwise of various elements will be defined within the description.lua in the livery’s folder. This means that even if you download a skin that shows a load of forge elements you don’t like it will be a simple enough task to open the .lua up and edit some “1”s to “0”s or “True” to “False” entries (or vice-versa depending on your mood) and you are done. Whether there’s an interface in the ME or Specials tab in the options menu to override these settings is a reasonable question but in the greater scheme of things it’s not worth getting one’s underwear in a knot… also why it’s so important that you must be informed now and you can’t just wait and see how the implementation is handled when it gets here like the rest of us, is a feel the greater question.

Point 1 - it’s not about timescale it’s about man hours; a skyscraper will have a couple of hundred bodies working on it; a developer crew may have as few as 4 people in their team; maybe even only one. Point 2: for most of the 3rd Party developers, building DCS modules is not their day job/primary source of income. Most of these people are building these modules in the small hours after dinner or at weekends. That effectively halves the man-hours you can invest per week. Suddenly those timescales seem a lot more impressive.

The short sightedness of some commenters is surprising. Is a PC-9 getting me moist in anticipation? No, not really. However, we have another 3rd party developer interested in bringing content to DCS and using a trainer-light attack to cut their teeth with learning how to interact and integrate with the DCS code base. This is a tried and tested entry route for DCS developers; Aerges, M3 and India Foxt Echo have all done the same to provide themselves a solid understanding of how to simulate systems and flight models in relatively simple aircraft, then utilise this experience as a stepping stone to produce more complex combat aircraft thereafter. So, quit the petulant whining about useless aircraft and just be happy that we have yet another 3rd party interested in expanding the DCS meta and the potential that exists for what more they could bring in the future.

Thanks NL. Checking through my copy of Spit & Polish: RAF Polish Squadrons Fight Back from Chailey, Sussex in Support of the D-day Operations of 6th June 1944 I can find a single solitary photo: I suspect that's an Extra Over Blister. From what information I can glean there should be 4 total, each located at the 6. reference on the airfield plan; see marked version below. That seems to be it. Even the British ALGs were pretty spartan affairs. Accomodation was entirely tented. It must be remembered that these airfields, as well being places to help locate some of the vast number of air units a useful distance from France, were also being used to help acclimatise the tactical units of the RAF 2nd TAF and US 9th AF to the austere lifestyle they would have to come to expect post invasion, particularly those who may have, up until 1943-44 become accustomed to comfortable heated mess areas, warm brick billets and a cosy bar...

Note:

The version of the Mustang that comes free with DCS is a TP-51 - it has no armament. It's there to give you a taster of what the systems and flight modelling fidelity is like in DCS and to allow you to decide whether or not it's your cup of tea. If you want to be able to blow stuff up/shoot stuff down in a Mustang in DCS you'll have to purchase the DCS P-51D Mustang module: DCS: P-51D Mustang (digitalcombatsimulator.com) Regards Steam compatibility, I do not use DCS via Steam so I cannot be of any assistance in that, however it does appear to be listed as DLC for DCS: DCS: P-51D Mustang on Steam (steampowered.com)

Wow. Someone needs reminding of rule #1…

This is the point - he can't. The triggers he utilises are provided by ED, they are the that tools he is obliged to use and that he has zero quality control over. Yes, he uses them in some very clever and complicated ways to get outcomes some of us who do know the ME can only marvel at, but when he built the missions the triggers worked, otherwise he would not have released the missions. There is no way he can foresee what EDs updates bring in terms of breaking trigger logic. What you ask is impossible. Whist it is appropriate to highlight issues here for Baltic Dragon to be aware, you need to direct your grievances at ED in the appropriate forum: General Bugs - ED Forums (dcs.world)

Some screenies taken from a VF-103 Division BVR Timeline practise session:

This where most of the trouble starts in these forums; idle speculation can be amusing but too many seem to take that speculation and make it into an expectation; after a while this expectation conflates and in their mind becomes a promised feature - all in their own head. Why can't peeps just enjoy a nice surprise anymore?

I am tempted to agree with you on this aspect. You assume too much. I don't think I am entitled to a free H-Fi module; never have. I have always believed people should be paid for their hard work, if they wish to be. However, I proffered an opinion based on my experience where the 2-week demo angle has been an issue - not for me, but for fellow squad members. Many were intrigued by the graphics and gameplay of DCS yet intimidated by the apparent complexity of some of the hi-fi modules. The A-4 has proven to be an excellent balance of hi-fi systems modelling yet accessible enough to not be a turn off, and allowing more flexibilty of use and time accessibilty than the demo version of one of the payware modules allow. To top it all the A-4 is fun yet challenging and free - for that latter we are extrememely lucky that such a talented group of developers are willing to allow us to utilise their hard work without expecting reimbursement. What I am suggesting is that, given my experience, maybe DCS is missing a trick - especially given that some of those squad mates who initally would not give DCS a second look are actively considering a payware module, something that 2-3 years ago even I would have said they'd only be seen in DCS when Hell was getting the gritters out... I am certainly not demanding a freeware hi-fi module; but considering the demographic that DCS appeals to, a good majority of which is customers over 30, to truly get to grips with a hi-fi DCS module takes more than a handful of 2 hour sessions that some peoples real life allows.

Well I as a husband, father and holding down a 40+ hour a week career, don't have that luxury. Whatever planet you live on must be nice, but when you have responsibilties, that changes the meta considerably. Having them denounced as ridiculous doesn't make me wanna respect or like you very much either.

Horses for courses; for some time to dive into DCS is limited and a two week window barely scratches the surface. Something like the A-4 allows a longer period of acclimation to the DCS meta, plus whether full fidelity is right for you. In addition I would argue you have more time to realise the reward of getting to know a module, something that if you have a lot of other demands on your time, is difficult to accomplish in a 2 week period.

Ah, you’re one of the nuance = nonsense brigade; well then I’ll save my advice for those with the capacity to differentiate. Have fun being angry at everything that doesn’t fit a neat little binary category set!

Because you made a blanket generalisation that doesn't apply to all FFB users. I kind of have a right to do that in a public forum; you expressed your opinion - guess what! - I am allowed to express a counter opinion. Don't get pissy with me when your (very apparent) frustration needs to be directed at ED. No, I suggested a custom input curve that provides a compromise between getting a measure of controllability and delaying the tuck phenomenon to airspeed regions where it will still occur but, as you will not be in that region so often, presents less of an issue. I nowhere stated it was a cure and I certainly don't think that the force/trim model in DCS is helpful for FFB owners - I even started a thread here in an attempt to open dialogue with ED to get it changed but thus far no dice. No, they aren't because I took some time to investigate the issue and try and present to the community an interim band-aid to make the Mossie a little less intractable whilst trying to keep the tuck effect as far out of the general flying regime as possible. I tried to give advice to make the Mossie more accessible and enjoyable to a portion of the community that are adversely affected by the force/trim-FFB issue. So sorry my altruism isn't as wide ranging or officially ratified as you deem acceptable. I never claimed they should do. Given the wide range of physical controllers and their differing stick lengths, throws and displacements (that all effect this issue to varying degrees), there is no one size fits all solution or even mitigation. That's why I prefaced my description with the stick I run. The concept IS however a starting point. YMMV. I would have thought that was a given. Your posting history shows a great deal of this kind of irascible, prickly response to anyone who dares to disagree with you. It's a shame as it precludes constructive discourse. I for example, ordinarily would have asked what the Rhino was like as I have had an eye on getting one; if your tone was more agreeable I'd have even looked at suggestions as to how to improve the curve suggestion for your stick in an effort to nail down some settings that provide a better experience, not just for you but for the wider Rhino using community. However, right now, I think you can go swivel.

Wholeheartedly disagree. As an Microsoft Sidewinder FFB2 user, trying to fly the Mossie with no curves is unpleasant to say the least; all of the OPs original issues will be exacerbated. It is true that a conventional curve setting (15-25 range) can cause a mismatch between virtual stick force/trim and stick position that causes a nasty automatic tucking sensation as airspeed increases. However, the trick is to use a custom input in the curve setting to get a balance between controllability and moving the tucking phenomenom to further up the speed range: Go to your pitch curve input cell for your FFB stick, highlight it and select Axis Tune. In the pop up window, find the user curve box and tick it. You can then adjust the numbers manually. Use the following values: 0, 5, 10, 15, 20, 25, 30, 35, 56, 100 I find these the best compromise between controllability and moving the airspeed range at which the mismatch between the virtual stick force and the physical stick position becomes untenable. It will also still allow you to access the full range of the elevator on the ground or at very slow speeds. What seems to be the case is that the shallower that initial gradient the lower airspeed the trim tuck manifests. At these values it does not occur until we’ll above 300mph indicated, so be wary of it during shallow dive bomb or rocket attack profiles from several thousand feet, but it shouldn’t manifest during cruise or level bombing attacks.

Yeah, I should have said "active" rather than "operational". If the Cold War had gone hot and the Soviets got as far as Eastern France though, these would have been the only bases even vaguely able to support military aircraft.

Not having flown a real one I cannot authoratively corroborate; however more often than not the overriding concern is speed when designers are allowing for the size of control surface area in WW2 combat aircraft; larger vertical tail surfaces causes more drag, so the designers calculate the minimum vertical tail surface area to keep the aircraft just positively stable directionally. Else you are slowing the aircraft down. The Mossie is not unstable directionally; the wobble (actually called a phugoid and a realistic behaviour in any axis with low positive stability) dampens out after a time which indicates positive directional stabilty, just not a lot. However the designers may have chosen that as the compromise for the Mosquito to have the straight and level performance it exhibits. If you practise coordinating the rudder and aileron inputs in the right way then the slip and skid issues whilst rolling and turning are much mitigated and the aircraft naturally starts to feel more stable but it is tricky to time the rudder inputs correctly and make the correct amplitude (size of pedal dispalcement) to get it spot on.

@MAESTR0 Firstly, let me say thankyou for all your teams efforts - the general layouts of the airfields look pretty good and I can see the effort that has been invested to make the airfields less sterile. After a more detailed review, I do, however, have some concerns. 1. Many of your RAF fields have too many control towers. One was the norm. In some cases there were two where the airfield topography required it because of blindspots, or where one originally built was not up to the capacity required as the airfield expanded (which they often did as the war progressed). However, they were the exception, not the rule. From the screenshots provided, Tangmere, Ford and West Malling immediately jump out as being examples of where we have a surplus number of unprototypically placed Control Towers. If you would like information on where to accurately place control towers please PM me or @Fred901 as between us we have the data to help you get it right. 2. There should be no foliage (shrubs, bushes trees) within the perimeter track. This is an instruction laid down in Air Ministry Standards long before the war. It's just not a feature of Allied wartime airfields as they present a hazard to aircraft. Please omit them from Gravesend, Ford, Farnborough and Funtington. 3. There should be no concrete block paving on the runways/taxiways. Whilst large aircraft pans were certainly paved with large concrete blocks, taxiways and runways were not. Please adjust the runway/taxiway textures to reflect this at Tangmere and Farnborough. 4. There is a lack of dispersal points and blast pens on some of the large airfields. Tangmere and Ford had provision by 1944 to support 9-12 squadrons each of 18-20 aircraft - this needed a LOT of real estate dedicated towards parking spots for aircraft. These could be as simple as a small poured concrete circle, many of which were in evidence at these two airfields but are missing in your reproductions. So too the blast pens, these dating from pre-1940 and a very distinctive feature on many RAF airfields of the time. Please conside adding some of these in. All the above can be summarised in these annotated drawings of Ford and Tangmere respectively: The layout is 75% correct regards runways and taxiways but the areas where the hangars are is wrong by some margin. Also note the foliage and compared to period plans there's a dearth of places to park aircraft. Tangmere best displays the over-abundance of Control Towers and again, the lack of aircarft parking spots. 5. Incorrect hangar types. Please see my original post on this matter here. I do see a change has been made to the large hangar type being used throughout the RAF airfields from this: to this: But even this generic hangar looks little like any example on any British airfield. In addition, it's uselessly too tall! The only reason you'd have a hangar that high is because you were expecting to put a tricycle undercarriaged bomber sized aircraft with a very tall single tail in it, yet that framed glass full width transom window prevents any aircraft from utilising the height within - it doesn't make much sense. Please, please, PLEASE consider making an accurate 3D model of a single bay Belfast Truss instead; a 2 bay version is shown below: This would be FAR more prototypical for all the airfields shown and I wouldn't grumble if it appeared on other airfields in lieu of their actual hangar because at least it was of a period prototypical pattern.

What stick hardware you using crazyave?

Ah, well, if it helps some other neophyte F-14 driver then it’s done it’s job but, fair point, how you centre the T when there ain’t no T…

The inverted 'T' symbol that appears within your VDI when you have an STT lock. A dark green ASE (Allowbale Steering Error) circle is also generated behind the 'T' that changes size depending on range, target aspect, closure etc. Your best Pk with any given weapon will coincide when you fly to position the 'T' dead centre of the ASE circle; it will help you account for lead (yes A2A missiles benefit from lead also, not just guns) and imcrease the liklihood of your weapon hitting your target.

Trained - should fire too soon and basically track the target via it's sight, not applying any lead laterally or enough elevation to account for bullet drop over range with large CEP Average - should open fire at about the right range, applying some lead laterally and elevation to account for bullet drop over range but starts to correct the error as the engagement continues with moderate CEP Good - should open fire at the optimum range, applying correct lead laterally and correct elevation to account for bullet drop over range and corrects more quickly after the first burst with small CEP Excellent - should open fire at slightly within the optimum range, applying correct lead laterally and correct elevation to account for bullet drop over range and very small CEP

Because user choice is a thing. I may not want Wake Turbulence on as it negatively effects game performance on a mid level machine. I may not want icons forced off as I have issues with my sight due to my advancing years. There are umpteen different reasons. Now, I get where you are coming fom, it's gotta be frustrating that as a Mission Designer you spend hours and hours - and I know, believe me - crafting your mission to work in certain way and a user comes along and a) blows a lot of that hard work by switching off settngs that are designed to challenge them and b) then moans when a mission doesn't work the way it should because of a). However... They are ALLOWED to. When you put your mission up in public domain for public use you have automatically thrown away any right to dictate how people use it. The 'No force from mission, use mine' is simpy a shortcut anyway - any user can open the mission file in the ME and edit the difficulty options to their liking. The tick simply sidesteps the ME interface and allows people to run the mission at the settings they like best. There's no stopping this. There's no way you can police it. The only thing you can do is mitigate the complaints from people who do moan that the mission doesn't work properly after they've messed with it - put a disclaimer in the mission description warning users that your mission is designed to work and is best experienced with the difficulty settings as they come in the mission and that you as the mission designer will not be held responsible for any perceived lack of playability/functionality/entertainment that may occur should these settings be overridden.

As part of the startup routine in the F-14 you have to setup the ammo counter manually yourself; there’s ammo in the aircraft it’s just not automatically able to detect and display how much. There’s a small rotary knob below an ammo counter window on the far right side of the front instrument panel below the hook lever; set it to 670 and voila! If the gun still does not fire you forgot to switch your air source to both (right side of the cockpit by your thigh), and ensure you have selected gun on the weapon selector and that the Master Arm is on. F-14s never carried Maverick of Harpoon operationally but in reality were often called upon to strafe when they were the only asset in the AO able to respond in a timely manner.