A potential solution to the perhaps minor problem of too many carriers jamming up places.

[Nevan Nedall]

While a rare and usually not too problematic issue, it has the potential to cause very large jams at times, such as in HIP 58832, Admin Systems, or around individual bodies a lot of people want to park a carrier near such as hotspots for mining/trade. This could also potentially become worse over time as more and more FC come into existence, and more and more of them become inactive husks with so much money they will effectively never be mothballed.

I suggest that, upon attempting to jump a carrier into a place that is full, the person attempting the jump is told their destination is full, and that they will need to wait a specific, given amount of time for another carrier to be diverted.
I suggest this is done by automatically moving the carrier that has been present around that specific body/in that system the longest, and that the owner of that carrier is subsequently alerted to this if they are online. That carrier would then automatically be jumped to another nearby system, and lets say the Tritium cost is handwaved away as being provided by the system authority for the inconvenience, or whatever.
Something along the lines of:

Commander, your carrier is being relocated to make room for other traffic. If you continue to have business in the system, please reenter at your earliest convenience. Your fuel costs have been provided by system authorities as compensation.

Optionally, allow the owner of the carrier that would be moved to respond, indicating they still have business to be done in the system, which bumps the warning down to the next oldest carrier in line. Give each carrier, say, 5 minutes to respond, and make the waiting period long, but not ridiculous. A day at the most, maybe.
Work your way down the list, until there is a carrier that does not respond or accepts the relocation, and when the timer is up, they are forced into another system, and the newcomer is allowed to enter.

 

[SteveWW57]

In space, no one can hear you scream.
But if this came to pass, you would hear the howls of outrage from Sol to Colonia.

Steve 07.

 

[Northpin]

Nope. There is no need for that.


HIP 58832 and the system before it should concern only FDev and they should find means to deal with it - or not (maybe they created the issue on purpose), but there are no issues with the rest of the systems
Carrier Admin Systems? there are plenty of them, hundreds, no issues.
Vendor Systems? who cares. If they're full whoever gets there to buy a Carrier that carrier will be placed in a nearby system with free spots - so no issue

 

[Danieros]

While a rare and usually not too problematic issue, it has the potential to cause very large jams at times, such as in HIP 58832, Admin Systems, or around individual bodies a lot of people want to park a carrier near such as hotspots for mining/trade. This could also potentially become worse over time as more and more FC come into existence, and more and more of them become inactive husks with so much money they will effectively never be mothballed.

I suggest that, upon attempting to jump a carrier into a place that is full, the person attempting the jump is told their destination is full, and that they will need to wait a specific, given amount of time for another carrier to be diverted.
I suggest this is done by automatically moving the carrier that has been present around that specific body/in that system the longest, and that the owner of that carrier is subsequently alerted to this if they are online. That carrier would then automatically be jumped to another nearby system, and lets say the Tritium cost is handwaved away as being provided by the system authority for the inconvenience, or whatever.
Something along the lines of:

Optionally, allow the owner of the carrier that would be moved to respond to respond, indicating they still have a business, which bumps the warning down to the next oldest carrier in line. Give each carrier, say, 5 minutes to respond, and make the waiting period long, but not ridiculous. A day at the most, maybe.
Work your way down the list, until there is a carrier that does not respond or accepts the relocation, and when the timer is up, they are forced into another system, and the newcomer is allowed to enter.

+1

It's reasonable, I like it. I keep hoping Frontier will eventually deal with this FC jam issue, because ultimately it isn't realistic for a system/body to run out of... space. And then there's nothing you can do to orbit that system/body until someone manually moves their FC.

 

[varonica]

+1

It's reasonable, I like it. I keep hoping Frontier will eventually deal with this FC jam issue, because ultimately it isn't realistic for a system/body to run out of... space. And then there's nothing you can do to orbit that system/body until someone manually moves their FC.

And what happens when the carriers is "diverted" and the next nearest star is outside the jump range of players who were in that carrier? Are they just stuck in the previous system? What happens, as frequently does up towards Rackham's Peak, when the next few closest star systems are also full. What happens if you jump the carrier to a system and the carrier is then out of fuel and there's no Tritium mining in the system? And etc, lots of issues that could cause problems, let players solve them, any forced moving from FDEV would not be welcome by a "lot" of players.

 

[Danieros]

And what happens when

1. the carriers is "diverted" and the next nearest star is outside the jump range of players who were in that carrier? Are they just stuck in the previous system?
2. What happens, as frequently does up towards Rackham's Peak, when the next few closest star systems are also full.
3. What happens if you jump the carrier to a system and the carrier is then out of fuel and there's no Tritium mining in the system? And etc, lots of issues that could cause problems, let players solve them, any forced moving from FDEV would not be welcome by a "lot" of players.

The implementation of such a system should of course not cause more trouble than the initial system it's meant to alleviate. And neither should it open room for abusing it to grief others. I've divided your points to give my thoughts:

1. If we aren't talking about the bubble/colonia, I don't see traffic jams happening in the fringes where jump range might be an issue to players that aren't the FC owners, though of course the carrier owner can simply come back.

2. For multi-hops required like Rackham's Peak I believe you'll either have a diversion causing another diversion so effectively managing the Rackham's traffic, or a much more simple solution of giving that FC a boosted range jump towards the nearest non-full system if it goes beyond 500 ly. That boosted range would be kept for the next manual jump of that FC so the owner should always be able to jump back to that system they were diverted of.

3. Diverted jumps shouldn't cost Tritium. And neither should be the first jump you make after getting diverted, so that grieving scenarios of forcing jumps just to eat tritium don't become feasible. The FC limits are required because of how the game works, so those free jumps in tritium costs are of course an extension of the handwavium here.

 

