Dispatch Standard Operating Procedures

Dispatching is a job often taken up by rats who aren't able to be in-game at the moment, or as a break from the rat racing to deliver fuel to the client. It is not a promotion, but it is an important job, and one that can at times require a cool head, a capacity for multitasking, and attention to detail.

Dispatch is the client's primary point of contact, and handles the case on the IRC channel, while the rats take care of the in-game communications and the actual fueling of the client. We won't say that Dispatching is the most important job, but it is important to do it right.

Use of tools and aids

The Fuel Rats tech stack has grown large and feature rich over time, and provides a number of tools and automatic aids to dispatchers to ease the case flow. However, there is a very important thing to remember with regards to this:

Your primary tool is yourself, and the source of truth for case information is IRC!

Although Mechasqueak and the Dispatch board provides tools, they rely on the most difficult of computer tasks - understanding and correctly capturing human input. This is something computers are bad at, and humans are good at. What the automated systems may miss, you, as the dispatcher, should be able to notice. This means that when you are dispatching, your focus should primarily be on what IRC is telling you - what the client and the rats are saying. Mecha may crash. The API may go down, or the dispatch board might not receive an update, or even silently lose its connection and no longer update at all. But as long as IRC is working, it is entirely possible to run cases. The list below describes our tech stack for case handling, in order of resilience and authority.

• IRC chat: As long as our servers are up and running, we are able to receive clients in chat, and they can be handled completely manually. You should be able to handle a client entirely without the use of additional tools.
• RatMama announcements: The client submits information using a form that RatMama announces into #fuelrats when the client arrives. If a problem develops with the announcer, the client is instructed by the topic line to trigger a ratsignal manually.
• MechaSqueak board: MechaSqueak has an internal board system that works independently of any backend systems. Even if system information or the API is unavailable, Mechasqueak can still track cases using manual commands. If MechaSqueak goes down, cases have to be tracked entirely manually, either in memory or using pen and paper.
• MechaSqueak facts: Contains canned responses and instructions for how the client should proceed on various points of the case flow. These fact commands are available to help cut down on repetitive phrases Dispatch often has to say for each and every case. If MechaSqueak becomes unavailable, you must understand the case flow and what the client and rats need to do sufficiently to manually instruct the client.
• API: The main API stores our paperwork, and various other APIs provide such things as system information and distances to landmarks. If these systems are unavailable, paperwork cannot be filed until they are once again available, or system information may not be available in IRC.
• Dispatch board: Tied into the API, the dispatch board presents a graphical view of active cases. It also tries to collect relevant information to each case from #fuelrats. This tool is useful for when there are a lot of cases going on at once, as a reference for keeping track of multiple threads and not having to scroll back and forth in chat to keep everything in mind. It is NOT a substitute for paying attention to IRC! 

Be aware of the priority of these systems. You should be able to dispatch using only the first item on the list - IRC. 

Preparing for dispatch

In most cases, there is only one active Dispatch on #fuelrats. The role and responsibility of Dispatcher is passed from person to person as needed, and is in Fuel Rats colloquium called "Having the hat". To simplify seeing who has the hat, most Dispatchers tag themselves with the [DISPATCH] tag after their nickname on IRC. It's not a requirement, but it helps to keep people aware of who has the hat.

Check the Board for inactive cases and familiarize yourself with them; if necessary, ask rats assigned to the case on their status, or in #RatChat if none of them are online. You may also want to bring up the web based Dispatch Board to help track cases, or equip yourself with pen and paper, in case things get busy. Having an open Private Message window to MechaSqueak can also help.

Client Arrival

99% of our cases arrive through the webpage, and are thus announced onto the server by RatMama, with all the relevant details of the case.

<&RatMama[BOT]> Incoming Client: Testclient - System: Fuelum - Platform: PC - O2: OK - Language: English (en-US)

MechaSqueak responds to this by creating a case for the client, and triggering a Ratsignal that should highlight rats and notify them of the new case. Unless the client skipped entering any information, everything you and the Rats need to start the rescue is presented in that line of text - the CMDR name of the client, their system, what platform they are on, and their O2 status.

Your first action as Dispatch should be to !prep the client, which has Mecha tell them to power down their modules and come to a complete stop. It also tells them to leave their Multi-crew session if they're in one.  (See the MechaSqueak Command Reference)  A Multi-crew session prevents them from winging with the Rats, so it's important that they exit their session.

Assigning Rats

At this point, rats should call their jumps to the client, indicating both their willingness to go on the rescue, and how far away they are from them. For a normal, non-code red rescue, one or two rats is sufficient. Two rats are preferred and is the standard for all non-CR rescues.  If it's slow, and the rats for the most part have the same jump count, feel free to assign more. Using the !assign or !go commands, send the rats on the rescue, and if necessary instruct the client on how to add the rats to their friends list, using the platform-dependent !facts. While underway to the client, the rats will report back when they have received the friend request (Or the lack thereof), and you can have the client add them to their wing, and then drop the beacon.

