OnCourse Software

Thanks for the log Mark, I will take a look at it shortly.

The user guide says it's best to leave PF3 to handle the climb profile, that's why PF3 puts your cruise altitude into the first waypoint and handles it from there. The descent profile however is a different matter and it's always best to see what PF3's profile is like and make any adjustments you feel necessary.

Incidentally, I was able to recreate the pause issue you were having once I'd updated to the most recent FSUIPC. It appears there were some changes with the way 'pause' works in MSFS and therefore some changes made in FSUIPC. I've now got that working correctly and it will be in the next beta.

I have not, however, been able to recreate your sim rate issue and was wondering if you still had that problem (I will know of course once I check your log)

Thanks again I'll get back to you with my findings.

Hi Mark,

There's nothing wrong in the log but I did notice that you have selected a long descent profile... therefore your descent started at ATRIB. You may want to experiment with other settings. Here's what your current flight profile looks like, followed by the other two settings available, just to give you an idea of the difference each makes.

I actually got my descent to 10000 at about TUMGU while I was climbing out after departure, so there was something strange going on.

Glad to see you got to the bottom of my TOD issues, and I am looking forward to testing the beta when it comes out.

No more sim rate problems since I reverted FSUIPC7 back to V3. I do not think the sim rate was actually running at 0. I think that PF3 thought it was being set to 0. This problem happened every time and always right at the start, so it was game over as I could not get PF3 to see sim rate was correct.

Anyway I am back to 3.21.0 and everything is working as normal except TOD of course.

Thanks again
Dave

Well I went back to your log.... it certainly was a strange one. What through me was when you got the command to descend to FL100 the log was showing the next waypoint to be WP #9, and yet you hadn't actually reached WP #4 when I checked the Lat/Lon coordinates. So you reached the SID altitude way before the end of sid WP marker at WP #9. PF3's internal waypoint flag incorrectly jumped to WP #9 as being your next WP. So, thank you, another bug revealed and fixed.