dutchili

Like the topic starter said: it is so strange that the pilot initiating the search is not getting the result. Please consult a subject matter expert.

Had multiple crashes in ME and one while trying to run a simple flight. Only found this at the end of the dcs.log: 2024-12-15 18:35:12.549 WARNING ASYNCNET (Main): Ignoring duplicate request to imageIRAQ_terrain while one is already in flight. 2024-12-15 18:35:12.551 WARNING ASYNCNET (Main): Ignoring duplicate request to imageAFGHANISTAN_terrain while one is already in flight.

Yes, and: waypoints created while flying (mark / TGP lase) have the wrong elevation too.

This issue still excists, bump! @BIGNEWY It is hard to hit a bridge. The object height seems not be added to the ground altitude. In this example mission, the ME lists the altitude equal for the water and the bridge (which cannot be right). Also, the elevation of the water as displayed by the ME differs significantly on different area's of the lake, suggesting that the water depths are also ignored. During the miz, the TGP points at the water below the bridge. When lasingBridge strike test.miz the road on the bridge, the elevation is different from what the ME reads and the actual elevation of the road. Out of 5 tests, at least one bomb misses the road by underflying or overflying the target. For GPS bombs, waypoints create in the ME or on the fly are far from exact.

see topic title @BIGNEWY

Fixed as instructed. Must have been a windows update that broke it ...again.

Hmm, might a different cause. I get this err when trying to launch DCS server standalone: null

2024-12-09 16:07:26.425 INFO ASYNCNET (8348): Login success. 2024-12-09 16:07:28.420 INFO ASYNCNET (8348): Got auth data. === Log closed. @BIGNEWY

Wouw, that fog looks amazing!! Good to know that fog thickness is based on MSL, not just 'thickness from ground level'. In NTTR i had to raise the fog over 1000 ft compaired to field elevation on Nellis to actually see it. Althoug i could see some fog over the lake to the south-west. When set to 2700ft...wouw, just amazing. Bad weather flying is more interesting than ever.

The current implementation works well on the Quest 3 with PD 1.3 and max resolution set in the headset. The dots are larger than the actual objects, but would be hard to see given the resolution of the Quest 3 without the dot. I perceive them as 'ugly', but during dogfighting the compensate nicely for the lack of resolution in the hardware. It would be great to configure the transition distance (from object to spotting dot) and the size of the dot so everybody can tune it to it's own liking.

Thank you for explaining. Allow me to suggest that you communicate a release date one day prior to release, after you are sure you are going to release. This might result in one day delay between completing the update and releasing it to the community, but the upside is that you will become trustworthy and the community can understand the impact on planned OPS. After a successful build, test and release preparation, you could already publish the change log so we know what to expect the next day and can decide whether our planned OPS need to be postponed due to the changes. I would greatly appreciate the above.

@BIGNEWY: Can you explain the purpose of communicating a plan that is subject to change. How should the community process that information?

+1 Some get through.

Would be great if the arms move out of the way when you look at the side panels, just like a real pilot would do.

task test.miz Expected: - when Ground 2 drives through Go trigger, Ground 1 should go to waypoint 3. Actual behavior: - Ground 1 doesnt start moving to waypoint 3

@BIGNEWY: we can close this thread with the conclusions: - AREA lock (TMS RIGHT) can be used when one expects LOS to be lost - INR POINT track (TMS UP) requires improvement as the TGP can jump to different objects that (somehow) look equal to the TGP.

What is happening here? I was expecting the vehicle to drive rounded rectangles. But instead it seems to have a mind of its own. I truly hope ED can explain this behavior or fix it, because it is in the way of reliable vehicle movements. This is only the beginning, as i intent to hold and continue the traffic based on triggers, which seems even less reliable. task test.miznullnull

This video is exactly what i experienced while making the uploaded track. INS AREA was stable when i just tested it.

INR AREA seems to be reliable in a few tests. Point track was more reliable than before. So this hints at something dynamic. (same mission). The problem seems worse IN WHOT compared to TV.

Why does the TGP jumpt to random (?) locations instead of maintaining an INR point track? I this scenario i lock a BTR-80 with the TGP (TMS up). The lock soon changes to a different object. After making two hooks, the TGP is pointing somewhere completely different. It jumps from object to object. Is this a bug? And if not, what am I doing wrong? tgp jump.trk

Was the performance improvement mistakenly not deployed?

567.464.743.567 hours

I would say this calls for a hotfix.

JTS is viper focussed at the moment. From two or more Hornet (or other airframes) we can include those in the missions. We are quite serious on how we go about things. One Wednesday is mission planning, the next Wednesday is mission execution. We intent to enjoy ourselves, learn along the way and be as good as we can be (implying publicly known procedures).

null