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

Life saver for me as well - thought I was going crazy! Has anybody had any success in fixing this with the AIG Manager? I've also noticed similar behaviour in the Contrail App (but to a much lesser extent). I tried turning off Windows Hardware Acceleration in display settings - no change, however. Cheers

In addition to Bryan's suggestions I can only offer what works in my case. I am using an external speaker and a headset. Bryan and I spent some time trying to work through what might be causing it and ultimately settled on some oddity that cannot currently be explained or determined. I am able to get FS2Crew to work by: Before starting Prepar3D I set my headset to be the active sound device. This is achieved by clicking the speaker button in the lower right hand system bar (between the language and network connection icons). There is an up arrow that you can click that lists available sound devices. In my case, it says "Headset Earphone (HyperX Virtual Surround Sound)" Start Prepar3D Once Prepar3D is loaded, leaving the Windows Sound Device as my headset, in the P3D sound settings I select: Primary Playback Device - My speaker Voice Playback Device - My headset Voice Capture Device - My headset Loading a flight with those settings (and any additional recommendations from FS2Crew) works for me.

Hi Simbol, I can confirm the amended file is now picking up the Orbx models. Thank you for taking the time to look into this. Cheers!

No problems! Yes there is. At the Orbx forums there's a Compatibility Sub-Forum that covers most common airports and what needs to be amended. For FSDT's KLAX you'll find it under the "SCA Compatibility index" thread (it's currently pinned). Be aware you may need to re-apply the fixes after running the Couatl updater. FSDT don't have a manager like Flight Beam's so you'll need to do it manually by renaming the bgls from ".bgl" to ".off". As Dave_YVR said, not sure on that one.