Skip to main content ↑ ↓You are either not logged in or not registered with our community. Click here to register.

WikiFullscreen ChatVoice Chat (Discord)Org PageF.A.Q.
Topic: "Blue Fire" Response Protocol Proposal (Read 11882 times) previous topic - next topic

"Blue Fire" Response Protocol Proposal

Okay, so we know that we're likely to be infiltrated by 'Dents and other ne'er-do-wells who will be trying to monkey-wrench Pitchfork. We're also going to have a very large number of ships in space, many of them without any organized leadership- which isn't to say that lone wolves aren't welcome, just that a disorganized group is more vulnerable to friendly fire incidents by nature.

Honest mistakes happen, especially when lag gets thrown into the mix. Anyone can get tunnel vision; it would be easy for a pilot to miss a shot on their intended target and accidentally hit a friendly ship beyond it. Likewise, one pilot might unintentionally cut across or into another player's line of fire while in pursuit of their target, or two ships might get in each others' way while pursuing the same target. Even those of us who will be flying with guildmates or in more organized Pitchfork-dedicated squadrons can fall victim to these sorts of mistakes. The last thing we need is to wind up blowing each other up over the fear that somebody might be a traitor.

What we clearly need is a standardized protocol for dealing with those incidents in a way that allows us to distinguish a simple "oops" from a deliberate act of sabotage.

My proposal:

Section I: Immediate Response Protocols

1. In the event that a "blue fire" incident occurs and is recognized, any ships involved will immediately disengage and separate from each other.

2. The ship that fired the shot will immediately contact the ship or ships they hit to let them know that they did not intend harm.
|------> 2a. If the shooter is operating as part of a unit, then they must contact the rest of their group to let them know what happened and why they are breaking off.

3. The ship that took the hit will immediately contact the shooter to determine the nature of the incident.
|------> 3a. If the affected ship is operating as part of a unit, then the pilot must also contact the rest of their group to let them know what happened and why they are breaking off and to make sure no action is taken until the nature of the incident is determined.

The above steps are critical and must be part of any action plan. I realize that I'm asking people to possibly render themselves vulnerable during a space battle, but the best way to prove that an accident is an accident is for both parties to make an immediate and obvious display of non-aggression towards each other. We do not need anybody reacting to a friendly hit with insults and aggression, and we definitely don't need an isolated incident becoming an instance-wide he-said, she-said that degenerates into all-out infighting. That kind of self-destructive, paranoid behavior is exactly what the saboteurs want. We have to be better than that.

Section II: Post-Incident Response Protocols

4. If it is determined that the incident was accidental...
|------> 4a. If the players involved bear no ill will, then they may go back to whatever they were doing.
|------> 4b. If the players involved would rather be separated, then one or the other must attempt to leave the instance. Which player leaves will be determined by the following criteria:
--------|------>4b.i. If fault can be determined, then the player at fault will attempt to leave.
--------|------>4b.ii. If no fault can be determined, then both players must attempt to leave the instance.
--------|------>4b.iii. If one player is unable to leave the instance, then the other must attempt to leave.
--------|------>4b.iv. If neither player is able to leave the instance, then they should attempt to maintain a minimum distance from each other for the remainder of the battle.

For the above, reasons why a player may be unable to leave an instance may include:
- The player is operating as part of an organized group in that instance.
- The game does not allow the player to leave the instance.
- The player's ship is disabled.
- The player's ship is otherwise unable to leave the instance (too slow, no jump drive, or there is only one local instance).

Reasons why fault may not be readily apparent or discernible may include:
- Combat in the instance where the incident occurred is too intense to allow for investigation.
- There is no neutral third party willing or able to arbitrate the dispute.
- Both players may be at fault.
- Neither player may be at fault.

