KlarSnow

The DCS kneeboard has become much more useable over the last year or so since the introduction of resizing, moving it around and the ability to click on bookmarks. However there are still some significant things that could be done to make the kneeboard far far more functional. First, a scratchpad option. For starters this could simply be a text editor page that you can click and type whatever you want into, or even draw on with the mouse, would add a lot of common sense functionality and use for those that want it. The next step for the scratchpad would be the ability to get coordinates from other locations in the game copied to the kneeboard. For example to get the coordinates for a waypoint or target on the F10 map you could simply right click the map and “copy to scratchpad” and the coordinates of the cursor would be dumped into the scratchpad which can be viewed when you are back in the cockpit. This could also be a keyboard command. ideally this would be the correct format for the aircraft you are currently flying by default. However, other options would be when you right click the drop down menu options could include a coordinate type, before you copy it to clipboard (DDMMSS, DDMM.SS, MGRS, etc…). Or it could just match the coordinate type you have selected in the upper left of the F10 map. This feature would help IMMENSELY with mission planning, and entering coordinates because one of the biggest pains is getting things from the F10 map, and then you either have to write it down on a sheet of paper, or go back and forth as you enter it in to make sure you don’t mess it up. Finally this could also be applied to radio messages from AI unit. For example if a JTAC reads you the coordinates to a target, either through a key command, or perhaps just clicking on the message text, it would get highlighted and copied to the scratchpad, that way again, in game you can quickly copy important information passed from AI elements, that you can reference when inputting coordinates, waypoints, targets, etc… This could also apply to for example the Supercarrier giving you the Marshall stack and case 3 information. Or when you talk to a tanker and are trying to get its altitude/airspeed , etc. Finally a big issue with our kneeboard currently is twofold. First you have to manually page through every image and set your bookmarks, and they do not save between missions. Secondly, all of your pages are in one massive list that gets unwieldy as you add more and more useful information. My solution to this is simple, make the kneeboard able to display and interact with PDF’s using standard PDF, and PDF form functionality. This would enable users to create clickable kneeboard to quickly hop between relevant checklists, search through an entire manual for specific functionality issues, or even in game TOLD calculators on their kneeboard page using drop down menus and forms. I would also make it so that you can choose between several PDF’s in a folder, maybe using the tab system currently with a limit of say 10 files. This would allow logical file structures that can be brought up like for example, the planes manual as one PDF, the Instrument Approaches are a separate PDF, the player made checklist is a 3rd PDF… etc…. This would give players far far more flexibility and functionality in how hey use these products and open the door to some truly creative and immersive functionality.

The new Petrovich AI interface is great, an awesome and intuitive way to work through crew coord and complicated scenarios with simple hotas commands and not having to take your hands off the stick or throttle. Suggestion is to make the radio menu navigable in a similar up/down/left/right and context sensitive manner. Up/down would take you up and down in the list, right would select an option and left would go back a level of the menu. This way you could operate the radio menus completely with HOTAS, no need to reach up and hit the function keys on the keyboard. Another option for this that would really help is dual using a hat, for example when the radio menu is up, whatever controls you have assigned to it only perform the commands to the radio menu, and after the radio menu is closed, it reverts to its normal usage. An example of this is the A-10C’s 4 way radio switch on the throttle, if the radio menu is open, that switch could be mapped to navigate the menu, after the radio menu is closed, it goes back to normal functionality. Something that would also significantly help is context and frequency sensitivity. Only show receiver options in the menu that are on the frequency you are dialed to, for example. That way you do not have to sort through several options that will not respond to you. There are several other context sensitive things that could also be neat to see, for example if you are in air to air mode in a hornet, when you open the radio menu it has the declare, picture and bogey dope options up initially, instead of having to sort through the menu to find it. Similar to how once you talk to a tanker or the super carrier right now it keeps you in that context until you leave them. All of this should be an option on top of the current functionality. The current functionality is fine, and works, but I think adding additional options like this would make using this stuff much much easier.

