AH_Solid_Snake

Once again, you're asserting something and not really backing it up? I'm sorry the analogy didn't land for you. This, this, and more this. If you really really want to get into the electronics of it you're correct the DAC step happened before the RWS returns were drawn to the TID, but now we're getting into programmable vs non-programmable electronics. While you're running in RWS mode you're right, there is a DAC step, but all of that is occuring in non-programmable fixed logic silicon. Again, based on iteration of previous designs this is a very well understood problem and accepting certain limitations with regards to the processing of that signal return we can get a pretty good result on the B-Scope. As GGTaros said, strictly this is where our gating comes in. We literally mean hardware encoded logic gates to process the input in near real time and then draw a dot on the B-Scope / TID. TWS takes all of that as an input to its algorithm where it will then lay on a TWS trackfile, so firstly, this is slower as generally before a trackfile is even shown to the TID it has to go through 2 passes to be considered valid and shown. Secondly because the TWS part is part of the software oriented programmable CPU this has to accept that we have a certain clock speed. In this way we are limited to 24 active tracks, both due to memory and process speed limitations. TWS is basically drawing an oval around the track (as i was trying to explain with the cells analogy earlier, hes in B1 right now, hes moving toward me and a bit to the right, we expect him in C2 on the next cycle). These track files are really pretty binary in their interpretation, there is something in gate B1, we expect to see something in C2 next time - if we do continue to build the same track, if not, attempt correlation (sources are debatable if this was possible with the AWG-9 and how rudimentary the implementation was). If correlation outright failed and nothing is where we expected it to be, dump the track. So yes, the TID is showing "digitized" information in all cases. However one is based on a very raw return and is updated as fast as the radar can do its bar scan. The other has had a lot more computations done on it. I should also point out that even with much more modern radars, well into the Allied Force / 1999 time period - it was still doctrine to use STT for attacks and was unusual to rely on TWS in the scenarios real life pilots found themselves in. And a lot of that is because TWS simply is not as reliable as other modules in DCS make it out to be.

The DDD will always show the unfiltered raw return from the "analog" part of the system which is a major reason the RIO is still in the back. Having a skilled operator makes all the difference with the AWG-9.

@xarann- im trying to figure out exactly what the question you're asking is, when people give you pointers to why it doesn't work the way you expect you don't seem to ask for clarification, you reject the answer and then repeat that TWS should be just as good as RWS? What are you basing that assumption on? To try again to boil it down, the radar in RWS mode can give pretty precise information on a given return, for example the antenna angle off the nose was 2 deg up, 4 deg left, with a time for return of 3s, that gives us a target on the scope at 20nm - all of that is precise and has almost no digital computer processing going on. The problem is the computer running this very first generation TWS implementation can't handle running the entire flow for up to 24 tracks in real time with that degree of precision, so a cheat is used. We introduce cells and we divide up our radar picture into blocks, looking kind of like a chessboard. Now we can make the math a little bit simpler (and therefore easier for our slow CPU to perform at the speed desired) but its kind of like playing the old battleships game. In pass 1 i saw a return in cell A1 going to my right and towards me, I assume next time the scan zone passes over this track it will have moved to cell B2 so i set a trackfile expecting to find a return in B2 next time we arrive there, if my guess was right I update my file and recompute my guess, now its coming head on so i expect to see it in B3 on the next pass, and so on and so on. By necessity these cells are large in comparison to the raw returns, so getting a single return in a cell can mean theres literally 1 target, or it can mean that there are really 2, we just cant break them out yet. As we close range eventually we will, and the single trackfile will be thrown away and 2 new trackfiles will be generated in adjacent cells.

Right now you'll need to tune it manually on your own TACAN panel, and make sure the TACAN selector is set to PLT not NFO. If you ask Jester he'll take over the TACAN then set his own panel to the right freq, but A/A mode. Flipping it back to PLT and T/R mode isn't enough, you'll need to add the freq by hand too.

