Golo

I have 2 notes about it (EDIT: Special note about it, I tested it on the ground, not sure if WOW plays role in that, I think not) 1) "When the wings are aft of 50 degrees, the flap handle is locked and will not move. This is obviously not the case for a PC controller, so you can move your physical controller, but the virtual flap handle visible in the simulator will not visibly move." This is not the case right now, flap handle still moves for me even with wing sweep past 50°. Its not a big deal imho, Ive considered writing it up as a bug report some time ago, but I decided against it after thinking about it. It would really only work if our devices were locked too, but it is not the case so you can lower your flap handle (physical) anyway and it will stay in whatever position you leave it and in game flaps will react accordingly when appropriate. I think, only solution here is proper discipline with physical flap device one have. I dont see this as a problem worth solving. 2) Currently in game, If wings are between 21° and 50° of sweep, upon lowering the flap handle main flaps will start to extend, wing will be commanded to 20° and aux. flaps will also extend. It should not be the case according to following: From 01-F14AAP-1 (01-F14AAA-1) 2.20.5.3 (2.19.2.4) Flap Wing Interlocks. The main flap and auxiliary flap commands are interlocked electrically and mechanically with the wing sweep to prevent flap fuselage interference. An electrical interlock in the CADC and a mechanical command in the wing-sweep control box prevent wing sweep aft of 22° with auxiliary flaps extended. In a similar manner, upon extension of the main flaps, the wings are electrically and mechanically limited to wing-sweep angles less than 50°. The FLAP handle is mechanically prevented from moving to the down position if wing position is aft of 50°. If flaps are lowered with wings between 21° and 50°, main flaps will extend but auxiliary flaps will remain retracted. I actually already posted it in a bug section while ago but I guess it got overlooked, might as well mention it again while we are on a subject of flaps functions.

As I understand it (and I might be wrong), they actually did not look at it based on my report, or very vaguely. That is the issue. And I do not p*ss on anyone, I reasonably criticise. You have a problem with that, fine, have one.

You mean if Victroy didnt back me up on this, you would just dismissed me (like you actually did, even tho there was a bug with it anyway) based on what? Because someone said/remembered it was like that? Did whoever told you that gave you some technical evidence backing up his case? If you get one sided/conflicting information you need to evaluate the evidence, and scientific studies strongly suggests that "eyewitness" evidence has tremendous fault rate. If your SMEs give you some clarifications, pointers, some corrections that somewhat logically correlates to hard evidence its one thing, this one was another from my point of view. Also dont forget that we users are your last line of defense against any kind of f-up you might put in, especially if the report against it has some kind of evidence and is logically sound. It should not be just dismissed because "this is not a bug as it's clearly an intentional change from our side" like @Naquaii stated. I would hope it would get looked at even without backing up from any SMEs. I hope Im wrong but Im starting to see change in your development attitude of becoming more like ED, less like the ones who developed this masterpiece and art of the software. If I make a bug report I very unusually take it lightly, and try to do my part of a research about the issue first so I dont present you with BS so I would like you to take them seriously. In the end if Im right about it - excellent, we get correctly functional airplane, if Im wrong about it - excellent, we get correctly functional airplane. I hope this is your attitude as well.

Im not saying it was used like that only that it is its functionality and is consistent with what is in NATOPS. Btw that is exactly how it worked up until now, consistently exactly how it is in NATOPS.