The current manner of swapping controls between pilots by pressing “c” and then the pilot in command has to click an “allow” option is perfectly functional. However it is a bit cumbersome, in dual control aircraft there is normally a positive change of controls that can be initiated by either aircrew Pilot: “you have the aircraft” copilot: “I have the aircraft” usually a firm stick shake by the taker is used to positively confirm that they have the controls. now in DCS we have a lot of limitations with this, namely our controls are highly unlikely to be force feedback, much less both aircrew having force feedback,and you have the perpetual issue of people abusing the control swap in an online situation that needs to be considered. my suggestion is that the “take controls” ( C ) command becomes a generic context sensitive button that initiates and accepts the transfer no matter who starts it. And add an emergency “MY CONTROLS NOW” command, for emergencies when time may not allow or you may not want to permit the other player to have the option of relinquishing the controls. how this would work is if either player presses the “C” (take controls) command once, while in command of the aircraft controls, it immediately asks the other aircrew if they want the controls. The receiving player then just has to hit “C” (take controls) to acknowledge it and Immediately has control of the aircraft, this way a pilot and copilot can quickly with a simple hotas push (no need to click the current dialog box) swap controls back and forth. if you are not in command and you press the take controls command once, it should request the controls from the other player, which they can again acknowledge with a single press of the take controls command. for an emergency situation, a double press feature could be implemented. If either aircrew double taps the take control command within a second, the controls are immediately transferred to their station. Obviously this could lead to fighting over the controls, so in order to prevent that, disable the copilots ability to double tap and take command for an amount of time after the pilot emergency takes command, that way the pilot/whomever the aircraft “owner” or “commander” is always has the ability to override and take the aircraft back in an abuse or griefing situation. the normal single tap request and then acknowledge method should still work however during the pilots emergency command lockout of the copilot. This way if for example in a trainer, the copilot is flying, the pilot takes the aircraft briefly in an emergency, they can then immediately hand it back if desired. finally in cases of egregious abuse their should be a way for the aircraft commander to completely lock the other aircrew from the emergency command function. I’d recommend this be a long press of the “take controls” command by the aircraft commander, which then pops up a dialog they can click on to lock the other aircrew from performing the emergency command control. This way you can pass the controls if desired, with a standard request and acknowledge but they cannot take the controls from you without permission. Essentially pressing the button once should request or acknowledge control transfer. Pressing the button twice should immediately transfer controls to you. if the aircraft commander presses the button twice it prevents the other aircrew from doing the double button press for a set amount of time (30 seconds to a minute). if the aircraft commander long presses the button they have the ability to remove or enable the other aircrews double press action for the rest of the flight. Bit of a long explanation but I think this would be intuitive, cover most use cases, and be quick and easy with most hotas out there.

MIDS works just fine for transmitting voice, works like VOIP or any of your internet phones... its specifically built into the network to have this capability. Only some platforms have implemented it though. its one of the core features of MIDS even listed in a brief Wikipedia search https://en.m.wikipedia.org/wiki/Multifunctional_Information_Distribution_System J-voice, JTRS, Software Defined Radio etc... does not impact any other part of the network if designed to use it. The F-16 as used by the USAF does not have and should not in DCS have this functionality. It is and should be on the DCS Hornet though.

Make a ground crew request option to open/close the HAS/PAS/hangar/whatever doors. Then when a plane spawns in you can open em up or close them manually in case of any automatic weirdness. While at it, put some lighting on the inside so you can start up at night...

