Jump to content

Bog9y

Members
  • Posts

    571
  • Joined

  • Last visited

Posts posted by Bog9y

  1. Posting on behalf of a former AV-8B avionics engineer. 

    The fuel pump switches on the left console should always be left in the ON position. During the shutdown procedure you leave the pumps on (as per NATOPS pocket checklist NFM-500).  During our cold starts these switches are in OFF which is not how they would have been left from the previous flight. 

    Same with the AFT EQUIPMENT switch on the right console. This one should also stay in the ON position throughout flights, currently this is in the OFF position for cold starts. 

    It should be a fairly easy coding solution to have these switches in the correct position for a cold start. 

  2. Just to confirm, the abeam distance bug has not been fixed with the last patch. The abeam distance factor is actual double now from what it used to be. I suspect the coding line has added or subtracted the magnetic variation 2 times now. So if you want a course of 360 in Caucausus you have to add 12(ish) degrees to the course in order to get the correct abeam distance. 

    • Thanks 1
  3. 11 hours ago, BIGNEWY said:

    please include your track replay it allows us to test the same circumstances

    thanks

    I've had the same issue with HD bombs consistently landing long. My release parameters are 500 kts, 10 degr dive and release alt of around 1000-1200 ft (as per real life Z diagrams) and the bombs always land long by around 150-200 ft if in HD config.  I tried this in several modules and the results are the same. I have posted a bug report last week in the WEAPONS BUGS thread. 

  4. I was practicing dropping HD bombs at a bombing range with a scoring script and noticed that when you drop MK82AIR bombs in the HD configuration they always land long. My release parameters were:

    - 1200 ft release alt

    - 500 kts TAS

    - 10 degree dive

    Subsequently I also tested releases at lower altitudes and the bombs are much more accurate (ie not landing long) when you release around 500 ft. Changing the dive angle did not make a huge difference if the release alt is above 500 ft, they would still land long if the dive was steeper.

    I tested this mainly with the AV-8B but also with the A10C, F16 and F18, all had the same result so I suspect the bomb trajectory is suspect here. I wonder if maybe the retard chute deploys later than what the weapons (mission) computer uses to compute the trajectory? 

  5. On 1/24/2021 at 2:54 PM, Shiroka said:

    I had exactly this question today. I was using a WO/S from the IP (from the 9 line) to get close to the tgt (I've actually never used the O/S function before - it's awesome), JTAC lasing -> pick up with LST, then I hit DESG to get the HUD symbology up and ready to drop. Was worried it would designate the O/S as opposed to the lased target but it didn't so seems to be fine. That worked for me, if there is alternative way then keen to hear it!

    Sorry to bring up an old post but I've recently been looking into LST mode and bombing with it. The way I understand it from reading the TAC-000 manual is that when the LST captures the laser PRF (3 times) it locks onto it and automatically designates it then computes the bombing solution for AUTO mode. In DCS however I noticed that the LST picks up the laser designation but to get the bombing solution you have to press/release the TDC to get the bomb fall line to appear in AUTO mode.  i believe this may be a bug but want to do a bit of research first before I post it as a bug. 

    • Like 1
  6. Whilst learning A/G deliveries I noticed that I was always ending up steep on my bombing runs despite turning in at the correct distance.

     

    I did a bit of investigating and noticed that when you select A/G mode the range to the waypoint indication on the HUD changes from ground range (straight line from waypoint/target to position right under the aircraft) to slant range (straight line from waypoint/target to aircraft).

     

    I was told by Harrier pilots that this is incorrect and that the HUD range to the waypoint should be displayed in ground range in A/G mode like it is in NAV mode.  This will ensure that you turn in at the correct distance and not end up too close to the target and hence steep on the profile. 

  7. Here is the track file. 

     

    What you can see is that I have waypoint at a bearing of 067 at 84.7 nm.  

    When you select a course of 067 the course line should be close to my current position but it isn't, it says my abeam distance is 10 nm (south of my position). When you change the course to 074 the abeam distance is 0.3 nm (which is pretty accurate with a waypoint that far away). I change it back to 067 and it's 10 nm again. 

     

    So, what I think is going on here is that somehow magnetic variation needs to be added to the course line to get the correct abeam distance calculation to happen, this is not correct because the EHSD map is in magnetic. 

     

    CRS LINE.trk2

  8. 4 minutes ago, Ramsay said:

     

    Both Nevada (+12°E) and Caucasus (+6°E) have easterly magnetic variations, that is, in both regions a magnetic compass will point slightly West of true north and needs a +ve value added to it, to point to true north.

     

    MagVar = True - Magnetic

     

    i.e.

     

    • Batumi RWY 13 MagVar = 126°T - 120°M = +6°E

     

    • Nellis RWY 03R MagVar = 40°T - 28°M = +12°E

     

    The sign of MagVar is often confused in DCS as we often convert from the F10 map (True) to the cockpit (Magnetic) by subtracting the (positive) MagVar i.e.

     

    • Batumi RWY 13 Magnetic = True - MagVar = 126°T - (+6°E) = 126°T - 6° = 120°M

     

    With regards to the EHSD bug, it'd be useful if you could include a track demonstrating the problem. 

     

    Ah ok , my bad i assumed one of them was east, one of them was west, I'll amend my original post.  Still, it doesn't matter if it's east or west with this bug, the abeam distance on the course line will still be incorrect. I'll post a trackfile later today.  

  9. I noticed that the WRD page is missing from the STRS page. Not sure if this is a limitation of DCS or if it would be easy to implement but it would be a great feature to have for bombing runs. 

     

    The TACMAN-000 describes this page (page 370) at 1.14.5.3.11. It says that it shows the release data at pickle for a CCIP delivery and release data at the moment the release cue touches the velocity vector for an AUTO delivery.   Basically it should show the airspeed, altitude , flight path , normal acceleration (Gs?) , Time of flight, Steering error, Range X/Y, WIND X/Y.   

    It would be handy to have all this info if you are at a bombing range and want to assess your bombing parameters and how to amend the next run in. 

  10. A few months ago we had this bug and it was reported for both the TCN and WAYPOINT offsets. TCN offset seems to work correctly now since an update a few months ago.

     

    Waypoint offset- WO/S however is bugged, with this one you still need to add the MAG Variation to the bearing entered to get the correct offset location.

     

    If you are parked at a bearing of 180 degrees and at 20 nm from a waypoint and enter a bearing of 180 @ 20 nm and then select W/OS steering you will see that the w/OS will be 2.4 nm east of you. If you now add the MAG VAR to that bearing and type in a bearing of 186 (if in the Caucasus with mag var of 6 W) your w/os will be exactly where you are. 

     

     

  11. There seems to be a bug with the course line abeam distance. 

     

    It seems that the course line is based on TRUE heading not MAGNETIC in DCS, this is incorrect, it should be MAGNETIC.

     

    When you set a course of say 360 degrees , fly abeam it at say 5 nm on heading 360 or 180 degrees with no wind, you will notice that distance will increase/decrease gradually, even though you are flying exactly on a parallel heading as the course.  I noticed that if you add the magnetic variation to the course line on the EHSD you fix this problem. So for this example, if it's the Caucasus map (with mag var of 6 deg W) ,you make the course 006 , fly 360 or 180 degrees and your abeam distance will not change.  In Nevada you have to add 13 degrees to fix this bug.   

     

    Note, I only tested this with course lines from waypoints, not Tacans. 

     

    Note 2: In the past the UFC used to display the true track, this got changed to magnetic a few months ago but I think the fix is incorrect and has instead turned the EHSD course to TRUE and not both to MAGNETIC. So I believe both the UFC and EHSD are now showing TRUE.

    • Like 1
  12. I was checking out the PUC function and noticed that the symbology is wrong, it is identical to the reflected CCIP symbol, apparently (according to the RB Discord channel) it got changed in the last 12 months, it used to look as per the TACMAN. 

     

    I tested it's functionality and it seems to work but not exactly as it should. When the PUC approaches the VV and you initiate a 4G pull you will go below the entered ALT by around 500 ft on dives between 20 and 35ish degrees. If you dive with 45 degrees or more you will go below the PUC alt by around a 1000 ft.  This is not how it should work, according to TACMAN-000 if you pull 4Gs as the PUC approaches the VV you should not go below the entered PUC altitude.  Also, according to the manual this altitude should be a barometric altitude, not radar. 

    • Thanks 1
  13. 16 hours ago, Multiplayer team said:

    So finally Syria has also been updated to the new codebase that has been running on caucasus, and we have also basically reworked the whole mission. Apart from long distance runs you can now also do city missions in Beirut, Haifa and Asana.

     

    Cyprus is still in the works, but we did not want to keep you waiting longer with the syria update. If you have recommendations for locations for bases, hospitals and factories on cypres we are all ears!

     

    Please let us know if you run into any issues and as always, your opinion is very valuable for us!

    There is a hospital with a helicopter pad in the town of Paphos (haven't got the exact coordinates at the moment but can provide if you can't find it).  Great work on improving the Syria server. Will you be adding the Mi-24 to it too? 

    • Like 1
  14. 20 hours ago, pappachuck said:

    The evidence is on the NFM-000 and NFM-400.

    I agree the older Flight Model was too off, however this one is aprox. 15% underpowered.

     

    There are other aspects to the graphics that is not listed, they are assuming 95% of the total engine output as safety margin. So even if the currently model was for the engine  F402--RR--408 (Pegasus11-61) it would need to be slightly above of what the manual states to match what the aircraft would output.

     

    You can confirm on figures:

    Maximum Corrected Hover Capability, Remarks engine: F402--RR--408 on Figure 3-8

    Hover Capability Dry, Remarks engine: F402--RR--408 on Figure 3-10

    Vertical Takeoff Capability, Remarks engine: F402--RR--408 on Figure 3-12

     

    Remember that the engine F402--RR--408 (Pegasus11-61) is capable of aprox. 22,200 lbs of static thrust running dry in optimum ICAO conditions. There are engineering tables which states how much loss of thrust according to the Reaction Control System required flow rates, and varying conditions (temperature, air pressure, ....). From those tables they derive (with a safety margin) what is given to the pilots and what you can see on NFM-000 and NFM-400.

     

    My personal opinion is that RB misunderstood the tables and made the engines slightly closer to the F402--RR--406 rather than the F402--RR--408.

     

    The only way to tell for sure is if someone help me extract their code and run on MATLAB.

    I'm really curious to see exactly how the current engine model is 15% underpowered.  Can you please provide a clear graph or picture or some kind of proof of this?

    With regards to the safety margin you mention, are you saying there is an additional 5% margin on top of the 3% margin already implemented for the VTO graph? 

    For the VL graph there is a 5% margin implemented, are you not confusing the 95% margin with that?  

    If I remember correctly the DCS performance conforms to what the VTO & Hover graphs are depicting, with a small margin but it would be good if you did some tests to show that it is incorrect and provide the proof.   

     

    When it comes to climb performance the RB flight & engine performance model reflects the figures depicted in the TIME TO CLIMB/DISTANCE TO CLIMB/FUEL TO CLIMB graphs really closely. Upping the engine performance would probably lead to the climb performance being wrong again. Unless they modify the drag and weight too.  

     

    Extracting the code? I doubt that will happen but worth asking RB. Message Helljumper with that request, he may be able to help. 

     

    You may be absolutely right with all this, it's just that the model closely resembles what graphs that are available to the public depict. So please don't take offence to me questioning what is correct.  Unless we are reading these graphs wrong like you said and you can point us in the right direction where exactly we are going wrong?  It sounds like you have knowledge of the Pegasus engine, are you an engines mech/engineer? 

     

     

  15. 3 hours ago, pappachuck said:

    The NFM-400 states that the Pegasus 11-61 produces 22,200 pounds without water injection. Exactly my point. The engine they modelled it is the Pegasus 11-21. 

    I searched a lot as matter of fact.

    That's interesting. The best way to go about this is raise a formal bug in the bugs section and provide all the test data with the charts you've used to prove that yours is correct and theirs is wrong. 

×
×
  • Create New...