pilot87

I'll have to let him further address his issues. @mikealpha I'm gathering you didn't notice the spark issue during your beta test? It's more than just the sparks issue: Sparks Whilst the actual pushback path is smooth, the tug is all over the place (as referenced and evidenced in the other thread) The inability to pre-position the pushback tug whilst GSX completes it's actions - this is a loss of core functionality over v2.3

I appreciate that, however as I described in great length in the "sparks" thread, there are other significant issues introduced with v2.4 regarding the behaviour of the pushback tug. Manuel has said: and Both of these comments are after "v2.4 final" seems to have been published. The whole experience of v2.4 has been very disappointing compared to v2.3 and I'm imagining it's all of this why mikealpha requested an option to download v2.3.

I just downloaded UGCX from the legacy website again and the installer is reporting: This is before the date of the thread Manuel references above where we had the discussion about sparks and other issues with v2.4. There is no mention of "final" in the installer. The configuration manager reports the installed version as "Config Manager - Version 2.4" with no reference to "final."

As a contributor to the thread referenced, is the selection of "Create ground crew as vehicles" Unchecked/Unmarked considered the official fix or only a temporary fix? I understand that essentially UGCX development has ceased, however for me (and seemingly mikealpha), v2.4 has been a backwards step in quality and usability. With all due respect, unchecking/unmarking that option does not revert functionality in the same way that actually occurred in v2.3. In v2.3 I was able to utilise GSX and UGCX together without conflict or additional steps. With that option checked, UGCX will not generate objects with GSX active meaning an additional step is now required prior to pushback. In the thread referenced, you alluded to potentially working on a fix to allow GSX and UGCX to function together as it did within v2.3 - is this still in the works? Cheers,

I was using the freeze movements method but just tested the other two and the pushback behaviour was identical to that previously described.

Ok - I think we're getting somewhere here! Adding a checkmark to "Create ground crew as vehicles" in UGCX Settings window seems to have corrected a lot of the odd behaviour: PMDG 777-300ER (Schopf) and Aerosoft A321 (TMX150) No erroneous effects/walking animation present Tug wheels briefly went hard left and right (aircraft didn't react - continued straight) when initiating pushback but otherwise went smoothly Initiating turn, tug seemed to almost go to 90° which seems a bit aggressive to what it should be Pushback stopped not quite aligned with taxiline - tug offset 45° to push back direction with front wheels only in hard left turn (again seems like computer route is not quite pushing back far enough to allow complete straightening of tug and aircraft); TMX150 had wheels locked in a hard right turn

Under normal circumstances I would however, during testing for this issue I haven't worried about activating GSX (it's present in my sim, but not actually in use/loading simobjects). The behaviour seems to be random each time. Some random photos from the 787, A321 and 777-300ER QW787-9 Schopf First pushback: Walking animation, with spray effects Sparks from Schopf tug Wheels locked hard right but after some initial craziness straightened up Pushback commenced - tug, towbar and person bounced around all over the place. Aircraft appeared to pushback smoothly. Appears as though UGCX simobjects were bouncing over invisible objects. Sparks, splash and engine spray effects QW787-9 Schopf Second pushback (new P3D session): Walking animation gone again Sparks, splash and engine spray effects Schopf wheels locked hard right but then straightened up for push Towbar did not respect offset location - remained at same height as initial generation 90° turn, tug and towbar disconnected and moved independently of actual turn. Stopped at 45° opposite to turn Aerosoft A321 Comet Pushback (new P3D session): Sparks generated from both tug and person on initial generation Wheels straight (not locked hard right) Walking animation returned but no pumping tow bar animation (I may be recalling incorrectly but I believe this used to be present?) Towbar did not respect offset location - remained at same height as initial generation Pushback had sparks generate at random intervals during pushback 90° turn initially went ok but then when straightening up tug remained offset 45° opposite to turn holding nose wheels offset as well (despite moving backwards straight). After stopping nosewheels went straight but tug and towbar were disconnected and tug remained at 45° offset angle when asked for brakes to be set. Aerosoft A321 TMX150 Pushback (new P3D session) [First]: Sparks generated from both tug and person on initial generation Wheels locked hard left turn Towbar bounced around all over the place as tug moved towards connecting eventually settling 2m offset to the Captain's side at connection Walking animation returned but no pumping tow bar animation (I may be recalling incorrectly but I believe this used to be present?) Pushback abandoned at this point Aerosoft A321 TMX150 Pushback (new P3D session) [Second]: Sparks generated from both tug and person on initial generation and move from generated position to connection point Wheels straight until stopped then locked hard left turn Towbar did not drop to profile offset Tug and towbar vibrated whilst waiting pushback instructions Walking animation present Sparks generated at random intervals during pushback from both person and tug Halfway through pushback but before turn, tug and towbar bounced around violently and completely separated, person moved from aircraft side to side After bouncing around, doing loops rolling upside down, tug completely disappeared offscreen At stop position - tug was nowhere to be seen. Person was about 20m in front of aircraft, towbar reconnected but was vibrating and generating sparks at random intervals Tug did not reappear when disconnecting towbar Pump action present (despite towbar not being at set offset height) Towbar disappeared after disconnection PMDG 777-300ER Schopf (new P3D session): Sparks generated from both tug and person on initial generation Wheels straight until stopped to connect towbar then locked into right turn Engine spray effect behind person Walking animation present Person and tow bar vibrated At initial start of push, tug moved right then left then straight - pushback remained straight Wheels faster than tug speed Stop position, tug was still offset in turn Interestingly, despite the random effects it appears as though the PMDG 777-300ER was the smoothest and otherwise problem free pushback. In all cases I was using the computer generated route. It almost feels like the pushback is not going back far enough to allow the tug to straighten up properly. Profiles as follows: QW 787-9, Aerosoft A321 and PMDG 777-300ER Yesterday I reset the offsets for a different livery. This was how the offsets for the QW787-9 appeared on first load. It also appears that the towbar offset isn't saving properly between sessions. I can see the XML file changing when saving, but I had to reset it again between the first and second Aerosoft TMX150 pushback. As you can see, it's quite random and sporadic in what actually occurs with the only consistent being the random sparks and spray effects playing. I certainly don't recall any of this behaviour being present in v2.3 it's definitely quite odd!!