Uplooks are implemented but the central reticle is not the uplook reticle, the uplooks are little crosshairs that appear way up on the upper edge of the FOV on either side depending on which way you are looking. Think about where your eyebrow is, instead of where your nose is. Depending on your FOV setting you may be zoomed in just too far to see the uplooks. Try zooming out a bit and looking to either side. The only issue IIRC from when I was playing with these a while back is they do not blink when you exceed the AIM-9X’s field of regard with them, which can make it difficult to cue with. Other wise, the seeker of the AIM-9X cues to the uplook, and you can uncage the missile on a target when you hear a tone change. There is zero symbology (seeker circle or any kind of cueing) other than the crosshairs, so it can be rather hard to use unless you know what you are looking for. You can actually see the HUD AIM-9 Seeker circle pegged on the upper right corner of the HUD when you have your view roughly centered, it is pointing to the right uplook. The HMD’s AIM-9 Seeker circle stays centered in the HMD. All of this behavior is correct and accurate, other than the uplook reticles not blinking when you exceed the FOV of the AIM-9X.

MIDS voice and range is exactly the same limitations as MIDS itself. If you are in the link and somebody else is in the same link, and you both have MIDS Voice capabilities, you can talk to each other. It's basically VOIP, instead of a straight up radio system. If you and the listener are in the same MIDS network, you will be able to talk. It is used as a secure radio or a 3rd or 4th radio by Hornets and Superhornets all the time assuming they are in the link. Not unusual or special at all.

MIDS voice has nothing to do with the ARC-210, separate systems completely

Depending on which NITEHAWK pod, it also has separated functionality. ONe of the pods was just a Steerable FLIR camera, a separate pod added the laser designator and rangefinding capability. And A third pod would be the LST function... You would have to split all of that up between your flight/formation. Or possibly carry two pods.

Theres nothing "technically wrong" with having the M904/5 Fuze (old mechanical one in DCS right now) on the front of a JDAM, its just not done IRL cause thats an old fuze and would serve no real purpose than as a backup to the electronic programmable fuze that is in the tailkit, which already has a backup fuze setting in it that you set with a screwdriver in case the programmable part fails. The bulb nose with the DSU-33 would serve no purpose other than graphical in DCS until DCS starts to model other weaponeering and true programmable fuzes. We don't really have any of that right now so it doesnt really matter tbh. You can petition ED to make the different graphics all you want, sure it should have them at some point, but as of right now there would be no in game effect other than how it looks. Would be neat to have, doesnt really affect gameplay though so at least for me its not all that important (right now)

None of those are contact fuses, the fuse for a JDAM is actually in the tail kit, not the nose. The bottom picture is just a nose cap to help it penetrate “slightly” hardened structures, the middle one I’m not sure, other than it just looks again like a simple nose cap, the top one is a completely different fuse, probably a DSU-33 (proximity fuse). In all of these cases, its only graphical in DCS, right now none of these fuses or nose caps really matter.

If a single AIM-54 is launched at long range in TWS, you do not know if it was shot at you or your wingman. The issue here is that the AI knows its been targeted and fired upon immediately. If we are going with the logic of the AI can see the missile come off the rail, then EVERY AI the AWG-9 is illuminating that is "close enough" to see the launch should also IMMEDIATELY defend, not just the guy who is actually getting targeted. Either that or All of them should ignore it and continue in until the missile goes active, or some other defensive checkpoint.

So the most important thing in that list that I am fairly certain does not exist on the internet or in any form other than these archives is the F-105B-34-1 That manual is the unclassified manual on how the weapons systems, radar, any computed bombing modes, gunsights, etc... all work. That would be the first priority. Cause otherwise you have no real way of modeling those systems. After that the F-105D-1-1 (supplemental flight manual) is next, that appears to be for the thunderstick which is the F-105's Fire control system, I don't think there are ANY manuals for that out there. If its not that it is probably performance manuals, which would also be very helpful in developing a flight model. Finally the F-105B-1's (flight manuals) these will tell you how the jets systems work, but stop short at the weapons systems. There are a few of these for various era's of F-105 floating around on the internet that can probably be acquired cheaper/easier than this, off a quick google I can find F-105B,D, and F flight manuals. I have no way of knowing however if they are as complete as these manuals are, or if they match all the other dates and systems. But generally that stuff isnt going to change too terribly much. You'll have to ask a mod team or a dev team if that looks like it would be enough, but the -34-1, and the -1-1 are gonna be the finds out of that list if you can get ahold of them. The maintenance manuals it is very difficult to tell without opening them up if they would be useful or not. Some of them can have tons of information that is super relevant to a flight sim, or it might just tell you which panels and wires to take off to service system X. Not really a great way of knowing beforehand.

