First a quick question: Does anyone happen to know what the bottleneck/reason for the super-cruse -> normal-space transition delay is?
For me it's usually 2-5s in solo when changing between super-cruise -> normal-space. The transition feels a little like a "loading screen" but I'm sure it's more complex than that, i.e. super-cruise -> pause/load/etc -> normal space.
Now on to the suggestion/feature request: Whatever the cause of that switch delay is, I wonder if it's possible to do the bulk of it in the background by having ED try to predict where the player is most likely heading and start that process going as they approach.
It wouldn't catch all cases (such as emergency stop), but the A->B way-point trips might be helped by it. Here's a scenario or two:
1) I pop out in my target system and my nav selection is already pointing at the station as the next way-points to follow. As I get within X LS of my selected destination ED starts to prepare the bulk of what's needed for the area I'm heading to.
2) I'm in super-cruise and am flying toward my destination. ED rolls an NPC pirate encounter, but before starting the interdiction mini-game, begins setting up what's needed for the normal-space encounter should that interdiction escape fail (e.g. player submits for a quick getaway). Then after the bulk of that work is done, begins the interdiction mini-game.
3) I'm on approach to some planet that I'd like to land on. A way-point marker isn't necessarily set (but may be the planet I'm heading to if so). As I enter orbital cruise ED starts to pull in any plant-side data it needs, and as my orbital cruise height gets lower starts to gather more data local to the candidate area I might pop out in.
I'm not sure how viable figuring out a general solution to (3) is, but (1) and (2) seem reasonable. For (3) it could be that things like planet-side way-points are required to constrain the pre-load candidate to a single location (i.e. the pre-load area is in the area where you put the marker).
That's if there's anything that can actually be done, of course. If background preparation effectively does something catastrophic like doubling ED process resources, or doubles the central transaction server load/bandwidth use, etc, then obviously that's not a great thing to do
Otherwise, this seems like it might be a solvable problem in some way, and if not I was curious what the problem actually involves to made it a difficult one to solve.
Has this been discussed before? If so I'd find any related links/tech/dev talks interesting on this topic if you happen to have any handy.
For me it's usually 2-5s in solo when changing between super-cruise -> normal-space. The transition feels a little like a "loading screen" but I'm sure it's more complex than that, i.e. super-cruise -> pause/load/etc -> normal space.
Now on to the suggestion/feature request: Whatever the cause of that switch delay is, I wonder if it's possible to do the bulk of it in the background by having ED try to predict where the player is most likely heading and start that process going as they approach.
It wouldn't catch all cases (such as emergency stop), but the A->B way-point trips might be helped by it. Here's a scenario or two:
1) I pop out in my target system and my nav selection is already pointing at the station as the next way-points to follow. As I get within X LS of my selected destination ED starts to prepare the bulk of what's needed for the area I'm heading to.
2) I'm in super-cruise and am flying toward my destination. ED rolls an NPC pirate encounter, but before starting the interdiction mini-game, begins setting up what's needed for the normal-space encounter should that interdiction escape fail (e.g. player submits for a quick getaway). Then after the bulk of that work is done, begins the interdiction mini-game.
3) I'm on approach to some planet that I'd like to land on. A way-point marker isn't necessarily set (but may be the planet I'm heading to if so). As I enter orbital cruise ED starts to pull in any plant-side data it needs, and as my orbital cruise height gets lower starts to gather more data local to the candidate area I might pop out in.
I'm not sure how viable figuring out a general solution to (3) is, but (1) and (2) seem reasonable. For (3) it could be that things like planet-side way-points are required to constrain the pre-load candidate to a single location (i.e. the pre-load area is in the area where you put the marker).
That's if there's anything that can actually be done, of course. If background preparation effectively does something catastrophic like doubling ED process resources, or doubles the central transaction server load/bandwidth use, etc, then obviously that's not a great thing to do
Otherwise, this seems like it might be a solvable problem in some way, and if not I was curious what the problem actually involves to made it a difficult one to solve.
Has this been discussed before? If so I'd find any related links/tech/dev talks interesting on this topic if you happen to have any handy.
