Below you will find a list of common terms we use in standard rescue operations. It's important to note that you are not limited by these common terms when talking in #FuelRats, and you're free to communicate in a way that is most comfortable to you.

Be aware of your language!

Are you sure your callouts make sense? Ambiguity in communication is the #2 client killer (it's true*)! Avoid using language that could be interpreted different ways or considered a typo. (EG: use "Wr+" or "in wing" instead of just "wing")

Abbreviations often used during rescue operations:

  • BC (Beacon) The beacon fitted to all ships which can be enabled to enable your wing mates to drop on it.
    • BC+: The rats can now see the client’s beacon and are on their way to dropping into the client's instance for refueling.
    • BC-: The rat doesn’t see the client beacon
  • CR (Case Red / Code Red) An alert that indicates the client has lost power to life support and the clock is counting down on their oxygen depletion timer
  • DB (Debrief) When a rat has refueled the client, they have a conversation with the client about what they may need to know concerning fuel and/or the game as a whole, in some cases
  • DC (Disconnected) Abbreviation used in #FuelRats. Got kicked out of the game, either to Main Menu or out of the whole game
  • EZ (Exclusion Zone) The area around a stellar body where your ship is automatically dropped to normal space to avoid crashing into the stellar body.  A client in EZ prevents instancing with them through navlock and requires them to SC Hop away or a Tactical Face Plant (usually just on CR's).
  • FR (Friend Request) The first step of a rescue, the client adds the rat as a friend in game.
    • FR+ or "FR received" is reported when a request from a client is received and accepted.
    • FR- Can be used to let dispatch know the request didn't get through, or client neglected to send it (after appropriate time has passed)
  • FUEL / Refueling Report that tells dispatch that at least the first limpet fired has completed its fuel transfer (giving you the on screen confirmation “Fuel Transfer Complete”). Reported either as "Fuel+" or "Refueling".
  • HOR/HORI (Horizons) Used to indicate the game mode Horizons, or potentially that a client is in said game mode.
  • INST (Instancing) The efforts to establish a Peer-to-Peer connection with a client. If attempts fail, “no instancing,” is specified and workarounds begin to be used in order to resolve the connection issue.
    • INST+ Optionally reported on dropping on clients beacon and in instance with client
    • INST- Reported if dropped on beacon, but not seeing clients ship
  • J (Jumps) Called by Rats responding to a rescue call in order to determine who is closest to support (e.g. 2j, restock + 1j, etc.)
  • Legacy Used to indicate the game mode legacy, or potentially that a client is in said game mode.
  • Long Drop called by rats who are in the process of dropping on a client's beacon and are experiencing a longer than normal time to enter into the instance
  • MM (Main Menu) Often used like "client in mm" during CR rescues.
  • ODY (Odyssey) Used to indicate the current live game mode Odyssey, or potentially that a client is in said mode.
  • PG (Private Group) Used to indicate the game mode private group, or potentially a client is in a private group.
  • PW (Paperwork) When a rat has completed a rescue, they file/edit the case, called "paperwork" provided by the bot.
  • Party Xbox voice communications which are separate from the game itself. Often reported as Party+
  • PREP Can be reported to alert dispatch that clients shields are still up after getting in the wing.
    • PREP- client didn't comply with module-shutdown.
    • PREP+ client has now complied with instructions after PREP- was reported.
  • POS (Position) used on CR cases as "POS+" when a rat reaches a given in-system position, for example 1000ls from a named station, to let dispatch know you are holding there ready for the client to log in.
  • Rdy (Ready) Primarily used in CRs and LRRS to indicate that a rat or client is prepared for login
  • RGR (Roger) A rat will use this to show they acknowledge the information/request/command. Sometimes you may see COPY or ACK - same thing.
  • SC HOP (Supercruise Hop) A technique used to resolve instancing, the client powers up their thrusters and frameshift drive, enters supercruise for 5-10 seconds away from any stellar bodies while the rat(s) wait in SC to confirm positive instancing - or simply to get client away from EZ of a planet/star.
  • SOLO Used to indicate the game mode solo play, in which no instancing with other players may occur.  May also be used to indicate that a client is in Solo Play.
  • STBY (Standby) "please wait"
  • STDN (Stand down) A rat will use this to communicate they are no longer participating in a rescue. Dispatchers will also sometimes use this to tell other rats to stand down from a case.
  • SYS (System) When a rat has arrived in the client’s system, a call of 'SYS+' may be made. Only used when the client is not actually in-game and has beacon active, such as Code Red or long range rescues where the client is logged out to the main menu. Otherwise, a 'bc+' automatically implies that the rat is in the system.
  • SYSCONF Can optionally be reported once a clients reported system has been verified correct on the Galmap (clients green friend icon shown being there). Most commonly used in CR and LRR rescues.
  • TFP (Tactical Face Plant) The technique of manually flying into the Exclusion Zone to achieve instancing with a client.  Requires practice!
  • TM (Team Request) The second step of a rescue, the client invites the rat to a team.  Can be used interchangeably with WR.
    • A response to a team request may be “TM Received” or even more simply “TM+”, or if sufficient time has passed and the request hasn’t been received “TM-"
  • WR (Wing Request) The second step of a rescue, the client invites the Rat.  Can be used interchangeably with TM.
    • A response to a wing request may be “WR Received” or even more simply “WR+”, or if sufficient time has passed and the request hasn’t been received “WR-“

Other or more general abbreviations & terminology:

  • Bubble, The Civilized space (refer to the Powerplay view of the galaxy map for a rough illustration)
  • Client The person we are serving fuel
  • Dispatch The rat who is coordinating activity on #FuelRats.  Also known as Spatch or The Hat.
  • Drillsignal is used by drill clients as a replacement for "ratsignal" during a drill. (Not used to find seers)
  • Hat, The Symbolic identifier for the Dispatch. Quite frequently put onto the stuffed rat “Stuffy” after a hectic session of dispatching.
  • Hatsignal is a term used to notify other Rats that a dispatch is needed.  It should only be used after a client is !prep'd (which every rat should and can do).
  • Epic Rescue Any rescue nominated by another rat for its sheer epic awesomeness may reward the rat with Laurels for their roundel!  Any rescue requiring more than 15,000Ly travel to the client is automatically considered epic but still requires a nomination.
  • FL (First Limpet) Sometimes a term used by Dispatch to ask Rats to identify who to award the rescue to. Usually means first Rat to land a limpet on the client and receive a refuelling message on screen.  
  • LRR (Long Range Rescue/Refuel) Any rescue where the client is more than 5000ly from human space
  • Mischief, The Did you know that the collective noun for Rat is “Mischief”?
  • ND "Needs Drill", A tag seen on newer rats, who think they are ready for a drill.
  • PSRat  A Playstation Rat or case, because the alternative wasn't very nice.
  • Ratsignal Alert!  A client needs fuel, man your ship and call your jumps! Never say this unless you are stranded without fuel.
  • Roundel How to display all of your ratting accomplishments!  
  • XRat/XBRat An Xbox Rat or Xbox case, because we love our terminology.


*There is no statistical evidence to definitively prove that miscommunication is a leading cause of failed rescues.

 

19 Comments

  1. Unknown User (xastrono)

    Add "Synth: aka O2 synthesis, limpet synthesis" ect (smile)_

  2. the definition for sys+ here is likely why we see new rats use it during rescues.

  3. What is wrong with sys+ ?

    1. It's redundant in almost all cases. 

      bc- or bc+ serves the same purpose, and gives more information to the dispatcher. 

      The only time a sys+ is applicable is if a rat is on a long range rescue, and the client isn't in IRC, and so the case needs to be updated by the dispatcher to note that the rat has arrived in system. 

      1. Sys+ is great to use with fr- or wr- for Hat to nudge client along to sending those. Also aplicable when rats are in a system before a client is even instructed to send invites.

        1. you should not report sys+ when not even assigned, one jump call per case is enough.

          and fr- or wr- does the "nudging, not sys+. its totally irrelevant if you are in the system (which you cant even confirm possibly at that point)

        2. The key question is: What does dispatch do with sys+? what action does it trigger for the dispatch to perform?


          To put this into perspective, fr- informs dispatch that you expected a friend request, and did not receive one, and triggers them to, at an appropriate time, as they client to add you as a friend once again. 


          WR+ will inform the dispatch you're in a wing with the client, and triggers the dispatch to ask the client to turn on their wing beacon. 


          The goal is for communications between dispatch and rats to be clear and concise. Every communication should have a clear and useful purpose. sys+ is, almost always, purposeless, and in the instances where it would have a purpose, bc- and "bc+ 3kls" are clearer and more concise in delivering the the information the dispatcher needs. 

          1. This ^^ using sys+ before assigned also gives me a feeling of "hey, whatever those other rats called before, it's irrelevant, I'm here so assign me pls" (unless you happen to be in the same system as the client of course, or didn't call jumps for that case earlier)

            1. Yes, its become quite the nuisance and makes ratlings feel they need to update their current jumps as well. I don't like to be pressurized into assigns like that and usually will exclude a ratling doing it from a case.

      2. Useful during Code Reds when the client is logged out and Dispatch is marshalling their rats into system.

        1. I refer to my previous question, what action does it trigger for the dispatch? 

          In a Code Red, it would be far better for rats to report pos+; signalling that they are indeed in the system, in the reported position (or in position for a bearing check) and ready to go - triggering the dispatch, when appropriate, to get the client to log in. 

          1. If I know a rat is at least in the system already, I can begin walking the client through CRINST and its relatively safe to catch should he log in during that preparation phase. I always wait for that before I tell them what to actually do.

  4. could we perhaps remove the "available to be assigned to a case" part of the STBY defintion?   It's never really used in that context as we just call jumps.  the only time I see it used in that way are by newer rats who aren't quite familiar with how to call jumps

  5. I recommend 'MMCONF' be added as an alternative to "MM".

    *opens a bag of m&m's*

  6. If we could rewrite or add some phrases commonly used by the rats now it might be beneficial, at least I think spatches don't have to tell ratlings what not to report as much as right now

    For INST, i find occasionally ratlings reporting inst+ when dropping on the client before actually fueling the client, perhaps the position of INST+ could be below INST- like how prep+/- was dealt with and the definition of INST+ could be written as "Reported in situations where INST- was previously observed, or during special scenarios like TFPs or blind drops, Not to be used if it were to delay refueling the client."

    For STBY like what nvn said we never use it nowadays to be honest, removing it altogether might be a better call

    For SYSCONF, since we require rats to do it on all LRRs, perhaps it would be better to add this into the definition, the checking sys on gal map is not entirely in line with what we do now checking client sys on comms panel when fr+ either, i would think "Should be reported on LRRs after client system is verified, can optionally be reported on normal cases after client system is checked via comms panel when friends with the client or via galaxy map when in wing."

    The below 2 items are quite commonly used but not included in the lexicon, many newer rats don't know what they mean when on a rescue

    Chain/Chaining: Dispatch will use this phrase to ask a rat to send a friend and wing request to another rat, commonly used when a client only adds one rat and not the other.

    Navcheck: Dispatch will use this phrase to ask a rat to check whether the client has fuel to jump to another system after the rat is in system. This is performed by checking the navigations panel to see whether the client can jump to nearby systems. (this is a bit chunky and might need link up with the !navcheck fact)

    1. A review of this page is definitely in order.

      RTB is never used as far as I know. Comms+/- is a common inject and can also refer to the comms panel in-game. WR needs to be updated with TM. To name a few things...

      1. The definition of "ND" here may also be why some ratlings thing drills are regularly scheduled events organised by the higher-ups, and that they have to sign up for a drill.

    2. +1 to adding "navcheck", perhaps also with a mention of "no jumps" since that's how I've seen rats respond to it