To remove rats from a rescue, use the !unassign command.  Rats should be unassigned if they don't attempt a rescue after calling jumps, or incorrect Rat assignments are made.  The intent of unassigning Rats isn't to remove them if they've made effort in attempting to rescue a client.  For example, if multiple Rats attempt to wing and instance with a client unsuccessfully, they should NOT be unassigned after their attempts.  Likewise, if multiple Rats are assigned to an LRR and fly towards a client's location, one of them shouldn't be unassigned if the client returns early and the Rat isn't online for the actual rescue.

For Long Range Rescues see our Long Range Rescue Guide.

The Rescue

Once the rats arrive in the client's system, they will report this and whether they have the beacon in sight. Sometimes, the client may be in the sun's exclusion zone, which may require a SuperCruise hop, which is performed by having the client reenable their FSD and thrusters, go to SuperCruise, and head away from the star for a few seconds before dropping back down.

Barring any instancing problems, the rats should then be able to drop on their beacon and deliver fuel. They will indicate this with the fueling, refueling or fuel+ report. Once they do, you can safely !close the case. Instruct the rats to perform debrief and paperwork, and thank the client for their custom.

Related articles

• Page:
  Dispatch SOP
• Page:
  Submitting screenshots for our Front Page and The Rodent Report
• Page:
  How to filter the Galaxy Map for scoopable Stars!
• Page:
  IRC FAQ
• Page:
  Как фильтровать карту галактики по классам звёзд (4.0)

Dispatch SOP Quick Reference Sheet

Standard Rescue (Client not on Emergency O2)

1. !Prep the client.
2. Assign rats to the client.
3. If needed, give instructions to client about friend requests/wing invite/beacon.
4. If the client is far away it's a good idea to have them check their fuel status and notify dispatch when the get low or even log them out to conserve fuel.
5. If the rat(s) don't get instance, perform a SC-hop.
6. If still no instance, have all rats and the client restart the game (no need to close the launcher), test comms from main menu and try again with rats in SC ready for beacon and wing.
7. When clearing a case, assign the rat that got first limpet to do the paperwork. (Use !close <case> <rat> )
   1. If the client disconnects or otherwise disappears before we can successfully rescue them, file the rescue as normal, under the "other" category.
   2. If no rat was assigned or it was a duplicate case, use !md to add it to the deletion list.

Code Red Procedures (Client on Emergency O2)

Ensure that you have the client's system, and that the client has logged out to main menu.

1. Make sure they don't log in until told otherwise.
2. CRs are usually (but not always) performed by 3 rats to raise the chance of successfully instancing with the client.

3. Get the client's location in system, and place rats accordingly. If we do not have an accurate position, see the Bearing and Distance section below.

4. Give the client instructions on how to set their beacon and send wing invites, and have them log into open play.
   1. If client is too far for the rats to reach in short order, let the rats get a bearing and distance and log them out to main menu again until rats are in position. See Supercruise Travel Times for an estimate on how long a rat will take to fly a certain distance.
   2. If the rats can't get instance, distance to beacon can be helpful to see if client is in exclusion-zone. In any case, log client out again.
   3. If client is in exclusion zone (EZ), rats need to perform a TFP (tactical faceplant).
   4. If client is not in EZ, let all involved parties restart the game (no need to close the launcher). Have the client send text messages to each rat from main menu, and try again with rats in SC ready for beacon and wing.
      1. If client is in open space (not close to any structures), one of the rats may wait at the drop in normal space for next login of client and do a short SC-hop followed by a nav-lock-drop if the client doesn't respawn right in front of them.
      2. If this also fails, the client may not be connectable due to NAT problems. Follow the NAT Troubleshooting guide. (Not implemented yet)

Tactical Faceplant (TFP)

If rats are unsure how to perform this as it is actually very seldom:

1. Rats should be a bit away from the star so that they can circle it if necessary. A rule-of-thumb would be a speed of 2c.
2. They have to bring the wing-signal and the center of the star into overlap and try to keep that until they automatically emergency-drop.
3. Even when they only see a signal after drop, they shall start boosting towards it. It often takes 20-30s for the client to actually pop-up in the game.

TFP blind drop. This is just in case a standard TFP drop does not work.

A blind drop = untargetting beacon and dropping blind on the approximate location

Blind drop = go to towards the beacon, slow down to 30km/s (minimum SC speed), at about 300 km distance untarget the beacon, count 10s and drop. Hopefully you'll get close enough to client.

You can practice that on outposts - they work the exact same way as wing beacon in this regard. FSD will actually tell you "no target, dropping"

Please note that the drop spot can be affected by server lag. Up to 2s – that is 60 km.

Mecha Command Reference 

These are some of the more common Mecha commands you will use during a rescue. For more thorough reference how to use mecha during rescues, see Mecha Interaction - For Dispatchers