I agree, would be nice to have that, seeker active ranges for the missiles, RCS sizes and detect ranges for the radars etc... all in game of course not what they are IRL, so rather than digging through files to see how things work or taking 60 bazillion test shots, the data is all right there. Playing I have a secret with this stuff that you can derive just leads to spurious bug reports and endless accusations that something is not working "correctly" I don't really care how accurate or innacurate it is to the real thing, I more care about how it works in game.

80 seconds for both versions of the AMRAAM

Wait till you level out, in a bank it is unusable for any SA

No, that is theorycrafting from a video game perspective a feature that you wish you had so fratting in a video game wouldn't happen or so you'd have an option to be more carefree with your shots. IRL that is not how the thought process goes. It is hard enough to get the missile to get to the target on its own. The entire existence of the missile and the radar system is to get the missile to the target. The operator is supposed to be the QC that what they are shooting is the right thing, and then the missile gets there. There is no Abort missile option or thought process that goes into it. It doesn't exist on AMRAAM, it doesnt exist on sparrow, and it certainly didnt exist on the phoenix. if it was somethign they wanted, again with how complex this stuff and the mechanization is, they would not put it in some wierd use case scenario, it would just be an ABORT or SELF DESTRUCT button you could hit in the cockpit when your IFF return suddenly swapped. The solution to that problem is good employment, into a clear field of fire, not sloppy employment. Again this is not an issue nor a thing that aircrew have ever AFAIK wanted or asked for. The common perception that you can "safely" fire a SARH missile into situations where an active missile might grab onto a friendly is flat out wrong, and is a common thought because of how they are mechanized in DCS, IRL you still would not want to shoot a SARH missile into a merge or into the near proximity of friendlies, it has about as much of a chance of guiding on a friendly as an active missile would, if not more. Locks can swap targets when jets are in close proximity, the radar beam is not a laser beam, it will be illuminating multiple things in close proximity. Active missiles can in fact be safer to shoot into those situations. The fact that you can cut the lock is also a simplification, what happens if you drop lock in the tomcat? It goes to flood mode, and if they are in your HUD theres a decent chance that missile might still get guided into something you dont want.

Yeah when designing a weapon system like this the links in the chain and implementation are there to get the missile to the target. There is little or no consideration for what if you shot at the wrong thing. Thats on aircrew/tactics to perform their IFF/ROE stuff before they pull the trigger, and thats why they go through training. It is not a consideration in employment or design of real air to air missiles of what if I shot the wrong thing. You should have figured that out before you shot the missile. If trying to cancel a missile that was in the air was a consideration instead of all this wierd mechanical implementation, wouldn't they just put a giant ABORT MISSILE switch somewhere...... that doesnt exist on any of these systems... that should tell you that its not somethign they are "designed to do"

Command Inertial Active and Inertial Active is how the AMRAAM works, it is specific language to how the AMRAAM's operating concept works, it is not a term that is just thrown around.

I also do not disagree, but I also think that making distinctions like that in the absence of information are fine because again reasonable assumptions in the absence of hard data. It also serves the purpose from a game mechanics perspective of making the two missiles distinct and having separate capabilities and distinct advantages/disadvantages and employment considerations. To me thats more important in a game than just a different chaff value. I mean you could just implement it and say "These are our best assumptions based on the lack of hard data" caveat, that is essentially what you are also doing with the AIM-7 and the AIM-54A, or what ED is doing with any of the other missiles in the game, you just have more pieces of the puzzle available. Keep in mind I'm not knocking anybodies development or research into any of these weapons or how they are implemented. But it's a game with mechanics, and assumptions have to be made about important things that aren't known about every system that gets implemented.

