mcdiod

Update: GRAD List Buymenu - Tracking improved documentation (moved to Wiki) automatic display name / description for certain item types (read from config) ability to track what users buy, even across different missions chatcommand for admins to display the recorded statistics:

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 { //Rifleman class Soldier_F { addItemsToUniform[] = { "ACE_MapTools", "ACE_EarPlugs" }; addItemsToVest[] = { LIST_2("HandGrenade"), LIST_8("30Rnd_556x45_Stanag") }; }; //Asst. Autorifleman class soldier_AAR_F: Soldier_F { backpack = "rhsusf_assault_eagleaiii_ocp"; addItemsToBackpack[] = { LIST_2("rhs_200rnd_556x45_M_SAW"), "rhsusf_100Rnd_556x45_M200_soft_pouch" }; }; }; }; ------------------------------------------------------------------------------------------ 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.

After a week on-off looking for resources on how to get started this is the first tutorial that i found that is easy to follow and up to date. Thank you so much! Meanwhile, the sticky resource collection is full of 404s and old shit.

Uh, okay? I have never done it without any mods. Maybe this is not vanilla behaviour? https://youtu.be/mdo6fcIV5QQ Edit: Yea, looks like this is actually a TFAR feature. I never knew. Edit 2: That's cool then. The movement can easily be scripted on mission level I guess.

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.

Can confirm, have the same problem.

Is there a way to prompt the teamspeak channel switch with an .sqf script? I'm trying to make players switch the channel upon death. I was thinking I could just overwrite tf_radio_channel_name with the new channel name and then run TFAR_fnc_ClientInit again, but that doesn't work.

Will this get an update for 3den missions? If not, does anyone know a good alternative? What you posted is a script that creates those PipeWalls for you. Is this what you want instead?: yourObjects = [ ["Land_PipeWall_concretel_8m_F",[13362.4,4138,0],[],0,"CAN_COLLIDE"], ["Land_PipeWall_concretel_8m_F",[13367.7,4130.67,0],[],0,"CAN_COLLIDE"], ["Land_PipeWall_concretel_8m_F",[13368.7,4135.66,0],[],0,"CAN_COLLIDE"] ]; Why? This - by itself - will not do anything.

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; //Or: [myvehicle, myunit, ["ACE_MainActions", "myactionname"]] call ace_interaction_fnc_addPassengerAction; //Or: [myvehicle, myunit, [myaction]] call ace_interaction_fnc_addPassengerAction;

The FAQ state So I'll take that as a "no, clients do not need the userconfig files". 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.

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.