Save Default Dispatcher Remarks and other cool ideas

Would love to see this implemented!

1 Like

I too would love to see this implemented!

1 Like

What a an OUTSTANDING idea and plan. I would LOVE to see it implemented!!!

Hi, these requests have now been added in version 2.15.0.

Best regards,

1 Like

Are they included on the API for these extra field now?

Yes, I have added them to the API documentation topic now: The SimBrief API

Best regards,

2 Likes

This is incredible stuff @SimBrief. FANTASTIC WORK!!

Real quick, regarding the SWA OFP format, I noticed a couple slight bugs that need to be fixed.

  1. MEL/CDL fuel is currently spitting out a time in the TIME column however it should not be doing so. Per the real world SWA release format, it should be BLANK in the TIME column. However, it SHOULD populate in the FUEL column. See attached photo for evidence.

  2. For ETOPS flights using the SWA OFP format, the simbrief dispatch release is NOT planning ETOPS APU fuel and is not letting the user manipulate ETOPS ADD fuel.

For reference, ETOPS APU normally shows as 0005 (500lbs) on the dispatch release and is BLANK on the TIME column. ETOPS ADD defaults to 0000 in the FUEL column and 00+00 in the TIME column. It is only to be manipulated by the dispatcher if necessary for the specific flight conditions. See attached photo for evidence.

image

Is there any chance we can get these bugs fixed with the SWA OFP format?

Thank you for all the hard work you have put into this Derek it really shows sir!!

1 Like

Hi,

Should be fixed now.

You can now control the ETOPS APU fuel by planning an ETOPS flight and adding APU fuel, like so:

Best regards,

@SimBrief Ok so i am confused about something here.

image
image

Why is my release showing 300lbs for ETOPS APU even though I planned 500lbs for ETOPS APU?

Also, is there a way to make it so we can manipulate both ETOPS APU and EXTRA, individually? It appears the way it currently is you can either change ETOPS APU or EXTRA but not both at the same time.

Because you are at max tanks on that flight, so part of the APU fuel was reduced. Generally, if there isn’t enough space, extra fuel is reduced from right-to-left (so tankering first, then extra/apu/hold, then wxx, etc.)

image

Not directly, but if you manually force a “Block Fuel” that is higher than what SimBrief calculates, the difference will be placed in the EXTRA column. So you can add extra fuel that way.

Best regards,

1 Like

@SimBrief ahh okay I see the work around now thanks!

In the real world, the dispatch software my company uses will show an error popup message (we call it a reversion message) that says tank capacity has been exceeded when we go to generate the release. Is this something you think that SimBrief users could benefit from adding into the system?

IRL, we get reversion messages anytime payload is reduced due to max structural weight exceedence (either MTOW, MLW, or MZFW), performance related weight exceedence (i.e. field limited max takeoff weight or an obstacle limited max takeoff weight or a climb limited max takeoff weight has been exceeded, for instance), enroute max takeoff weight exceedence (method 1 drift down takeoff weight exceeded), or tank capacity has been exceeded.

It would also tell you exactly how many pounds of payload has been forcibly reduced by the system AND as well if tank capacity was exceeded it would say by how much exactly tank capacity has been exceeded by.

What is your opinion on getting something like this implemented into the SimBrief system? To start I think it would be very beneficial to at least to let the user know if requested fuel exceeds tank capacity (especially required fuel for flight- min takeoff fuel that is) and as well if any STRUCTURAL weight limitations have been exceeded and exactly how many lbs or kilos of payload weight has been reduced by the system.

Would love to hear your thoughts on this Derek.

Furthermore to add, in the scenario above from my latest Dispatch Release that you shared, required fuel is required fuel. We dont require to take payload but we DO REQUIRE to take the minimum amount of fuel needed to safely perform the flight. I noticed on my latest release that I still have 33,100lbs of payload plnned on the dispatch release OFP. The system should be reducing my PAYLOAD in order for me to take all required fuel for the flight. Thats how it works in the real world.

IRL my company’s software prioritizes fuel over payload (especially required fuel for flight “min takeoff or MINTO”). So in this case, i should be getting 500lbs of ETOPS APU on the dispatch release OFP and less payload. The idea is the aircraft will burn less fuel if there is less payload onboard (less weight). The system would spit out a payload value that would reduce the ENROUTE BURN fuel to the point that tank capacity was no longer exceeded. This might be a significant amount of payload reduction, depending on wind and cruise speed planned to reduce the enroute burn, to allow the needed extra 200lbs of ETOPS APU required for flight.

Fuel should always be prioritized over payload. Even if it means reducing payload all the way to 0lbs. We wouldn’t send the release to the flight crew if the system reduced the payload to 0lbs but if it did we would know we have a serious problem on our hands and begin to troubleshoot to get as much payload as possible back on the flight, or plan an intentional fuel stop, or even possibly cancel the flight depending on the circumstances.

I’ll look into adding a message if the requested extra fuel could not all be boarded.

SimBrief already auto-reduces payload to make space for fuel in cases of MTOW or MLW exceedance, and a message is provided, as I’m sure you’ve already seen before. But auto-reduction of payload for purposes of reducing the enroute burn (when max-tanks limited) is probably not something that will come any time soon, you’ll need to handle this manually for now.

Best regards,

@SimBrief understood thank you sir. I hope I’m not pulling hairs here or anything. I love dispatching IRL and want to bring that passion to this community and help you make the best product possible based off of how the real world systems work.

That being said, would it be possible to add to SimBrief’s current functionality and have the system say exactly HOW MUCH payload has been reduced by so the user has an idea of how weight restricted the flight is and therefore they can more easily troubleshoot the problem manually to try to get all payload safely onto the airplane? This would be a nice touch because this is one of the biggest problems dispatchers face everyday on the job.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.