Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Posts posted by mcdiod

  1. Gruppe Adler Script Modules

    This is a list of modules that we built for various missions. All of them multiplayer and JIP proof. All of them easy to implement into your mission.

    Download and insert them manually, or use npm. More information on each module as well as installation, configuration and dependencies can be found on github. Most require CBA and ACE.


    • grad-loadout - class based, reliable loadout system
    • grad-leaveNotes - write notes on paper, pass them to other players, place them on the ground, compare handwriting
    • grad-makeFire - build fires (if trees are near), add more wood to make it bigger, add leaves to make it smoke
    • grad-listbuymenu - class based buy menu, very versatile, categories, pictures, descriptions, buy-permissions
    • grad-moneymenu - money framework, can be used in conjunction with listbuymenu or standalone, give money to players, take money from (dead/captured) players, store money in containers, bank accounts
    • grad-scoreboard - a dynamic scoreboard, displays what you give it, (does not save statistics for you)




    GRAD Loadout

    GRAD Loadout is a class based loadout system that applies loadouts on missionstart based on unit type. Works on AI as well as players.

    Organizing loadouts in classes makes it very manageable and easy to read. Most importantly though, it means you can use inheritance. A medic can inherit his loadout from a rifleman and add a backpack full of medical equipment. 


    Check out these loadouts for US Army soldiers with OCP camo as an example.


    class USOCP {
        class AllUnits {
            uniform = "rhs_uniform_cu_ocp";
            vest = "rhsusf_iotv_ocp_Rifleman";
            headgear = "rhsusf_ach_helmet_ocp";
            primaryWeapon = "rhs_weap_m4a1_blockII_bk";
        class Type {
            class Soldier_F {
                addItemsToUniform[] = {
                addItemsToVest[] = {
            //Asst. Autorifleman
            class soldier_AAR_F: Soldier_F {
                backpack = "rhsusf_assault_eagleaiii_ocp";
                addItemsToBackpack[] = {



    GRAD Leave Notes

    GRAD Leave Notes allows players to write messages on a notepad. Notes can then be placed on the ground, passed to other players or stored in (virtual) inventory. Notes that you found on the ground can be inspected for their handwriting. Every handwriting is represented by a font as well as a modifier+adjective combo. For example, on inspection a note's handwriting might show up as "very elegant". Now if you find another note with "very elegant" handwriting, you know that it was likely written by the same person.


    Number of notes that a players can write, or if a player can write note at all can be configured in mission config and with script commands.





    GRAD Make Fire

    GRAD Make Fire allows players to build fires if there are trees nearby. More wood can be added once, making the fire bigger. Leaves can be added twice making the fire smoke. Fires will burn out after a certain time (configurable). An extinguished or burned out fire can be inspected, giving you information about the time since it went out (e.g. "The embers are still slightly glimming."). 


    We are using this module in a TvT mission in which a downed pilot is to be rescued/captured by two opposing teams. The pilot can build these fires as a way to signal his position.






    GRAD List Buymenu

    GRAD List Buymenu is a fully configurable buy menu supporting inventory items, weapons, vehicles, units or even your own script code. All of these can be given prices, categories, item stocks, descriptions and preview pictures. Multiple sets of buyables can be configured, giving you the possibility to buy different items at different locations. Inventory items will be either placed directly into the buyer's inventory, into the trader's cargo space or on the ground. Vehicles will be spawned at a suitable location nearby. Optionally you can set permissions on items, allowing you to control who can buy what.


    Here it is in action in an early version of an upcoming mission. Note that I have yet to configure the description of some of these items in the mission.



    GRAD List Buymenu also has the ability to track what users buy. Even across multiple missions. Admins can then use a chat command to view the statistics:



    An example of a config for this menu can be found here.

    class Items {
        displayName = "Items";
        kindOf = "Items";
        class ACE_fieldDressing {
            displayName = "Bandages (x10)";
            description = "10 simple bandages in sterile packaging.";
            amount = 10;
            price = 100;
            stock = 40;
    class Vehicles {
        permissionLevel = 3;
        displayName = "Vehicles";
        kindOf = "Vehicles";
        spawnEmpty = 1;
        class rhsusf_m998_w_s_4dr_fulltop {
            condition = "uo_missionParam_ISWOODLAND";
            displayName = "Commandvehicle";
            description = "Functions as a backup respawn and buymenu access position.";
            price = 10000;
            stock = 1;
            code = "[_this select 2] call uo_fnc_setCommandVehicle;";




    GRAD Money Menu

    GRAD Money Menu can be used supplementary to GRAD List Buymenu, or as a standalone money system. It allows you to give money to players, take money from captive, surrendered, or dead players and store money in containers. Storage containers can have an owner or be accessible by everyone. Deposit and withdraw money at an ATM and do bank transfers to other players. Check your account at an ATM and see your latest receipts.


    Lots of pictures in the readme on github.






    GRAD Scoreboard

    GRAD Scoreboard will take an array of statistics and display them for your in a nice and tidy dialog.

    It supports any number of columns and rows and will automatically adjust its size as well as the width of each column accordingly. It will try to find the local players name and highlight it.  Below the actual scoreboard, you can optionally display a second dialog for additional statistics.


    Here it is with some fake statistics. Note that the winrates are unrounded. Rounding has to be done before feeding the array.




    • Like 11
    • Thanks 2

  2. I can imagine some users wanting to be able to hear players from the zeus camera as you mention (to be technically correct it the zeus entity remains in place, it is the camera that moves) and others may not want this. I can also see some wanting the ability to communicate from zeus to zeus to coordinate (which can be achieved by having two zeues next each other and talking on direct as long as they dont remote control units). 


    If you are playing a "virtual zeus" unit, it is in fact moving with the camera. And since it is right where the camera is, it should also be able to hear and speak from that position.

    If you are playing a real unit (as in a solider, not just a bodiless entity) the actual "You" stays, while the camera moves. Two zeuses playing real units and standing next to one another would still be able to talk.


    This is how TFAR does it. And honestly, this is something that would keep me from making the switch even though I love everything else about ACRE.

  3. Will this get an update for 3den missions? If not, does anyone know a good alternative?



    Every time I run SMC I get a ton of unwanted text with my sqf.  Here is a example.


    What you posted is a script that creates those PipeWalls for you. Is this what you want instead?:

    yourObjects = [

    Why? This - by itself - will not do anything.

  4. How does ace_interaction_fnc_addPassengerAction work? 

    From ace_interaction.pbo: 

     * Arguments:
     * 0: Vehicle <OBJECT>
     * 1: Player <OBJECT>
     * 3: Parameters <ARRAY>
     * Return value:
     * Children actions <ARRAY>
     * Example:
     * array = [target, player, [params]] call ace_interaction_fnc_addPassengerAction
     * Public: No

    What I have:

    • An AI unit, myunit
    • A vehicle, myvehicle
    • An action, myaction, that I created with ace_interact_menu_fnc_createAction


    Adding myaction to myunit with ace_interact_menu_fnc_addActionToObject works fine. Now myunit gets into myvehicle. I, as a passenger, want to access myunit's action. 


    Here is the code:


    //This works:
    myaction = ["myactionname", "My Action", "", {mycode}, {true}] call ace_interact_menu_fnc_createAction;
    [myunit, 0, ["ACE_MainActions"], myaction] call ace_interact_menu_fnc_addActionToObject;
    //This doesn't:
    [myvehicle, myunit, ["myactionname"]] call ace_interaction_fnc_addPassengerAction;
    [myvehicle, myunit, ["ACE_MainActions", "myactionname"]] call ace_interaction_fnc_addPassengerAction;
    [myvehicle, myunit, [myaction]] call ace_interaction_fnc_addPassengerAction;

  5. The FAQ state

    Q: Why are there 2 files in userconfig ? Do I need them ? [...] A: All these files are required for servers and single player games.

    So I'll take that as a "no, clients do not need the userconfig files".

    2. You can override any variable in your mission scripts

    I paste this into my init.sqf:

    asr_ai3_main_sets = [ // for each level: skilltype, [<min value>, <random value added to min>]
    [	"general",[1.00,0.0],	"aiming",[1.00,0.0],	"spotting",[1.00,0.0]	],	// 0:  super-AI (only used for testing)
    [	"general",[0.90,0.1],	"aiming",[0.40,0.2],	"spotting",[0.40,0.1]	],	// 1:  sf 1
    [	"general",[0.85,0.1],	"aiming",[0.35,0.2],	"spotting",[0.35,0.1]	],	// 2:  sf 2 (recon units, divers and spotters)
    [	"general",[0.80,0.1],	"aiming",[1.00,0.0],	"spotting",[0.30,0.1]	],	// 3:  regular 1 (regular army leaders, marksmen)
    [	"general",[0.75,0.1],	"aiming",[1.00,0.0],	"spotting",[0.25,0.1]	],	// 4:  regular 2 (regulars)
    [	"general",[0.70,0.1],	"aiming",[0.20,0.2],	"spotting",[0.20,0.1]	],	// 5:  militia or trained insurgents, former regulars (insurgent leaders, marksmen)
    [	"general",[0.65,0.1],	"aiming",[0.15,0.2],	"spotting",[0.15,0.1]	],	// 6:  some military training (insurgents)
    [	"general",[0.60,0.1],	"aiming",[0.10,0.2],	"spotting",[0.10,0.1]	],	// 7:  no military training
    [	"general",[0.80,0.1],	"aiming",[0.25,0.2],	"spotting",[0.35,0.1]	],	// 8:  pilot 1 (regular)
    [	"general",[0.70,0.1],	"aiming",[0.20,0.2],	"spotting",[0.30,0.1]	],	// 9:  pilot 2 (insurgent)
    [	"general",[0.90,0.1],	"aiming",[0.60,0.4],	"spotting",[0.90,0.1]	]	// 10: sniper 

    Yet these values don't get applied. Instead the values from asr_ai3_settings_ss.sqf are being used. What am I doing wrong?

    Nevermind, I figured it out. Thank you for your help and thank you for a great mod.

  6. First time using this mod as a mission maker and I have some questions that I couldn't find explicitly answered in this thread:

    1. Since the server's config values override the client's, does that mean the clients don't need userconfig files at all? Can I save the players the hassle of installing them?

    2. In the server config it says "Mission makers can control these features by setting these global variables in init.sqf". Does that not apply to the asr_ai3_main_sets values? If I add skill values to my init.sqf, it seems to ingnore them and instead take the values that I have in my asr_ai3_settings_ss.sqf.