Please Increase Time Delays Between Tellings Off !

[Gabe_62 1]

I hope you can increase the time delays between instruction and complaining from ATC.When I'm asked to climb or descend, it will often expect me to perform impossible tasks like climing at 10,000 ft per minute ! ATC will tell me over and over that I've "busted my blah, blah, blah...." after giving me like 10 seconds to start descending or climbing. Equally, if I miss a waypoint - maybe my FMC and RC flightplans are slightly different - it will tell me to "Fly heading of x degrees"... (to get back on course), and then as soon as I acknowledge, it tells me I'm not following the instruction... this cycle can continue for 6 iterations, before I get the time to ask for a direct to... ckkpt.... and get out of the appalling cycle.It is simply not always practical to make an immediate turn to a heading, and not going to happen if you're heading to your "correct" (as per FMC) waypoint. It also happens when I'm about to ask for a full ILS instead of vectors... if they just paused for 10 seconds between instructions, I could actually use the menu and make certain requests. They are available generally, but due to the often TOTAL lack of ANY delay between instruction 1 - acknowledgment - instruction 2... I can rarely get a word in.There should be a "pause" button where you can simply shut them the heck up while you think etc.But whatever, the delays between issuing instructions and bollockings (for not immediately following their instruction), is seriously FAR too short.Moreover, it happens so often and in so many different circumstances that it should really be looked at for Version 5. I end up switching the thing off at least 50% of the time as it so frustrating... ironically, it should be simple to fix it.In logic, it would go "... after command x... wait for 10 seconds before issuing next command AFTER ''acknowledgement' has been received.'Acknowledge' should not be seen as a 'command'... unfortunately the coding sees it as just that, and goes on its merry way issuing the next command... usually a repeat of the earlier one... and so it goes on - an endless, futile and highly irritating cycle.Thnx.

[jd 57]

I hope you can increase the time delays between instruction and complaining from ATC.When I'm asked to climb or descend, it will often expect me to perform impossible tasks like climing at 10,000 ft per minute ! ATC will tell me over and over that I've "busted my blah, blah, blah...." after giving me like 10 seconds to start descending or climbing. Equally, if I miss a waypoint - maybe my FMC and RC flightplans are slightly different - it will tell me to "Fly heading of x degrees"... (to get back on course), and then as soon as I acknowledge, it tells me I'm not following the instruction... this cycle can continue for 6 iterations, before I get the time to ask for a direct to... ckkpt.... and get out of the appalling cycle.It is simply not always practical to make an immediate turn to a heading, and not going to happen if you're heading to your "correct" (as per FMC) waypoint. It also happens when I'm about to ask for a full ILS instead of vectors... if they just paused for 10 seconds between instructions, I could actually use the menu and make certain requests. They are available generally, but due to the often TOTAL lack of ANY delay between instruction 1 - acknowledgment - instruction 2... I can rarely get a word in.There should be a "pause" button where you can simply shut them the heck up while you think etc.But whatever, the delays between issuing instructions and bollockings (for not immediately following their instruction), is seriously FAR too short.Moreover, it happens so often and in so many different circumstances that it should really be looked at for Version 5. I end up switching the thing off at least 50% of the time as it so frustrating... ironically, it should be simple to fix it.In logic, it would go "... after command x... wait for 10 seconds before issuing next command AFTER ''acknowledgement' has been received.'Acknowledge' should not be seen as a 'command'... unfortunately the coding sees it as just that, and goes on its merry way issuing the next command... usually a repeat of the earlier one... and so it goes on - an endless, futile and highly irritating cycle.Thnx.

it's quite simple, in two ways1) if you have pilot autoreply on, or otto has the comms, take the comms from otto. he's going to acknowledge the clearance immediately. unless he's flying too, you can't keep up with him. with pilot autoreply off, don't acknowledge the clearance, until you have started the climb, or descent, or the turn. it's better to be asked to comply again, than to comply and not be doing what you are supposed to be doing.2) as you fly, you will become accustomed to the boring, routine, step by step method of air traffic control. anticipate, listen, act, acknowledge.3) also, don't fly at 2x or 4x speedjd

[Gabe_62 1]

