Introduction

Long Range Rescues are defined as any rescue surpassing 1,000 LY from the bubble boundary (Approximately 500 light years from Sol). For rescues at this range, the expenditure of time requires more judicious use of Fuel Rat resources, and is subject to slightly different procedures.

 

Verifying client position

When a client calls for rescue outside of the bubble, our first action (Unless it is a Code Red rescue, of course) is to have the client's position verified. This is usually accomplished by having the client send a friend request (And if needed, a wing request) to a Rat. It doesn't matter if this rat will be going on the LRR or not, they are just confirming the client's location.  The rat checks their galaxy map to verify that the client is in the system they claim to be.

This is necessary, as there have been cats who have tried to trick us with this before.

Check for Jumponium

If the client isn't CR and has sufficient fuel it could be valuable to have them check if they any jumponium boosts and if any of them would allow them to reach a scoopable star. This can best be confirmed by having Rats confirm the closest scoopable while the client is on the menu. The last thing we want is for them to go CR.

Arranging client meetup

In most cases, long range rescues require a travel time of several hours, if not a day or more of near-constant jumping. This makes it unfeasible to have the client wait for the rat(s) to arrive. In conference with the rat(s) assigned, a suitable meeting time is set up with the client for when they will be available to log on after the rats have completed their journey to the client's system.

Flexibility is key here; clients sometimes can't make their arranged time, and rats may run into unforeseen consequences en route to their rescue. 

 

Case Management for Dispatch

When a long range rescue arrives, the rescue workflow deviates from normal. Once the client's O2 and fuel status has been established, redirect them to #RatChat for discussion on the particulars of their rescue. From there:

  • Verify client position
  • Log client out of the game
  • Ask for rats interested in going on the LRR.  It's also a good idea to Tweet for rats that may already be nearby exploring (see Mecha's command documentation for information on how to Tweet case information)
  • !assign rats to the case. If at all possible, send more than one rat. LRRs can be attended by more than three rats, if many are eager to go.  Keep in mind that on consoles, this may leave the a minimal number of rats in the bubble.
  • Gauge time needed to reach the system. Assume a pace of about 1,500 LY for an non-engineered ship, 2,500 LY per hour for an engineered ship not using neutrons and about 4,000 LY per hour for using neutrons.
  • Based on pace and the rats' needs (Work, sleep and other commitments), arrange a meeting time with the client.
  • !inject information on meetup time and other details into the case such as an approximate distance from a major landmark (i.e. Bubble or Colonia).  Make sure to reference all times UTC
  • Once the rats are on the way, make the case inactive until the rescue is about to be undertaken. At this point, move rescue traffic back to #FuelRats.

 

6 Comments

  1. I would suggest that an LRR be defined as "any rescue that is outside the bubble, and requires telling the client it will take more than 1 hour of travel time". 

  2. I agree.  The definition should guide that it's a different SOP to follow (verify position, arrange meetup if needed, etc.) not the location of the rescue, which is meaningless imo.  Being an LRR does not immediately tie it to any type of epic laurel or prestige that seems to come up sometimes, with discussions trying to classify rescues as MRR vs. LRR. All it means is that the rat(s) won't be able to call jumps on other rescues for a while

    1. This is even more relevant since there is now a second bubble around Colonia, and some rats have taken up residence there.

  3. Since some clients on LRR's are in systems that are not yet in the system DB, a possible step could be asking a client to upload their current journal file to EDSM? That will add the system to the DB, and make it available for routing in Spansh, for example.

    1. How will console players upload their journal files? They cannot get to them.

      Also, as far as I know, spansh has its own database which is periodically synced with EDSM, so the system will not appear immediately.

      Finally spansh also has a nearest feature, where you can enter coordinates and then get the nearest system known to spansh, which makes searching for a "spanshable" system easy.

      1. console rats can create a account on EDSm using the frontier APIU and it will synch to edsm