Closing cases is important so that we have accurate records of our successes, failures and other cases.
For purposes of this SOP:
- Dispatching rats is defined as dispatch telling them to go. It does not require them to be !assigned to a case in Mecha
- A successful Fuel Rescue is defined as following SOP, including debrief and ensuring the client can reach a scoopable star or station, except as noted below
- A successful non-Fuel Rescue is generally defined as jumponium or repair cases in which the client can continue on their previous activities.
Cases that should always be filed as Valid Cases
- If Rats are dispatched, Fuel or Non-Fuel Rescues (e.g. Jumponium or Emergency-repairs) should always be filed as valid cases.
- If a client is fueled or otherwise provided with jumponium or repairs (i.e. Rescued) by Rat(s) file the case as a "Success".
- When a rescue does not occur because the client was able to rescue themselves (i.e. make it to a station, star, etc.), changed their mind, or became unresponsive, after Rats are dispatched, the case should be filed as "Other".
- If the client is destroyed due to a lack of fuel, after Rats are dispatched, the case should be filed as a "Failure".
- If the client is destroyed due to NPCs or player attacks, after Rats are dispatched and before a limpet or rescue is completed, the case should be filed as "Other".
- If the client is destroyed due to NPCs or players, after Rats are dispatched but after a limpet or rescue is completed, the case should be filed as "Success".
Cases that can be marked for deletion
Generally, cases where Rat(s) have not been dispatched can be marked for deletion using the command !md <case# or clientname> <reason> (see below for other related commands).
- PEBKAC - When a rat or other visitor mistakenly raises a ratsignal, or improperly uses the !inject or !grab commands.
- Duplicates - More than one case from the same client, usually caused by reconnecting using the IRC client in rescue mode, after the rescue has been cleared.
- Clients who change their mind (such as make it to a station or scoopable star, reboot/repair or otherwise save themselves even with help from us) - without dispatching rats to their case. If rats have been dispatched, it is a valid case (see above).
- Clients who immediately leave chat - Clients that start a rescue, but do not respond to our communications, or immediately leave IRC.
- Clients who have pushed the wrong button - i.e, their intent was just to chat with us, but they did not understand the green button, or want to see how the system works.
Cases that should NOT be deleted
Cases where Rat(s) have been dispatched should be filed and assigned a rescue outcome:
- Cases where the client changes their mind either because they choose to self-destruct, or find a way to carry on their journey (Either through tips from the Rats or on their own). Clear case and file as "Other"
Fake Calls - Calls which are intentionally created for purposes other than a legitimate need for fuel. ALWAYS clear case and file as "Invalid", and then report the event to a Janitor. These cases get filed regardless if Rats were dispatched or not.
Cat calls - Fake cases in an attempt to lure us out for target practice.
- Troll calls - Cases where a user intentionally creates a case for purposes other than requiring fuel. Typically these reasons include: personal amusement, attention, attempting to troll the dispatcher, or to generally disrupt the rescue channel.
When to close inactive cases
Inactive cases should be closed and filed after they have exceeded the times below. In the event that the client returns after their case has been closed, a new case should be created.
- 15 minutes after a client leaves chat immediately.
- 1 hour after the client leaves chat mid-rescue.
- 24 hours after a LRR client fails to make a meeting time, and cannot be contacted.
Associated Commands
| Command | Function |
|---|---|
| !md <case#/clientname> <reason> | Marks a case for deletion. Usable by any Rat. |
| !delete <caseID> | Confirms that a case should be deleted from the database. NOT REVERTABLE. Use with care. Overseers+ |
| !mdremove <caseID> | Removes a case from the Marked for Deletion list, returning it to the case pool, but not reopening it on the board. This means that paperwork will need to be filed for it. Overseers+ |
| !mdlist | Lists cases marked for deletion. Overseers+ |
| !invalid <caseID> | Marks an already closed case as "Invalid", this also removes it from Marked-for-deletion-list if applied. Usable by any Rat. |
22 Comments
CrunchyBaton955
Reminder to review these. "just to see how to we do things" probably shouldn't go under cat calls. sometimes people just hit the wrong button and rat aren't dispatched
Absolver
Clarified the points.
Cpt_Shinobi
How is that a success? No fuel = No success. Otherwise the "Cmdrs Saved Number" stops being the "Cmdrs saved number".
Stillian
Would also appreciate clarification on 'death before Rats assigned,' as I'm seeing a lot of these and feel this guide is not 100% clear on what to do with them.
MasterLoon
We had another borderline case just now. Rats was assigned very quickly after client (CMDR ENS-LEGIS ENTITY) came in from website, and about 1 min later client says "Hello, I just bought horizons and decided I would try out the lander by driving from the edge of a crater to the mt in the middle. Unfortunately, I can't locate my ship again! Can someone assist me in locating my ship on the surface? I have 25% fuel left"
Was cleared as success per guidelines "client changed his mind".
MasterLoon
I'd usually when dispatching, spend a little extra time on prepping the client before actually assigning the rats on the case - this gives the client amble chance to cancel the rescue if there's other reasons why he/she pushed the button. This weeds out most of these situations and also gives out rats a little time to call their jumps so it's not just the first caller who gets assigned + ensured more clients actually finish prep before they are asked to perform next task.
Most of the questionable cases I've seen was because rats was assigned on cases they probably shouldn't have been too early in the process..
Also on a sidenote - I don't seem to be able to access OPS-30 - JIRA
Dystopia
Yep this is the recent case details Pastebin of the conversation re md or success for a recent odd case https://paste.fuelrats.com/bakodicixi.xml
<Dystopia> And the actual rescue log https://paste.fuelrats.com/zazabejele.xml
My view is that this is an odd one. Probably need to ask spatches to be clearer in analysing the needs of the client? Don't know that we need to do much more?
Tom X
One comment:
The rules at the top seem very prescriptive - trying to identify each situation and deal with it.
Instead I'd suggest a set of principles.
Such as (a bit back to foront but :
1, Is there a commadner desiring a rescue (for fuel or anything else) that continues until the end of the case. (The you don't principle).
(So anyone who calls then finds they can get themselves out of it is a success, helping with SRVs etc. all sucesses, So griefers/traps/people leaving IRC/choosing to self destruct wouldn't be cases because there wasn't a continuing desire for rescue)
2, Is there a commander desiring a rescue leave fuelled and rescued - That's a success.
(The we have fuel pinciple/Any rescue they walk away from is a good rescue.)
In the same way as in aviation they say any landing you walk away from is a good landing - once we get them to a state of being safe and on their way that's it done - so people we fuel then escort that pile into the station are successes - basically because if we hadn't escorted we'd never have known...
(There probably would have to be a decision on whether being fueled and then killed by npc/cats or boosting and dying during the debrief etc. is a success. Traditioinally it has been (limpet delivered is end of rescue, but personally I don't think it should be - otherwise there's no incentive for us to work to prevent NPCs being dragged down with us etc.)
Any questions? There will always be grey areas but it won't be possible to address them all.
Personally with the rules as they are above - I feel recording cat attacks and self destructs as successful cases is being a bit dodgy with our claims/statistics (even if it isn't very much) and leaves a bad taste in the mouth.
Stillian
I think what you've proposed needs refining, but I broadly agree with more holistic rules on this matter.
Falcon JSDF (Royd)
Just got pulled up on this. We cannot call it a success if no fuel is delivered. That will only falsely inflate our success rate and make it meaning less. If client changes their mind and we are no longer needed that isn't failure. No fuel delivered isn't success therefore delete. We do ourselves no favours faking our rescue numbers
Clapton
what's not being explained here is why you should be attributing these cases to the "N/A". We're planning on adding some new ways of handling these kinds of odd cases, and for now storing them with the N/A Rat. Please at least file these with that rat.
Orange Sheets
And we are using the N/A to tag those odd cases that will be properly classified retroactively, in the future.
Stillian
Just a quick one, but I would be greatly appreciative if we could ask Rats to be more clear in their MD explanations. I often find myself querying cases where a Rat is assigned but the case is marked as "Client left IRC," which misses the vital information of "left immediately" or "left without any communication."
Clapton
Agreed. Adding reminder.
Unknown User (esxste)
This needs updating given the Website updates
CrunchyBaton955
Updated for new rescues states.
Tom X
How about if the client is successfully rescued by another agency (friends etc) after rats have been dispatched.
CrunchyBaton955
I think that'd very clearly fall under:
Bold Mole
As there was this problem just now.... client left unnoticed and a rat was assigned afterwards, leaving a blind spot in how to file cases, a good suggestions was made:
[22:18:36] .:NumberPi:. Just change "...before we dispatch rats to their case." to "...without dispatching rats to their case"
[22:18:46] .:NumberPi:. If that's the correct intention
Imo covers these rare cases, too. And removes an uncertain decision. I'll change it now.
Salvuu
When closing cases that are not a success, i.e Other or Failure, we close it without a first limpet rat. However some newer dispatches sometimes are not aware of this and still close it with a rat. While in both the dispatch SOP and Mecha interactions
!close <case no.> <first limpet rat> is mentioned it might not be clear enough. Since this page deals with closing cases how about adding a line about how closing cases that are not successful should be without a first limpet rat and that the paperwork should be assigned manually-ish to one of the assigned rats by dispatch to clear up confusion.
NumberPi
The Mecha Command Reference has it written correctly with
!clear <Client Name|Board Index> [First Limpet Sender]The others incorrectly imply the first limpet is required by using
<>.Delryn
This is in need of an update for Fleet Carrier rescues, which are semi-officially-supported in IRC.
An FC rescue technially is covered by these regulations (rat assigned and fuel provided), but if anyone is searching for FC rescue information (which is a discreet type of rescue), they won't see it here.