5. To account for skill gaps, lag, and carelessness, a three-strike policy will be implemented for non-critical incidents.
|------> 5a. "Non-critical" refers specifically to friendly fire incidents which result in minimal or negligible damage with no loss of life on the affected ships.
|------> 5b. "Carelessness" refers both to negligent shooting (i.e. hitting other players while attempting to hit an enemy instead) and negligent flying (i.e. crossing another player's line of fire without warning, resulting in a friendly fire incident).

There is no need to whip out the *ahem* torches and pitchforks over a few stray shots. It only becomes a problem when someone who's been warned to be more careful consistently fails to do so.

6. In critical but non-lethal incidents, only a single incident will be tolerated.
|------> 6a. "Critical" means that serious damage was done to a friendly ship.

7. Due to operational security concerns, a strict policy will apply to any lethal incidents with only one possible exception.
|------> 7a. Where a pilot or gunner has been deemed too dangerous to remain in a combat instance, yet is not obviously a saboteur, even if they have been killed or removed, or had their ship destroyed for the safety of other players in the instance, they may be permitted to assume a noncombat support role so as not to be excluded entirely from the remainder of the Operation.

I don't expect that it will be easy to seriously damage or destroy a friendly ship. The possibility needs to be accounted for, but it would have to be some kind of screwy set of circumstances to have an incident where bits are falling off someone's ship by accident (I'm picturing someone getting in the way of a torpedo launch or a Idris' railgun shot here).

However, we want to strive for leniency toward well-intentioned players. Stuff happens. If we want to call ourselves better than the trolls who want to screw up the Operation, then we need to act the part and go the extra mile to not be jerks even when a mishap results in permadeath. An accident is an accident, no matter how big of an accident it is. The above bits are focused on ensuring that serious accidents only happen once if they happen at all.

Section III: Precautionary Measures

8. Any player able to do so should maintain a record of friendly fire incidents to keep track of problem players.

...which neatly rolls into our existing need for Electronic Intelligence/Warfare oriented players (SWACS, etc) as well as everyone's desire to capture every moment of this glorious insanity for the sake of posterity and bragging rights. If we can identify and dispense justice to saboteurs in real-time as events unfold, so much the better. If we can't... well, then at least we'll know who they are after the fact so we can make sure they don't get keys to the clubhouse and show up at the after-party.

9. It is the responsibility of a ship's pilot/captain to deal with offenders aboard their ship.
|------> 9a. The pilot/captain of the offender's ship must be given a fair chance to deal with their crewmember before further action is taken.
|------> 9b. It is the pilot/captain's responsibility to prevent the offender from causing further harm while disciplining or removing them.
|------> 9c. If the pilot/captain of a ship is unable or unwilling to remove the offender from duty, or otherwise cannot prevent the offender from causing further harm, then their ship may be treated as though the entire crew were hostile.
|------> 9d. If the offender is in a parasite ship (i.e. a Merlin or carrier-based ship) then the pilot/captain of the mothership should attempt to deal with the offender if able to, or direct other players to do so who are able to.

10. If the offender is a member of an organized group, then that group is responsible for dealing with the offender.

With regards to 9 and 10: if you brought the idiot into the battle, it's your responsibility to clean up the mess. Hopefully that won't be much of an issue; hopefully folks will take the time to get to know their crews and squadmates before the Operation, but it bears mentioning just in case any trolls are just that dedicated. COs, either of ships or organized squads, should be aware of their subordinates' actions anyway.

11. Although COs are responsible for their subordinates, they and their remaining subordinates should not face sanction once the offender has been dealt with.

We do not cripple ourselves by killing/removing any more players, or destroying any more ships, than absolutely necessary to deal with the incident at hand. We want folks to be responsible if they choose to be leaders or members of organized groups, but we don't want to discourage cooperation by making everyone in a group suffer for the actions of a delinquent comrade. If the offender is a turret gunner, and they are removed from that position, there is no reason to go slagging the whole ship.

12. Obvious incidents of sabotage or treachery may be dealt with immediately by anyone within range to do so.
|------> 12a. If an offending pilot or gunner fails to disengage, they may be assumed to be hostile.
|------> 12b. Any player declared hostile and destroyed or killed may be attacked on sight if they attempt to return in a new ship.
|------> 12c. It should go without saying, but I'll say it anyway: anyone who attacks noncombat ships in a rear area where there are fewer enemies or no enemies should be treated as an obvious troll and the entire furious might of every gun in the area should smite their sorry ass accordingly.
|------> 12d. Don't waste ammunition on obvious trolls. That serves their interests more than it does ours; every bullet or missile wasted on a 'Dent is one that can't be used for makin' bacon. Use only energy weapons unless it is absolutely necessary to expend the ammo, and in that case use only as much as necessary to put the fool down.

------------------------------------------------------

...and that's all I've got for now. Thoughts?

Re: Proposal: "Blue Fire" Response Protocol

Reply #1 –
We definitely need to think about how to approach these sorts of situations, and I'm glad to see you've put so much thought into this situation. Honestly, I think a lot of it is going to handled by the people in the instance their own way.

Admittedly, I haven't been able to finish reading all of your post yet, but I just wanted you to know that it isn't being ignored. The parts I have skimmed definitely have a lot of work put into them.

Re: Proposal: "Blue Fire" Response Protocol

Reply #2 –
Honestly, if I take a friendly hit or two and it doesn't drop my shields, I'm not going to do anything. Accidents happen.

Now if someone unloads on my ship, it's a different story

Re: Proposal: "Blue Fire" Response Protocol

Reply #3 –
Really nice guidelines, Wrath.

Probably a bit much for the average forker to keep all in mind so maybe if command staff have the whole thing in mind while everyone just needs to learn 'If there's friendly fire, GTFO and call both the other guy and your superiors'

Re: Proposal: "Blue Fire" Response Protocol

Reply #4 –
Right... the first three are simple, easy to remember steps, and should in theory provide a pretty good way of weeding out most trolls (only a troll would keep shooting), while also providing a means of diffusing honest mistakes before they get blown out of proportion.

The most annoying griefers in gaming are almost invariably the ones that jump up in front of other players' guns so they can play the victim card and get the other player kicked or banned... but we'd be paying attention to both shooter and victim, so if a pattern of behavior emerges then the trolls will out themselves regardless of what approach they try to use. Sneakier trolls might get away with one or two incidents, but if they keep popping up either as shooter or victim then people will start getting suspicious.

Those first three are also steps that, if agreed on by everyone involved with the Operation, would give every instance a means of detecting griefers and dealing with them even if they don't have a command structure in place.

The rest is just brainstorming on my part... one suggestion for a plan to deal with things when there is an organized structure in place, or something for our troll hunters to use as a means of investigating and dealing with any incident that doesn't end at "crap, that was my fault, sorry dude" and "no worries, just be more careful next time."

Re: Proposal: "Blue Fire" Response Protocol

Reply #5 –
A bit complex, but covers a lot of ground. I think the ones who have to be the most careful about blue on blue fire will be the bombers and their escorts while they are under attack. But with DFM we should be able to set up escort training sessions to work out how to engage enemy targets while they line up on one of our assets.

Also we will need to act like mature players and think about how we might look to other forkers when laughing stuff off. For example if I'm escorting bombers, and fly in front of the formation to chase a fighter and accidentally ram a friendly torpedo, that is probably not the time to send "Leroy Jenkins!" in the communications to laugh it off. That could cast suspicion on myself in that context. Ramming an enemy ship while chasing that fighter? Sure. That would be appropriate.

Re: Proposal: "Blue Fire" Response Protocol

Reply #6 –
The dynamic (hell, even the genre) is very different, but if you want a decent way of practicing group tactics and formations, have a go at Planetside 2.

Yes, yes, it's a FPS but they've really got the comms system downpat in that and moving in formations within squads and larger groups really helps get you used to fire dicipline and watching fields of fire.

The only real issue is finding an outfit that runs solid ops like that..

Re: Proposal: "Blue Fire" Response Protocol

Reply #7 –
I actually have nothing to add at this point. I fully agree, and you have covered all the bases. Well written, and easy to implement.

Safety is important, since there's so many of us, and there's important to have standards and regulations or everything falls into chaos.

Well, I have one thing to add, and that is that  bookmarked this thread for quick access.

Re: Proposal: "Blue Fire" Response Protocol

Reply #8 –
Quote from: AdmlBaconStraps on

Really nice guidelines, Wrath.

Probably a bit much for the average forker to keep all in mind so maybe if command staff have the whole thing in mind while everyone just needs to learn 'If there's friendly fire, GTFO and call both the other guy and your superiors'


That seems to be the case with those three first steps, so that's easy enough to remember and implement. But it's nice to see there's someone with enough time and thought to pour into details which will rather make this operation whole lot easier (and more commanded army like). So thanks for that Wrath.

Re: Proposal: "Blue Fire" Response Protocol

Reply #9 –
I like this, it makes sense and the basics of it should be pretty easy to drum into people. The more advanced/complicated bits could be handled by the command staff at an appropriate level.

Re: Proposal: "Blue Fire" Response Protocol

Reply #10 –
Nice writeup. Looks like it can be simplified down to "everyone spread out, whoever keeps shooting gets pasted."

Re: Proposal: "Blue Fire" Response Protocol

Reply #11 –
I just thought of this while thinking of a question of how hostile IFFs will be displayed (as in will pirates and vanduuls have different sensor color codes even though both may be flagged as 'hostile' factions).

It would probably be a good idea to avoid carrying IFF missiles. Even though we are united while on mission, we will be of differing and not officially friendly factions. We don't want to launch an IFF at a Vanduul and have it seek out a Pirate instead because it's closer.

So I think Heat Seekers and Image Recognition missiles would be highly recommended with IFF's being officially banned for safety reasons.

Re: Proposal: "Blue Fire" Response Protocol

Reply #12 –
Yeah, that's probably a good call on the IFF missiles. We can't enforce it, but we can ask people not to bring them. Image Recognition might be the best, just turn off any human shaped ships from the targeting computer, if that's possible, and send it flying.

I got through the entire write-up today, and as I had thought for the brief read earlier, this is in fact quite well done. It is reasonable and gives everyone a common ground on how to deal with these issues.

We have to keep in mind that there will be people flying with us who do not read any of the forums and are just along for the ride, and there will be trolls who most certainly don't come here to read the rules. That being said, since this is such a common sense and well organized write-up, even as an informal rule it is doesn't leave an aggressor much of a leg to stand on.

If even half of us fly with this policy in mind, it will allow us as a group to self-manage a lot of these incidences. Even in real war, Blue-On-Blue happens, much less in a video game environment. It's good to have a response for such incidences already prepared ahead of time.

I'm going to pin a copy of this, and include it in the Orientation Packet. Nice work, Wrath_Of_Deadguy!

Re: Proposal: "Blue Fire" Response Protocol

Reply #13 –
Not sure there was a need to create a new thread. It's better if people can see the discussion and reasoning behind the policy.

Re: Proposal: "Blue Fire" Response Protocol

Reply #14 –
The new thread is for the Orientation Packet. I don't want to fatigue people with reading threads as well as posts. Just realized I pinned that one, and not this one. I'll swap those around. I also have to remove the LTI pin out of the packet now as well.

Re: "Blue Fire" Response Protocol Proposal

Reply #15 –
There's lots of good stuff in here.  Unfortunately, I don't expect the majority of 'Forkers to memorize, let alone follow, a rigid protocol; many will never read about it in the first place.  Our COs, however, should definitely be versed in it, and enforce it as best they can.

I'm surprised no one has brought this up yet, but it bears mentioning that there will be friendly scythes among us (16 so far on the asset roster).  The number will not be great, but they will unquestionably be the most likely to receive friendly fire - and it would be easy for the 'Dents to feign misidentification.  These may be our most valuable dogfighters.  Should we simply put all the scythes into one (or more if needed) squadron?  Or should we limit each squadron to one scythe, and only place them with organized/experienced players?  I don't have the answer; I just think it needs to be discussed.

Re: "Blue Fire" Response Protocol Proposal

Reply #16 –
No, I like the idea of having a single Scythe squadron.

It may irk some people not being able to fly with their friends in the scythe, but honestly, it's for their own safety. They can use other ships or simply run an increased risk of blue on blue.

Re: "Blue Fire" Response Protocol Proposal

Reply #17 –
I'm not expecting people to memorize this either, but if everyone at least skims it, they will know what people are talking about should something happen. Simply knowing that there are rules in place, even if not the rules themselves, sometimes help people organize things better.

Besides, most of it is so simple, there's not much excuse for shooting someone up. This gives people some authority to stand on when dealing with an obvious asshat.

Re: "Blue Fire" Response Protocol Proposal

Reply #18 –
Nice write up
Agreed
Pitchfork Belongs to all of us

Re: "Blue Fire" Response Protocol Proposal

Reply #19 –
I like the idea, but implementation may be hard, as other people have said. Not only because there's a huge chunk of people who will not be aware of this rule-set, but also because of other factors:

1) How can you tell when you've been victim of friendly-fire?
2) How can you tell who it was that fired upon you?
3) Is it worth it breaking out of a dogfight or combat maneuver in order to clarify the event?
4) How much time can we spend sorting this out without affecting momentum?

