Going to go ahead and snap this off the mail slot discussion so it can be evaluated in its own merit.
Right now, docking communications chatter is... Wanting.
I have noted that in the dialogue for players, there is a subtle set of dock approach and departure instructions that warn the alert what AI are up to, but they are so vague as to be dismissed.
I would like to propose an improvement in traffic queuing audio callouts to the players when arriving or departing from mail-slot controlled space stations.
Of course, I recognize that 'rushing the slot' is a smuggling tactic for players and that absolute local space control via comms would break this illusion. I do find it odd that a station you're in direct communications with, and in visual range to see, can't direct a patrol craft to you to scan you, and that the station can't have scanners in the slot to catch would-be smugglers. But this isn't about that.
To begin with, I'd like to establish some terminology for this post:
1: APPROACH - Is defined as a ship that has come out of jump, is within' the 7.5 KM comms range, and has requested docking clearance and has had said clearance granted.
2: HOLDING Position - Is defined as the point in front of the mail slot on the outside of the station where AI seem to line themselves up for approach.
3: FINAL - Defined as a ship that is moving from HOLDING Position into the mail slot itself.
4: Short Final - Defined as a ship that is now IN the 'cage' just in front of the slot.
5: PAD HOLD - Defined as a state between requesting departure, and being released from the docking pad.
6: WIDE - Defined as a ship of size such that it cannot fit side by side in the airlock with itself or ships wider than itself and cannot allow for ...
7: ... BI-FLOW Traffic - Defined as traffic operations where in counter-flowing traffic may pass side-by-side in the airlock.
First Point:
Establishing Traffic Priority.
Any flight sim pilots lurking around here can probably talk easily about traffic patterns around a major airport. Including holding patterns, clearances, airspace management, and all kinds of complex features to keep fast moving metal tubes from becoming a hail of burning parts. But I want to establish how the traffic control AI of a station should handle things. Starting with who gets priority in a situation. As it stands, the game kind of just throws out a first-come first-serve mechanic at the AI, and players just thread themselves between the traffic. While I want to keep the freedom for the player to continue doing this, I'd like to establish rules to help guide the player if they want to decrease the risk to their ship.
So the question is, 'who goes first'?
At an airport, the Runway is the 'mail slot'. Whoever is ON the runway, OWNS the runway at that moment in time. Everyone else is trespassing. Of course, the controller wants you on, and subsequently OFF the runway as fast as possible to keep things running smooth. So for AI purposes, we're just going to call this academic for now. The next highest priority for an airport in regular conditions, is aircraft on Short Final, and Final. The reason being that you can't keep aircraft in the air forever, and they need to get on the ground first before anyone else can take to the sky.
For Elite, I feel this mechanic can be partially reversed, or at least narrowed down to only stuff that is already all but on the way in... Because the docking bay behind the airlock is a limited space with a short time limit to be inside before things get... violent. The priority should be shifted slightly in favor of departing spacecraft. Plus, with the nature of the AI being somewhat a randomly generated, never ending stream of ships, a priority shifted towards departing craft means that the docking bay runs out of ships to have exit LONG before it runs out of ships 'coming in out of jump'.
Right next to departing ships in priority are going to be ships that are already 'on their way in', or on 'FINAL' and 'Short FINAL' as defined at the top of my post. At this point, telling the ships to get out of the way is kind of silly, as it is just faster at that point to get them into the docking bay and landed, and chances are their momentum would carry them part way in as well. No sense telling them to move when their nose is in the cage.
So here's a tentative Priority list for who has right of way at the mail slot, and how they should be arranged in a dynamic queue:
0: Anyone IN the slot. They own it until they trigger the loiter alert: THE END.
1: Ships on SHORT Final (In the external 'cage')
2: Ships on Final (Lined up, approaching lock.)
3: Ships departing station.
4: Player Ships with docking clearance, any approach position. Order of request.
5: Ships in HOLDING position, in order of docking clearance request.
6: Everyone Else
Second Point:
BI-FLOW Traffic.
Since the mail slot does have a kind of 'so-so' arrangement for two-way traffic, it would be silly not to incorporate smooth BI-directional flow where applicable. So, a branch of the prioritizing should always check if the next few ships in a docking pattern can pass to the side of each other in the airlock. If that is true, then the priority should modify slightly to allow the approaching ship in at the same time as letting the departing ship out. If this is false, the ship higher up in the priority queue gets the go-ahead.
Third Point:
Delayed departure.
As it stands, when a player-ship is released from the pad, a 5 minute timer immediately begins counting down before the ship is registered as a trespasser and blown to bits. In practice, this seems to be plenty of time even when the departing ship queue in the station runs the length of the station interior. However, it does seem like a bit of a hazard to hover in the station, unable to determine if you're too close to a pad and might get stung for 'loitering over a pad'.
In cases like there where permission to depart might take a minute. If the internal 'departure' queue is over a certain number of ships, the player ship may be placed on a PAD HOLD. That is, you click launch, but instead of immediate release, the controller sends a message that you're being held for a moment until some of the ships in the station depart. This may SEEM inconvenient to an impatient player, but in reality, if the station puts you on a PAD hold, chances are you're going to have a hard time shoving past the ships lined up without doing damage and getting fined. If it causes too much of a stir among players, it could just be set as optional, like preflight checks.
And that brings me to
Fourth Point:
Docking Control chatter.
Right now, the docking controller gives the player some pretty generic messages amounting to it either being all clear, or a ship might be arriving... or exiting. You don't really know for sure what's doing what until you fly into the middle and get your bearings. Reworking the chatter, two things would happen.
1: The player is given brief but solid instructions as to their position in queue, and are warned about flight activity in the pattern around the airlock.
2: The comms chatter is no longer generic comms chatter, but comms chatter to other ships in the queue being updated on their position.
This communications banter would be more complex and consist of more [choice] fragments, but would be dynamic, and relevant to the station.
As an example, here is both a arrival and departure for a player just off the top of my head, no 'other ship' chatter, but that's mainly because I'm not going to try and keep track of multiple imaginary ships in text.
ARRIVAL, From request granted:
[MANUFACTURER] [PLAYER LETTERS] (From now on [M/PL]). Request approved for pad [PAD NUMBER]. Procede to [HOLDING POSITION]. You are number [NUMBER IN QUEUE] in line.
...
[M/PL] Stand by. You are number [#iQ] in line. [Type-9] [WIDE] Departing.
...
[M/PL]. You are number [#iQ] in line behind [Ship Type]. Stand by.
...
[M/PL]. You are cleared for approach. Be Aware of BI-FLOW Traffic and follow the greens on your way in.
DEPARTURE, with Hold and traffic.
[M/PL]. PAD Hold in effect. It's a little busy in here. Sit tight, we'll get you out of here in just a moment. You are number [#iQ] in line.
...
[M/PL], Head's up! Stand by for pad release...
*SHIP RELEASED, ENGINES ENGAGED*
[M/PL]. You are cleared for departure momentarily. Be aware [Ship type] [WIDE] on Final. You are [#iQ] in line.
...
[M/PL]. All clear to depart. Have a nice flight.
If the player chooses to ignore the traffic queue, they aren't penalized for anything short of what we have now, but for flavor, the dock controller could snark at them:
[M/PL]. You're doing that at your own risk.
[M/PL]. Not my fault if you get stuck.
[M/PL]. *Sarcastic* Don't worry about the airlock. My unjamming button works just fine if you jam it up.
[M/PL.] Your paycheck, not mine.
As a side effect with live, relevant chatter, multiple players in the same dock instance will hear the dock controller issuing instructions to their friends and vice versa. This subtle effect makes the game session feel more unified between them.
Right now, docking communications chatter is... Wanting.
I have noted that in the dialogue for players, there is a subtle set of dock approach and departure instructions that warn the alert what AI are up to, but they are so vague as to be dismissed.
I would like to propose an improvement in traffic queuing audio callouts to the players when arriving or departing from mail-slot controlled space stations.
Of course, I recognize that 'rushing the slot' is a smuggling tactic for players and that absolute local space control via comms would break this illusion. I do find it odd that a station you're in direct communications with, and in visual range to see, can't direct a patrol craft to you to scan you, and that the station can't have scanners in the slot to catch would-be smugglers. But this isn't about that.
To begin with, I'd like to establish some terminology for this post:
1: APPROACH - Is defined as a ship that has come out of jump, is within' the 7.5 KM comms range, and has requested docking clearance and has had said clearance granted.
2: HOLDING Position - Is defined as the point in front of the mail slot on the outside of the station where AI seem to line themselves up for approach.
3: FINAL - Defined as a ship that is moving from HOLDING Position into the mail slot itself.
4: Short Final - Defined as a ship that is now IN the 'cage' just in front of the slot.
5: PAD HOLD - Defined as a state between requesting departure, and being released from the docking pad.
6: WIDE - Defined as a ship of size such that it cannot fit side by side in the airlock with itself or ships wider than itself and cannot allow for ...
7: ... BI-FLOW Traffic - Defined as traffic operations where in counter-flowing traffic may pass side-by-side in the airlock.
First Point:
Establishing Traffic Priority.
Any flight sim pilots lurking around here can probably talk easily about traffic patterns around a major airport. Including holding patterns, clearances, airspace management, and all kinds of complex features to keep fast moving metal tubes from becoming a hail of burning parts. But I want to establish how the traffic control AI of a station should handle things. Starting with who gets priority in a situation. As it stands, the game kind of just throws out a first-come first-serve mechanic at the AI, and players just thread themselves between the traffic. While I want to keep the freedom for the player to continue doing this, I'd like to establish rules to help guide the player if they want to decrease the risk to their ship.
So the question is, 'who goes first'?
At an airport, the Runway is the 'mail slot'. Whoever is ON the runway, OWNS the runway at that moment in time. Everyone else is trespassing. Of course, the controller wants you on, and subsequently OFF the runway as fast as possible to keep things running smooth. So for AI purposes, we're just going to call this academic for now. The next highest priority for an airport in regular conditions, is aircraft on Short Final, and Final. The reason being that you can't keep aircraft in the air forever, and they need to get on the ground first before anyone else can take to the sky.
For Elite, I feel this mechanic can be partially reversed, or at least narrowed down to only stuff that is already all but on the way in... Because the docking bay behind the airlock is a limited space with a short time limit to be inside before things get... violent. The priority should be shifted slightly in favor of departing spacecraft. Plus, with the nature of the AI being somewhat a randomly generated, never ending stream of ships, a priority shifted towards departing craft means that the docking bay runs out of ships to have exit LONG before it runs out of ships 'coming in out of jump'.
Right next to departing ships in priority are going to be ships that are already 'on their way in', or on 'FINAL' and 'Short FINAL' as defined at the top of my post. At this point, telling the ships to get out of the way is kind of silly, as it is just faster at that point to get them into the docking bay and landed, and chances are their momentum would carry them part way in as well. No sense telling them to move when their nose is in the cage.
So here's a tentative Priority list for who has right of way at the mail slot, and how they should be arranged in a dynamic queue:
0: Anyone IN the slot. They own it until they trigger the loiter alert: THE END.
1: Ships on SHORT Final (In the external 'cage')
2: Ships on Final (Lined up, approaching lock.)
3: Ships departing station.
4: Player Ships with docking clearance, any approach position. Order of request.
5: Ships in HOLDING position, in order of docking clearance request.
6: Everyone Else
Second Point:
BI-FLOW Traffic.
Since the mail slot does have a kind of 'so-so' arrangement for two-way traffic, it would be silly not to incorporate smooth BI-directional flow where applicable. So, a branch of the prioritizing should always check if the next few ships in a docking pattern can pass to the side of each other in the airlock. If that is true, then the priority should modify slightly to allow the approaching ship in at the same time as letting the departing ship out. If this is false, the ship higher up in the priority queue gets the go-ahead.
Third Point:
Delayed departure.
As it stands, when a player-ship is released from the pad, a 5 minute timer immediately begins counting down before the ship is registered as a trespasser and blown to bits. In practice, this seems to be plenty of time even when the departing ship queue in the station runs the length of the station interior. However, it does seem like a bit of a hazard to hover in the station, unable to determine if you're too close to a pad and might get stung for 'loitering over a pad'.
In cases like there where permission to depart might take a minute. If the internal 'departure' queue is over a certain number of ships, the player ship may be placed on a PAD HOLD. That is, you click launch, but instead of immediate release, the controller sends a message that you're being held for a moment until some of the ships in the station depart. This may SEEM inconvenient to an impatient player, but in reality, if the station puts you on a PAD hold, chances are you're going to have a hard time shoving past the ships lined up without doing damage and getting fined. If it causes too much of a stir among players, it could just be set as optional, like preflight checks.
And that brings me to
Fourth Point:
Docking Control chatter.
Right now, the docking controller gives the player some pretty generic messages amounting to it either being all clear, or a ship might be arriving... or exiting. You don't really know for sure what's doing what until you fly into the middle and get your bearings. Reworking the chatter, two things would happen.
1: The player is given brief but solid instructions as to their position in queue, and are warned about flight activity in the pattern around the airlock.
2: The comms chatter is no longer generic comms chatter, but comms chatter to other ships in the queue being updated on their position.
This communications banter would be more complex and consist of more [choice] fragments, but would be dynamic, and relevant to the station.
As an example, here is both a arrival and departure for a player just off the top of my head, no 'other ship' chatter, but that's mainly because I'm not going to try and keep track of multiple imaginary ships in text.
ARRIVAL, From request granted:
[MANUFACTURER] [PLAYER LETTERS] (From now on [M/PL]). Request approved for pad [PAD NUMBER]. Procede to [HOLDING POSITION]. You are number [NUMBER IN QUEUE] in line.
...
[M/PL] Stand by. You are number [#iQ] in line. [Type-9] [WIDE] Departing.
...
[M/PL]. You are number [#iQ] in line behind [Ship Type]. Stand by.
...
[M/PL]. You are cleared for approach. Be Aware of BI-FLOW Traffic and follow the greens on your way in.
DEPARTURE, with Hold and traffic.
[M/PL]. PAD Hold in effect. It's a little busy in here. Sit tight, we'll get you out of here in just a moment. You are number [#iQ] in line.
...
[M/PL], Head's up! Stand by for pad release...
*SHIP RELEASED, ENGINES ENGAGED*
[M/PL]. You are cleared for departure momentarily. Be aware [Ship type] [WIDE] on Final. You are [#iQ] in line.
...
[M/PL]. All clear to depart. Have a nice flight.
If the player chooses to ignore the traffic queue, they aren't penalized for anything short of what we have now, but for flavor, the dock controller could snark at them:
[M/PL]. You're doing that at your own risk.
[M/PL]. Not my fault if you get stuck.
[M/PL]. *Sarcastic* Don't worry about the airlock. My unjamming button works just fine if you jam it up.
[M/PL.] Your paycheck, not mine.
As a side effect with live, relevant chatter, multiple players in the same dock instance will hear the dock controller issuing instructions to their friends and vice versa. This subtle effect makes the game session feel more unified between them.
Last edited:
