dutchili

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

IMHO it has nothing to do with customers understanding the bigger picture. It has to do with customers expecting a higher quality level than you are providing and not showing the improvements in quality that we ask for. I am not blaming your beta testers. I am suggesting that you (as a company) should provide test scenario's to ensure the features work as intended. Whether the software system is complex or not, has a huge history or not, engineers being of lower quality than you wish for, or whatever factors are in play, it remains a choice whether you deliver tested or non-tested software. Given your response it shows that you choose to deliver non-tested software. Without judgement, that is your choice. Similar to us choosing to still use it. I truly hope you will introduce structured testing for your engineers, alfa testers and beta testers to fix long existing bugs and reduce the number of newly introduced bugs.

Fixing newly introduced bugs doesn't improve customer satisfaction. Consider structured testing, also with your Beta testers.

If your are using a quest 3, update the software off your haven't. The latest release works wonders in reduction of ground stutteres. The spacewarp has improved. 72 fps is now perceived as fluent in most scenarios.

Interesting. I would expect he coordinate to not change

thank you