alpha993

I have an addon that has a custom main menu scene, but the menu displays a gray screen for a few seconds before fading into the scene. The gray screen only appears after the game starts up, and does not appear after coming back out of the editor, or other menu. I've tried looking through RscDisplayStart for this gray screen to no avail, and I am at a loss on how to remove it. I also don't understand why it's occurring with my custom scenes when the vanilla game doesn't have the same issue. I checked without any other mods and the issue persists. I'd greatly appreciate any suggestions.

Huh, for some reason I thought Params couldn't supply default values. I even double checked the wiki before writing that and somehow glossed over the relevant syntax parameters section.

I'm actually German so I don't mind playing it in German lol. I'm really busy with law school atm, so I can't give you a concrete example, but I would suggest something similar to the following process: In your first mission, use the nearObjects command to get an array of the town's buildings. Get the damage value for each item in the array. Make a nested array with each building and its respective damage value so it looks something like [ [House_1, 0.4], [House_2, 0.7], [House_3, 1] ]. Store the nested array into your profile namespace using profileNamespace setVariable ["myTownState", TAG_nestedArray]; and then saveProfileNamespace. (there is also the saveVar command if your missions are part of a campaign file). In your next mission, load your nested array using profileNamespace getVariable "myTownState"; Then use a forEach loop to run through each element of the array, and use setDamage on each house with its corresponding damage value at mission start. Hope this helps!

Glad to hear it's working for you! I'm always happy to play new missions, so send away! 🙂

selectRandomWeighted does not require all weights to add up to 1, so there's no need to try and visualize the weights as percentages. I would just look at them relative to each other. So, an item with a value of 4 is more likely to appear than an item with any lower number, for example. Here's Killzone Kid's example from the wiki to illustrate the point:

It works correctly on my end. I'm attaching an example mission for you HERE. _______________ I The (_x != _unit) condition is important because the nearObjects command includes the player in its output. That condition filters out the player and leaves only the nearby soldiers. Otherwise the player would also have a helmet added. _______________ II The nearObjects command already selects objects by distance (the defined radius), so adding another distance check when adding the helmet is redundant. _______________ III My example was copied verbatim from a working mission, so my only guess is there is something going on with your paths on your end, or perhaps a typo in a file name. For example, the game is looking for fn_addingHelmet.sqf, and not fnc_addingHelmet.sqf. _______________ IV In that case you would not use the Params command, but rather the Param command. You would therefore define your variables like so: _unit = param [0, player, [objNull]]; _radius = param [1, 5, [0]]; This means: _unit is the first parameter passed in the function arguments, with the local player as the default value, and it must be an object. _radius is the second parameter passed in the function arguments, with a default value of 5, and it must be a number. _______________ V "Man" includes extra things other than actual human entities, such as snakes and rabbits. CAManBase is a step further down the config hierarchy, and only includes human entities.

This question would be more appropriate in the configs forum: https://forums.bohemia.net/forums/forum/162-arma-3-addons-configs-scripting/ In any case, I would suggest playing with the missileLockCone config value, as it's possible the target is outside the cone within 20 meters.

Try using setVariable on the units to store the value of the private variable, and then recall it when calling your function. When you define your private variable: TAG_unit setVariable ["TAG_myPrivateArgument", _privateVar]; When the unit completes the waypoint: [(TAG_unit getVariable "TAG_myPrivateArgument")] call TAG_fnc_myFunction;