[Rebel Yell]

The simplest solution is to lock permanetly all popular systems (including engineers' ones) and temporarly every system where there's going to be a lot of traffic... most of the "jamming" (which causes also lag / stuttering when playing [very annoying for PvP]) happens at CG systems. It is not the amount of carriers which causes issues, but the combined traffic of carriers jumping/arriving with dozens of CMDRs doing the same (as demonstrated by the fact that the smoothest CGs have been the ones set in locked systems).

 

[zikolach]

I would suggest FDev to target next (and subsequent) thargoid wave(s) to the systems having maximum number of FCs with the message to the owners:

Your carrier was destroyed by thargoids. The case is not covered by the insurance. Sorry for inconvenience!

 

[Ettanin]

Simpler solution: Restructure how carriers are instanced and add a menu to spawn a supercruise beacon on demand to the carrier you wish to dock to (which you pick from a list).
No need for traffic regulations, no capacity woes, no orange sidewinders because the carrier list doesn't have to be transferred on jump.

 

[varonica]

Simpler solution: Restructure how carriers are instanced and add a menu to spawn a supercruise beacon on demand to the carrier you wish to dock to (which you pick from a list).
No need for traffic regulations, no capacity woes, no orange sidewinders because the carrier list doesn't have to be transferred on jump.

If carrier are persistent through all modes (and platforms as long as consoles are still running on H 3.8) you can't, because carriers aren't instanced, they are persistent, like stations,, and changing them to instanced would create huge problems.

 

[Cmdr. Numa]

I'd already be happy if FDEV set up a queue. Even in a CG system there's a constant come and go of carriers, so eventually there will be a free slot. Let me schedule the jump as an entry in the queue and then let it sit there until it can either be executed, which is then done, or until I cancel it of course. Make a sensible rate of polling for a free slot, and all is set. A visual indicator on my position in the queue would be the icing on the cake and also prevent too much queueing up. When a 2 or 3 digit waiting position gets shown and there's little to no movement, I'm far more likely to simply cancel for now than if I simply didn't know if I'm next or #100 in the line.

 

[Ettanin]

If carrier are persistent through all modes (and platforms as long as consoles are still running on H 3.8) you can't, because carriers aren't instanced, they are persistent, like stations,, and changing them to instanced would create huge problems.

Does it matter if the stored position is virtual (and thus has no persistent bound in the system like stars, stations and planets) and is only transferred when needed?

 

[varonica]

Does it matter if the stored position is virtual (and thus has no persistent bound in the system like stars, stations and planets) and is only transferred when needed?

All persistent objects require a ID64, the number of ID64's available for objects in a system is limited to the last 8 or 9 characters in the full ID64, the preceding characters are used for system identification in the galaxy, therefore the maximum number of objects in a system that can be persistent is limited, persistent objects include stars, planets, moons, asteroid fields, stations and Fleet Carriers etc, it doesn't matter what the stored position is, once you run out of ID64's that's it, no more Fleet Carriers. The reason it takes so long to jump from one system to another is because the database has to be updated with the new ID64 and that ID64 has to be sent to all players around the world, and that takes time, and if there isn't one available then you don't get in. No amount of playing around with visible/invisible will get around that problem.

Oh just to add, personally I would have prefered a "personal" Fleet Carrier that wasn't persistent and only appeared when I logged in because all I wanted was storage for my own stuff, but since FC's were originally designed for squads which meant other players would need to land and stay on the FC even when the owner wasn't logged in it sadly never came about like that.

 

[Ettanin]

All persistent objects require a ID64, the number of ID64's available for objects in a system is limited to the last 8 or 9 characters in the full ID64, the preceding characters are used for system identification in the galaxy, therefore the maximum number of objects in a system that can be persistent is limited, persistent objects include stars, planets, moons, asteroid fields, stations and Fleet Carriers etc, it doesn't matter what the stored position is, once you run out of ID64's that's it, no more Fleet Carriers. The reason it takes so long to jump from one system to another is because the database has to be updated with the new ID64 and that ID64 has to be sent to all players around the world, and that takes time, and if there isn't one available then you don't get in. No amount of playing around with visible/invisible will get around that problem.

Well then make a new table which links carriers which have an identifier on their own (the 6 character alphanumeric string next to the name) to a system and the body it orbits (the ID64 of the body). There, no common ID64 space needed. That way they can stay persistent and at the same time instancable on demand. Does FDev truly lack database engineers as well?

This also solves the carrier spam on the system map.

 

[varonica]

Well then make a new table which links carriers which have an identifier on their own (the 6 character alphanumeric string next to the name) to a system and the body it orbits (the ID64 of the body). There, no common ID64 space needed. That way they can stay persistent and at the same time instancable on demand. Does FDev truly lack database engineers as well?

This also solves the carrier spam on the system map.

That won't work, did you miss all I said? Every persistent object has to have an ID64, that's not optional, it's the way the system works, the carrier would no longer have a unique identifier in the database. Do they have database engineers? I mean they created a model of an entire galaxy with 400b stars, many trillions of planets and other objects, I am sure they are just bumbling along making guesses, sure that's how they do it!

 

[Nevan Nedall]

I would suggest FDev to target next (and subsequent) thargoid wave(s) to the systems having maximum number of FCs with the message to the owners:

There is no way in hell the community would accept losing a 5+ billion credit investment because they arbitrarily decided to have the Thargoids attack a given system, nor should they be expected to.

 

[Schmack]

The solution is for even stationary carriers to consume fuel.