Hold my beer. Worlds worst analogy coming in. If you're old enough to remember the first digital cameras then its a similar idea. The analog part of the system, for a camera the lens, for the radar the transmitter / receiver / logic gates is a very highly developed very good resolution system. The digital part is the camera sensor / computer processing the TWS tracks into trackfiles, which turns the very sharp analog image into a much blockier lower resolution image. Similarly to cameras the digital version is better, after its been developed and refined, but at least in the short term its actually worse in some respects than the analog system its replacing. In RWS the AWG-9 is just painting analog returns onto an analog display but because these are very high end very expensive systems you can actually make out the distinction between 2 very close together returns, thats not the computer doing it, its just your eye discerning a good display. TWS is different, here the raw returns aren't shown to the user but trackfiles are, and due to computing limitations of the time (remember the CPU in the F-14 would be beaten by your average calculator in the 1990s) the return is divided into what are called cells. To continue the analogy think of this as representing an image with only a limited number of pixels, say 200x200. In the F-14 those cells are much wider than later jets, from memory (and dont quote me on this) something close to 5 degrees and 1nm plus or minus. As the targets get closer and closer you can start to break those apart in terms of azimuth particularly, where you'll start to see 2 tracks, but fundamentally that's the problem. Digital processing with a generation 0 CPU.

Theres also the simple fact that the only input we’ve had on this topic from Victory205 was “center the T, precisely” If the missile immediately makes a hard turn away from the steering cue then either the symbology or missile is doing something wrong.

On a related note during recovery as they clear the deck AI F-14s will sweep their wings before the flaps retract, also going through the fuselage.

Against fighter type targets if you can find a loner I’d tend toward employing in STT, they will get a warning for sure. But if you were in good parameters kinetically then STT will hold the lock better. For me in TWS the weak link is the AWG-9 and lack of correlation.

It would be interesting to understand a little bit about the methodology or toolchain though. Does the DCS SDK allow the external flight model to be tested in a scripting harness, or is the flight model itself tested with fixed inputs against the baseline in some other tool, then exported for use in DCS. If it was the latter then you can introduce errors simply because the inputs can be off, just as an example OAT might introduce an error compared to the external tool.

I've had similar thoughts about the auto throttle, if a mechanism similar to force feedback was added, connecting a motor with a belt drive to the throttles - and something like DCS BIOS could output the current position. In principle at least I think you could push through the motor to drive the throttle to a new position when in manual, but for the auto throttle if you went hands off the belt and motor could drive the throttle grips just as they do in the real jet.

It was quickly superseded by NCTR. If there had been a shooting war between 1975-1990 you can be sure the TCS would have found its use as during that period to meet the VID criteria the USAF F15s were mounting rifle scopes to their HUD to convince themselves they’d get that ID remotely close to TCS ranges. By 1991 the APG-63 had NCTR which works from greater distances and at night and removes operator recognition problems from the loop. USAF successfully got the ROE updated such that NCTR was an acceptable element in the matrix, and the rest is history.

I think the ITAR requirement gets a little overstated sometimes. Items directly in the cockpit are essentially repeaters for the real little black boxes that are in the avionics bays. If Iran wanted to send spies to steal the backup attitude indicator from a museum it would feel like a pretty poor use of resources on their part.

Yes, I guess I wasn't being very specific. It's hard to keep track sometimes of what the current (accepted) limits of the sim are, vs whats considered a bug vs whats been reported but is hearsay etc. You're right that I've seen plenty of threads regarding MP net code, and guidance generally, and some changes around the Phoenix specifically. Just keeping up with the current state of the art and expectations can sometimes feel like a full time job. Hence every so often I'm just left going huh, theres a disconnect between what I'd expected of the 54 vs what I'm seeing.

I don't doubt any of your observations here - they're in line with my own thoughts of the current Phoenix. What it makes me wonder is - is there some issue with the drag computations on the 54 in game, or is the problem entirely a poor loft profile / late stage pursuit steering thats resulting in these types of ranges. Against fighters the weak link is the AWG-9 and the TWS implementation so ignoring that for a second bombers probably will be nearer 30k if we imagine the Soviet hoards approaching the CVBG, the closure rates and the available range aren't really in line with what I've read the requirements for the missile to be. If the test criteria included hitting low fliers and high fliers and shots out to 90nm all the chat (and my own experience) of Pk falling off a cliff beyond 45nm either a) the missile didn't meet the criteria - despite the much watched test shot videos b) the missile did but DCS has some combination of drag / guidance / loft issues c) ?

