[Suggestions] HIP 58832
- Thread starter Hacks
- Start date
There's a hard limit to the number of Fleet Carriers in a system determined by the way the ID database works, you can't have infinite!
Got an idea for you - once there are more than, say, 15 carriers in a system, start putting 30 day limits on each carrier's presence in the system.
You park it for too long, pilots' federation tells your carrier crew to go over to the nearest below-threshold system. If you really need to be in system, come back manually so you're not babysitting a spot somebody else could use.
For a system like HIP 58832, where
, add a small carrier admin outpost somewhere in system, or possibly add a feature in your ship to recall the carrier. Make it so ship-initiated recalls can only stay in system for two or three days, before getting told to jet.
You park it for too long, pilots' federation tells your carrier crew to go over to the nearest below-threshold system. If you really need to be in system, come back manually so you're not babysitting a spot somebody else could use.
For a system like HIP 58832, where
you might need a carrier in order to get out
Last edited:
Wouldn't work, you can't recall your carrier to a system that's at maximum capacity, and often it's not just HIP 58832 that's full, it's the preceding systems also because they are all carrier jump only distances! Your carrier may actually end up several carrier jumps away.
may be an increasing fine on the carrier for rapid dismantling
What if multiple carriers can be deployed at single spot (as number of spots is limited)? There would be multiple carriers is the same instance, but only first one is shown in navigation panel. It could be marked differently - as FC cluster. If the original carrier departed, the name of the next one from this cluster would be shown in navigation panel/system map.
This way we could see simultaneous launch of multiple carriers at once
It could theoretically save time - reloading commodities from one carrier to another - if needed.
This way we could see simultaneous launch of multiple carriers at once
It could theoretically save time - reloading commodities from one carrier to another - if needed.
What if multiple carriers can be deployed at single spot (as number of spots is limited)? There would be multiple carriers is the same instance, but only first one is shown in navigation panel. It could be marked differently - as FC cluster. If the original carrier departed, the name of the next one from this cluster would be shown in navigation panel/system map.
This way we could see simultaneous launch of multiple carriers at once
It could theoretically save time - reloading commodities from one carrier to another - if needed.
Still doesn't solve the problem of a limit to the number of FC's that can be in a system. Sure I am up for any system that makes it easier to view carriers in the nav panel and system map, that's only a visual thing. Also you can't have multiple carriers in the same instance so that's a no go from the very beginning.
Really, this could become a problem, long term. Imagine someone gets enough carriers on alts to completely block off an important system, and then starts selling slots for irl money?
I think I am repeating myself and you probably anyway disagree, but the analogy I see is a limited capacity of IPv4 and the way many of us use Internet - most of our devices are "hidden" behind routers (as FC behind instance wake beacon) and we use port forwarding to expose some services (could be sort of beacon/name service for FC to drop onto specific instance, to advertise its name to the system map). So FDev "just" need to add some proxy which would represent FC cluster (in simple case cluster containing single FC). I am (and was) not speaking of visual representation only.
If there is a demand sooner or later supply will come
No that's a ridiculous analogy, this is a database we are talking about, and every carrier has to have a unique identifier in that database because they are persistent and appear across all modes and networks, and there are only so many ID64 numbers available per system. What you are talking about is having multiple FC's with potentially the same identifier in the master database so any operation done in the master database on the ID64 will affect all FC's. You couldn't jump or decommission because that requires an action on the ID64 assignment, ie, deleting that ID64 used for that Fleet Carrier in that system and assigning a new one from the new system, potentially just losing forever a number of Fleet Carriers in the process. No you can't just play with the unique identifier in a database that way, it doesn't work, that way lies disaster!
IPV4 is nothing like managing a database.
Please not again
Please not again
You started it, your analogy is a false analogy, a database is nothing like IPV4, it doesn't work the same, so you can't say they can just do it like IPV4.
I didn't realize it's the other systems leading to it too.
In that case, I guess the recall wouldn't work, unless they added a waiting list for FCs to get into a system. But, I still think any system that has more than 15 FCs in it should start kicking them out past 30 days - would free up spots for others, no?
I don't think that's a bad solution myself, but it would have to be carefully curated. For instance in some cases a Fleet Carrier could be kicked to an out of FSD range system, it would be rare but could happen if you are on the edge of the galaxy and left your ship out of the FC and say your PC died and it took a while to get back on, but that would be rare to almost zero because you wouldn't ever get that FC's in one system unless you are somewhere like Beagle Point. Now the problem with HIP 58832 is it's not just 1 or 2 systems, here is the list of systems you need to jump through to get there;
That's 16 systems and 5400ly, an average of around 300ly per jump, once you hit the HD systems, all catalogue systems, it's FC all the way, blockages usually occur in the last two systems before 58832, to clear a route you have to start moving FC's from HD 104495 to previous systems, then from HD 105341 several systems down before you can even start making space at HD 58832, so to actually have this automatic method clear a route through the crowded jump points could take not just 30 days but in the order of 6 months or more because you can't jump a FC out to lower systems until the FC's have jump out to still lower systems, and then what happens if the auto-jump actually moves FC's up into the nearly filled systems because they have the closest empty spot?
No, Rackham's Peak need a human run scheduling system, and I believe there is one actually run by a group on discord. But in the end it's all personal preference, crowded system in the bubble don't bother me, if I can't jump my FC in I just jump it into a system 1 jump away for the jump range of the ship I am using, and that range is large enough that all systems in range couldn't possibly be filled with FC's, if it slows me down slightly filling my FC with goods that's not a big issue. And out where I usually operate just seeing another CMDR is rare, let alone another FC.
PTN had manually run space traffic control in place during public holidays at the peak, but stopped to do it due to the inconsistencies with FC parking.
Proposals for the "too many FCs in some systems" issue
Really like proposal #2 here. After the timeout, if the carrier can't log off as proposed, it should be "bumpable" out of the current full system by an incoming carrier.
The truth / reality about Rackham's Peak ?/!
Hi, after some more testing, we came to the conclusion that there was/is some silent testing by you (FDev) going on in HIP 58832. The currently observed behavior: Only for EDO users, and only at the Peak (confirmed by Operation IDA that other systems in the galaxy don't show this behavior)...
They'd need somewhere round 100 accounts to do that for most systems (so maybe £500 picked up in bulk in a sale), and even with maximised earning rates they'd need several hours per account to get them a carrier (so a few months of full-time work).
Frontier would probably ban and delete all those accounts the moment they found out ... so the advertising of "moving a carrier in exchange for real money" services would have to be fairly low-key ... I can't see any plausible way that someone doing this could find enough suckers willing to pay real life cash for the privilege of having their carrier one system along to cover their expenses before the whole thing fell apart.
Hire foreign laborers and use free epic accounts, maybe. There are hundreds of thousands of those out there; who knows where they went.
It doesn't need to be for real money, either. There are plenty of people who troll just for the sake of trolling. If they just filled up every carrier admin system, they'd effectively be trolling the whole game.
There's currently 391 carrier admin systems, so if someone (some team of hundreds...) goes to the trouble of getting 40,000 separate alt accounts levelled up to the point of having a carrier and fills up every slot in every carrier admin system in them ... to be honest, I'm quite happy to let them have their well-deserved one week of fame before Frontier says "due to popular demand, 400 new carrier admin systems are now open" to troll them back.