Super Grover

Thank you for the report. This has been fixed internally and should be distributed in the next patch.

Interesting. Was it single player or multi? Land or carrier? If carrier, did you tune the data link to the carrier? If you have the mission, could you share it so I can try reproducing it?

I'm sorry, I must have missed that when quoting the messages to respond, but I clearly remember I wanted to answer this. That sounds like a good idea. I may add a bit of dead zone at the edge to get the full rate if you want, but make the rates zero outside of the circle. Adding it to ma todo list.

This is an intriguing idea. Unfortunately, it would require some additional logic for spotting, and some time to code, so it won't be a top priority, but I'll put it in the backlog, and we may address it at some point, but I can't promise anything.

It looks very close (minus rounding) to the first line (RAMP). I think that in your case, Jester was entering the HB waypoint coords. However, there is no indication of which waypoint is being edited, so it might have looked as if he had entered your own position. Was the INS working correctly after the alignment was complete?

Thank you for the report. I'll pass it to Jester, and I'll make sure he understands how important for LANTIRN operations it is to enter waypoint altitude.

There has been some good question, useful suggestions and bug reports in this threat, so please allow me to answer them all in one post. This may form some kind of FAQ Oh, and again, thank you, everyone, for your feedback and all comments. Yes, it's a good idea to let Jester finish slewing the pod to the desired location before using a search command as his default behaviour is to consider what is under the cross to be the search centre. Jester automatically designates the targets he finds after using search command if they are in laser range. He should also automatically track those targets and use all modes to do it efficiently: AREA, POINT and QDES (although he uses this one mostly to recentre on the target after heavy manoeuvring). Manual QDES is not necessary and usually would result in worse results as selecting QDES will stop following the target. Finally, using QWP undesignates (LANTIRN feature not Jester) so you will be unable to use QDES. Since this can be confusing, QDES will be available from the Q modes menu only when a valid designated point is available. LANTIRN is unable to spot other lasers, sorry. That was how we taught Jester - always follow the circle and it worked like that in our tests. I'll investigate it since your observations suggest a bug. Could you describe your procedure of using QEYEBALLS more precisely? This seems to be a bug because the relative location of the dot is exactly the input that we send to the LANTIRN pod. Could you give us more details which would be helpful in reproducing this behaviour? I couldn't find in all available documentation any hint suggesting that the LANTIRN pod contained ballistic data for non-guided bombs so only the laser guided bombs are supported. I suppose the issue is that the circles are displayed as if they were very far from you while the VDI display is quite close. I'll see if we can attach the circle to a physical position in the cockpit for the VR users. That's a bug, and the fix is already uploaded to ED. Apparently, Jester thought that all static aircraft are dead. I'm dead serious. Just use the option to deactivate Jester from the menu, submenu "crew contract". However, there is a bug in the current version which makes Jester unable to wake up from his nap. The bug has been fixed already and the patch is uploaded to ED. When launching hot (either air or ground start), the pod is ready to go and aligned. If you use a cold start slot, Jester will switch the pod to on as a part of the startup procedure. However, we missed one scenario where you hot stat on the ground but then rearm. In such a case Jester did nothing until he was asked to switch to A/G. After your reports, we implemented new behaviour. Jester will turn the pod on always when the aircraft is on the ground and running, which should cover the rearm situations. Also, if you rearm within 4 minutes from hot spawning, the pod should be already aligned and cooled down, as if it had been installed when you entered the aircraft. We hope that should help in typical multiplayer scenarios where you rearm after getting into the aircraft. That's a very good suggestion and we've been thinking about it. However, we didn't want to change the default behaviour of the A/G mode for those who had started using the F-14 as in the Bombcat role long before the release of the update. Depending on the feedback and future testing, we may add Jester selecting the bombs automatically if only one bomb type is loaded. If the marker is too far away, LANTIRN may not enter the AREA mode. Jester has a time limit to enter a mode in which the pod will track the point itself. When that limit is hit, he'll just assume that it's impossible to track the point. We may want to add a voice feedback when such situation happens. Unfortunately, he is unable to track structures unless they are placed as static objects in the mission. This is a design choice and it won't change. The pod is able to track any object. However, the abundance of the objects in the scenery would make searching for targets offering some reasonable return of interest for a GBU very tedious. Jester should stow the pod when you select the landing mode and lower the landing gear, or after you land. Actually, Jester lasers only when "laser always on" is selected. Normally, Jester uses auto-lasing offered by the pod. That's why you can see 'A' in front of the laser code on the display. Nevertheless, if you need longer lasing time, just ask Jester to lase constantly from the second page of the Jester LANTIRN menu. Jester loved his new skills so much that he doesn't want to share the LANTIRN stick any more. If you want to operate the pod yourself, you may want to disable Jester from the "crew contract" submenu. Jester, like any human, can memorise some things. For example, he memorises potential targets that he identifies when he looks at his display. Unfortunately, he likes to target first those objects which he spotted first. That's why you may see him moving away from the crosshair and picking other targets. We know how to fix this, and we prepared a dedicated class when we plan to teach Jester to move to the close target first. Unfortunately, this is not ready yet but should be available in November or December. Additionally, we plan to improve his search logic further. It's a challenging task because we can't analyse the video feed, and we need to emulate Jester vision using synthetic information about the objects inside the pod field of view. By construction, it can never be as realistic as you using the VDI, but our goal is to get as close as possible, and the initial release of Jester LANTIRN is only the first step of this process. I'm adding it to the TODO list. We should be able to ship it in November or December.

