Increase the lift factor of all transports

I remember a game maybe a month or two ago that my ACU was thrown maybe 3-4 factories in distance as the transport was killed. Somehow survived too lol

I've been experimenting with using blueprint buffs to modify the flight characteristics of transports based on whether they're dropping off/picking up/flying etc. If there's a reliable fix to be made, I think it's there.

(Hadn't occurred to me before, but the same technique could also address the leisurely pace with which aircraft enter carriers)

@clyf said in Increase the lift factor of all transports:

I've been experimenting with using blueprint buffs to modify the flight characteristics of transports based on whether they're dropping off/picking up/flying etc. If there's a reliable fix to be made, I think it's there.

How would this work? I'm not aware of a way to edit the values on a unit-to-unit basis

A work of art is never finished, merely abandoned

https://www.twitch.tv/videos/1945822700?t=05h58m22s
this was one of the fun moments from the summer tourney

TA4Life: "At the very least we are not slaves to the UI" | http://www.youtube.com/user/dimatularus | http://www.twitch.tv/zlo_rd

@jip

Just from looking at the BuffBlueprint setup (again, not something I've really exhaustively nailed down) it looks like it's possible to set up a couple of different flight profiles ("cruise", "takeoff", "air brake") and apply them on a per-unit basis, like adjacency?

Just curious if this is being worked on?

Transports going over flat terrain: 👍
Transports going over a tiny difference in height: 😵

They're slower when changing altitude than my thought process...

( ͡° ͜ʖ ͡°)

Happened on mapgen for me as well recently. I hope your experiments result in a successful fix clyf, thanks for looking into this.

This post is deleted!

It's on my list, and very near and dear to my heart. Some very general updates:

  • I've become intimately familiar with the OnMotionEventChange functions during some recent work on the Fire Beetle, so I'm confident the front piece--reliably and tidily detecting (read as: without a forked thread) when the transport is landing/picking up/taking up--is possible.
  • The end bit (a working flight profile) has always been possible.
  • That leaves the middle bit, actually modifying the transports themselves on an individual basis.

Just for kicks, the behavior I'm trying to emulate:
alt text
(Ignore the engine failure part, engine failure and descending as fast as possible have a lot in common!)

ziggity:
https://github.com/FAForever/fa/pull/5653

None of that BuffBlueprint bs (that probably won't work, as Jip surmised), but we can bypass the problem entirely by simply telling the transports to unload when they're very close (1-2 ogrids), as opposed to the extremely close currently asked for by the engine (<1 ogrid).

With a little flexibility ("little" as in, a rounding error compared to that introduced by a group unload order) in the dropoff point, we're free to adjust the flight performance parameters to whatever we like. See the Courier in the above PR.

These changes are now live on the deploy/fafdevelop branch. We'll ship it with the next and hopefully last hotfix. Please give it a try and report back here.

With thanks to @clyf for his initiative and effort in this 🙂

A work of art is never finished, merely abandoned

Just tried it and it feels like a huge improvement. Transports are way more responsive, drop quicker and are much faster when traversing mountains. great job!

Thank heavens (and contributors) for this. I, too, noticed this huge delay in drops after flying over high terrain.

The changes by @clyf are released and available on the FAF game type

A work of art is never finished, merely abandoned