TL DR: system which will allow player to request different form of 'off map' support (from resupply crates to fire support)
Integrations:
[x] Systems - centralized location for handling of whole thing
[x] Supplies - when enabled in the world then check if there is Main HQ and ensure that it has enough supplies to request desired call-in
[x] XP - when xp handler is present then use rank system to restrict availability of 'better' call-ins
[x] Gadgets - when required then ensure that player has them
[x] Audio playback - when call-in is requested then play appropriate radio message (depending on the outcome of the request either approved or denied)
[x] On Screen Notifications - local notification to inform the user why something cant happen and if it did then what happened
[x] Radial menu - way to request call-ins
MVP:
[x] Have all integrations ready
[x] Have at least one call-in ready for both factions
[x] Document script and config members for easier configuration
[x] ENG localization
[ ] US vocielines
[ ] RU voicelines
[x] Rework RHS_ReplaceDeployableEntityComponent to comply with 1.2 SCR_BaseDeployableInventoryItemComponent
Description:
The goal is to have a fully working system that is capable of integrating with different parts of the game while not being hardwired to them. For example, the supply system may not be present in a GM session, and in such cases, the system should skip supply requirement. When the system is present, as long as the player fulfills the requirements set by each of the provided call-ins, then they should be able to request such form of support by asking the 'main' through the radio. The primary method of interacting with the system will be done through user actions available in the radial menu. These user actions will be added to specific gadgets such as range finders or mid-range radios (backpack). Depending on the device, one may be able to call in for support either at a designated position (range finders) or at the current player position (mid-range radio). The system has to allow for defining how many times a call-in can be used, how often, what will be, and if the delay between requesting and deploying will be randomized, randomized spread of target location, cost in supplies which will be taken from the main base, minimal required rank as well as which gadgets are required for the player to have in order to be able to request such support.
Example:
Player wants to call bombing on a certain position. In order to do that, he has to have with him, some form of a designator such as a vector (range finder), mid-range radio (backpack), and a GPS unit (DAGR). While using his designator (ADS), he then opens the RHS radial menu where he is presented with all of the gadgets that have available actions on them. The player then selects the designator category which presents now a list of entries (possibly subcategories) which show their name and optionally in '( )' a reason why they can't be used and when hovered over the option then it will present their description which will contain both a short description of this form of the support call-in as well as a list of the requirements that the player has to fulfill in order to be able to request that call-in. When all the requirements are fulfilled, then when the user selects that option the game will try to find the point at which the user was looking with his designator and ask the system for such call-in at such coordinates. At this point, the role of a player ends and the host (server) starts checking if he can as well as how he should deploy such call-in. When checks are finished, then the system will respond to all players that such call-in was approved by trying to play a radio message on compatible radios (in the case of the requesting player, he will hear himself as he would be talking - not through the radio while the response will sound like it's coming through the radio - while the rest of possible receivers will hear both sides through the radio). This also means that if the enemy captures your radio then they will be able to hear that information. Unlike in the case when a call-in is approved, when a call-in is denied, then only the requesting player is informed about that. When the call-in is finally deployed then the whole process is finished and if applicable cooldown starts.
Nice to have:
[ ] Custom composition that would be built at the main base to enable different types of call-ins - for example, 'Fire support center' would unlock all kinds of fire missions while 'Logistics support center' would allow players to request resupplies or vehicles
[x] Map markers for target positions
[x] Game Master integration which would allow for changing system requirements (whether to check player rank or not)
[ ] Game Master integration to allow changing each call-in property (for example, cooldown, delay, cost, etc)
[x] Option to cancel call in which was requested but wasnt deployed yet
TL DR: system which will allow player to request different form of 'off map' support (from resupply crates to fire support)
Integrations:
MVP:
Description: The goal is to have a fully working system that is capable of integrating with different parts of the game while not being hardwired to them. For example, the supply system may not be present in a GM session, and in such cases, the system should skip supply requirement. When the system is present, as long as the player fulfills the requirements set by each of the provided call-ins, then they should be able to request such form of support by asking the 'main' through the radio. The primary method of interacting with the system will be done through user actions available in the radial menu. These user actions will be added to specific gadgets such as range finders or mid-range radios (backpack). Depending on the device, one may be able to call in for support either at a designated position (range finders) or at the current player position (mid-range radio). The system has to allow for defining how many times a call-in can be used, how often, what will be, and if the delay between requesting and deploying will be randomized, randomized spread of target location, cost in supplies which will be taken from the main base, minimal required rank as well as which gadgets are required for the player to have in order to be able to request such support.
Example: Player wants to call bombing on a certain position. In order to do that, he has to have with him, some form of a designator such as a vector (range finder), mid-range radio (backpack), and a GPS unit (DAGR). While using his designator (ADS), he then opens the RHS radial menu where he is presented with all of the gadgets that have available actions on them. The player then selects the designator category which presents now a list of entries (possibly subcategories) which show their name and optionally in '( )' a reason why they can't be used and when hovered over the option then it will present their description which will contain both a short description of this form of the support call-in as well as a list of the requirements that the player has to fulfill in order to be able to request that call-in. When all the requirements are fulfilled, then when the user selects that option the game will try to find the point at which the user was looking with his designator and ask the system for such call-in at such coordinates. At this point, the role of a player ends and the host (server) starts checking if he can as well as how he should deploy such call-in. When checks are finished, then the system will respond to all players that such call-in was approved by trying to play a radio message on compatible radios (in the case of the requesting player, he will hear himself as he would be talking - not through the radio while the response will sound like it's coming through the radio - while the rest of possible receivers will hear both sides through the radio). This also means that if the enemy captures your radio then they will be able to hear that information. Unlike in the case when a call-in is approved, when a call-in is denied, then only the requesting player is informed about that. When the call-in is finally deployed then the whole process is finished and if applicable cooldown starts.
Nice to have: