Forums » Bugs
After loading into the universe, I experience a long delay before being able to perform any actions in-game.
I've been having this issue for a while, I live far away from the server, and I've only ever seen one other person complain about it in chat so I've left it alone for the time being.
It takes a minute or two of being in the universe before I can dock, undock, buy or sell commodities, jump to another sector, and see chat messages from other players.
I have a 100 mbps download / 50 mbps upload, FTTH Connection
I've been having this issue for a while, I live far away from the server, and I've only ever seen one other person complain about it in chat so I've left it alone for the time being.
It takes a minute or two of being in the universe before I can dock, undock, buy or sell commodities, jump to another sector, and see chat messages from other players.
I have a 100 mbps download / 50 mbps upload, FTTH Connection
Hmm, that's concerning.
- Is it consistent, like every single time? Or sporadic?
- Is this solely on Windows, or is there a mobile version involved?
- Are you connecting over local wifi, or is your home connection wired-ethernet to your FTTH?
The last one is particularly notable, we ran into some really frustrating issues in 2023 and 2024 when we were trying to improve the network layer, due to people who had pretty bizarre wifi routers/APs that were randomly "buffering" their packets (effectively holding them instead of sending them immediately) and other strangeness. We could identify the specific individuals because of their clock-sync problems.
- Is it consistent, like every single time? Or sporadic?
- Is this solely on Windows, or is there a mobile version involved?
- Are you connecting over local wifi, or is your home connection wired-ethernet to your FTTH?
The last one is particularly notable, we ran into some really frustrating issues in 2023 and 2024 when we were trying to improve the network layer, due to people who had pretty bizarre wifi routers/APs that were randomly "buffering" their packets (effectively holding them instead of sending them immediately) and other strangeness. We could identify the specific individuals because of their clock-sync problems.
It is much the same for me. It has been for a long time, so I thought it was "intended." When I log in and immediately click Launch, it takes tens of seconds before the ship actually launches. The same happens before I can enter a turret, jump, and so on. There are also some risks or problems when performing particular Lua API calls during this warm-up time.
I am on Linux, with a 2.5 Gbps fibre optic connection to the router and a 1 Gbps metallic connection to the PC.
I am on Linux, with a 2.5 Gbps fibre optic connection to the router and a 1 Gbps metallic connection to the PC.
Okay, but Nick was exclusively reporting an issue related to initial login.
Are you experiencing this only during initial login? Or is this happening "all the time" (beyond initial login) when you go to jump, enter a turret, etc?
Are you experiencing this only during initial login? Or is this happening "all the time" (beyond initial login) when you go to jump, enter a turret, etc?
I wrote "When I log in and ..." I also later referred to it as a "warm-up time". I'm not completely sure what *initial* login means, but I mean right after any login.
I just log in and cannot launch for some time. Some other activities are limited as well. These problems disappear after 20 to 60 seconds and do not return. While I stay in the game, everything is quick and responsive. When I log out and back in, another waiting.
I accepted it as a necessary warm-up period. It was always there. I just remember it being much shorter a few (or many?) years ago. I am sharing my experience simply because it was mentioned/reported.
I just log in and cannot launch for some time. Some other activities are limited as well. These problems disappear after 20 to 60 seconds and do not return. While I stay in the game, everything is quick and responsive. When I log out and back in, another waiting.
I accepted it as a necessary warm-up period. It was always there. I just remember it being much shorter a few (or many?) years ago. I am sharing my experience simply because it was mentioned/reported.
Thanks, I appreciate the report, feedback and clarification.
I had read what you had written, but I was a bit uncertain about the way you had phrased "The same happens before I can enter a turret, jump, and so on.", if that was solely at login time, or at another point in gameplay.
There is a lot of game-state that gets transferred on initial login, and some of that is necessary. But, I suspect this could be made more efficient.
- Do you know what your average ping ("/ping") is? That would be helpful.
- Is your Linux version (of the game) up to date? Some Linux people run older versions of the game, and those sometimes have to transfer more data on login because they're more out-of-date.
I had read what you had written, but I was a bit uncertain about the way you had phrased "The same happens before I can enter a turret, jump, and so on.", if that was solely at login time, or at another point in gameplay.
There is a lot of game-state that gets transferred on initial login, and some of that is necessary. But, I suspect this could be made more efficient.
- Do you know what your average ping ("/ping") is? That would be helpful.
- Is your Linux version (of the game) up to date? Some Linux people run older versions of the game, and those sometimes have to transfer more data on login because they're more out-of-date.
Sorry for any confusion earlier. I was referring to situations when I previously logged out while undocked. Then, after logging back in, there was a delay before I could perform any actions.
Upon checking, the ping is currently under 100 ms. I do not have a track of average values. Both my operating system and the VO client are up to date.
Nonetheless, I decided to measure the time more precisely because the given range of 20 to 60 seconds was vague and possibly exaggerated. I logged in and immediately clicked the launch button. The first test, conducted yesterday, was quicker than I expected and definitely took way less time than I was used to lately. Today, I repeated the test, and it was almost instant. I recall it taking up to a few tens of seconds on many occasions not too long ago. Now, I’m confused. I will continue testing.
Upon checking, the ping is currently under 100 ms. I do not have a track of average values. Both my operating system and the VO client are up to date.
Nonetheless, I decided to measure the time more precisely because the given range of 20 to 60 seconds was vague and possibly exaggerated. I logged in and immediately clicked the launch button. The first test, conducted yesterday, was quicker than I expected and definitely took way less time than I was used to lately. Today, I repeated the test, and it was almost instant. I recall it taking up to a few tens of seconds on many occasions not too long ago. Now, I’m confused. I will continue testing.
Now, I’m confused. I will continue testing.
Okay, please let us know.
Also, Nick_9137:
- If you can similarly objectively measure the exact amount of time you're experiencing before the game is "functional" for you, that would be helpful.
- And similarly, if you could report your /ping time, around when this happens, that would also be helpful.
Okay, please let us know.
Also, Nick_9137:
- If you can similarly objectively measure the exact amount of time you're experiencing before the game is "functional" for you, that would be helpful.
- And similarly, if you could report your /ping time, around when this happens, that would also be helpful.
I do have a long delay after logging on as well.
Usually when it comes to entering station, launching right after logging in, and have to wait quite a bit for chat to send my responses, or to load the mission board.
This may be because of my internet and server distance, but its quite long regardless.
Usually when it comes to entering station, launching right after logging in, and have to wait quite a bit for chat to send my responses, or to load the mission board.
This may be because of my internet and server distance, but its quite long regardless.
Well, if you could time exactly how long it is, and then measure your /ping at the time, that would be helpful.
I have waited quite long last time i logged on. its quite random, but the last time it was a minimum of 2 minutes, even 3, just to enter station after logging on. my ping was 320 right after it loaded, fairly average for my(terrible) internet, due to distance and bandwidth usage. then it gone down to 210.
To anyone who wants to make a report on this subject, please provide the following:
1) Record the actual amount of time it took to log in. Don't guess or provide estimates or best-recollections. We've had some issues where some people "remember" it being much longer than it actually was.
2) Record your /ping value at the time of the lengthy login.
3) Tell us if you are on wifi, or a wired internet connection.
4) Tell us what platform you're using to play the game (Windows, Android, etc).
Reports that include all the information listed above, are potentially helpful.
However, simply saying "I also have slow logins sometimes!" is not helpful, as it doesn't mean anything. If you have a malfunctioning wifi router injecting random latency, or a lot of packet loss due to poor internet, you're going to have a harder time logging in, that's just reality.
We're trying to find examples of problems that happen to people who are not in the above situation, and are on wired, high-bandwidth, relatively lower-latency connections. "Piling on" to claim you have the problem, with providing additional information, basically just muddies the waters and makes this more difficult to solve.
1) Record the actual amount of time it took to log in. Don't guess or provide estimates or best-recollections. We've had some issues where some people "remember" it being much longer than it actually was.
2) Record your /ping value at the time of the lengthy login.
3) Tell us if you are on wifi, or a wired internet connection.
4) Tell us what platform you're using to play the game (Windows, Android, etc).
Reports that include all the information listed above, are potentially helpful.
However, simply saying "I also have slow logins sometimes!" is not helpful, as it doesn't mean anything. If you have a malfunctioning wifi router injecting random latency, or a lot of packet loss due to poor internet, you're going to have a harder time logging in, that's just reality.
We're trying to find examples of problems that happen to people who are not in the above situation, and are on wired, high-bandwidth, relatively lower-latency connections. "Piling on" to claim you have the problem, with providing additional information, basically just muddies the waters and makes this more difficult to solve.
Incidentally, are any of you using "Compatibility Mode" in Network settings?
That would likely cause your game login process to take longer.
That would likely cause your game login process to take longer.
1) "We've had some issues where some people "remember" it being much longer than it actually was."
If you are referring to me, no, I remembered it correctly; it is random. I have just come to report. On some occasions, it really takes tens of seconds. I have experienced it several times over the last few days. I can try to measure it, but it would mean measuring every single login. As I said, it is random.
2) Always tightly about 100 ms.
3) Ethernet / Fibre.
4) Linux.
If you are referring to me, no, I remembered it correctly; it is random. I have just come to report. On some occasions, it really takes tens of seconds. I have experienced it several times over the last few days. I can try to measure it, but it would mean measuring every single login. As I said, it is random.
2) Always tightly about 100 ms.
3) Ethernet / Fibre.
4) Linux.
For example, it took 12 seconds to switch a ship, over 25 seconds (total) to launch, and even more time for the jump point to appear on the radar. Ping 101.1. It is random. The delay can be shorter or even longer than this.
If you are referring to me, no, I remembered it correctly; it is random.
I was not referring solely to you, no. Not everyone is even on this thread.
The point is just for the reported data to be as objective as possible, that's what gives us the greatest chance of success in debugging any potential problem.
The simple reality here is that not everything is actually our problem. UDP traffic is widely filtered and rate-limited by ISPs, because they predominately see it getting used for DDoS attacks. Other than that, it's only high-performance games and DNS that really need it. QUIC (HTTP/3) uses it as well, but can transparently fall back to TCP for most cases.
So, debugging anything that involves "traffic across the internet" is a challenge, and getting objective data is really helpful. Speaking of which..
Incidentally, are any of you using "Compatibility Mode" in Network settings?
It would be helpful if people could respond to this question of mine.
I was not referring solely to you, no. Not everyone is even on this thread.
The point is just for the reported data to be as objective as possible, that's what gives us the greatest chance of success in debugging any potential problem.
The simple reality here is that not everything is actually our problem. UDP traffic is widely filtered and rate-limited by ISPs, because they predominately see it getting used for DDoS attacks. Other than that, it's only high-performance games and DNS that really need it. QUIC (HTTP/3) uses it as well, but can transparently fall back to TCP for most cases.
So, debugging anything that involves "traffic across the internet" is a challenge, and getting objective data is really helpful. Speaking of which..
Incidentally, are any of you using "Compatibility Mode" in Network settings?
It would be helpful if people could respond to this question of mine.
Incidentally, are any of you using "Compatibility Mode" in Network settings?
It would be helpful if people could respond to this question of mine.
In addition to that question, it would also be useful to know:
- Are any of you trying to play through a Virtual Machine?
It would be helpful if people could respond to this question of mine.
In addition to that question, it would also be useful to know:
- Are any of you trying to play through a Virtual Machine?
Okay, it's been a week, and I've tried investigating this to some extent, hopefully we'll be able to put more time in it soon, but I could really use responses to these two questions:
1) Are any people reporting this issue using "Compatibility Mode" in Network settings?
2) Are any people reporting this issue operating Vendetta Online within a virtual machine.
These are really technically arduous issues for us to figure out; the more responsive people can be on this, the more likely we are to be able to fix something.
1) Are any people reporting this issue using "Compatibility Mode" in Network settings?
2) Are any people reporting this issue operating Vendetta Online within a virtual machine.
These are really technically arduous issues for us to figure out; the more responsive people can be on this, the more likely we are to be able to fix something.
Sorry for the delay, no Compatibility Mode or VM here. Additionally, I am quite confident about my uplink quality, including the absence of any third-party filtration, as far as I am aware.
Okay, thanks.
Additionally, I am quite confident about my uplink quality, including the absence of any third-party filtration, as far as I am aware.
Unfortunately, I can virtually guarantee the opposite. Practically all internet traffic is shaped and manipulated to some extent. Not necessarily by your provider, but by some or all of the various networks you pass through to reach us. Packet filters, flow analysis, route padding, various MPLS circuit tweaks, and so on. There's a lot going on.
Because much of this is route, path or endpoint-specific, individual end-users have a tough time even seeing that these soft-barriers exist. Asymmetric routing is a good example: you can only tell (see the issue) if you do traces from both ends at roughly the same time. You can't identify the problem purely from the "user" side, all you can see is "man, my ping sucks".
When major DDoS events happen, they get filtered at what is called the "network edge", or where they "border" with other networks at internet exchange points. This is often when/where network engineers start to get aggressive on traffic manipulation. Unfortunately, this may also be a "traffic handoff" point between networks, that you are also using, several-stages removed from your personal ISP.
So, when I say UDP traffic is widely filtered and rate-limited by ISPs, because they predominately see it getting used for DDoS attacks, please understand that doesn't necessarily mean your home-ISP that provides service to you. Every network between you and us is also "an ISP".
Regardless, none of this is intended as an excuse for us to wave away these kinds of issues, we have to try and make things work as well as possible on the internet we have. It just illustrates that.. there's a lot to unpack here, and solving (or even debugging) these issues are not simple.
I have a suspicion that this is a clock-synchronization thing, maybe stemming from momentary packet loss, but.. we'll have to try and reproduce it in a "lab" environment before we'll know. We've been too intensely busy to do that so far, but this is high on my priority list.
Additionally, I am quite confident about my uplink quality, including the absence of any third-party filtration, as far as I am aware.
Unfortunately, I can virtually guarantee the opposite. Practically all internet traffic is shaped and manipulated to some extent. Not necessarily by your provider, but by some or all of the various networks you pass through to reach us. Packet filters, flow analysis, route padding, various MPLS circuit tweaks, and so on. There's a lot going on.
Because much of this is route, path or endpoint-specific, individual end-users have a tough time even seeing that these soft-barriers exist. Asymmetric routing is a good example: you can only tell (see the issue) if you do traces from both ends at roughly the same time. You can't identify the problem purely from the "user" side, all you can see is "man, my ping sucks".
When major DDoS events happen, they get filtered at what is called the "network edge", or where they "border" with other networks at internet exchange points. This is often when/where network engineers start to get aggressive on traffic manipulation. Unfortunately, this may also be a "traffic handoff" point between networks, that you are also using, several-stages removed from your personal ISP.
So, when I say UDP traffic is widely filtered and rate-limited by ISPs, because they predominately see it getting used for DDoS attacks, please understand that doesn't necessarily mean your home-ISP that provides service to you. Every network between you and us is also "an ISP".
Regardless, none of this is intended as an excuse for us to wave away these kinds of issues, we have to try and make things work as well as possible on the internet we have. It just illustrates that.. there's a lot to unpack here, and solving (or even debugging) these issues are not simple.
I have a suspicion that this is a clock-synchronization thing, maybe stemming from momentary packet loss, but.. we'll have to try and reproduce it in a "lab" environment before we'll know. We've been too intensely busy to do that so far, but this is high on my priority list.