lock it AddAction

[Casio91Fin 31]

How could I lock the AddAction, for example someone would have taken the role "AutoRifleman" or "AT Rifleman " and if the player gives up the role it would somehow appear as free to take.

And that role could somehow maximize how many people could get that one.

[Casio91Fin 31]

i have made progress lite bit, but still i need help with this. Now i need to know, how to stop given to other players this gear. so long that player release this role/gear.

script: 

this addAction ["<t color='#339933'> Take gear 'AutoRifleman'",
{ 
    if (diag_tickTime < (uiNamespace getVariable ['tag_cooldown', -1])) exitWith 
    {
        hint (format ['Toon soon! Please Wait %1 seconds. \n There is a possibility that someone has already taken this role %2', (round ((uiNamespace getVariable ['tag_cooldown', -1]) - diag_tickTime))]);
    };
    _cooldown = 180;
    uiNamespace setVariable ['tag_cooldown', (diag_tickTime + _cooldown)];
    [] execVM "AutoRifleman.sqf";
}, [], 1, false, true, "", "_this distance _target < 3"];

 

[mrcurry 496]

14 hours ago, Casio91Fin said:

i have made progress lite bit, but still i need help with this. Now i need to know, how to stop given to other players this gear. so long that player release this role/gear.

 

I'd just use a counter for number of active troopers and a constant for max allowed.

A naive solution looks a bit like this peudocode:

 

// On server

TAG_activeTroopsAT = 0

TAG_const_maxAT = 2

 

// In the action 

addAction [ ...

    {

          If TAG_activeTroopsAT < TAG_const_maxAT then

          {

                missionNamespace setVariable [ "TAG_activeTroopsAT", TAG_activeTroopsAT + 1, true]; // update the value and transmit the new value 

                [] execVM "AutoRifleman.sqf";

          } Else {

               Hint "not available";

          }

    }

]

 

 

 

An idea for a more reliable method would involve remote exec to server and letting the server do the comparison and return result to the client but I ain't typing that on my phone 😛

[Casio91Fin 31]

@mrcurry thanks for your help, it works very well. but now i have to figure out how to release the role if the player wants to change the role to someone else e.g. auto rifleman or other character.

[mrcurry 496]

1 hour ago, Casio91Fin said:

@mrcurry thanks for your help, it works very well. but now i have to figure out how to release the role if the player wants to change the role to someone else e.g. auto rifleman or other character.

Well you just reverse the addition so... Subtraction 🙂

 

But then you need to know which role they have taken. For that you can use setVariable on the player object and assign them a string i.e. "AT" (it can be anything as long as its unique but descriptive is probably better). You do this when they pick any role.

 

Then just before that just retrieve their assigned role (their string) using getVariable and check which variable needs to be subtracted. Remember to account for the first time they pick a role.

 

 

 

Personally I'd use a hashmap to build a store of active numbers and a store of loudouts using the players role as key. It's a more advanced technique with some locality traps but it'd be easier to manage if you wish to reuse the system or add more roles in the future. If you wish I could build something for you ( it'd be a fun puzzle to solve 😛) but I fully understand if you don't.

[Casio91Fin 31]

@mrcurry 

9 hours ago, mrcurry said:

If you wish I could build something for you ( it'd be a fun puzzle to solve 😛)

you are free to help and build the script

[mrcurry 496]

On 2/7/2024 at 7:23 PM, Casio91Fin said:

@mrcurry 

you are free to help and build the script

Apologies for the late response but after a bout of covid and a work trip I finally got around to wrapping this module up.

 

My idea was to have a system that manages the loadout actions themselves via the server.

You as the mission maker then decide what each of those loadouts do by just configuring the system and providing the script files for each loadout.
The system expects loadouts as .sqf script files, this means you can define them as something static like an export from the virtual arsenal or a more dynamic thing like giving the player a random hat or switching gear based on mission progress, it's all up to you.

 

Link to archive containing source, an example mission and installation instructions here.

Below is some pictures on what it can look like in game.

Icons, formatting and colors is fully configurable as well as some other general settings like apply on respawn etc.

Spoiler

 

Tested on a hosted and dedicated server so should work but I haven't tested fully with a lot of players, let me know if there's any issues.

 

[Casio91Fin 31]

Thank you very much and I'm going to test it on the weekend when my friends have more free time. I'll tell you how it worked. I promise there will be feedback.

feedback:
is good and functional, even though a lot of work has been done.

Edited February 25 by Casio91Fin
feedback