Add a variable for the Chosen Objective Site to R6:Siege game events

Rambling video on this request: https://youtu.be/AXRFPlLH-sI

Feature description

Add a new Game Event to the Rainbow Six: Siege API that provides the name of the Objective Site that is/was played this round.

Current workaround

There is currently no way of automatically detecting this, with the current information provided. I’m asking my users to manually provide the information by way of an unobtrusive pop-up. But obviously this isn’t an ideal solution.
image

Implementation recommendation

Could be an additional variable added to the roundStart and/or roundEnd info updates. Thus:

{"event":{"name":"roundEnd","data":{"objective_site":"THE_OBJECTIVE_SITE"}}}

When Defending, the Objective Site is known at the end of the Operator Selection Phase:
image

When Attacking, it is not known until ‘detected’ by a drone or Operator:
image

Technical recommendation

For Defence rounds, this should be fairly straightforward, pulling the string from the UI.

For Attacking rounds, this could be potentially a difficult task.

Feature potential

Granted, potential is somewhat limited here, and may not be ‘worth’ the effort.

Knowing the Objective Site can be used for various potential app ideas and feature additions.

Some off the top of my head:

  • Strategy recommendations
  • Showing floor plans
  • Statistics tracking per Objective Site (my current implementation)

Possibility of exploiting

Depends on the implementation.

If only implemented for Defence rounds, there is no potential at all for it being misused.

The Objective you pick is always known, as you selected it yourself. It’s clearly communicated from the very first second of a round, so there is no chance of any ‘unfair advantage’ of any kind.

If implemented to be given for Attack rounds, it should ONLY be provided once the Objective has been detected by a drone or Operator (‘roster_XX has found the bomb’).

Knowing the Objective Site as an attacker can give you a big advantage, which would be unfairly given if known sooner than normally possible.

@Bl0n thanks for the detailed request!.. we will discuessed that internally and update you.
Just to clarify: how would you rate that FR (for your app) - critical? mid? low?

Hey @eransharv!
I would say for my app it is: mid.

I have the feature already implemented, but with the user having to manually enter the data.
It is annoying enough that a majority of users opt-out of doing it.

Hi. I pushed it to our backlog. I will keep you updated. That might take some time to implement, due to our prioritization.