I believe this is the only option as there's no way that I know of to "lock" specific playable slots in the lobby without removing the "playable" option in the editor. I could be wrong though. Larrow showed a similar approach for creating reserved slots in a server in this post, but I'll write out an example that suits your purposes below. I don't have a chance to test it right now, but it should give you a starting point. The following will allow you to restrict specific sides in the multiplayer lobby via the parameters menu. If you prefer, you can change the variables in the initServer.sqf script to take their values from something else. Description.ext class Params { class TAG_restrict_BLUFOR { title = "BLUFOR Restricted"; values[] = {0,1}; texts[] = {"No", "Yes"}; default = 0; }; class TAG_restrict_OPFOR { title = "OPFOR Restricted"; values[] = {0,1}; texts[] = {"No", "Yes"}; default = 0; }; class TAG_restrict_INDEPENDENT { title = "INDEPENDENT Restricted"; values[] = {0,1}; texts[] = {"No", "Yes"}; default = 0; }; }; class CfgDebriefing { class BLUFOR_NOT_ALLOWED { title = "BLUFOR IS RESTRICTED"; description = "Please switch to another team."; picture = ""; }; class OPFOR_NOT_ALLOWED { title = "OPFOR IS RESTRICTED"; description = "Please switch to another team."; picture = ""; }; class INDEPENDENT_NOT_ALLOWED { title = "INDEPENDENT IS RESTRICTED"; description = "Please switch to another team."; picture = ""; }; }; InitServer.sqf TAG_restrict_BLUFOR = ["TAG_restrict_BLUFOR", 0] call BIS_fnc_getParamValue; TAG_restrict_OPFOR = ["TAG_restrict_OPFOR", 0] call BIS_fnc_getParamValue; TAG_restrict_INDEPENDENT = ["TAG_restrict_INDEPENDENT", 0] call BIS_fnc_getParamValue; publicVariable "TAG_restrict_BLUFOR"; publicVariable "TAG_restrict_OPFOR"; publicVariable "TAG_restrict_INDEPENDENT"; initPlayerLocal.sqf params ["_player", "_didJIP"]; switch (side _player) do { case west: { if (TAG_restrict_BLUFOR == 1) then {endMission "BLUFOR_NOT_ALLOWED"}; }; case east: { if (TAG_restrict_OPFOR == 1) then {endMission "OPFOR_NOT_ALLOWED"}; }; case independent: { if (TAG_restrict_INDEPENDENT == 1) then {endMission "INDEPENDENT_NOT_ALLOWED"}; }; default {}; };

