Jump to content

Super Grover

3rd Party Developers
  • Posts

    200
  • Joined

  • Last visited

Everything posted by Super Grover

  1. It's a perfect exercise for orbiting without masking the pod
  2. 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?
  3. 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.
  4. 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
  5. 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.
  6. To confirm QEYEBALLS or Direct Head Control, press the key you normally use to display/select Jester Menu.
  7. 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
  8. 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.
  9. 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".
  10. 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.
  11. That is very suspicious behaviour. I'm putting it at the top of my priorities list after we release the upcoming update.
  12. 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.
  13. 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.
  14. 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
  15. Yes, a different software version (newer). The same applies to the mini-compass symbol in the upper right corner.
  16. Noted. I'll take a look at the code and get back to you.
  17. This is an interesting observation, and it suggests that Jester may be taking some shortcuts and skip some buttons. So I'll talk to him and instruct him to be more careful. Thank you.
  18. The issue has been mentioned already, but I couldn't reproduce it during my tests. However, the observations from the previous discussion suggested that Jester input correct coordinates, and it was confirmed by observing the TID repeater. So I suspect that it's rather an issue with the INS and the alignment or malfunction. I can't confirm that it's a bug at this stage, but I'd greatly appreciate more reports and as detailed as possible.
  19. I would say that it's not that easy . So I agree with you on most of the things you mentioned, but there are some limitations to the available information during spawning. Nevertheless, we will see what we can do with that and maybe we will find a clever way. I'll keep you updated, but, as I mentioned before, it may take a while.
  20. Hey PSYKOnz, Thanks for the suggestion. I can't promise anything now, especially on the time estimates, but I added it to our internal tracker backlog, and we will check if we can add a wing sweep override option to the mission editor options.
  21. Yes, the RWR is 'stabilised' by the INS, and should automatically switch from the IMU to the AHRS when the IMU fails. This uses only the angular part of the INS, so the alignment quality shouldn't affect it that much, as long as the pitch ladder looks ok and the heading isn't completely wrong. I remember I tested the RWR against the INS failures and they worked but it was long ago , so I'll check it again. However, depending on the geometrical situation, under certain circumstances, some threats appearing at unexpected angles can be normal and not a bug.
  22. Again, thank you, everyone, for your contribution to fixing this bug. I can confirm that we have found the source of the freezes, and it's fixed now. It should be included in one of the next updates.
  23. Thank you for all your reports. I'll take a look, and I'll keep you updated on the progress on this issue.
×
×
  • Create New...