It may be intentional, but it does not behave like its written in NATOPS. There is specifically stated in NATOPS that only aux flaps are two positional, not the main flaps. Are you sure you were talking about main flaps too and not just aux ones? Well, with that aside there is still a bug however you look at it. Because right now all flaps will begin to lower only after flap handle is all the way down position, which is clearly incorrect, because aux flaps (specifically noted in NATOPS) should extend down with just over 5° deflection of the flap handle from up position. And same up with deflection 5° or less from up, as I actually wrote above if you didnt catch that. Let me get on without explicit evidence a little. Lets assume that aux flaps are controlled by some kind of end switch in UP position of flap handle. In that case with flap handle up switch would be UP state, and aux flaps would be commanded up. With lowering the flap handle more than 5° from up position that switch would activate to DN state sending hydraulic power to the hydr. motor to lower the flaps. When raising the flap handle to position 5° or less from up the switch would get commanded to UP state sending hydr. power to hydr. motor to raise the aux flaps. It basically work as a two state piston, because we know that it cannot be in any intermediary position (not counting failures). We also know that main flap hydraulic motor can operate such that it can set main flaps to various positions with use of maneuver flap switch (and automatically by CADC). I see no logical reason why it would work differently with flap handle. Further more, I ask you on data as in witch position will main flaps start to lower when moving flap handle down, there in no data I know of that specifically states it. Did you just arbitrary chose down most position of flap handle, should it not move with aux flaps? Its moving with aux flaps now but its clearly bugged as it does not move with 5° down deflection of flap handle, or did your SMEs tell you its wrong in NATOPS too? Let me just say for the record that in this case I belive in what is in NATOPS more that your SMEs, because its function is more logical for me that way. So far Ive been nothing but impressed with your work on F-14, but this time I would like to challenge you present any kind of hard evidence not just what your SMEs remember. There has to be technical documentation that you or your SMEs have that explains the flap system. Let me also say that I will be more than happy to accept the change if you present that evidence, Im not buying this function otherwise. Well nothing I can really do about it, but hope you will.

So, here is my write up regarding the latest change in flap operation. Current in game operation: If flap handle is all the way up flap are retracted. When lowering the flap handle nothing happens until flap handle in all the way down position, at that moment both main and aux flaps will start to extend to full down position. From there if flap handle is raised all to the way up position at that moment both main and aux flaps will start to retract to full up position. That is incorrect operation, because of the following: From NATOPS FLIGHT MANUAL, NAVAIR 01-F14AAP-1, 1 AUGUST 2001, for F-14B NAVAIR 01-F14AAA-1, 15 MAY 1995, (Change 1, 1 February 1997), for F-14A 2.20.5.1 Normal Operation. (2.19.2.1 Normal Operation, For F-14A) The main flap and slat portion of the high-lift system is positioned with a dual redundant hydromechanical servo loop in response to the FLAP handle command. The auxiliary flap is a two-position control surface powered by the combined hydraulic system. With the FLAP handle exceeding 5° deflection, the auxiliary flaps fully extend. Conversely, they retract for a FLAP handle position equal to or less than 5°. The torque of the flap and slat drive hydraulic motor is transmitted by flexible driveshafts to each wing. My note: NATOPS here refers only to aux flaps as a two position control surface, and extension of said aux flaps should happen when flap handle is deflected more than 5° from its up position, not then flap handle is all the way down. And for retraction it should happen when flap handle is at 5° or less from up position. Also there is nothing anywhere in NATOPS manual that I can find about main flaps being two position control surface, in fact to the contrary as shown further 15.7.2.1 Asymmetric Wing Sweep Acceptable for Landing. (15.5.2.1 Asymmetric Wing Sweep Acceptable for Landing, for F-14A) ... b. Flaps — Lower incrementally to 20° to 25°. ... Note The 25° flap position can established by first noting when the spoiler position indicators switch to the dropped position during flap extension. An uncommanded, but controllable, roll transient caused by spoiler gearing change will also occur. Upon observing either event, retract the flaps to just less than 25°. The roll transient will occur in the opposite direction as the flaps pass through 25°. Main flap extension without auxiliary flaps will require greater than normal aft stick trim. My note: keyword here is incrementally, and it can not be reference to maneuver flaps because they only go to 10°, with flap handle they to up to 35°. So that would indicate to me that the flap handle is indeed 2 positional switch, but only for aux flaps, and is in fact incremental for main flaps. Now in the name of the transparency I would like you to present your sources of binary operation of the F-14 flaps because to me its sound totally illogical, and I dont see any indication of that being the case in any of my material from F-14.

Well, stand by for my bug report.

I dont understand why would you do that HB. The flaps operated correctly before this change and now they are buged. Im gonna have to write it down in a bug section. But seriously what the hell?

Ive checked it. You are set correctly for it to work. In track Ive waited until you set your switches and VS, than waited for 1-2 tries of your attempts to engage. Than all I did was just take control and pressed my AP Ref. button, did not work right away I had to reset to 0 fpm VS, because there was a pitch up when I took control for whatever reason. Other that that it worked just fine. My one guess is there is something wrong with your AP Ref. button binding. My second one, are you trimmed to 0fmp or are you wrestling with the stick to keep it level? You should be trimmed.

