Jump to content

Flagrum

Members
  • Posts

    6777
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Flagrum

  1. Thanks, Snoopy! Well, I guess that makes a lot of sense - so you can configure the weapon on ground and basically any aircraft capable of dropping MK-82s can employ it. And on the other hand, a more modern platform, can used it in a more flexible way.
  2. Hrmm ... what are those three pins at the top of the seeker, labeled 1 - 2 - 3? Some sort of rotary dials? But there are now windows to display the actual value that you have "dialled in"?
  3. "It is related to waypoint editind via EHSD and TDC, it may be related to TDC in INS mode so it does affect also TPOD when in INS... " I agree. In my case, when I thought I would move the IRMAV reticle, I had to undesignate my TPOD target and thus was in EHSD INS mode (which I failed to recognise). Instead of slewing the IRMAV seeker, I was slewing the INS cursor and the IRMAV was just slaved to it. The culprit is the EHSD.
  4. For conventional LGBs, the laser code is set mechanically on the ground directly at the guidance kit. The setting of the code in the A-10C SMS is only meant to be "informational" for the system - it would in reality not change the code of the bomb itself. But for practical reasons, in DCS it actually does change the code the bomb will look for. But how about the GBU-54 LJDAM? As it is also a JDAM and as such it already has a data connection to the aircraft to receive the target coordinates. But will that also allow it to change the laser code electronically "on the fly" (literally)? I.e. will changing the code in the SMS actually change the code of the bomb in RL? Or is that, too, just a "gamification" like it is done for the conventional LGBs?
  5. I was made aware that I made an error here - instead of slewing the IRMAV, I was in INS mode and was moving the INS cursor on the EHSD. Seems to have nothing to do with the IRMAV, but rather seems to be just another manifestation of the bug that Kappa reported here:
  6. Yes, thank you very much, that work for me as well. It's been a while since I more seriously fiddled around with the Harrier - so yes, this was an user error. The IRMAV seems to be ok! But regarding INS - then the behaviour I observed was more likely a direct result of the bug that @Kappa had reported, right? Something with the TDC and the EHDS/INS seems off.
  7. I would not be surprised, if these bugs might be related: @Hornet81, maybe you can have a look at those as well? ty!
  8. Not sure, if I saw this also with the TPOD, but for the IRMAV there is some strange slewing behaviour: instead of slewing vertically, it slews diagonally. If your pipper is right at the nose of the aircraft and you slew it exactly vertically, it does not deviate from it's horizontal position. But if you start with a pipper some degrees left or right of the center line, the pipper will slew diagonally. So for example, if the pipper is i.e. 5° off to the left at the top of the HUD, it will end up something like 10° off to the left at the bottom of the HUD. The screenshot will illustrate this better: I have overlayed the position of the pipper in one picture, showing the positions on the top of the HUD and, after slewing exatly vertically, at the bottom of the HUD. It looks like the slewing considers one point in front of the nose of the aircraft (that it seems to be at the horizon might be just a coincidence?) as some sort of point-of-origin for the concept of "top" or "upwards". Strange. EDIT: I also just noticed, that the horizontal slewing is also affected in some way. If the aircraft is banked to one side, horizontal slewing causes the pipper to move always parallel to the horizon! Example: bank 90 °, the horizon is now vertically in your field of view. Slewing the pipper left and right makes the pipper go up and down on the hud, parallel to the horizon! Slewing up and down then also makes the pipper move vertically on the HUD. The difference is the slewing speed (see my other bug report). While slewing up/down is considered as farther away/closer nearby, the slew rate increases. But slewing left/right causes the pipper to move with a constant speed ...
  9. When slewing the IRMAV seeker, the slew rate is depending on where the seeker is looking at. The farther away, the slower the slew rate. If you are looking at a point close by, the slew rate is very high and it is impossible to be precise - even with an minimal axis saturation (like 10% my case). On the other hand, if you are looking somewhere far out, near the horizon, the slew rate is very low. The closer you are to the ground the more pronounced the effect is. Seems to me as if the slew rate is directly depending on the absolute distance between aircraft and the point on the ground that you are looking at. The slew rate in degrees per second should not change, right? So the distance traveled by the pipper over ground per second would increase farther out, but the distance traveled by the pipper on the MFD or HUD per second should be constant. Also the horizontal slew rate is higher than the vertical one, which makes slewing even more inprecise. You will notice that in the video feed, but the IRMAV pipper on the HUD demonstrates the difference really well. IRMV slew.trk
  10. Which trimmer mode do you guys have configured under special options? And do you have FFB enabled or disabled under general settings?
  11. Flagrum

    VR BUGS

    How is all this "Community News"? o.O
  12. p. 85/86, copy&paste error:
  13. Yes, thank you! And yes, you were right, I was using "Enable Action / No Action = Yes". This probably confused me the most as I was used to the "gamey" TDC when I last fiddled around with the Harrier a few months ago. Now, after a couple of hours, I seem to get the hang of it again. Still had some situations with what I would consider unintuitive behaviour, but at least it seemed to be more consistent.
  14. If TDC is assigned to HUD, the slew rate of the HUD reticle is ok vertically, but horizontally it is 2-3 times the rate as vertically. (Yes, my TDC X and Y axis are set up identically) Why?
  15. SSS Fwd --> TDC->HUD Designate spot under velocity vector with TDC Depr. Slew HUD reticle SSS Aft --> TDC->DMT/TV, HUD reticle changes to DMT rectangular reticle Slew DMT reticle, but when I let go of TDC slew axis, the reticle jumps back to the point where I had slewn the HUD reticle to, right before SSS Aft. Why?
  16. Since the most glaring problems now seem to be gone(ish), I figgured that I'll give it another try. And yes, I try to do baby steps... So Lesson One: switch TDC between HUD and DMT. Situation: directly after Master Arm: on and A/G: on. Left MFD=EHSD, right MFD=EW SSS Aft --> DMT/LST SSS Aft again --> DMT/TV TDC: slews DMT/TV reticle. Cool. now SSS Fwd to assign TDC to HUD: DMT goes to DMT/INS, no TDC slewing of DMT reticle possible, no reticle in HUD, *confused* SSS Aft --> DMT/LST SSS Aft --> DMT/TV, but it looks at god knows what. My attempt to slew something while in HUD seems to have moved the invisible reticle to somwhere in the sky. Now back in DMT/TV I can't seem to move it anywhere else. UNDESIGNATE: DMT/TV slews to velocity marker Not. Intuitive. edit: ok, I learned something now. At step 4, the missing reticle in the HUD - I have to designate a target with the velocity vector. Then I get the reticle and the DMT is slaved to it. From there I can toggle the TDC assignment between HUD and DMT with SSS Fwd. and Aft. So, ok, cool! Now I can even Undesignate and still get the TDC slewable reticle in the HUD after SSS Fwd - even if I unbox the EHSD DESG. Why the difference between "before any designateion" and "after an undesignated designation"!?
  17. There are several ways how I can designate a target and I can use severak sensors to do it. I am able to designate a tgt, but I am struggeling with the "workflow" - or rather the switching of different modes that happen if I switch between sensors. It seems to me, that if I designate a WP at the EHSD, the TPOD is slaved automatically to that designation. How can I now "sweeten" the designation? The TPOD always jumps back to the WP? And if I undesignate, then the aircraft switches to HUD designation? I don't know, I probably recall it wrong, but almost everything I try seems to result in inconsistent or at least unintuitive reactions of the systems. So, I'd love to have some sort schematics, a workflow chart of some sorts. Like, you start designating with this sensor. If you do that, these sensors will do so-and-so. Now you are in mode blabla and from here you can do this. Which components are affected (sensors, weapons) how, If I am in designation mode X with sensor Y. Which options does it then provide me to use other components with that designation? Does something like this exist?? Thanks, --Flag
  18. Also the special option works only when starting a new mission. If you respawn within a running mission, you always get the indicators, not matter what the special option says.
  19. I just found out, that RPG dudes shoot at helos now! This must be relatively new? I always wanted them to be a threat - thanks ED!
  20. @myHelljumper or @RAZBAM_ELMO Can someone of you guys please have a look at this? For months now people are raising concerns and provide evidence that the current implementation of this feature is in need of a rework, but it seems this completely slipped through Razbam's net. tl;dr: *bump*
  21. ... if it goes super sonic. ^^
  22. The new 3D Model for the Blackshark 3 seems to have functional avionics access panels on the fuselage. A few other aircraft have already something similar as well. It would be great, if those panes would be clickable if in F2 view (plus weight-on-wheels) and could be opened and closed by the user! That would allow - to some extend - to pretend that we virtual pilots perform a proper walkaround. Really nothing fancy in terms of simulating anything, just for the visuals experience. If there is already detailed 3D modelling present, why hide id 99% of the time behind closed access panels?
  23. Yes, perhaps. But different people might be, well, different. But whatever, lets just lock everything and eventually and finally get rid of one of DCS' best features - it's moddability (mod, as in modification/altering stuff).
  24. Yes, software runs on hardware and therefore if hardware fails, software is always involved in one way or the other. But it is the responsibility of the OS and it's drivers to allow access to the hardware within it's specifications. Regular applications like DCS have no real way to make the PC hardware work outside it's safe parameters - aside of user(admin!) errors and hardware issues.
×
×
  • Create New...