opensky-to / agent Goto Github PK

Settings window does not seem affected
Left side seems to slightly reach into my second monitor (around 5 pixels or so)

Not sure what is causing this, second time. Xplane you can pause and Opensky will "abort tracking due to a warp" or something like that, and you will lose a lot of fuel through that

• Payload minimum check, higher values are always accepted
• Fuel check with only warnings, but not requirement, low warning, high charge for it
• Real-time clock only as a bonus, changing it should not abort tracking, changing it by more than X minutes disables bonus, a few seconds change should be ignored in case physics engine slowed down

Similar with resuming flight:

• Payload just minimum check
• Fuel this time only a range up or down, but percentage based and not so strict
• Location radius increased by a bit / depending on aircraft type?

Check new custom message box code

this.fuelWeight = (int)value switch
{
0 => 6,
1 => 6,
2 => 6.7,
3 => 0, // Electric engine
4 => 6.7,
5 => 6.7,
6 => 0, // Rocket
7 => 0, // Tip rockets
8 => 6.7,
_ => 0
};

This is outdated, new one goes to 10

• Move that to a single method to remove the code duplication
• Reference that one from all three locations

We are unable to remove the small gaps between files from the software side, so the cut in/out of the background noise is really noticable. The whole "Opensky flight number XXXX is now ready for boarding" needs to have that removed.

This includes the fixed start/end files and the 10 number files dynamically added in between.

APU was started and avail, bleed was off ... no other change or sim pause

Add this to the aircraft types screen

Currently all groupboxes (side info, add and edit) are all stretched down when the grid is too long
Plus the grid is not scrolling with the mouse wheel

• Altitude
• Airspeed
• Fuel
• Radio alt
• Ground speed
• Sim rate

All those values are available from the position reports of the flight log

• Transfer new custom controls from client project
• Modify OpenSkyWindow template
• Replace existing calls to ModernWPF.MessageBox where appropriate

Title explains it all

Should move on to other flight phases

While checking in there, last flight was doing a v-path shallowish descent (500-800 fpm), flight phase was displayed as "Unknown" before switching to approach

The current envelope for resuming flight is too narrow. Expand the radius to resume flight so that study level airliners can load in at nearby airports and resume flight rather than tracking back to the exact last known location and altitude.

• New regional airliner type
• Minimum runway length
• Include in world populator flag

Agent is not flagging payload or fuel differences in XPlane

I think there is already code for handling this for the below 10k for larger planes, needs to be applied to piston too

In xplane, if you uncheck autoset time, it seems to flag it even though the time is the same. I would suggest not forcing time for player enjoyment and scenery enjoyment

Additionally, something to keep in mind (MSFS does this now too), sims will slow the world time in order to calculate certain physics. Originally MSFS didnt do this, but recently its been seen. XP is much worse in this probably though.

What happens is when you dip below the benchmark FPS (20 in XP), it slows the time in sim, in order to continue to calculate flight model per frame properly. When frames are generated too slowly, the sim doesnt keep real time anymore. I am guessing MSFS keeps real time counted, so it may not be an issue there. I would say though, removing the time requirement wont impact gameplay in my own opinion.

Setting the correct payload, tracking condition is green ... but when clicking resume flight it changes and doesn't allow for the resume to happen

When opening aircraft types in agent, it often CTD's after client update to .5.1

When trying to add new variant from in sim detection, it causes error that the aircraft could not be added

Looks like the sim is still updating the primary tracking data in a crash
We should keep a reference to last one BEFORE the crash to detect what kind/how hard the crash was

Like just taxiing and clipping something with 3kts or vertical speed -5000 and airspeed 300 into the ground?

Test if "APU SWITCH" simvar works better, otherwise create a minimum gap of 90 seconds between events, as those are purely info anyway

Screenshot shows over 160, but it was over 200 before turning wing anti ice on

Tracking was therefore aborted, agent should allow any payload weight as long as it is above the amount to be carried and only abort if it goes below

This flight had a transition level of 5000 and QNH 996, turned off landing lights above 10000 indicated, got warning

To give a uniform look across the website, client and agent
Allow editing of linked accounts and show profile image
Allow uploading of new image from there and then also add that to the client

• Check for useful custom simconnect variables/events
• Check if we can perform fuelling and loading automatically again
• If not, provide guide/calculator on how to load the aircraft

Aircraft automatically set to enabled

Copy over the fix from the client

Example airport:

Time warped for a few seconds, agent calculated a time saving of like 2.5 minutes

Last test flight did not show this behaviour, but double check!

• Create splash screen
• Place new logo on custom window
• Final checks

Or is this a unit conversion issue? Recent test flights had negative fuel consumption overall, also check values in saved flight log xml

Remove the existing placeholder model
Add extra features of new model
Keep adhoc simbrief download integration?
Add accelaration options for ground handling -> add to time warp

Also add fuel weight / gallon to aircraft types section and confirm with chosen defaults in the API

Check how often aircraft position updates get rendered
Maybe introduce setting so players can choose a value that works for their computer

The payload stations were never changed, switch this logic by adding them up and comparing to the flight payload
Icing and co. will then never have an impact on tracking conditions

Low priority, at some point need to look into what is causing detected warpage when none was used. Will continue to triage