Poor Gateway Flight Times

Gateway Speed Comparison

A lot of people are noticing that gateway trips are taking longer than FTL flights to the same destination. This seems to be the case for all but the slowest ship types. We expect very fast ships to be faster without a gateway, but we’re seeing gateways perform worse on speed, damage, and sometimes fuel consumption. I understand the design might be for: “gateways are only situationally good”, but right now we have “gateways are rarely good”.

There seems to be a few contributors:

  • Long DEP times from gateways when they are used as part of a longer flight.
  • The way STL fuel is distributed among segements when using a gateway
  • Long TRA times from a CX to a gateway

A flight Razenpok shared demonstrates a common poor performing flight from ANT to MOR that takes 3d 8hr.

The highlight here is a particularly terrible time on the ANT to Heph TRA (9.5 hr) and also very long DEP times of 6hr 23m. I believe this is an FSE HCB, so it’s a relatively slow ship (and should be one to benefit the most from gateways).


Here’s an apples-to-apples comparison of a WCB flying ANT to BEN with the default fuel sliders:

With gates:

  • 20hr 20m,
  • 197 STL, 496 FTL
  • 0.431% damage

Without gates:

  • 16 hr
  • 157 STL 754 FTL
  • 0.356% damage

Note how the Ant to Heph TRA is 165m km and is allocated 54 STL fuel to create a 3hr segement. With gateways off, the DEP from ant only takes 18m and is allocated 78 fuel. Despite that, the gateway version uses more fuel in total. I assume this is partly because of the static fuel consumption of LOCK, DCAY, and TRA (is that all intended?)

