Yes I think this is worth considering. The gateway should be allowed to have a very slow STL drive. So you build/configure it at a planet, make motions, etc… and then it can be slowly flown to the CX. The trip could take 14 days but once in position it’s exactly where everyone wants it to be.
If you need to make changes to it (unlikely) you could fly it back to a planet and make motions again, etc.
In a system with a CX there’s just no reason to have the gateway on anything but the CX.
I don’t think gateways were ever intended to be “one per system”. Not only does that make them too general purpose but it reduces the total number of possible gateways that could be built.
I agree that for systems with a CX people would prefer to fly TO the CX using gateways. However, other than Benten (which for some reason is 4au away from the center of the system) every CX is less than a 2hr flight from the nearest planet so I don’t see that as a big concern.
Some might expect that the primary use of GTWs is to shorten the travel of existing trade routes. In reality, the primary use is to bring together systems that are physically close but require several hops. For example, IA-158b is 36pc away from Antares but only 17pc using a GTW (by way of Heph). Gateways cut the flight time in half. The gateway is still a good deal even if you factor in flying from one of the other planets in IA-158 or from a nearby system like IA-151. The devs did a bit of this a while back by manually creating new links between certain systems. It seems to me that part of the reasoning behind gateways was to give us the agency to do that rather than the devs periodically choosing where to put new links.
I confirm same issue.
Jump Vallis to Verdant (unsure if I am not mistajen another trip) is 1d 8h via GW, and 16h conventional jump + 1500 ncc fee
Check out my Gateway Sweet Spot Visualizer, play with parameter sliders to see how good/bad a gateway route would be. Trust me, your opinion on gateways would be reformed. (I was shocked as well)
*Edit: Updated Desmos link to fix several bugs
My own statistics also come to this same finding. For my WCB & LCB ships (LHP, QCR/RCT, FSE), planetary jump points are in the range of 25m~100m km (depending on various factors), while for CX station jump points is 10m~35m and mostly around 20m km. This means time taken to transit to/from jump point can be 1.5~2.5 times longer
This difference would take away time and distance saved by gateway travel thus when combined it produces a worse flight. Each separation along a gateway route adds one pair of DEP & APP, or a TRA if at different planet. Those STL stages can easily cost a lot of fuel, time and repair materials.
Gateways are not “0” in terms of saving time, instead they’re “(-10)+8+(-10)”. Gateways being located at planets means you would need time to transit to/from planet orbit, which takes time. This is the “(-10)” part and it actually becomes “-10”. But if you’re already at orbit with gates around, the “(-10)” now is hidden. A single hop through gateway is “-10+8-10” due to transit to/from planet before entering and after exiting gateway. A gapped gateway route is worse since every “(-10)” are “-10” and they stack up into something terribly long. But for a continuous gateway chain, ship only transit to planet at the first gateway and transit away from planet at the last gateway, this becomes “-10+8+8+8+8-10” so it gives “22” at the end.
Agree, current state of gateways (network) demonstrates:
First two are fairly straightforward, third one is somewhat similar to what lowstrife said:
The true benefit of gateway is its ability to shorten FTL distance required for a specific route, significantly or even drastically. HRT-ANT is a mediocre yet slightly better than ANT-MOR, HRT-BEN (through central void) actually falls under this category better than other CX-CX links. The most extreme example in this universe is OY-661<->MG-708, a 200+ pc distance down to under 15 pc.
I also made a tool to visualize gateway performance with Desmos, you can check it out here: PrUn Gateway Sweet Spot Visualizer | Desmos
I’d just use it to point out that ANT-MOR would not be very efficient even after fully completed, why HRT-ANT is mediocre, HRT-BEN being better than other CX-CX, and how overpowered OY-661<->MG-708 gate would be:
*Please note that all times below are FTL time, in-system STL time (DEP,APP,TRA) is not considered
If I used more fuel in both scenarios, the gateway would take nearly the same time while the directly FTL flight would take 15 hours so gateways would lose even harder.
I run Katoa-ANT and the Heph-Etherwind gateway slowed me down and cost me money.
Addition of the Katoa-Etherwind gateway should have made this even faster, but the STL time AI1-Heph slowed thing downs.
One option if the Flight Planner algorithm is too complex, is to simply allow us to select which Gateways are used if there are multiple. For example the Katoa-Etherwind one makes sense, but Etherwind-Heph does not.
So for now, with two gateways along my path, its still faster to just fly normal with an LCB.
This is an incredible amount of work and some fascinating software. I don’t have anything to add other than congratulate really smart people in this community.
Should there be a way to select which gateways to use when there are several on your path between origin and destination?
I ask this for two reasons:
1 - some gateways may or may not be an improvement over FTL flights for certain ships especially if you need to do a TRA flight to get to it. If I’m going from Moria to Verdant maybe I’d want to skip the Montem–Sand gateway and just FTL to Sand then use the Sand–Verdant gateway.
2 - gateways at the midpoint might not always be at the same planet which could result in a long TRA flight. For example, there will soon be a gateway link between Gasworld–yi-265j. If I’m flying from Moria to yi-265j then it would make sense for me to FTL to Gasworld and then hop on the gateway to yi-265j. However since there is currently just a toggle button to use or not use gatways, the ship flight computer might have me STL from Moria to Montem, then gateway Montem–Sand, then STL Sand to Gasword, then gateway Gasworld–yi-265j.
There could be other reasons you might want to avoid a gateway - high fees, unreliable uptime, etc.
I think having a pair of systems would be a benefit here. One would be the current system, which just tries to optimize things as best as possible, and goes from there. The fire and forget solution if you will. Then there would be an advanced view, where you could individually edit every segment of the flight, ensuring that it’s as optimal to you as you wanted it. This advanced view could have saved parameters, such as specific percentages for TRA, TO, etc.
