Ship won't jump even tough target is locked

[Martin Shepard]

Hey there,

since the hotfix a few days ago I infrequently have the problem that my ship doesn't want to jump to the next system but wants to go out of supercruise even tough the next system is locked as target. I have to press the button for the next target on my route to get it working again. I use different keys for supercruise and jump. I never had this issue before in my 900 hours of playtime. I didn't change my bindings.

Martin Shepard

 

[Anticon]

Hm. Have you double-checked that your bindings are the same, even though you didn't do anything? Otherwise, how about validating files?

 

[Templar01]

That is strange. I have had issues too.

Two things come to mind. Did you try making a copy of your bindings and then doing a simple change to your bindings and operating on the new version?

I have noticed in the last nine months that some of my bindings seem to revert back to their previous settings. I've even logged the difference between copies of the bindings file and have been able to document these discrepancies. My problem is that like yours, my experiences are random and I cannot reproduce them.

Second, can you do a screen recording so we can see what you see? If you're not using the NVidia "instant replay" DVR feature or its AMD equivalent, I suggest turning it on.

 

[wenkman]

well, not exactly the answer to your question, but i have different keys for supercruise and hyperjump.

so no dropout when you want to jump, and you can go to supercruise even if you have selected a jump target.

 

[Martin Shepard]

Hm. Have you double-checked that your bindings are the same, even though you didn't do anything? Otherwise, how about validating files?

Yes, I did.
Today it didn't happen. I will have an eye on this issue.

well, not exactly the answer to your question, but i have different keys for supercruise and hyperjump.

so no dropout when you want to jump, and you can go to supercruise even if you have selected a jump target.

As I said in the first post, I already have this since day one.

That is strange. I have had issues too.

Two things come to mind. Did you try making a copy of your bindings and then doing a simple change to your bindings and operating on the new version?

I have noticed in the last nine months that some of my bindings seem to revert back to their previous settings. I've even logged the difference between copies of the bindings file and have been able to document these discrepancies. My problem is that like yours, my experiences are random and I cannot reproduce them.

Second, can you do a screen recording so we can see what you see? If you're not using the NVidia "instant replay" DVR feature or its AMD equivalent, I suggest turning it on.

I checked the bindings. It was like it has to be and how I set it up. I will make a video the next time this happens.

 

[Cmdr. Cavit]

Hey there,

since the hotfix a few days ago I infrequently have the problem that my ship doesn't want to jump to the next system but wants to go out of supercruise even tough the next system is locked as target. I have to press the button for the next target on my route to get it working again. I use different keys for supercruise and jump. I never had this issue before in my 900 hours of playtime. I didn't change my bindings.

Martin Shepard

I'm having the same issues and I'm quite sure it has nothing at all to do with bindings. I seems more like ED loosing the jump destination information, it just acts as if there was not destination selected at all.

Additionally, I've noticed that the game, at least on PC, is currently having problems when engaging SC, staying in conventional flight mode for a long time although the countdown to SC is already at 00:00:00, eventually recovering OR leading to a connection error. And no, that error is NOT on the player's side, as you can re-enter the session immediately from the "Continue" main menu. So the game does not loose the login session, as it appears (for example) on a complete disconnect or IP address change on the player's side.

I'm NOT having the same issues with the countdown to Hyperspace Jump, that - once it starts charging - works fine.

I'm using separate controls for SC and Hyperspace Jump as well, btw.

o7
Cmdr. Cavit

 

[sinisalo]

Just covering all bases here, but are you using a wake scanner prior to the issue popping up?

The reason I ask is when you scan a wake it shifts to the target's destination. And perhaps, if a ship did this without the jump range to follow it might just do nothing at all when attempting to high wake out?

 

[Templar01]

I'm having the same issues and I'm quite sure it has nothing at all to do with bindings. I seems more like ED loosing the jump destination information, it just acts as if there was not destination selected at all.

Additionally, I've noticed that the game, at least on PC, is currently having problems when engaging SC, staying in conventional flight mode for a long time although the countdown to SC is already at 00:00:00, eventually recovering OR leading to a connection error. And no, that error is NOT on the player's side, as you can re-enter the session immediately from the "Continue" main menu. So the game does not loose the login session, as it appears (for example) on a complete disconnect or IP address change on the player's side.

I'm NOT having the same issues with the countdown to Hyperspace Jump, that - once it starts charging - works fine.

I'm using separate controls for SC and Hyperspace Jump as well, btw.

o7
Cmdr. Cavit

Now that error sounds completely different from the original description by the OP and matches some troubles I was having last year.

In my case it was definitely a sever connectivity issue and I can prove it. The symptom I had was that once I commenced countdown, the frameshift drive would engage into a jump. Then it would stay in that load screen until the connection timed out. I think it was "Orange Sidewinder" or something like that. I restarted the game and it happened again. This was going on all night. I did screengrab of the server address on the game launch screen in order to document and report it to FDev. However, before I did that, on a hunch I used a VPN connection to change from a North American IP address to one in the EU and the game ran stable for the rest of the night.

The next day everything was back to normal so I just chalked it up to network congestion on the North American server I was connected to and never reported the incident to FDev. I may still have the original video that I record such errors but truth be told, it would take hours to scour through all the video I record. So unless it has any value to anyone, I'll hold off on posting it.