Hi Manuel, First install was over top of existing, reinstall was an uninstall/reinstall. I may have missed restarting after the uninstall though (can't recall) so have just completed an uninstall-restart-reinstall. The walking animation appears to be back, however: there are two spray effects behind the person as they move (one on the left, one on the right) Tug doesn't bounce on generation but is vibrating and not moving smoothly with the towbar Sparks still showing Tested with Schopf - front wheels still locked hard right I'm also not sure it's reading the aircraft config properly as every aircraft seems to have the tow bar position significantly behind the nose wheel. I know I can move the offset but I don't recall that being as much of an issue in the previous version (i.e. I may have had to adjust one or two aircraft, not every aircraft and every livery). Log below (AppData path is my name not "*****", have edited for privacy): Cheers!

I'm seeing this behaviour too using P3Dv4.5.14.34698. Tried a reinstall to no avail (confirming anti-virus off, etc). Behaviour I'm witnessing: Tug and tow bar seems to bounce violently when first generated Tug slides forward separate of tow bar, both generating spark effects when moving Tug front wheels are turned hard to the right and don't centralise Person slides forward towards aircraft with no walking animation - spray effect (I think!) seems to play as the person moves Attempting to push back - sparks effect plays and tug makes an immediate hard turn to the left (tail right) before then straightening up Repeatable at different parking bays/different airports, different aircraft (have tried QW787, Aerosoft A320 Family, PMDG NGXu) Wheels moving faster than tug (Schopf) Behaviour less obvious conducting a tow operation Behaviour doesn't occur (sparks effect plays briefly on first generation) if previously run a pushback or tow operation in the same session Behaviour doesn't seem to occur with PMDG 737 NGXu, however spray effect plays on first generation of tug (clear skies/no rain) and when hooking up during a tow operation the wheels are crooked (right hand turn) however aircraft and tug move straight once moving.

Ah yes, I see now that the original [Lights] section is edited by AILRP and therefore not reflective of the original. I have followed the steps and now the wingtip strobes are gone. I'm imagining that any updates via AIM-OCI will overwrite that, so may raise that with AIG as well. Many thanks once again for your fantastic and expeditious support!!

Hi Simbol, Hope you're staying safe and healthy! I wasn't able to find any reference to this, so wondering if perhaps there's something not quite right with my setup. It is my understanding (and observation) that the 100, 200 and 300 series Dash-8's utilise a vertical stabiliser rotating beacon and traditional wingtip strobes however the Q400 utilises a single top flashing red beacon (recognition light and combination vertical stabiliser/bottom fuselage strobe (or anti-collision light as Bombardier call it) with no wing tip strobes. The AOM I have confirms this. With AI Lights Reborn, there are wing tip strobes flashing with the tail/fuselage strobes and the configuration seems to confirm this, with strobes listed with 4 different positions: [FSREBORN_LIGHTS_CTRL] light.0=3, 3.55, -46.64, 0.35, fx_navred light.1=3, 3.55, 46.64, 0.35, fx_navgre light.2=2, 4.05, -46.65, 0.35, fx_strobe light.3=2, 4.05, 46.65,0.35 , fx_strobe light.4=1, 9.25, 0, -9.85, fx_strobe light.5=1, 18.51, 0, -1.28, fx_beacon light.6=1, -48.5, 0, 13.1, fx_strobe light.7=3, -56.3, 0, 12.2, fx_navwhi I imagine I could delete the two entries that have similar positions to the navigation lights and renumber the rest but I'm wondering what controls this? Is this something connected with the attached objects of the TFS model or is this something that AI Lights Reborn determines from an internal directory? I also imagine that doing this would be overwritten anytime I run the apply settings function in the future? The lights section of the aircraft.cfg seems to suggest that it's a function of AI Lights Reborn as only one strobe position is listed: [lights] //Types: 1=beacon, 2=strobe, 3=navigation, 4=cockpit, 5=landing light.0=3, 3.55, -46.64, 0.35, fx_fsreborn_navred2836 light.1=3, 3.55, 46.64, 0.35, fx_fsreborn_navgre2836 light.2=2, 0, 0, 0, fx_fsreborn_stcs2836 light.3=1, 18.51, 0, -1.28, fx_fsreborn_beacon2836 light.4=3, -56.3, 0, 12.2, fx_fsreborn_navwhi2836 I know text can hide tone so I wish to assure you that I am in no way complaining, to the contrary the lack of reports leads me to believe an error on my part or set up. Are you able to advise how AI Lights Reborn handles this allocation? If relevant I have the Professional Edition and the version number is currently showing 1.36.0 Kind regards, Haydn

Absolutely! And you're most welcome. Best of luck with the PPL - if you elect to continue past that you will develop a love/hate relationship with the law docs for your exams (definitely speaking from experience there!!! haha)

Sam - I see where the confusion has come from. Directly from CASA's website: CAAPs are basically not regulations but if you choose not to follow it and have an incident, you'll have a lot to answer for. You'll see that to conduct Low Visibility Operations (anything less than CAT I minima) as per CAAP EX-01, it requires a specific exemption issued by CASA and an operator would need to submit the application for a LVO exemption based on the criteria spelled out in that document (intent to train and qualify crew, etc). The document lays out the criteria that would need to be addressed (as I stated previously: risk mitigation) to be considered for an exemption. Part of that would include spelling out how the operator intends to ensure flight crew proficiency which is where CAAP EX-02 comes into play. This document provides guidance to operators on what procedures they would need to develop to ensure flight crew proficiency. It's important to note that proficiency is relevant in more than just autoland procedures - under Australian regulations if you haven't completed an ILS (practice or real) within each 90 days and you're faced with the prospect of needing to do one to safely land - you legally can't! You are quite correct that CAR 215 provides the regulatory guidance for what CASA requires operators to place in an operations manual. This allows operators a guide to build the manual for approval so they're not left guessing. Why is so much of it based on manufacturer specifications? Will that's simply because they are the ones who have the data necessary to determine what the aircraft is actually capable of. An airline that flies 737's, 767's and 747's would have a different operations manual for each aircraft. So if you were writing a manual for a new aircraft the best place to start to collect the information CASA requires for an operations manual would be the person who has all that information - the manufacturer. I certainly was not attacking your experience levels, everyone here has different levels of knowledge and the only way to get answers is by asking questions. I was more reinforcing that these a hugely complex aircraft, that despite flying the same way as smaller aircraft, require a lot of training and experience to fly safely outside of a simulator environment. And you're most welcome! Jaime - No problems! It's not so much a "take" as it is technique or knowing from experience. You could fly into the same airport on the same day 5 times and it could be different in 5 different ways. Flying is an extremely dynamic and fluid environment - no two flights are the same! As you stated in your third point a smooth landing in trying conditions is far more satisfying than a smooth landing in good conditions where it is more or less expected. A particular technique as long as it doesn't contravene regulations or operations manual is not wrong.... just different. The same as two people driving a car won't drive it in exactly the same way even though they're still complying with the road rules and limitations of the car.

The FCOM and FCTM are both fantastic references for a lot of questions! I would respectfully disagree with that statement. The regulations are separate to the operations of the aircraft. In Australia we have the Civil Aviation Act (CAA), Civil Aviation Regulations (CAR), Civil Aviation Safety Regulations (CASR and meant to eventually replace the CARs), Civil Aviation Orders (CAO), Civil Aviation Advisory Publications (CAAP), Aeronautical Information Publication (AIP), Departure and Approach Procedures (DAP) and En-route Supplement Australia (ERSA). These documents all describe the safe operation of flight independent of the aircraft in operation, whereas the aircraft flight manual or standard operating procedures are completely dependent on the individual aircraft to which they apply. SOPs would also be required to not contradict anything written in the suite of regulations provided by CASA. If an airline wanted to amend a procedure it would need to speak to the manufacturer to ensure they were not making a change that could adversely affect the safe operation of the aircraft and then provide CASA with significant information to prove why the change is needed and what actions they are taking to mitigate any associated risks introduced by the change. SOPs cannot contradict the regulations unless a dispensation is sort. Essentially regulations apply to every pilot operating in Australian airspace, whereas SOPs belong to the aircraft and more or less tell the crew how to operate the aircraft in a state that is compliant with the regulations. As far as what a pilot does with respect to each categories procedures, I think you will struggle to find a specific answer to that question. SOPs are not designed to be all-encompassing and assume a certain level of knowledge and experience - a product of many years of training. The FCOM states the minimum altitude that the autopilot must be disconnected by however no maximums. An autopilot is simply a device to reduce the workload of the flight crew. You can fly a 737 without an autopilot. In that circumstance the autopilot would never be engaged and the whole approach would be flown by hand. That would obviously restrict the type of approach you could fly (i.e. CAT III would not be available). You could ask the same question of 20 pilots and get 20 different responses. Remembering that it's an aid to reduce workload, the answer of when to disconnect is really "am I ready to assume full responsibility for aircraft manipulation?" I use manipulation as a pilot is never not "flying the aircraft," even with the autopilot engaged they are always monitoring and ensuring the aircraft is doing what you require it to do. Increased automation can also result in a huge increase in workload and pilot attention so in some cases it is better to just disconnect and fly the aircraft. Absolutely correct. Any instrument approach (other than CAT III autoland) is designed to get you to a point where you can achieve the required visibility to safely land the plane. An excerpt directly from the Aeronautical information publication which applies to all aircraft operating in Australia (with my bolding):

Hi there, As far as I understand, the requirement to disconnect the autopilot is based on a limitation in the system rather than a regulatory requirement. To my knowledge, Australia does not specifically certify aircraft instead electing to adopt the type certificates issued by the FAA/JAA. The type certificates would be issued based on a set of SOP's (in this case Boeing produced) which could be adjusted by an operator however that is usually done through consultation with both the regulator and the manufacturer. If you have a look in the NGX FCOM volume 1 limitations section (page L.10.5), it lays out the requirements to disconnect the autopilot both under FAA and JAA regulations. As to which one Australian operators utilise, I am uncertain and could vary between the few operator of 737. If you then pair that with the FCTM which states that a CAT II approach may be flown with either Single or Dual Autopilots engaged and that a CAT III is based on the approach and landing being flown with the automatic landing system it provides some good guidance to your questions. Unlikely. Flare is a pretty critical part of the landing process and adjusting from autopilot to manual control at that point would be unlikely. Possible. I was taught in my training to wait for a few seconds for your eyes to adjust from the instrument scan to the visual scan. Remember that in a real aircraft your eyes have to adjust from instruments roughly 50cm away to the runway landing environment perhaps 1-2km away (which is where HUD comes in handy!). It's also worth noting that on a CAT I or II approach, as per the regulations, if you are not visual (cloud or visibility) you must conduct a missed approach. That varies with a CAT III approach that has significantly reduced visibility requirements and is planned with an autoland anyway. Based on the information in the FCOM-1, yes. If the crew were using the ILS for guidance on a visual approach they may elect to still fly the instruments either with the autopilot on/off or even flight directors on/off for proficiency and currency. Flight crew must remain current on the instrument approaches to be able to fly them in bad weather. Visibility would not normally effect the decision to disconnect the autopilot from a regulatory stand point but may with the individual. The visibility would however determine which approach was to be flown (i.e. if it was below the requirements for a CAT I approach then you would fly the CAT II ILS instead). That being said, there are aircrew training and checking requirements (in addition to the aircraft being certified) to fly II and III ILS approaches. CASA approval and training in a full motion simulator is required to fly a CAT II or III approach in Australia by Australian crew. I would say that the information you have with the CAT I in good weather is somewhat correct but not completely. Given an ILS to fly is certainly safer in terms of runway aligned approach with a standard 3 degree profile. As you quite correctly stated, it is a preference rather than a requirement. Sydney airport prefer a visual approach via the ILS due to the parallel runway operations. It may also serve as a requirement in the conduct of a visual approach at night (not below the glidepath with less than full scale localiser deflection) amongst other items. There is however nothing stopping a crew during day operations from simply looking outside and flying the aircraft without reference to an instrument approach. Hope that answers your questions. Just as a side note, PMDG require all posts within their forums to be signed with your first and last name either via a signature block or separately - even if your username is your real name.