Just tested it in A, works fine on my end. If you try again drop track file here, I will check it.

NATOPS says operation of MCB reduces thrust by aprox. 3000 lbs per engine on zone 5 takeoff. I think in dry thrust the MCB is inoperative. Now that is only from MCB which is from 7th stage compressor, there are 3 more air bleeds, from 9th, 12th and 16th stage which can be switched off. But If TF-30 is anything like engines I have experience with, MCB would have highest flow mass out the compressor, other bleeds would not help much for thrust gain, and disabling them is really stupid anyways. But in flight MCB would only help in higher AOA regime (as was said) and its not really wort decreasing engine stall margins especially in high AOA/Sideslip (BFM) situations.

Im pretty sure youtube had problem with one of the caution showed on mfd screen, wasnt it "WTF INTERLOCK"? Funny that one .

Well, there goes my wish for real pilots high performance jet like F-14 is, and not something in which I would described pilot as a "flight software operator". With that said I can see this as total hit for both TG and HB, hell I might even pick it up as a curiosity. All the best in the ongoing development process. But next one, next one will be F-4, for sure, it must be.....please .

Yes it works. You are overcomplicating this, just do it for tracks 1-6 and we are good for now. If you want to go more into it later fine, but I think 1-6 would be more than enough for majority of engagements.

Ok, this is what I dont understand. What is the reason behind surface clutter being so wide as to cover such a wide area? Is it from a wave speed? I think not. I will assume sea state with strong wind at about 25 knots, wave height about 4 m, with peak wave period of 5 seconds. That should give a wave velocity of about 4 knots (phase velocity around 8 knots). If radar is seeing that it should still fit in a narrow clutter band. Why exactly would PD radar mode with MLC off have such a hard time to group it in its rate band, and would spread it across the MLC range? If I turn MLC off to track airborne targets (even a beaming once with very low/no closure) it has no trouble whatsoever to rate group it. Also same thing about PD search with MLC off over land. There is again just a narrow clutter band, its given that land does not move at all, but if surface clutter should be spread out in rate, shouldnt ground clutter also behave same? Consider this discussion just academic, I dont really have any wish to engage surface targets in PD, im just interested in that radar function. Sorry to be such bother : ). And if it makes radar behave better (more correctly), then all the better.

@NaquaiiI started this topic as a continuation of a discussion we had about PD surface search. I didnt want to go so OT in that thread, but I at least think it should be looked at more. I did some further testing of a AWG-9 PD surface search feasibility. I acknowledge that AWG-9 wasnt designed in with such capacity and wasnt used as such, but I only care about what it actually can do not what it was designed to do. I also note that my understanding of radar function is just basic, I dont want to go into technical stuff, just look at it from logical and critical thinking standpoint. So, you said: "The difference is that in pulse doppler all surface/ground returns show up in the same rate location meaning that it should be much harder to see the ships. Currently there likely is too little clutter from water modelled but even if we increase it it would make much less difference in pulse than in PD, again becase it would all show up at the same rate. PD just shouldn't be good at looking at ground/surface targets and locking them in PD-STT should be nearly impossible due to the fact that the STT would not know what returns to focus on. My current thinking is to disable the ability for STT in PD against ground/surface targets as that shouldn't be a thing but in the end we might have a look at changing how the clutter looks at sea" Lets look at that. Im not going to argue about intensity of sea clutter since I have no experience with it, in my opinion it should be distinctly lower than returns from actual target, but for a sake of argument lets say its the same (as shown in my test futher). Im more interested in what you said here "all surface/ground returns show up in the same rate location". That is only true for sea clutter/stationary targets/or targets at speed but perpendicular to the radar. Then yes they would fall into the clutter band and would be indistinguishable from it. But any surface target at speed with its velocity vector pointing to/from the radar to certain offset would in fact fall out of the clutter band and could be easily identifiable (as shown in fig. 2). Speeds at which I was able to pick up targets from clutter is somewhere above 20knots difference to ownship (but, it is the fact that I knew what I was looking for). Anything around 30 knots difference is easily distinguishable, and anything above that (speedboats) Is just screaming Im here. Furthermore, I was able to easily lock the speedboats at 57knots even in heavy clutter I simulated by stationary ships (as shown in fig. 1). Confirmation if its actual target is made by referencing the target speed on TID which showed 57. Now I dont think it should be impossible to get PD STT lock on surface targets. When in DDD RDR mode, locking such fast moving surface contact, my range (velocity) gates were outside clutter band, so I dont see how it would present any problems to lock. Now, I didnt think about it and test it to turn F-14 into anti-ship platform. It really is of a questionable use, as it only works in perfect conditions that you cant expect to find during majority of times you would try to use it, but I think it is an interesting capability of a AWG-9 system. The surface clutter modeling should definitely be there, making your modelling of DCS AWG-9 even better, but if there isnt any technical radar stuff that would prevent it to operate like this, Im categorically against disabiling this capability just because it wasnt used like this. Fig. 1 - Ship without waypoints are stationary to simulate surface clutter, Ships with waypoints are moving at 27knots, 2 speedboats in the middle are moving at 57knots Fig. 2 - DDD image in PD search, As you can see you can clearly identify targets outside the clutter band in PD with MLC fitler off. Fig. 3 - Here I locked the speedboat moving toward me (north one at F10 map) at 57knots. Edit: Not sure why I posted it in bug section, but I guess no surface clutter could be considered a bug, so there.