Unfortunately there are 2 problems there.Firstly, I already "manipulate" the program in a number of ways, which shouldn't be necessary really, when 95% of the exasperation I encounter using RC, could be avoided by increasing the delay between: "instruction - wait for user response - second instruction (OR repeat of first instruction due to non-compliance".When I need to make a user-command, such as "Request Direct Checkpoint", to prevent the cycling of an instruction, I can't as the ONLY possible response, is "Acknowledge". ie. "Acknowledge"... user menu pops up... but I then have no time to make a selection before the "bollocking" is repeated, Ad Naseum.So, manipulation in this situation is simply not possible.Secondly, the other 5% of the time - and what must be the most annoying feature - is how ATC expects to me to climb or descend in a 'micro-second'. Avoiding the 'Ack' is okay I guess, but due to the badgering that results, nonetheless, infuriating. Can you not appreciate how a simple delay put into every instruction - repsonse - reaction, could solve all of this ?

[airliner_75 0]

Unfortunately there are 2 problems there.Firstly, I already "manipulate" the program in a number of ways, which shouldn't be necessary really, when 95% of the exasperation I encounter using RC, could be avoided by increasing the delay between: "instruction - wait for user response - second instruction (OR repeat of first instruction due to non-compliance".When I need to make a user-command, such as "Request Direct Checkpoint", to prevent the cycling of an instruction, I can't as the ONLY possible response, is "Acknowledge". ie. "Acknowledge"... user menu pops up... but I then have no time to make a selection before the "bollocking" is repeated, Ad Naseum.So, manipulation in this situation is simply not possible.Secondly, the other 5% of the time - and what must be the most annoying feature - is how ATC expects to me to climb or descend in a 'micro-second'. Avoiding the 'Ack' is okay I guess, but due to the badgering that results, nonetheless, infuriating. Can you not appreciate how a simple delay put into every instruction - repsonse - reaction, could solve all of this ?

Totally agree here.I even posted earlier I think that before version 5 since it seems to be a long way there you maybe should consider if it is possible of course to give more instructions from approach whithin 40nm out of the airfield as an update to current 4.3.Now, I am asked first to contact approach. After that usually nothing for couple of seconds. Then I have to aknowledge the expected runway. Then I am given descent clearence. This is so not good in terms of my VNAV. I loose so much time and when flying straight in approaches I really loose minutes. that's critical. the result is I need to dive and increase speed.I dont know if there is a possibility to when switching to approach the approach tells me which runway and also at the same time cleares me to a lower altitude so I can continue my descent with a descent rate.Best regards

[jd 57]

Unfortunately there are 2 problems there.Firstly, I already "manipulate" the program in a number of ways, which shouldn't be necessary really, when 95% of the exasperation I encounter using RC, could be avoided by increasing the delay between: "instruction - wait for user response - second instruction (OR repeat of first instruction due to non-compliance".When I need to make a user-command, such as "Request Direct Checkpoint", to prevent the cycling of an instruction, I can't as the ONLY possible response, is "Acknowledge". ie. "Acknowledge"... user menu pops up... but I then have no time to make a selection before the "bollocking" is repeated, Ad Naseum.So, manipulation in this situation is simply not possible.Secondly, the other 5% of the time - and what must be the most annoying feature - is how ATC expects to me to climb or descend in a 'micro-second'. Avoiding the 'Ack' is okay I guess, but due to the badgering that results, nonetheless, infuriating. Can you not appreciate how a simple delay put into every instruction - repsonse - reaction, could solve all of this ?

make a log, instructions pinned to the top of the forum. duplicate these issues, and send me the log file, zipped. tell me where during the flight you had problems responding to a clearance within 60 seconds.are you missing checkpoints, and that is the reason you are having to request direct a checkpoint? or are you trying to skip a few checkpoints (maybe closely spaced together) and get a more direct route?and just so i understand exactly what you're having to deal with - you are flying at 1x, you have pilot autoreply turned off, you have display text unchecked on the rc options page, and when you are given a clearance to climb and maintain 15000 let's say, you start the climb and you press the key for pilot acknowledge. with all those conditions met, you are still being harangued for not climbing?if this is the case, i can tell from the log exactly how long it took to acknowledge, and why you were berated for failure to comply and acknowledgelooking forward to seeing the log.jd

[jimble 0]

