Bog9y

I'll try it later today and report back

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

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.

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.

When you put in the BRG and RNG when entering the TCN or WAYPOINT OFFSET, the range disappears from the UFC scratchpad as soon as you press ENT, and it doesn't display on the scratchpad when you press the RNG ODU. This makes it hard to figure out what is actually entered for the range.

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.

I noticed that on the Nevada map, with no winds, the ground track displayed next to the aircraft symbol on the EHSD MAP was showing 7 degrees more than what my actual track was. Not sure if this is an isolated bug to the Nevada map or exactly what may be causing this. I will investigate further and report back.

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.

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.

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?

Cool, thanks guys. I wonder what the other 2 modules could be? Tornado and F-4 maybe?

With Heatblur taking on the Eurofighter/Typhoon project does that mean that the A6 will be significantly delayed?

Hi guys, I flew on the server last night and noticed that I can not refuel the Hind at the Garbani hospital. Bug or not?

Agree with the above post, the distances in the Syria server are a bit too much for casual flying. I never fly on that server because of it, although it would be fun to explore Syria more. Also, no Hind slots.

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?

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.

ah ok. Do you know how long that could take?

Is the Caucasus server down too?

Only discovered this server after seeing Mover play it last week. What an addictive way to play DCS! I normally only fly jets but have now been mainly flying choppers, it's so much fun. Just wondering what happened to the Syria Server though? It's not been around for 2 or 3 days now.

Hi, thanks for that detailed reply. Like I said, I'm just relaying what I read on FB written by someone. That's why I posted the question to ask people who are probably way more clued up on this stuff than I am. The person never stated why DCS would need UE, I suspect the statement was just based on the footage he may have seen of UE on youtube, it does look pretty impressive. Cool, thanks for the replies guys. It will be amazing to see where DCS will be in a year or 2 from now. Hopefully VR performance and image quality will improve.

Hi, I read in the FB group that the Unreal ENgine 5 is amazing and what DCS needs. I am clueless with software development , not an IT guy or engineer so was just curious if this is something that could be used by ED to make DCS even better? It sure looks amazing:

Hi Hornet, I just tested the waypoint offset function and it does have the same error except it's only 1 time the variation error. Because the F10 map uses True north the bearing is different than what you get in the HUD or EHSD. To test this, go to mission editor , a/c hot start on ground, create 1 waypoint north of you by around 20 nm. In the mission, check the HUD to see what the bearing and distance is to waypoint 1, then create the offset with the reciprocal of that waypoint bearing. You will see that the waypoint offset point will be 2.3 nm or so away. If you then add the magnetic variation to the offset bearing you will see that the waypoint offset point will be 0.2-0.3 nm away which is more correct.

That's the thing I haven't checked yet myself, the F10 map bearings...are they magnetic or true? I guess true based on what you said here. Cool, thanks Hornet. And like Wisky said, in order to see the error the distance needs to be greater. Also, it may be worth checking the waypoint offset too and see whether that has the same error or if its just TCN. I'll see if I can do that test today.

Hey Wiskey, I'm not saying that the radial function is bugged. It's the offset waypoint that is bugged. If you look at your screenshot from the PG, what I can see there is you have a TCN OFFSET set with a 353 bearing, and the T/OS waypoint is 2.6 nm from you. The TCN station is on a 179 bearing from you (you are on the TCN 359 radial). And if this is with TRUE selected you still have the "double the variation" issue. Do you see what I mean? For an easy test of this error i use my current position whilst parked up but you could also put a target on the 360 radial at 20 nm from a TCN. Then create the OFFSET from the TCN (360 brg & 20 nm dist). Fly to the offset and see where the target is, it will no be where you are, it will be at least 2+ nm away , possibly up to 4nm away, depending on variation and if you use TRUE or magnetic on the EHSD. This offset issue has been around for at least 6 months (since I started learning the Harrier) but I never formally raised the bug.

Hi Hornet, many thanks for looking into it. Just bear in mind that I used the bearing and distance numbers just as an example, the exact numbers will ofcourse depend on where you are in relation to the TCN or waypoint.