Fleet Carrier servers are bugged, FC OWNERS PLEASE READ!

[Clockdistrict]

Fleet Carrier servers have been bugged like crazy since the stabilizer CG recently, we've gone from being able to jump carriers all day every day without problem to the servers not accepting jump requests from CMDR's all over the galaxy, and across all regions. We've seen plenty of "No time slots" errors and plenty of jumps that have 20, 30 sometimes even 40 minute long jump timers, which all block out the inability for ANYONE to plot a jump. I've been stuck in the same system for about 2 hours now, with zero ability to plot, and many CMDRs within a community I'm involved in are also stuck.

Until a fix is (hopefully) deployed, if you plot a jump with your carrier and you get a timer that is more than 15:06, CANCEL THE PLOT AND REPLOT as you've just locked out the entire galaxy from plotting a jump, and please spread this around to anyone else you know who owns a Fleet Carrier.

Clearly there is an issue here, and we need to get this in front of Fdev's eyes, I've posted a link to the Issue Tracker down below, please vote.

Issue Tracker Thread: https://issues.frontierstore.net/issue-detail/57600

 

[Fnord Velkor]

I had one with 45 minute delay - cancelled the jump - replotted after the 1 min cooldown - then it was 15 min, same as all my other ones today (less than ten).

So maybe try that?

 

[Clockdistrict]

I had one with 45 minute delay - cancelled the jump - replotted after the 1 min cooldown - then it was 15 min, same as all my other ones today (less than ten).

So maybe try that?

That's fine if I get a longer timer, but if someone else get's a longer timer, I physically cannot plot. I've been stuck in the same system for 2 freaking hours now without the ability to plot because of this stupid server issue.

 

[alexzk]

Yes, it have been there at least 2 weeks already. Cancel / replot fixes.

 

[Surdra]

Tried throughout the afternoon to jump. “No free time slots” is the error I get, regardless of when I request the jump, the game mode I’m in, or the system I’m trying to get to. Logging out doesn’t help and while not game breaking (I’m in the Bubble), it’s very annoying.

 

[varonica]

Haven't had an issue the last few days, the last time I had a time longer than 15 minutes was when I was an idiot and tried to plot a jump just before maintenance, 1 hour and 35 minutes lol.

 

[Fnord Velkor]

That's fine if I get a longer timer, but if someone else get's a longer timer, I physically cannot plot. I've been stuck in the same system for 2 freaking hours now without the ability to plot because of this stupid server issue.

I don't understand what you are trying to say. Is this other FCs in your system? Other FCs trying to go to the same system as you? How can other's delays affect you?

I asking a serious question, not contradicting you, just seeking to understand the conditions you are ascribing your difficulties to.

 

[yianniv]

I don't understand what you are trying to say. Is this other FCs in your system? Other FCs trying to go to the same system as you? How can other's delays affect you?

I asking a serious question, not contradicting you, just seeking to understand the conditions you are ascribing your difficulties to.

The hypothesis is that there is one server responsible for all the FC jumps in the galaxy, and if it's busy, it allocates a much longer jump window. All jumps are then assigned to that window, which means that a single commander can be responsible for the whole delay.
It's like creating the instance on a CZ in open, the first cmdr's PC is the "server".

 

[Fnord Velkor]

That can't possibly be correct else why would most of us have no issues? If what you say was true then surely the whole population of commanders would be stuck permanently.

 

[varonica]

The hypothesis is that there is one server responsible for all the FC jumps in the galaxy, and if it's busy, it allocates a much longer jump window. All jumps are then assigned to that window, which means that a single commander can be responsible for the whole delay.
It's like creating the instance on a CZ in open, the first cmdr's PC is the "server".

It doesn't have anything to do with servers, there's one database that records all the location data for stellar objects, this database must be updated each time a carrier jumps, and also for all the players, their ships and etc in the carrier. Carriers don't "move", the vanish from one location and reappear in another location according to the database update, you can only do so many database updates in a given time span, it's a physical limitation of the hardware, it's not magic, there has to be a maximum you can do before you have to extend the time required.

 

[yianniv]

That can't possibly be correct else why would most of us have no issues? If what you say was true then surely the whole population of commanders would be stuck permanently.

Not permanently, just for that specific jump that would take more than 15 minutes. Then the queue clears. It's my hypothesis, anyway, nothing concrete. A way to test is, if you have an alt and by chance your main faces a longer jump window, check if your alt (assuming they have a FC) also has a longer time to jump (minus the time to start the game for them).

 

[Rat Catcher]

I've not seen any delays in jumping recently - so cannot add to the issue tracker, sorry.
Both the FCs in the bubble and the one I took to Colonia have not exceeded 15:10 jump countdown.
Granted, the bubble ones have not been in 'popular' locations, which may or may not have anything to do with it.

 

[yianniv]

It doesn't have anything to do with servers, there's one database that records all the location data for stellar objects, this database must be updated each time a carrier jumps, and also for all the players, their ships and etc in the carrier. Carriers don't "move", the vanish from one location and reappear in another location according to the database update, you can only do so many database updates in a given time span, it's a physical limitation of the hardware, it's not magic, there has to be a maximum you can do before you have to extend the time required.

I was in a hurry to type, by "server" I meant a database one... But I made my assumption based on my perception of the situation.

 

[MVBanks]

I had one jump 50 mins timer, but other jumps were ok, I jumped 5 - 6 times last couple of days.

 