I think there is a work round to this problem. Let the co pilot handle the coms, so when you are "bollocked" for not responding quick enough, the co pilot will politely inform ATC that you acknowledge their instructions, you are free to work on complience, The controller might be having a bad day as he is dealing with ten aircraft at the same time. Also, be mindful of the fact that when you compile the flight plan, that is the one that RC will read, it doesn't care what is your FMC I use the Wilco Airbus series, and have the option to import the flight plan into the FMC, a bit unrealistic, but it does ensure, most of the time, compliance. After you reach the gate, don't select "flight critique", as you will have to deal with Bill Stevens, simply ###### down RC, and think "job well done"oops i meant shut down.

[ronzie 21]

Actually in some airlines the company data link "ACARS" may be used to load a flightplan from their dispatch office into the FMC. The pilot's responsibility is to check everything and modify as need so importing a flight plan from a compatible planner is not unrealistic. I use FSBuild, use a downloaded archive in Active Sky (6.5) for the UTC time of the take-off hour at the location, and FSBuild can create what is needed for the plan interfacing to weather. It uses aircraft profiles and can function as an approximate fuel planner for generic aircraft loading by model.I use the FSBuild data terminal procedure base, updatable by fee AIRACS from its web site, to export the plans to my PMDG FMC including SIDs and STARS, and also the same plan exported to FS9 (or FSX if you prefer). That way RC uses the same plan as in your FMC. All I do on the FMC is select for DEP/ARR the runway and navaid runway approach to give me situational awareness. I do the latter after RC assigns the runway in approach.For those who use FSBuild here is a tips sheet that in part may apply to your current planner. This forum will not let me attach a zip or pdf so the unformatted text is pasted below:FSB tips:1. Include this line in FSbuild.cfg:NAVCHKDUPDIST=100This decreases the chance of using the wrong duplicate named local (to the airport) waypiont from a nearby airport. Local waypoint names are not exclusive. It decreases the database search when it is named in the route to within a 100 nm radius of your airport. You will find these in terminal procedures such as "D" number something within a SID or STAR to define a merge or turning point.2. When doing a Auto Generate (Route) be sure the SR (Stored Route) button next to it is "up" that is not highlighted. Auto Generate will use a stored route if found by default and most are out of date with old waypoints and terminal procedures. Having Stored Routes off forces it to search a path with fresh data.3. Take advantage of the frequent AIRAC updates at the FSBuild site for the greatest possibility of matching current charts and real world flight plan procedures and waypoints.4. Where an airport uses specific runways for different terminal procedures select the runway using an estimate based on weather and if the runway fits your aircraft requirements before doing the Auto Generate. This helps select the correct SID and STAR for the runway and direction of departure and arrival.5. After the Auto Generate and/or first build look at the map created to spot any obvious errors. In the route grid look for any sudden non-sensible changes in direction or extremely long legs not in the correct direction creating a zig-zag in the map. (See item 6 following to correct).6. Be aware there is an option you can set for each session titled "Build Route from Grid Table". It does not stick between sessions. This lets you build from an edited route grid that you may have modified without recreating the table with the same error on your next build/export. For example you might wish to drop an errant waypoint when proofing the map and rebuilding.7. Sometimes the name of a procedure (SID/STAR) does not match the name exactly in a published route and the procedure will not expand into its plan waypoints in the grid table. You can click on the arrow in the SID/STAR box to see what close name is in the FSB database. (Another reason to keep up with AIRACS.) For example KMSP has a current real such as this one:http://flightaware.com/resources/airport/KMSP/DP/WAUKON+TWObut the FSB database only has UKN2. (It does have UKN3 now with the latest available AIRAC update). If so in the route line just change UKN3 to UKN2 so it will expand. Here's a real route from flightaware.com for KMSP to KMDW:KMSP UKN3 DBQ CVA MOTIF3 KMDWthat can be pasted into the FSB route line. If UKN3 or MOTIF3 does not expand in the route grid to individual way points look in the upper part of FSB in the airport section dropping down the SID or STAR box to get the available version and substitute that label in the route line and rebuild.8. Sometimes it takes a second build to get the map to move and/or magnify. The mouse scroll wheel lets you magnify. Just click on the portion of the map you want to center on and scroll to magnify.9. If you click on a line in the route grid table to highlight it, the waypoint on the map will turn red. This is useful for finding errant waypoints that cause an error in the path. That line can then be edited or deleted and a rebuild accomplished with the build option to build from the route grid table.10. If you are running a weather program such as active sky, first build the route in FSB exporting to FS9 using an anticipated cruise altitude and specify the nearest aircraft profile. In AS get the weather you wish to use. (I always get the weather for the zulu time of the departure in FS since time of day affects weather characteristics). Import the plan into AS via the new route button, check the altitude and choose an appropriate true airspeed in knots (this is your no wind ground speed). Process the route. When it is finished click the button to print a hard copy of all. Use this AS navlog for METAR data at both ends and winds aloft and temperature aloft that can be used for FMC data. (You'll also get your estimated average wind at your specified altitude - handy for FMC data.) Leave AS running. Now go back to FSB and your chosen aircraft profile. Enter the surface temperature from your departure METAR, then estimated total taxi time, hold time, and extra time (sometimes called discretionary fuel). Now turn on again your FS9 export along with any FMC export you might use. Rebuild and you'll see the messages regarding the export completion. On the route selection on the left which brings up your route window select the navlog tab and click the .pdf to save the navlog in a file or the print button to get a hard copy so you can easily reference the estimated fuel and other data. This estimated fuel has now taken into account your winds aloft data - no need to enter it in FSB. Now that you have the hard copy and exported your route, you can first optionally save the plan by selecting flightplan window, then clicking the category tab, then select user category. Now click file, save from the menu bar. The name you might want to embellish. Click Save Route To User Flight Plans. For another session, you can recall this working plan and just build.11. If you are using an aircraft with nav equipment that has its own terminal data procedures in its nav equipment (think FMC) you might wish to use step 6 above to take out the waypoints of the terminal procedures keeping just the transition points and build and export with just them. This easily in most cases lets you select the SID and STAR assigned by ATC on your nav equipment by providing a clean legs list in your nav equipment. If you need ATC to monitor the waypoints of the terminal procedure than just export all. To keep ATC and you nav equipment in sync, you might consider importing the full plan into your nav equipment and not using your nav equipment procedure database.This is kind of long but through experience I've described some tricks I've used watching out for any pitfalls.There is a later update for 2.3 not linked from simmarket. From the fsbuild forum that link is:http://www.fsbuild.com/dl/Fsbuild2376_2Upd.exeInstall that if you have a lower version number after your 2.3 update from Simmarket.

[Gabe_62 1]

Thnx for the detailed info.I currently use FS Commander but will look at FSBuild, as I hear good things about it.It is sometimes difficult to match up databases unless you subscribe to the latest AIRACS, so some typ of workaround is always going to be desirable.BUT... I still maintain my original assertion, that RC would signifcantly benefit from including a decent pause between instructions, so that one can actually utilise the available commands AFTER having "acknowledged" an instruction. Sometimes RC ATC is just TOO damn fast and in a hurry to get home for dinner !!!Clearly RC is the best thing out there, and I'm grateful it exists and the support is great... but even the "best" can be improved upon.Unfortunately I know naff all about coding, so I can only 'request' things in the full knowledge of my ignorance regarding the 'practicalities' of such issues! 8-)Cheers.

[jd 57]

Thnx for the detailed info.I currently use FS Commander but will look at FSBuild, as I hear good things about it.It is sometimes difficult to match up databases unless you subscribe to the latest AIRACS, so some typ of workaround is always going to be desirable.BUT... I still maintain my original assertion, that RC would signifcantly benefit from including a decent pause between instructions, so that one can actually utilise the available commands AFTER having "acknowledged" an instruction. Sometimes RC ATC is just TOO damn fast and in a hurry to get home for dinner !!!Clearly RC is the best thing out there, and I'm grateful it exists and the support is great... but even the "best" can be improved upon.Unfortunately I know naff all about coding, so I can only 'request' things in the full knowledge of my ignorance regarding the 'practicalities' of such issues! 8-)Cheers.

i can only help you with your original assertion, if you make a log. i know that it must sound like i'm blowing you off, but 4.3 has been out for quite some time, and there are thousands of users who don't seem to have this particular issue you are having. i can spot little gotchas in seconds, with a log. for instance, do you have pre-recorded chatter checked? if so, uncheck it.without a log, you're not happy, and i'm blind.jd

[DJ 0]

I don't think it is a bug, it is just not realistic in my opinion. It happens to my regularily with RC4, but it never happened in real life.Let me explain: In RC4, if I get a hdg and altitude, I barely have time to readback and set the new hdg and ATC is giving me sh##t while setting the new altitude for not being expedicious enough. The default FS ATC is the same.In real life ATC will leave us more time to enter the new numbers, do our checks and initiate a descent. I have even seen pilots do the pre-descent after getting cleared lower before initiating the descent. I flying orders it says that pilots are expected to comply to the new without delay, anything reasonable. If ATC needs the descent now for traffic they will specify cleared XX altitude or FL start descent now. There is separation between planes and ATC gives cleareances with anticipation.Of course in very busy airspace sometimes things happen more quickly, but then I find ATC nicer in real life than in simulation, ie more polite and professional. In 25 years of flying I never got rude comments from ATC but many times from sim ATC just because I am slow to react... just like in the movies!RC4 is the best ATC simulation and I look forward to RC5.Dan

[Tom Allensworth 1,532]

I hope you can increase the time delays between instruction and complaining...

Obviously, you are not married.

[Gabe_62 1]

Obviously, you are not married.

Hehe....And, clearly you're not married to my missus.... I don't even get the warnings before being reminded how utterly useless I am !!!....

I don't think it is a bug, it is just not realistic in my opinion. It happens to my regularily with RC4, but it never happened in real life.Let me explain: In RC4, if I get a hdg and altitude, I barely have time to readback and set the new hdg and ATC is giving me sh##t while setting the new altitude for not being expedicious enough. The default FS ATC is the same.In real life ATC will leave us more time to enter the new numbers, do our checks and initiate a descent. I have even seen pilots do the pre-descent after getting cleared lower before initiating the descent. I flying orders it says that pilots are expected to comply to the new without delay, anything reasonable. If ATC needs the descent now for traffic they will specify cleared XX altitude or FL start descent now. There is separation between planes and ATC gives cleareances with anticipation.Of course in very busy airspace sometimes things happen more quickly, but then I find ATC nicer in real life than in simulation, ie more polite and professional. In 25 years of flying I never got rude comments from ATC but many times from sim ATC just because I am slow to react... just like in the movies!RC4 is the best ATC simulation and I look forward to RC5.Dan

Yes there is no doubt that RC5 will benefit for increased delays between instructions and reaction. 90% of the time, I barely get time to ARM my MCP for the new crossing restriction altitude when I'm being told off.It happens A LOT. This is why sending logs is pointless. It is hardwired into the program and needs to be tweaked..... End of.The time delays can easily be programed and therefore they can be changed. JD should really look at this as to my mind it the only real bug-bear in the program as it stands. In fact it often ruins the entire experience. And, I know I'm not alone here, but it must be "fixable"... surely ?

[ronzie 21]

If not mentioned, keep the comms. Don't ack a command until you manipulate the aircraft to start turning or changing altitude. Once you have a stable climb (above 300 fpm) ack the command.

[Gabe_62 1]

Thnx for your input.However, the post is clear that we all know the ways of "manipulating" the program... and we all have to do it. Another classic is to massively increase the margins of tolerance for heading deviation, altitude and so forth.The point is: why should we have to ? Particularly when it can easily be fixed.Many people I am sure, are hoping that RC5, may take on board this constant problem of "nagging"... and simply increase time delays to make it more realistic and less like a robot stuck on a futile cycle. An extra 30 seconds between... "instruction" ....... and........ "check to see if user is complying" THEN "tell-off user" ........ I am sure is not beyond the programming skills of JD & Co. It ithe fact that they do not feel this is a problem is what is really worrying. Moreover, it is sad, because I end up switching it off 9 times out of ten and am seriously considering switching over to VATSIM... which I don't really want to to do.Give users a minute to react to instructions... it will rarely make a difference particularly 50 miles from approach.It is quite ironic that at times, RC cannot wait to issue instructions, yet at other times I don't receive "permisssion to land" until I'm over the threshold !!!

[jetlag 65]

I think that horse is clinically dead...