When you get a buddy request a message tells you how to accept .
However there is no information about how to reject

some people exploit this by buddy invite every single new player

please add information on how to reject

If you use the /buddy command it will show the options.
/buddy decline <playername> i believe is the correct option.

Sounds like a good idea; providing more choices to new pilots is always better, as long as its provided in a manageable manner. I get that pilots 'could' just type the command, but I also understand how some might not really 'get' it. (though, you're talking about someone *other* than me, right?)

However, while we're on the subject of requests in general, how about also chewing on this idea for a further long-term solution? Queue incoming prompts, and use a section of the comm tab to list recieved invites/requests/etc. The user can select one to get an action selection window relevant to such response. The message pilots recieve could be changed to something general, such as

"You have recieved a <invite type> from <name>. You can view all pending requests in the Comm section of your PDA, under <menu name>."

This wouldn't replace the game commands, but might be more helpful to new pilots who struggle to even figure out how command-based systems work, while also unifying the scattered interfaces that currently let people handle specific requests (gunner, group, buddy). And, of course, you could have things that don't require responses to be listed in the same menu, if you treat it like an in-game notification wall, though the mission advancement tab kinda fulfills this.

Given how effective of a technique it is to hunt people down giving newbs a disclaimer on the first invite won't hurt granted they read it.

Just like the greyspace disclaimer this oughta help and prevent player from getting "stuck" thanks to good ol psychological manipulation.

So, given that the actual problem here seems to be usage of the Buddy system to hunt newbies by illicitly learning their location, an alternative is to simply disable Buddies from sharing location by default.

This is problematic in some ways, as the goal is to get people to play together and the like. But, you'd still be notified when your buddies were online and so on, and we could eventually aim for a kind of "regional knowledge" thing, like you could get a notice when a buddy was "in the area" or something (like within the current-and-adjacent systems).

It could also be a default-unchecked option on an "Accept" type dialog, like "Always show my in-game location to this Buddy (only for players you trust)".

No, the actual problem has nothing to do with the buddy list or treachery on the part of some pilots. The issue here is lone combatants do not survive. In every combat scenario Ive trained for, and executed real world, there is an assault and an overwatch element. As it stands now, the overwatch element is default neutralized by nation/faction standing penalties in monitored spaces. An arbitrary consideration that effectively penalizes a pilot for providing cover for his/her battle buddy. Unless two “buddies” in a “group” enjoy the same exemptions to faction/nation standings if responding directly to hostile actions against a single partner?

The issue here is lone combatants do not survive.

That isn't the topic we're discussing here. There's another thread about "Wingmen & Shared Retaliation" that is available on that subject, where you've already been commenting.

Whether or not new users accept buddy-invites too easily, or are being tracked by enemies via the buddy system, has zilch to do with factional combat response scenarios. Please see Rule #6 for any confusion.

Ooopsies. Wrong thread. I stand corrected

Disabling location sharing by default is the most elegant solution the way I see it, to boot someone asking the newb to turn it on will probably make the couple neurons in the concerned newb's brain fire hard enough for em to think twice about doing so.

it would be nice if when rejected, they cant just continuously resend the request.. which is pretty common, even after being asked not to in a few cases

it would also appear the ignore system doesnt put a stop to buddy or guild requests

So, the following changes should be going into production with tonight's release:

- Buddy location sharing is now off by default for new buddies.
- Buddy and Guild invites now expire after 30 days and cannot be re-sent for 7 days after expiration or rejection.
- Guild invites now continue to be available for acceptance for the entire 30 day period, persisting across player logoff.
- Buddy and Guild invites are only sent once while the invite is active for a given character.
- The Ignore feature now blocks Buddy and Guild invites from ignored characters.
- Added analytics to track the status of Buddy and Guild invites.

Hopefully this will mitigate or address most of the issues here. I still expect to further improve the user experience of the Buddy and other systems as we redo the interface, this is more about making the back-end fundamentals be a bit better.

Great!