Yup, that matches everything I've ever seen on the AIM-54C, which is that its more like an AMRAAM than not.

The overwhelming response if you ask any tomcat aircrew or read any reports about the difference is if you are given the choice between an AIM-54A of any flavor and an AIM-54C, throw the AIM-54A in the trash and go with the AIM-54C every single time. Unfortunately right now in DCS its just a pick between better kinematics (Mk60) or better Chaff resistance (AIM-54C). It should be a much more distinct difference than that, and making it operate like an AMRAAM instead of the rube goldberg device that the AIM-54A is would go a long ways to delineating that. Unfortunately as Naquii said there is no hard data, just reading between the lines and assumptions based on how other things work/worked. For example, there is no data on how an AIM-54C would behave in PD-STT, would it still operate as a SARH only missile? It still has all the same modes as the AIM-54A, how would you delineate or what settings would tell it what to do? Do I think if Heatblur wanted they could make reasonable assumptions as to functionality and implement a more distinct and in the process probably more "realistic" if not completely accurate version of the AIM-54C, yes I think they could. But thats their decision to make. And so far they have decided that that does not fit their development model, which is fine.

Best data out there on the 54C is that it adds a Command Inertial mode. No details on how that functions or what exactly that means. You could read between the lines because that is a completely different terminology than any of the AIM-54A's modes, and it also matches AMRAAM terminology (Command Inertial Active). The minimum you can draw from that along with the fact that the AIM-54C has a strap on IRU/INS type system is that it probly implemented some form of AMRAAM style command inertial guidance. How that functions with the AWG-9, what its limitations are, how it swaps between that and the other still available modes of the AIM-54 (nothing says any of the other guidance methods were removed) is unknown. Best source is the Forecast International report I've snipped out right here. If you google search AIM-54 Command Inertial, you should be able to find it.

Pre-Ordered 4 Dec 2020 Reciept from Virpil UAB on 18 Dec 2020 Order updated to complete on 30 Dec 2020 Fedex tracking number recieved 30 Dec 2020 Shipped to my door 4 Jan 2021 I have ordered several things from virpil, and especially with a preorder wait till you get the reciept/invoice, after that things move pretty quick.

in PD-STT it may continue to guide if you manage to relock the target in PD-STT. In TWS there is nothing to be done. go out, preserve range, recommit and shoot him again. To help minimize the track hold issue (which is far better than it used to be) After shooting descend below the target, that way the target can no longer notch your radar and cause a track hold/decorelation that way. May still happen, but it helps. Next if you are shooting into a complicated blob of targets it can also happen, you kinda just have to accept it. With a wingman, this is where you can either both double tap the same targets so if the track hold issue happens its less likely to affect both of you, or you can set up with one of you in trail so that if the first shooters shots get trashed by the track hold problem, then the guy in trail can shoot that guy again. As a single jet your options are much more limited in mitigating the weaknesses. About the only way you can actively help the decorelation problem is by setting the target size to large, this will make the missile go active sooner, which gives the track less time to mess something up. And descend below the targets altitude to minimize doppler notch problems. With any missile you only have so much control over what happens once the missile leaves the rail. you have to accept that and work the possibility of misses and failures into your tactics. There are ways to minimize or mitigate, but not ways to completely remove these weaknesses. You cannot expect to get a 100% successful missile on any particular shot, and have to account for that. I fully expect 50% of my BVR shots in DCS to fail, and build my tactics and techniques around that, so that a single missile missing doesn't result in either me getting hit or my wingman getting hit, and I give myself options. I may go out into the exact same scenario and run it over and over, first time every missile hits. reload the mission second time half my missiles hit, reload the mission 3rd time 1 of my missiles hit. My tactics and gameplan did not change between any of those, its just the luck of chaff, what exactly the bandit/bandits did after I pulled the trigger, and how well I executed and maintained my SA on what was happening.