[Fnord Velkor]

Not permanently, just for that specific jump that would take more than 15 minutes. Then the queue clears. It's my hypothesis, anyway, nothing concrete. A way to test is, if you have an alt and by chance your main faces a longer jump window, check if your alt (assuming they have a FC) also has a longer time to jump (minus the time to start the game for them).

Nope, I don't see that being possible. What you say is that if someone's plotted jump has a delay of 45 min then EVERY COMMANDER would not be able to plot a jump for that time. Which is patently nonsense since I have been transiting a FC yesterday and today with only one 45 minute offering (cancelled) and absolutely have never seen ever a "no time slots" message.

 

[yianniv]

Nope, I don't see that being possible. What you say is that if someone's plotted jump has a delay of 45 min then EVERY COMMANDER would not be able to plot a jump for that time. Which is patently nonsense since I have been transiting a FC yesterday and today with only one 45 minute offering (cancelled) and absolutely have never seen ever a "no time slots" message.

What I'm trying to say, and what I think the OP is trying to say, is that if, for whatever reason, I create a jump and happen to be the first commander that finds a busy server/database/whatever, which means the server can't offer me 15 minutes but raises them to 45, unless I cancel and retry (hopefully to try and find the server/database/whatever at a less busy peak), the time at the end of those 45 minutes are what each subsequent FC jump will be allocated to (until that jump is made), because the server/database/whatever creates a slot for "Next jump time" and puts as many FCs as it can fit on it. Until the next one...

 

[Fnord Velkor]

What I'm trying to say, and what I think the OP is trying to say, is that if, for whatever reason, I create a jump and happen to be the first commander that finds a busy server/database/whatever, which means the server can't offer me 15 minutes but raises them to 45, unless I cancel and retry (hopefully to try and find the server/database/whatever at a less busy peak), the time at the end of those 45 minutes are what each subsequent FC jump will be allocated to (until that jump is made), because the server/database/whatever creates a slot for "Next jump time" and puts as many FCs as it can fit on it. Until the next one...

So how come so many of us are not seeing this nor seeing "no time slots" messages? No. I don't buy it. However, since I know not which arcane methodology FDEV have conjured-up I have no idea beyond thinking that the "no time slots" must be a location (in the game I mean) issue - the 45 minute offering I received was in the Formidine thingie so that surely was not location based.

(EDIT - gosh lots of typos, sorry.)

 

[Ian Doncaster]

So how come so many of us are not seeing this nor seeing "no time slots" messages? No. I don't buy it. However, sine I know not which arcane methodology FDEV have conjured-up I have no idea beyond thinking that the "no time slots" must be a location (in the game I mean) issue - the 45 minute offering I received was in the Formidine thingie so that surely wan't not location based.

Without knowing the full details of how their servers are set up, it's not really possible to say. A plausible way it could work, though, given what we know:

• We know Frontier distributes the same data across multiple servers, and syncs it up later, for many types of data, for both resilience and having it served from somewhere reasonably close to the client. "Where is a station" is both too critical and too common a query to risk just having one database server able to answer it.
• We also know there's a lot of caching involved on the client so you're not sending hundreds of queries per second to the servers for data which probably hasn't changed since three seconds ago (like, in general, station locations)
• The efficient way to move a carrier from A to B is not to say "it's at A" then later say "it's at B", but to say "it's at A until time X, then it will be at B afterwards". That way any client which gets that update before time X knows it will jump without needing to check again.
• So to jump a carrier reliably, they need to guarantee that the position information will have distributed to all the servers, and then from there got into client caches, before the carrier actually jumps. Normally 15 minutes is more than enough to do this.
• If the servers are temporarily overloaded, this will take longer to guarantee, so when you send in the request, it checks the server load, and makes a (conservative!) estimate of how long it will actually take to distribute the data under these load conditions, and schedules the jump for then (e.g. 45 minutes later instead)
• If the servers are really heavily overloaded, it might decide that while it could estimate "3 hours" for the next jump, it's maybe easier just to tell the user "try again later" because they're unlikely to stay overloaded for the full three hours.

So, if the servers are overloaded when you try, you might get 45 minutes. But it might just be a really temporary spike in load that only lasts a minute or so - the server doesn't know it's going to fall off that quickly so says 45 minutes, but if you cancel and replot, by the time you replot the load has dropped again, and you get the default 15 minutes. Or it might not have dropped, and all the people trying to replot at once overloads it further and means it's now saying 90 minutes. The inconsistency in whether replotting helps or not is then an easy source of "if you paint your fleet carrier green it's more likely that it gets shorter jumps" theories.

This would also explain - if there were a number of short but intense overloadings - why some people can be chain-jumping their carrier all day and get lucky enough never to see a timer over 15 minutes, while others get multiple long jumps in a row and come to complain here, despite jumping their carriers at something which could be loosely described as "the same time".

 

[MVBanks]

Just couple of minutes ago, I had this message, "No time slots", first time I see this

 

[leonardofelin]

So how come so many of us are not seeing this nor seeing "no time slots" messages?

But many are seeing the "No time slot" messages. While I don't agree with OP that ONE delayed carrier would clog everyone else, there are CMDRs seeing this message for 1-2h, like I did a couple of days ago.

It is a problem and needs to be addressed. I've seen in this forum the constant "problem dismissal" because it "doesn't happen to me" and "it must be a problem on your end". This does not help the game to get better.