And probably others. Granted, all this factors may have partial or full solutions (having a friend watch your back, HUD tells you who fired at you, etc.) but each level of complexity we add to the operation may affect our overall effectiveness.

Simplest protocol to adopt seems to be exclusion rule that the OP mentioned: If a person becomes a nuisance because of constant friendly-fire (direct or indirect), then he is asked to leave (or jump into a non-combat role).
It's a penguin... with a gun. I'd run if I were you.

Re: "Blue Fire" Response Protocol Proposal

Reply #20 –
Really nice, it might be a little impractical in a combat situation (as others have mentioned) but it's clear that we do need a set protocol to differentiate accidents from traitors.  Something to consider is that it seems like the Trident strategy will not involve open engagement with pitchfork ships unless the Vanduul soften them up considerably: https://forums.robertsspaceindustries.com/discussion/70378/a-pirate-s-guide-to-operation-pitchfork-trident-the-trident-manifesto/p1

Re: "Blue Fire" Response Protocol Proposal

Reply #21 –
The great thing about the human brain is it can process a lot of that information at once, and make the judgement calls needed in the context of the situation for making the best call. We can't plan for every situation, but we can give people a starting point for how to handle a situation. If we give people access to this, whether or not we reach everyone, we would have laid the groundwork for resolving situations ahead of time for the ones that do read this. This will help them be better prepared for something happening ahead of time, rather than trying to react to them on their own as they happen.

Re: "Blue Fire" Response Protocol Proposal

Reply #22 –
good idea for the protocol but I am concerned that this would be difficult to do whilst in the middle of battle since it could leave them vulnerable while trying to understand the accidental (or not in the worst case) friendly fire.

Re: "Blue Fire" Response Protocol Proposal

Reply #23 –
I have but one humble suggestion if the possibility exists. To aid in Operation Wide designation of Traitors, a tac/comm which could be accessed directly by any ship involved could be instituted for the sole purpose of wide scale designation, such as; "Player A has been positively identified as a traitor, possible Trident Member, be on the lookout for Player A as they will sabotage." These highly valuable identifications could possibly end sabotage before it even starts. Or, on the less severe side, a player that has been kicked out of an instance could also be listed here, i.e. "This person should ONLY be in noncombat support role, if they are in a combat role proceed with caution and ask them to leave the instance." I'm unsure if such a large tac/comm could work in-game between that many people, but it would be definitely necessary, if possible.

Re: "Blue Fire" Response Protocol Proposal

Reply #24 –
It'd probably be part of C&C. Which will probably have to be dealt with on a instance-by-instance basis unless we can get an overarching C&C thing going..