Yes only negative pitch lines numbers have - signs, there should be no + sign for positive pitch numbers.

For the record Im against "just disabling it". If you can make see clutter a thing that is fine. From a little I know about a radar I know water likes to gobble up radar energy depending on wavelength probably. Also depending on a sea state and the type of surface target, if the reflection of the target is stronger than ambient clutter from sea you should still be able to pick up the the surface target from clutter. It would be cool if we could have various strengths of clutter depending on a sea state. Also how is PD search with MLC OFF different from pulse search, that using PD should not be a thing? If you should get surface clutter in PD with MLC OFF you should also get in in P, so both should be useless in anything other than rudimentary ground mapping. As I noted before I get NO clutter from sea surface whatsoever in both P and PD with MLC OFF.

OK, let me ask you this one time, who is your daddy and.... wait no thats wrong. Have you ever seen radar reflection from the water surface in both P and PD? Because I have not. Ive seen ground reflection from ground in P and maybe some in PD, but definitely not from water surface. I guess we should, but isnt yet implemented? Because what I see right now is this.

I think if you sweep wing aft and hold stick where it is there should be no change in stick forces (?maybe?, hard to say in sim, as Ive never been in F-14), your nose is just going down. And if you let it, it should speed up and gradually pick its nose back up to level flight with same stick position. Anyway Ive never have any trouble keeping in formation during commence from pos.3 in stack 1, we just called ready wings back, now. And there really wasnt any problems keeping in formation during wing sweep. More problematic was actually keeping formation during acceleration from stack 250kias to initial 400kias during the turn.

That is not true, is it? If you fly level wing forward and sweep wing aft, your CL will shift aft and you are going to need more hor. stab deflection (pull the stick aft) to maintain level flight at increased AOA.

As I understand it during IRL, cyclic ops, daylight VMC (CASE I) there should be no communication at all past initial inbound call (Marking mom). You should have your marshal altitude (stack) already assigned, you have baro, BRC, and Charlie time from mother. Nothing else is required and unless there is a safety of flight issue its zip-lip all the way to the deck. Once you are in the groove LSO should flash cut lights once to acknowledge implied ball call (no ball call is actually made), and maybe give you some correction in the groove, thats it. Things are different and there is lot more talking during CASE II, III, and CQs tho. Edit: There are great docs about carrier operations here -

Cant AWG-9 track and lock surface contacts in PD with MLC switched off? If I remember correctly, one time we were on CAP/RECON mission and my RIO located enemy carrier group that way.

Its pretty important for naval aviation, visuals in DCS are not that great to begin with, so every little improvement is great for visual lineup during CASE I, II. So take your argument and get lost.

Testing right now in A. If you have any single SAS switch OFF before switching autopilot then autopilot will not function at all. But if you switch autopilot first (by setting mode and AP engage) and then switch SAS OFF then autopilot will still engage on AP ref press/stay engaged.