Now the questions I have is this:

1. What platform were you running on? PC? XBox?
2. What service were you authenticating with? Steam? Epic? Frontier? XBox? etc.
3. What part of the world was your connection based? North America? EU, UK? etc.
4. Did the problem go away on its own or did you have to get FDev involved?

 

[Cmdr. Cavit]

Now the questions I have is this:

1. What platform were you running on? PC? XBox?
2. What service were you authenticating with? Steam? Epic? Frontier? XBox? etc.
3. What part of the world was your connection based? North America? EU, UK? etc.
4. Did the problem go away on its own or did you have to get FDev involved?

1. PC only
2. Primary Account: FDEV
2. Secondary Account: Epic (which was a nightmare regarding login / authentication timeouts in general for the frist weeks, but that's another story)
3. EU (Germany), and usually a very good and reliable VDSL2-Connection (stays active for months unless maintenance is done) with 175 MBit/s down, 40 MBit/s up and very short pings (around 15ms)
4. Did go away. Fortunately. FDEV claims to have a very good support, but I cannot confirm that, depends on the actual case very much. Problem was active at the time of my post, was gone next day.

Additionally, I need to point out that the problem existed on two (nearly identical) computers standing right next to each other, both running ED at the same time. On both systems, ED is configured to use different ports for peer-to-peer communication and my router is configured to pass through these ports from the external IP address to the corresponding internal IP addresses of these two computers. It's all classic IPv4. This setup usually results in quick SC / Hyperspace Jump engaging and dropping out. When both ships are at the same station, seeing each other works fine most of the time, so they're in the same instance.

Before you ask: Yes, I'm an IT professional. ;-)

Just covering all bases here, but are you using a wake scanner prior to the issue popping up?

The reason I ask is when you scan a wake it shifts to the target's destination. And perhaps, if a ship did this without the jump range to follow it might just do nothing at all when attempting to high wake out?

Nope, I didn't. I am well aware of what you describe, but that is not the cause of the problem here.


o7
Cavit, out.

 

[metatheurgist]

The delay at jumping is a server issue. It's taking longer than usual to matchmake the next instance, either in cruise or the next system. Usually this means you will soon get a disconnect but sometimes it muddles through.

 

[Templar01]

Thanks for the details. I'm inclined to point the finger at the pathway to the servers you're connected to. You wouldn't have by chance performed a tracert while connected and saved that log, have you? And yes, I know tracert doesn't prove anything but it can be used as a canary in the coal mine for network routing issues. It would be worth tracking this and comparing results over time. I've done precisely that during network performance issues before, not just FDEV's servers. Once you have a baseline of logs during good "Internet weather", it becomes obvious if there is a clog in the upstream pipeline. As an IT professional you of course realize it only takes congestion at just one node during your packet transport to cause latency issues that sometimes will thwart any client-side program.

You seem to have an enviable test bed that few have. By having two near identical computers connected to the same pipe on the net is about as good as it gets for diagnosing server issues.

Here are some questions that I'd be curious about:

1. Does this issue happen on both computers simultaneously?
2. When it happens, can you reproduce this issue?
3. Have you noticed if one time of day or day of week is more prone to this kind of failure?
   1. That would indicate traffic congestion on your local section of the net. Don't rule this out. I've noticed in my area of the globe, that right after Christmas for example, I saw a measurable slow down and increase in latency via the various private test servers I use at my company, for which I know precisely how busy that server is so I can rule out that server being congested.
4. Are you able to run two instances authenticating from the same service? So two FDEV's or two EPICs?
   1. I ask because your description might be explained by losing contact with the authentication server. In the handful of cases where I was having a similar problem in ALL not some but ALL of those cases, I was not able to relogin right away because I couldn't authenticate. I had to wait a few minutes which is why I suspect network connectivity in your circumstance.
5. Can you connect one of the other computers via either a VPN or better yet, can you connect them via a Mobile network?
   1. Having ruled out the computer and your local LAN, the next thing we want to rule out is your pipe to the Internet.
   2. When I suspect that my ISP or Internet connection is suspect, I create a second connection and verify that the route is different via tracert. You'd be surprised at how many times my cell tower is actually routing through a near identical path where as a VPN is rarely the case.
6. And as a long shot. Have you tried using your router's default mode. As an IT professional please don't be insulted by such a mundane suggestion but sometimes Ockham's razor prevails.

BTW: If you don't have a VPN as of yet, the one service that I found that worked well for precisely situations like this was NordVPN. There are many out there and if you have one that works, then fine but NordVPN worked in all my test scenarios whereas when I tested 6 others, each was blocked as an anonymizer by one service or another at random times. I personally have only two to use-cases for using a VPN, the first is to bypass Netflix Geographical embargo on certain content. The second is this precise scenario. What's nice about it in this scenario is that their applet sits in the system tray enabling you to quickly change your IP address to any part of the world and change your packet routing in seconds. What's more, as of this writing, of all the seven VPNs I've tested, they were the only one that passed the Netflix stealth test whereas the other 6 failed either 100% of the time or greater than 50% by Netflix as being "anonymizers". I've been using it for three years now with Steam and FDEV without restrictions.