The DEP from the Griff gate (segment #6) looks like a planetary takeoff.. but it must also be a CHRG because it uses STL and FTL? Honestly sort of fuzzy on these segment types. How much of this can be fixed by adjusting DEP? Why is the STL distance so much longer before jumping from a CX station vs. a gateway- both pieces of space-based infrastructure?

I also note that TakeOff TO from a surface doesn’t have damage associated with it (for a normal planet) but DEP does? Maybe shift most of that damage from DEP to TO since orbital departures should be less damaging than atmospheric take offs?


For 2k ships with poor FTL performance (flying at a mere 1.8 parsecs per hour), most of the gateway time savings from ANT to BEN are eaten up by the TRA and DEP stages:

These should be some of the best candidates for gateway improvements, but only save 1 hour by using a gate at default flight settings. The gateway usage also increases damage by 60%. 100 FF is saved, but an extra 50 SF is needed.

Increasing SF usage equally in this situation can slightly improve the situation in favor of the gateways, as can reducing FF. But if you run minimum fuel, the poor STL behavior dominates and the Gateway route takes 9hrs longer.

At max fuel, the gateway route can be faster, but due to the extra STL segments, SF fuel usage is doubled while using gates.


This image specifically shows how a DEP from ANT is much shorter in duration and distance than a DEP from the Griffonstone gate (traveling through the gate towards BEN).


Generally, planet to planet performance is great, but the gates won’t really be used that way:

Also, we believe longer chained gateways will perform somewhat better (for ships with poor FTL speed) because you only need to enter and exit the gateway network once.


I think this demonstrates gateway performance is worse in more situations than was originally intended. There are a couple possible rebalances that might help. Gateways might suck in ships, reducing the TRA time to the gate. This could happen if ships don’t need to spend half their time slowing down before entering a gate.

The DEP distance could be reduced to be similar to departure from a CX.

Increasing gateway speed above 3pc/hr could help, although it’s not my preferred solution since that’s not the source of the delay. 3pc/hr isn’t terribly high, so there are a lot of engines and fuel settings that exceed that, but the performance failure of the gates is certainly related to STL flights.

Reducing or eliminating SF consumption in TRA, DCAY, and LOCK might help a bit- at least it would make SF usage a bit more comparable.

I’m sure the dev team can also come up with other solutions. I’m looking forward to opinions from other players- including sharing situations where gateway flight performance didn’t meet your expectations.

8 Likes

As far as I understand from some research we did in LMAO, the reason DEP takes longer from the gateway vs. the CX is that jumping away from the gateway uses the planetary jump points, which are almost universally farther away than the CX jump points.

2 Likes

I think it wouldn’t be unfair to see clarified where in the system these Gateways are placed, and because of where they could be placed and the planetary jump points used, they could very well be set in orbits and trajectories that make it more STL fuel intensive to use and worse generally to use (especially if things like micrometeorite [general] damage is worse during STL vs FTL)

I think this is an acute issue that deserves to be addressed. I suspect that some adjustments to how the SF slider interacts with distinct segments could solve a lot of the issue. My biggest concern though is that the solution becomes a bit new feature or dramatic change versus a tweak to existing formulas. Would love to see a narrow fix attempted and then built upon if the future if needed.

3 Likes

I typically set my STL slider around 25% since I find that to be the sweet spot between fuel efficiency and shorter travel times. I also almost always set FTL to 100%. I think the travel times in your GTW vs non-GTW comparisons might be improved by using more fuel. Everyone is different but I am willing to spend more on fuel in order to fly faster.

I don’t think your comparison of GTW vs non-GTW travel from Antares CX to Benten or Moria is fair. Yes TRA time is significant but that is not the fault of the gateway, that is an issue with the gateway location. This also applies to your point about increased ship damage. I would argue that DEP time is not a gateway problem either as that is an issue with your destination. A more apples to apples comparison would be travel from Heph to Benten/Moria… or maybe simply Heph to Griff.

In any event, TRA and DEP are just 10% and 5% of the total travel time so I disagree that addressing them is more important than increasing the GTW 3pc/hr setting. I think setting that to 4 or 5pc/hr would be the simplest and best improvement that can be made (actually, I think it would be nice if it were closer to 10pc/hr but I doubt that is in the cards :slightly_smiling_face: ). The discussion we had on Discord seems to make clear that in many situations GTW travel is only a small improvement over FTL only flight (sometimes worse than FTL flight). For ships with HPR/HYR engines GTWs are rarely a better option. I don’t think it is right that people who spent extra money outfitting their ships with powerful engines are unable to enjoy any benfits from gateways.

PS: I noticed in your example that the WCB ship has about 285t of cargo. A full load would significantly alter STL flight times.

PPS: I don’t know if this is just me. In the blueprint flight test I am unable to turn off the GTW option in order to compare flights with/without a gateway.

What’s the problem? Gateways are bad for short distances. I don’t think this is necessarily a bad thing. They should, in some cases, be bad for short distances. The SFC flight planner needs to be intelligent enough to route you without 17 button clicks, which it currently does not do. It currently defaults to using gateways, if available, even if they are substantially slower and more expensive.

The root “issue” is the orbits of the planets. The gateway is a variable and sometimes quite large distance from the STL origin\destination, and thus require very expensive burns to even get there in the first place. Other times, or like in hortus, it’s extremely close.

This normal “DEP” and “APP” phase of FTL flight is usually quite short, minutes or an hour or two. Rather than 2-24 hours as it exists now. I have seen flight times between MOR <> ANT be 5 days due to this, while being more expensive than the 2 day FTL flight. While this is a temporary example, as the gateway network is incomplete, it does a good job of showcasing the root problem.

I think buffing the speed of gateway travel will make them too overpowered once there are more links online and you’re hopping multiple times. The root problem is that often just getting to the gateway takes longer than the entire FTL flight would take on its own.

3 options imo:

  • Allow gateways to be at cx’s (please let us move them rather than rebuild), eliminating this hugely variable STL transit time (anywhere from 2hr to 24hr). Add a fixed 5 hour “customs check” or whatever makes sense such that short distance (1 hop) gateway trips might still not be faster, but not too heavily penalize the long distance transits.
  • Gateways spit you out at your destination as if you were exiting a normal FTL travel lane - which is to say, a fixed distance from your target with a short but consistent STL transit to your eventual destination. If you’re staying on the gateway network and continuing to use it on another jump, you instead “stay on” and get spit out just as the system works now right next to the corresponding gateway you will be joining. I think this is the strongest choice as it normalizes the flights as much as possible and balances the travel in the way that other forms of travel are currently balanced.
  • Ships don’t need to decelerate before entering a gateway, enormously speeding up the STL transit time to enter the gateway network. However, this might make certain configurations\situations too overpowered, again, due to planets being hugely variable in their distance. I think this is the weakest option.
2 Likes

And on the topic of SFC flight times, this is something that needs to be addressed in SFC flight planner logic. It’s fine if it’s cheaper, and faster, to go to a planet that’s one gateway jump away with really good FTL lanes. Totally fine, I like that being the case. I agree that gateways should not be holistically better in every way.

But I really wish SFC flight planner would interact with this better and would configure gateway use in a manner in which optimizes travel time by default. Because right now the workflow process is:

Enter destination, wait. Toggle minimum FTL fuel. Wait. Toggle minimum +1 tick SF fuel. Wait. Disable gateways. Wait. Enable gateways. Wait. Move SF slider. Wait. Move SF slider back. Wait. Disable gateways. Wait. Send ship.

That is too many steps, especially when it takes 3-10 seconds to recalculate the route these days on every. Single. Change.

This set of example flight plans takes twice as long using the gateway, while also being more expensive. Why? The TRA to get to the gateway takes 24 hours. If you use more SF fuel to speed that leg up, you may as well just fly via normal FTL lanes as it’ll be a lot cheaper.

3 Likes

I don’t think gateways being bad for short distances in some cases is a problem. But they seem to be bad for short distances in many cases. Buffing the gateway travel speed won’t make them overpowered. Considering the point of gateways is to shorten travel times, given the expense to build and operate them it isn’t unreasonable to ask that the improvement be more than merely “slightly faster in some cases”. As it stands, in nearly all cases you’ll get there faster and cheaper by slapping a HPR/HYR on your ship.

Yes, it would be great to have gateways at the CX (I think that is planned for a future update?) but the extra TRA time is not a limitation of the gateway but rather a limitation of your departure location. Also BTW, what’s up with Min +1tick fuel? Add 150SF and you’ll get to the Montem gateway in 4hr instead of 24hr. It’s not that expensive.

i disagree with your first two solution, but i really like the last one, I thought about the same thing but the other way around, you get spit out of the gateway on the far side with a bunch of speed so swapping planets in destination system, or moving to FTL jump points is much much more forgiving. good combination would be to have gateways join together both ends of an STL trip, only speed up in departing system, then only slowing down in destination system, ship enters and leaves gateways with alot of speed.

I 100% agree that the current flight path planner is not up to the task anymore.

I would propose hiding the exact flight path behind a button somewhere, and replacing that list with a list of travel options that are all calculated and presented at once. In the current system, that would be the 4 options (with or without gateways, shortest FTL or least jumps) or less options in case they overlap.

With that new design, players could see at a glance which option makes the most sense and start the flight right away.

3 Likes

Definitely remove damage during GTW flight. We’re already repairing the structure itself, why does the ship also take damage?

To theSTL problems: yeah I think the formula for how fuel is distributed across segments needs work. Though consuming 5 for the GTW related parts makes sense.

2 Likes

Here is a quick and dirty mockup I made by editing some HTML. The values are obviously not realistic, the button would be green and not yellow etc. etc.
But I hope this gets the point across a little better

4 Likes

As it stands, in nearly all cases you’ll get there faster and cheaper by slapping a HPR/HYR on your ship.

To me that’s the point. Gateways should not greatly exceed the speeds produced by QCR or RCT. I’d be OK with an increase to 3.5 pc/h, but much more than that and you’re straying into HPR/HYR territory

2 Likes

Here is a trip from Vallis to Libertas, this should be an easy win for gateways.
Instead, it almost trapped my ship for a day.
I’ve only had one half-decent gateway flight so far and it was directly between two gateway planets.
Honestly, if gateway jumps paid me to take them, I might still skip them.
Actually, maybe gateways could function a bit like MMs and just generate a bit of money out of thin air, whenever people make a jump.

I honestly don’t understand why people are disappointed about travel times when not flying directly between two gateways. That is like complaining that your flight from Washington D.C. to Chicago takes twice as long because you had to drive to and from the airport.

If the gateway isn’t located at your origin or destination then that isn’t a problem with the gateways. It is a problem with where the gateways were built.

Also, the distance from Vallis to Libertas is 20pc with a GTW or 21pc without. These particular gateways aren’t really shortening the route. So unless your ship has a weak engine and flies a lot slower than the gateway’s 3pc/hr then there isn’t a benefit here. (I would reiterate here that since most ships have a speed at least close to 3pc/hr and many are much faster than that the gateway speed should be increased).

There are two ways in which gateways will provide a significant benefit:

  1. Where the origin and destination are two planets that typically have a lot of direct traffic and the route is shortened by a direct GTW flight. For example, Sand and Verdant (15pc with a GTW, 23pc without).

  2. Chaining several together to travel great distances in a way that shortens the total parsecs.

2 Likes

Gateways aren’t supposed to improve the travel time between two points. They are supposed to improve the travel time across multiple hops on long-distance transits.

The trouble comes from the variable and sometimes considerable transit time it takes to get to and from the physical gateway via STL travel.

Removing that element, by going from Monty to Kiruna directly, is quite a big time saver. 7hr vs ~18hr.

More evidence:

You can clearly see that the non-gateway flight is so much faster than the gateway flight even when I reduced the fuel sliders all the way down to minimums for non-gateway.

This makes gateways extremely poorly performing since they cost 100s of millions, weekly upkeep, and VF.

Maybe I missed some big discussion with the devs but yes, gateways ARE supposed to improve travel time between two points. Also, if they don’t improve travel time between two points then how are multiple hops going to improve travel time? That would be like saying, “0+0=0 but 0+0+0+0=11”.

If you have to do STL travel to get to a GTW then it is in the wrong place. Or else you should do the ‘FTL-out then FTL-back’ thing to get to it.

Direct Montem to Kiruna is ONLY a time saver if:

A - you have a slow ship. and,

B - you’re using minimum fuel.

Otherwise, you’ll get there faster without a gateway.

I keep seeing people use examples that include STL flight to/from the GTW and use minimum fuel such as your Etherwind to Benten scenario. Here are three comparisons using Moria to Etherwind as an example (I wanted to do an Etherwind-Benten example but don’t have ships there so couldn’t do a side by side comparison. My example is similar enough to yours although the GTW does cut the distance from 48pc to 38pc which gives the gateway more of an advantage in my example).
All three are the same ship (2k with a HYR) with and without a gateway. The only adjustments are the amount of fuel used.
1 - Minimum SF, 390 FF – The gateway option is significantly slower
2 - 25% SF, 390 FF – The gateway is much faster
3 - 25% SF, 790 FF – The gateway is a bit slower (if this ship had a bigger FF tank I could use a couple hundred more FF and the non-GTW flight would be even faster).

1 Like

Well then gateways should be allowed to be built at the CX, the origin\destination of the vast majority of the flights in the game. And you should be output into the system in the existing locations FTL travel spits you out at. Because as implemented, gateways are basically useless for any location planet in a system other than the one it’s built at. Or, in situations where you’re linking multiple gateways together and traveling long distances.

“You have a gateway in a system? Cool, the outer gas giants are a 3 day STL travel with 500 SF needed to get there.”

2 Likes