Random question but why specifically VF-154 in B models? Wouldn't the A be more appropriate?

Maybe check your throttle curves, at least with the TM WH "full" power before the detent is only about 90% in the sim without adjusting the curves.

Let me answer this question with two sides - I have a huge deal of personal admiration for Bio, Crunch, Victory, all F-14 pilots and RIOs. However theres not likely to be a completely clear cut answer here. For us armchair pilots its fortunate the navy does publish this type of training manual completely publicly. P-816 CV PROCEDURES So you can reference (at least for nuggets flying the T-45) what the Navy training is right now. And we can extrapolate that probably you train the same way you'll be expected to perform. But now we have 2 competing sources, and being armchair aviators thats our single biggest problem. We dont know, we didn't really do it. For Bio's story, even in a published book its not unheard of for a quickly typed error to go unnoticed. He could have meant 800ft 450kts (as far as I'm aware, the 800ft is non-negotiable, but the 450kts is a guideline...just make your pull work) and nobody caught the error. Perhaps in the 80s they did something slightly different, perhaps its different between what we can see for the T-45 and the F-14. All I can suggest is read as many primary sources (first hand accounts for events, written manuals and material from the time period for procedures) and "figure it out" for your own purposes.

I'd add the same for the current voice overs, particularly the "player" voice is very high pitched and quick tempo - its a real immersion killer. Persevering though as the missions you have are excellent, lots of stuff going on and decent variety. For other recommendations I'd say try to match aircraft side numbers a little better - its a bugbear of mine that the new ATC comms will correctly reflect side number, but that the defaults are numbers you'd never hear for a Navy jet, at least I never heard of 071 as a MODEX. On a related note it would be great if you shipped a couple of variations to the VF-24 skin so that not everyone is 201 uniformly, at least within own player flight or on deck at the same launch cycle. For the F-18 this is simpler as the skins will respect the programmed side number from the mission editor.

First holy crap that looks amazing. Second - holy crap thats eye wateringly expensive to print at shapeways. I was going to try other vendors but I cant find the download button from your screenshot.

The startup sequence with Jester could use an update for the A though. Im not aware of the TF30 having a secondary mode.

Although more related to TWS and the AWG-9 the most interesting utterance to me was when Crunch was discussing beaming the radar and how because it was so simplistic the radar would go “missed a frame there, oh there you are” which although anecdotal is the complete opposite of TWS correlation as in DCS right now. Its one of the harder problems to solve in a sim aiming for realism - finding hard documentation that proves the stories.

@Noctrachyes, I was in the pilot seat rather than RIO but the TID looked just like that and it usually is related to cranking for F-pole. I know TWS is sensitive to hard manuvering but I do think its got to be a bug for STT? How can you lose lock but also not lose lock in STT, if you go outside the antenna limit it should just drop back to RWS, not go into some kind of extrapolated guidance, especially when the AIM 54 cant go active when its been launched in PD-STT, there would be no value in the radar trying to keep tracking the missile on a non lofted trajectory towards nothing.

On a semi related note, I use the AIM-54 as a bigger fox-1 against fighters in PD-STT. Recently I noticed that I’ve started to get the correlation X over contacts while in STT. Anyone got a link for what that means? The lock isn’t broken and the target diamond is still in the HUD but it seems to contribute to misses in STT.

As a rule of thumb I’ve started to shoot AIM-54 below 20k in ACM only. The rather simple logic being that if its close enough for PAL then its got a chance to hit in the thick air and so long as guidance happens its active off the rail. Once the missile API / FM TWS priority are all a little closer to stable it would be good for the manual to be extended with some good information on employment of the weapons. Its got a lot of good info for how to work the system and get something fired, but not much in the way of expectation setting for ranges / performance/ good scenarios to give best chance of Pk.

Also if it helps the standard panel width is 5.25”