It’s my understanding that the pushback tool in the FMC is only in the 2020 version. It has been deprecated in the 777 and the 2024 version of the 737. PMDG have indicated that they are working on a replacement for their older code but they have not revealed more than that.
Personally I used GSX for pushback but there are other free and paid tools available.
We can now on the experimental branch, and it works brilliantly.
This is likely the issue tbh. At Heathrow about 95% of aircraft get their clearances by datalink, and only call delivery when ready. A short transmission, and at that point they are handed over to one of the ground frequencies depending on where they’re parked. Once ready to taxi they speak to ground again but then use 2 or 3 different ground frequencies before going over to tower frequency, of which there are normally 2.
BATC is trying to run a real world schedule with the sliders at 10 on about 3 frequencies so it’s never going to work.
I just Shift + P most of the time and 99 times out of hundred it automatically turns me in whichever direction BATC has asked me to and on the taxi line. I’m not sure if BATC is doing some magic there or not. Only aircraft this doesn’t work on is Fenix and FBW (2024 version). Sometimes, rarely, I’ll be pushed in a complete circle and I have to manually step in.
One assumption you are making is that you are talking about the visible actions, voice, and text you see on the screen in their apparent sequence but what we can’t see is the actual code execution which my have the AI messages actually hitting the processing prior to your entry and what you are seeing could just be a delay in BATC responding to them. I have no idea what pre processing might be going on with traffic messages that are created programmatically.
I would think using a mic instead of the pre-programmed responses would require some very intensive processing on the part of the AI which takes some time. Yes they can spit out the text you say very quickly but then the AI must decipher your sentence structure and words to ensure it understands the intent. With pre-programmed responses (which traffic would use as well), it’s merely an if-then statement. If a pilot says this, respond with that. Looking at it that way it kinda makes sense why you’d see a delay using a mic.
I must say I am with Nixon here. I can’t understand why (nearly) everyone is either missing the basic point or seems to be ‘talking around it’
The issue he is pointing out is that BATC has given him a instruction. He is (we are) trying to do one of, if not THE most basic requrment of RL (an one would hope sim) ATC. That is read back the instruction so ATC can confirm he has ‘got it right’ BEFORE ATC starts talking to another pilot.
The mic delay is totaly irrelavent to the issue being describe. If the reply takes .0005 sec. or 5000 sec. to process, that should not matter in terms of how ATC is handled? BATC should not be starting, let alone, completing ANY conversation with other pilots unless I, you, me, as the player have replied. Period.
Anyone ever notice that this scenario NEVER happens with AI comms? They are always completed from start to finish before the next one starts. Why are mine handled so differently? This is also combined with the incredibly long winded conversation strings. It leads to sitting annoyingly thru 10 min of monotinious conversations that should in reality (and if implemented correctly) only take 2 min. max to complete, if even that long.
I don’t understand why BATC does it this way, but it does. That is not entirely true, but I again will stay out of that discussion. I also think it does it on every transmition between the player and ATC. I suspect it becomes more, and more prominent as the traffic levels increase.
Many of the issues that have been reported ages ago have not been solved - the question is, can they ever be solved? Sending in lots of player logs for the same issues, did not solve it. devs get frustrated when you mention it and you are asked to upload more logs…
I personally believe a realistic VFR is VERY VERY far out - but maybe there will be a surprise. Who knows…
Yes, I feel they can. I think the problem is that it is soooo baked into the cake after years of added programing layers, fixing it is going to break a whole lot of other things. It was like this at the very start, many pointed it out, including myself. They did not fix it then because they did not want to.
This phraseology is extremely common in the USA however, they are a lot more casual there than elsewhere - using US phrasology in the UK for example will most likely get you fined.
I am a pilot and not a software dev - so I don’t know. I have left the discord because pointing things out is met with contempt.
Pilot, not dev. here also and to be fair I can only speculate it can be fixed. To your point about BATC Discord, 1000000% in agreement. Gave up on it long ago, and on BATC for the most part not too long after.
Sad part is the ‘other’ ATC option Dev/Customer interaction on thier Discord is turning in the same direction from my recent experiance.
Edit, as to the ‘other’ option experiance. It has NEVER been (and still is not) to the level of what I experianced on BATC Discord from the very start. Maybe it’s changed for BATC, not sure and not going to find out.
Speaking for myself, I still use BATC and will keep on doing so as it is the only viable alternative and things have improoved and also the CPDLC implementation is well done within its particular limitations - I do not expect 100% accuracy. I do enjoy and value the app - most flights are satisfactory however the app is not consistant and when it breaks, it sompletely destroys the immersion.
Did a flight in the new MSFS2024 PMDG737 trying it out only 3 days ago (because I was on a real life mission in the USA the past three weeks) and flew EGGW - EDDM and receiving screwed up vectors at destination. Was vectored overhead the opposite treshold of the assigned runway and just told to contact tower… no ILS vectors or the standard expected radio calls and clearances for the approach…
Now, I do not know if this happend because Sim Wings just updated EDDM and I did not delete my scenery indexes yet - but still - it sucks. Checked the player log myself and there is no hint in there, that may point towards what may have caused the issue. The subsequent flight EDDM -EGPH went ok - slightly late vector for final ILS intercept, so overshot slightly - but ok, it’s not a train smash.
This being said - I still get failures or at least “bad” unrealistic vectors for at least half of the approaches.
Your point that they have added to many layers before solving fundamental bugs and essentials is exactly correct and early acsess is not really a sensible excuse in my view.
The local voices often have some really weird pauses when pronouncing names such as “West… jet 588” or “Lang…en Radar”. It seems to happen more often as the flight goes on. It happens no matter where I fly.
Why is that and will that be fixed ?
Yes, I strongly suspect it’s thread timing and prioritization.
I usually have the sounds effects turned on, and after I say something and release the PTT button, it takes a moment for my voice to process into text. Once it’s done processing, it makes a beep/“clink” sound. But sometimes when it’s processing, another AI aircraft starts talking (i.e. requesting IFR clearance), and while that AI pilot is talking is when I hear the “clink” sound. I believe that logic needs to be adjusted, which might not be a simple matter.
That right there is the issue that needs to, should have been been, fixed. Nothing AI (comms wise) should be happening from the time ATC gives me a instruction until I have completed my readback and BATC has understood (verified) it. How long that takes should not be a consideration.
Going the other way, me making a request to ATC is (within reason) an different story. In that case ATC is not obligated to prioritize its handling of it.
Fined? What are you talking about?!
You want to try operating at most big international airports. A lot of pilots from certain airlines make a habit of tuning a frequency and just transmitting without listening first, often treading on other transmissions and increasing the mouth music for all involved. It must drive controllers nuts. I do get what you’re saying, but the fundamental issue is that the amount of traffic with the sliders on 10 is overwhelming the system. Get on Discord and bug it with the log, it’s the only way it’ll get looked at.
Minor Version 1.7.5.Experimental
Traffic:
D-ATIS:
Improvements:
Bug Fixes:
Ops Updates:
BIKF, EGNS, EGPF, EGPH, EHAM, ENGM, ESMS, KATL, KAZO, KBZN, KDEN, KEYW, KISM, KJFK, KMCI, KPIE, KSDF, LEVC, LFPO, LOWS, SBSL, VAPO
***Happy 2026 - the first BATC Release of the 2026!***
As we have said all along - work on IFR, Traffic and all the other aspects of BATC does not stop because we have started on VFR.
This release will move swiftly to EA in the next few days assuming no major new issues reported while in the Experimental channel.
FlyTampa KBOS is also such a great mess, will be great if that can be prioritised on lines of their EHAM.
I don’t know if I understand you correctly, but shouldn’t you ask Fly Tampa to clean up the mess? Otherwise: Discord, Logs, Documentation. That’s the drill.
Thanks for the OPS update on KBZN. Will give it a try this week.