Description.ext class cfgFunctions { #include "myFunctions\THY_functions.hpp" // Include THY_functions.hpp file into cfgFunctions }; myFunctions\THY_functions.hpp class THY_functions // Create a category for your functions { tag = "THY"; // Define the tag that precedes your functions class functions { file = "myFunctions"; // Folder where your functions are located class addingHelmet {}; // One possible function (the game will look for fn_addingHelmet.sqf inside myFunctions folder) class someOtherFunction {}; // Another possible function (the game will look for fn_someOtherFunction.sqf inside myFunctions folder) }; }; myFunctions\fn_addingHelmet.sqf if (!isServer) exitWith {}; // Run only on server params ["_unit", "_radius"]; // Define two parameters: the chosen unit used as the center of the search radius, and the search radius itself while {alive _unit} do // Loop while the chosen unit is alive { _unitsArray = nearestObjects [_unit, ["CAManBase"], _radius]; // Find all soldiers within the set radius around the chosen unit _validUnitsArray = _unitsArray select {(headgear _x != "H_HelmetB") AND (_x != _unit)}; // Select only those soldiers without the desired helmet {removeHeadgear _x; _x addHeadgear "H_HelmetB"} forEach _validUnitsArray; // Add the desired helmet to those soldiers sleep 0.1; }; In your player's init field: [this, 5] spawn THY_fnc_addingHelmet; ____________________________________________ Some comments explaining the above: There are lots of ways you can define your functions, and the one in my example (THY_functions.hpp) is just my preferred method of doing it. More info is available here. In your example, you were declaring your function twice by (1) putting it in the CfgFunctions, and (2) declaring it as an inline function via TAG_fnc_addingHelmet = { code } inside the script file itself. Doing both is unnecessary, as shown in my example. In your example, you set your function's preInit flag to 1. This makes the function run before mission start, and will lead to errors if you do not have the parameters defined, or the function does not have default values for the parameters. Since you are already calling the function through a unit's init field, the preInit is not needed. As for your function itself, your approach will be more performance intensive since you are running a separate script for each unit. In my example, I only run it on the player, and the function then detects nearby soldiers to add a helmet to. In other words, it's better to structure a script around a common element, which in this case is the player, rather than around random elements such as the soldiers.

I would really recommend using the functions directly in a script instead of modules. See this tutorial, and this page for more info. waitUntil {exfil2 == 1}; [west, "ex2", ["Exfiltrate Task 2 Description", "Exfiltrate 2 Task Title", "Exfiltrate 2 Task Marker"], TAG_exfil2Heli, "ASSIGNED", 1, true, "takeoff"] call BIS_fnc_taskCreate; If you want to use the trigger anyway, I've found you sometimes need to add some kind of condition to the "Activation" section. You could probably set it to activated by BLUFOR not present, set the trigger radius to 0, and put the following in the condition: this && (exfil == 1);

I modified my example above with the stackable eventhandler mentioned by @mrcurry It depends on what you want to do with your code. initPlayerLocal.sqf runs only on clients and player host whenever they connect. initServer.sqf runs only on a dedicated server or player host. init.sqf runs on every client, dedicated server, and player host. So, if the code you want to run after everyone's in should execute on all clients and the server, use init.sqf. If you only want the code to run on the server, use initServer.sqf.

Untested, but should do what you're asking if I understand your question correctly. In initPlayerLocal.sqf player setVariable ["TAG_playerLoaded", false, true]; addMissionEventHandler ["PreloadFinished", { player setVariable ["TAG_playerLoaded", true, true]; }]; waitUntil {player getVariable "TAG_playerLoaded"}; // Run code local to each player here after the player has loaded in fully In initServer.sqf waitUntil {({_x getVariable ["TAG_playerLoaded",false]} count allPlayers) == count allPlayers}; // Run code local to server here after every player has loaded in fully

Spawn a BLUFOR unit as Independent: _independentGrp = createGroup independent; _unit = _independentGrp createUnit ["B_Soldier_F", getPos player, [], 0, "FORM"]; [_unit] joinSilent _independentGrp; Spawn a group of BLUFOR units as Independent: _independentGrp = [getPos player, independent, (configFile >> "CfgGroups" >> "West" >> "BLU_F" >> "Infantry" >> "BUS_InfSquad")] call BIS_fnc_spawnGroup; // BUS_InfSquad is the CfgGroups config entry for your desired group Switch an existing group of BLUFOR units to Independent: _bluforGrp = group TAG_bluforTL // TAG_bluforTL is the team leader of the blufor squad you spawned (can also be any other unit from the group) _independentGrp = createGroup [independent, true]; (units _bluforGrp) joinSilent _independentGrp; Switch several existing ungrouped BLUFOR units to Independent: _independentGrp = createGroup independent; [TAG_bluforUnit_1, TAG_bluforUnit_2, TAG_bluforUnit_3] joinSilent _independentGrp;

The music should already restart itself automatically. Unless you mean starting the radio back up after you've turned it off. In that case, change your PlayMusicRadio.sqf file to this: TAG_radioOn = true; _TAG_song = _this #0; if (isServer) then { // adds the action to every client and JIP [ TAG_Radio, // Object the action is attached to "Turn off radio", // Title of the action "\a3\ui_f\data\IGUI\Cfg\holdactions\holdAction_connect_ca.paa", // Idle icon shown on screen "\a3\ui_f\data\IGUI\Cfg\holdactions\holdAction_connect_ca.paa", // Progress icon shown on screen "_this distance _target < 3", // Condition for the action to be shown "_caller distance _target < 3", // Condition for the action to progress {}, // Code executed when action starts {}, // Code executed on every progress tick { TAG_radioOn = false; // Code executed on completion publicVariable "TAG_radioOn"; [TAG_Radio] remoteExec ["removeAllActions", 0]; }, {}, // Code executed on interrupted [], // Arguments passed to the scripts as _this select 3 3, // Action duration in seconds 999, // Priority true, // Remove on completion false // Show in unconscious state ] remoteExec ["BIS_fnc_holdActionAdd", 0, TAG_Radio]; // MP compatible implementation }; while {TAG_radioOn} do { TAG_soundSource = TAG_Radio say3D [_TAG_song, 50, 1, false, 0]; waitUntil {(isNull TAG_soundSource) || !(TAG_radioOn)}; }; deleteVehicle TAG_soundSource; if (isServer) then { // adds the action to every client and JIP [ TAG_Radio, // Object the action is attached to "Turn on radio", // Title of the action "\a3\ui_f\data\IGUI\Cfg\holdactions\holdAction_connect_ca.paa", // Idle icon shown on screen "\a3\ui_f\data\IGUI\Cfg\holdactions\holdAction_connect_ca.paa", // Progress icon shown on screen "_this distance _target < 3", // Condition for the action to be shown "_caller distance _target < 3", // Condition for the action to progress {}, // Code executed when action starts {}, // Code executed on every progress tick { [TAG_Radio] remoteExec ["removeAllActions", 0]; nul = ["resonance", "playMusicRadio.sqf"] remoteExec ["execVM", 0]; }, {}, // Code executed on interrupted [], // Arguments passed to the scripts as _this select 3 3, // Action duration in seconds 999, // Priority true, // Remove on completion false // Show in unconscious state ] remoteExec ["BIS_fnc_holdActionAdd", 0, TAG_Radio]; // MP compatible implementation }; Now you'll have an action to turn the radio back on after turning it off.

Oh dear, so this is the horror that Harzach and I helped create in that last post with the bouncy rope. Looks fantastic lol.

Glad I could help! 🙂

At first glance, it looks like you're declaring the CfgFunctions class twice with your 'includes.' This... class CfgFunctions { #include "function_library.hpp" }; ...plus this... class CfgFunctions { class pizza { class action_functions { file = "functions\actions"; class lockpick; }; }; }; ...will get you this: class CfgFunctions { class CfgFunctions { class pizza { class action_functions { file = "functions\actions"; class lockpick; }; }; }; }; _____________________________ If you have multiple .hpp files, you should just have the one CfgFunctions class in your description.ext, include the .hpp files like you did, but remove the CfgFunctions classes from the .hpp files. Naturally, you should triple check all your paths to make sure everything is pointing to the correct directory as well.

Here's a working example and a video of the result: [ getPosASL ALP_missileStart, // ASL coordinates where missile should spawn "ammo_Missile_Cruise_01", // cruise missile classname ALP_targetHeli, // target object 100, // missile speed true, // destroy target on impact [0,0,0], // target modelspace coordinates for impact 0, // minimum distance to enter ballistic mode "", // code to run on missile true // run globally ] spawn BIS_fnc_EXP_camp_guidedProjectile

This might be a weird approach, but perhaps altering the mass of the attached object with setMass might affect how much the rope bounces.

Seems like the only solution I've seen that somewhat works is to use something like this from the wiki: private _lineHeight = getNumber (configFile >> "RscStructuredText" >> "size"); private _linesTotal = (ctrlPosition _ctrl select 3) / _lineHeight; private _trailingSpace = ""; for "_i" from 1 to _linesTotal do { _trailingSpace = _trailingSpace + " " }; _ctrl ctrlSetStructuredText parseText format ["<t size='%1'><t size='1' align='center' valign='middle'>%2%3</t> </t>", _linesTotal, "Centered Text", _trailingSpace]; Which produces this with different control heights: However, it seems to be very unreliable, and changing the control width to anything other than 0.5 messes up the centering for some reason.

My mistake. If you remove the underscore before all three instances of _TAG_soundSource it should correct the issue. (The error happens because the sound source is a local variable due to the underscore, and it is defined inside the while loop, but is undefined outside the loop's scope. Without the underscore, it becomes a global variable that is defined in all scopes. See here for more info if you're interested.) Unfortunately it seems to be a common problem with the game, especially if you have any kind of surround sound.

The best approach depends on how you have your tasks organized, and how you script your mission. On the campaign I'm currently working on, I have each task isolated into its own script file. The first task is handled by task1.sqf, the second one by task2.sqf, and so on (I'm simplifying it a lot here, but you get the picture). However, sometimes testing a task requires that certain things be true or have occurred, such as the player being in a certain spot, or a certain enemy having been killed. So, I always add a small 'debug' section to the top of each task script that takes care of that, similarly to your VTOL skipping example. Then, if I want to test a particular task, let's say task 4, I would execute nul = [true] execVM "task4.sqf"; with the debug parameter to true. In truth, I would need to see what your mission looks like in order to determine what the best approach would be.

How about using BIS_fnc_EXP_camp_guidedProjectile? You could spawn the VLS rocket itself and have it home in on the helicopter.

According to this page, the attribute for valign should be "middle", not "center." class Attributes { font = "RobotoCondensed"; color = "#E5E5E5"; align = "center"; shadow = "true"; valign = "middle"; }; Let me know what happens because I've had my fair share of headaches with vertical alignment lol.