I checked it, and nothing has changed. So it's there, but you need to have this option selected in the special options menu: In this mode, your PTT keys work as the SRS PTT / Jester Menu buttons, unless you presss the comms menu key (default '\') before pressing a PTT button and then it should summon the built-in comms menu. It only works in this mode because otherwise pressing PTT would display both the ICS comms and the Jester menu dialog.

It used to work like that - on the release, the ICS PTT was indeed activating Jester menu. I'll investigate it.

It's a perfect exercise for orbiting without masking the pod

At this stage, if he has nothing else to do, Jester usually starts entering mission waypoints. Could you show the kneeboard page with the waypoints?

Setting IP parameters is not there yet. We replaced the option switching between CMPTR TGT and CMPTR PLT with a dedicated submenu with all delivery modes, as with LANTIRN, you can also use MANUAL. Unfortunately, I can't promise when Jester will be able to set the IP parameters.

Yes, he does. However, he only tries to engage it when the target is moving. The reason is that engaging POINT isn't always possible, and it's easier to lose POINT track than AREA track, and when losing POINT, the pod reverts to RATES. In other words, he uses POINT only when I, as your RIO, would use POINT

Actually, the "middle" zoom is called NARROW. http://www.heatblur.se/F-14Manual/general.html#description The highest zoom level is called EXPANDED, and it doesn't increase the quality of the image as it is only digital x2. Instead, it makes the FOV two times narrower and the pixels two times bigger, effectively reducing the vertical resolution to 128 pixels (256 in NARROW), and reducing pod slewing rates. Jester's eyes are 20/20, and his screen is pretty big, so he doesn't like using that EXPANDED view because he can see much more using NARROW.

To confirm QEYEBALLS or Direct Head Control, press the key you normally use to display/select Jester Menu.

I know that this is a workaround, and we will think about adding it to the RWR modes menu, but as a temporary solution, you may consider using the volume knob http://www.heatblur.se/F-14Manual/cockpit.html#volume-tacan-command-panel

Thank you very much

Thank you for the suggestion on Jester menu. We tried it, and it didn't pass the functional tests. I want to add that despite the option being called 'direct head control', it's still Jester controlling the pod. For example, you may notice that when "direct head control" is selected from the menu, the steering helpers sometimes don't appear immediately. This is because Jester may need to finish his current task and move his hand to the LANTIRN stick before you ask him to slew the pod. I'd call it the last resort mode when you need to target something very specific and not an object as the rest of the modes are more automatic and usually much more handful. Last but not least, using it is 100% optional, so if you find it spoiling your experience, you can choose from a variety of other modes. Nonetheless, I would ask you to avoid calling people who have different opinions on the simulation 'casual arcade players' as some may find it offensive.

The slew rate in that mode is limited to 25%, so its effectiveness is reduced to only small corrections. Our goal was very close to what Spurts summarised nicely in his comment: So we wanted to emulate you giving directions to Jester, like: "that tall building next to the crossroads", or "move it a bit down".

The shortest description would be: You tell Jester to move the sensor to an approximate location of the targets using existing waypoints, map markers or your head/view, and then you ask him to search for targets of a given type. You can also switch between different targets he finds with the pod. The rest is more or less automatic.

That is very suspicious behaviour. I'm putting it at the top of my priorities list after we release the upcoming update.

Ah yeah, I fixed it some time ago.

Thank you, Rikus, for your report. The behaviour that you described is not a bug. The AN/ALR-67 in its default mode hides all units identified as friendly emitters unless they would be categorised as critical threats. Critical threats are those emitters identified as engaging the aircraft (directing missiles) or preparing to engage (locking). The RWR has no meaning of knowing if your aircraft is the missile's target or if the SAM is attacking another target in your area. Finally, one should remember that blue on blue situations happen both in real life and in the sim, and the RWR should warn you when a friendly SAM engages you. If you have any other questions on the RWR, please let us know.

These are very interesting questions . The displacement gyroscope of the AHRS device A/A24G-39 has two acceleration sensors: fore/aft and turn. However, on the F-14, the turn sensor is not used. This looks like a serious design flaw, but in my sim tests where I flew with the debug displays, I noticed that the fore/aft sensor gate prevents the torquers from applying the corrections to the gyroscopes and the synchro even in turns (thank you, physics). Ofc very shallow turns or small pitch changes can result in introducing errors to the system. This isn't normal behaviour in a normal situation with all devices working correctly. However, recently, I discovered that a part of the HUD/VDI heading tape code got accidentally replaced with a very old code. So I corrected that, and the fix should be in the upcoming update. If you mean after landing, then it's a feature and not a bug, and simply the magnetic field from the carrier disturb the readings in COMP, while the gyros/synchro need some time to adjust.

I've checked the code against the documentation, and when in SLAVED, pressing the HDG KNOB slaves the synchro. However, synchronization cannot be accomplished if the F-14 is accelerating or decelerating by more than 75 knots per minute. This implies very stable flight conditions, so probably you were limited by that acceleration gate. I've also checked the +/- deflection of the needle, and indeed it looks to be wrong. I reversed it, and the needle should be fixed in the next update. Thank you for your feedback. Best regards grvr