Increase the lift factor of all transports
-
The problem is not with the transports, but with the maps:
In particular Point of Reach; the game is not made for such tall and steep mountains. Compare these maps with 99% of the maps made by GPG and you'll see that they barely, if ever, contain these large and steep mountains.
-
Yes but my point is that such maps already exist and are played. If fixing transports doesnt affect the balance, then whats the issue? Its that, or suffering on them (and all other maps with steep hills, actually i'm not sure how big the hill should be to affect transports), or removing such maps from map pool.
-
We adjusted the statistics of the transports to make picking up and dropping off units more reliable (on the average map). Units inherit the velocity of the transport as they are detached when dropping them off. If the transport lands too fast (lift factor) then the units can fly off quite a distance (1 to 3 land factories far). If they end up in a mountain, a large field rock, a structure or some other unpathable bit of terrain then they are destroyed upon contact with the terrain. That is why the lift factor is quite a bit lower than before - it almost guarantees that the transport is only moving vertically upon dropping.
That's the problem
, as always: I'm open to a (different) reliable fix to both (reliable landing and quicker lift off) problems. But I'm not going to spent time on it when the current solution only impacts maps that look like this:
-
Also noticed that issue even on map gen it happens. Is there an acceleration for this one?
-
Also i noticed that t3 uef transport has lift factor of 4, which is already much more human, and apparently it has no issues offloading units.
-
@Tomma isolating properties won't work towards a solution; the continental is at a higher average altitude and therefore has more time to stabilize before dropping units.
-
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
-
https://www.twitch.tv/videos/1945822700?t=05h58m22s
this was one of the fun moments from the summer tourney -
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:
(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/5653None 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
-
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.
