mrcurry

Magazine =/= Ammo BIS_fnc_addVirtualMagazineCargo requires magazine classes. Check that the classes you provide are from Cfgmagazines

Looks like this is a problem directly related to the Altis life framework. You're better off asking in the Altis life forums tbh.

You guys are completely missing the point of the tweet. If you want to play Arma as you are used to don't load the Contact DLC. You still get all the cool new toys. If you want to play Arma for the aliens and the custom scenarios that use them you launch with Contact. If you are designing missions for Contact you have to take this new interface into account. It's the way of the world in Contact. You have to think of Contact as a different game with a different design language, hence why they call it a spin-off expansion. This ought to be evident just by the different main menu and no multiplayer... TL DR: Old mission: Start without Contact. It won't benefit from it anyway. New mission: If it's designed specifically for Contact then, and only then, launch Contact. Don't think there's any documentation on that (yet). Check out the modules section in the Contacts editor and see if you can find something relevant there. Otherwise you'll have to wait for the docs to be updated or the expansion files to be converted to PBO's so they can be unpacked and investigated.

is a AL EG command, there's a couple of reasons that I can think of to cause it to fail: A. Either of the parameters are invalid. B. The unit being moved is not local. C. The vehicle cargo is full. I imagine you have already ruled out C. B is unlikely since you are moving a player from, I presume, his own action call which is local to the player's machine. So A it is then. Well this seems the most obvious anyway since you can temp fix it by re-assigning the value. Couple of questions you should find an answer to before moving on: Does the vehicle have respawn enabled? Did it stop working after a respawn? Did the player(s) who experience the issue JIP or were they there from mission start? Does it only happen for one person or several? Does it stop working for everyone at the same time? What's the value of the variable when it has stopped working on the client? (If it only breaks for some players check on their clients) What's the value of the variable when it has stopped working on the server? (Use the server exec feature in the debug console to run something like: format ["Variable: %1", variable] remoteExec ["systemChat"];) Let us know if you need more assistance.

That's because the engine doesn't differentiate between soldiers, trucks, etc.They are all of the data type Object. The closest thing you're gonna get is this: https://community.bistudio.com/wiki/Scripting_Commands_by_Functionality Edit: Darn it, @Grumpy Old Man ninja'd me Or... you could say what you want to do on this forum and the answer shall be given (or where you should start looking if that's your cup of tea.) Some great topics to read up on: https://community.bistudio.com/wiki/Data_Types https://community.bistudio.com/wiki/Operators https://community.bistudio.com/wiki/SQF_syntax#Rules_of_Precedence (Specifically the Rules of Precedence which a lot of new scripters stumble on). Full scripting commands list: https://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3

While it's a little unclear what exactly you want here's my contribution. Nvm I got it. Separating the spawn of groups and units can be beneficial if you want to, say, do a caching system. Use the groups as holders for the group data and units are spawned only when players get close. However keep in mind that you can run into the 255 group limit pretty quickly if you do big missions so maybe it's not the best way. If that's what you want you really just access the group you just created using getVariable and the same variable format as when you created the group. The variable name can be gotten from the marker. //Creating groups, note that we also store which marker the group belongs to do a cheap lookup when the time is right. { private _grp = createGroup east; _grp setVariable ["marker", _x]; missionNamespace setVariable [format["grp%1",_x], createGroup east]; } forEach _Markers; //Creating units (can be done at any point later) private _grp = missionNamespace getVariable [format ["grp%1", _x], grpNull]; if(!isNull _grp) then { private _u = _grp createUnit ["Class", markerPos (_grp getVariable "marker"), [], 25, "NONE"]; }; Note: If you have no need to delay the spawn of the units until later then it's just wasted CPU cycles to do the above. If so just go with w/e floats your boat from below. A. To put one unit at each marker just do what's been suggested: private _unitClasses = ["class1", "class2", "classN"]; { private _u = createGroup OPFOR createUnit [selectRandom _unitClasses, markerPos _x, [], 25, "NONE"]; } forEach _Markers; B. Distribute a given number of units across the markers randomly: private _unitClasses = ["class1", "class2", "classN"]; //Change to use the classes you want to use. private _numUnits = 66; //This can changed to read from params or be random or w/e. private _markerTemp = +_Markers; //Make a copy of _Markers private "_x"; for "_i" from 1 to _numUnits do { //Delete a marker from the temp list at random. _x = _markerTemp deleteAt floor random count _markerTemp; //Create the unit private _u = createGroup OPFOR createUnit [selectRandom _unitClasses, markerPos _x, [], 25, "NONE"]; //Out of markers? if(count _markerTemp == 0) then { //Yes, make another copy _markerTemp = +_Markers; }; };

@David ArmAstrong Here's how I theoretically would set up the objectives. 1. When a new objective comes online execute on server: 99999 remoteExec ["setPlayerRespawnTime"]; 2. When objective is completed execute on server: "respawn_XXXX" setMarkerPos _newPos; 1 remoteExec ["setPlayerRespawnTime"]; 3. Make sure that at least a few seconds before the next objective goes live. Go back to 1. The result should be: Anyone who dies while an objective is live have an "infinite" respawn counter. Anyone who dies between objectives or is waiting to respawn will respawn instantly. Edit: I realised in step 2 you may possibly run into an out-of-order execution (respawn is enabled before the marker is moved). Now this is highly unlikely to cause issues but if you're pedantic (like me) you'd wrap up step 2 in a function like so: //In init.sqf, CfgFunctions or w/e fnc_updateAndEnableRespawn = { params ["_newPos", "_respawnTime"]; "respawn_XXXX" setMarkerPosLocal _newPos; //Note use of local marker command setPlayerRespawnTime _respawnTime; }; //On server when objective live [someNewPos, 1] remoteExec ["fnc_updateAndEnableRespawn"];

No it's still RGBA. 0.77 is the normalised decimal color value of a single channel, red in this case, the last letter in the variable name usually denotes which channel it is. Range is 0-1 where 0 is no color and 1 is full color.

Deleting won't do. Couple of ways to do it: setPlayerRespawnTime RespawnTemplate MenuPosition combined with BIS_fnc_removeRespawnPosition

@{ubb1}TheBeast Let's not overcomplicate things. In editor: 1. Place down a vehicle 2. Right-click the vehicle and select "Edit vehicle appearance". 3. When done press OK or w/e it's called. 4. Play the mission. No additional steps required.

The color variables are stored in profileNamespace if I remember correctly. As under which name I couldn't tell ya. Check the config of a display you'd like to match and see where it reads them from.

Well unfortunately the engine has no way to interpret what you think is "unwanted" unless you tell it how to do that... 😛 You just got to figure out if your unwanted classes got something in common that no other classes has and use that. P.S. It's easier to just filter the config names against an blacklist after you gathered the classes tbh.

@dlegion I was having wierd issues like this with it way back when. The cause ended up being the use of a soundPosition posAGL instead of posASL. Try switching out your getPos with getPosASL.

Enable view filename extensions in Windows and rename the file manually.

@La Croxyy 1. Fix your previous post, those quotes you put in broke the forum. 2. You should only need to replace your line I quoted with the line I gave you. If that doesn't work you need check your inputs

Since you say "selected player" I'm guessing this is for MP. Try this instead: [_unit, ["eject", _Veh] ] remoteExec ["action", _unit];

1. Check your triggers. Add some debug printouts using hint or systemChat to find out if they trigger as expected. Remember to remove them before release. 2. Remove the link to the second trigger and see if the mortar fires (remember to account for travel time when testing). Continue with one of the following: A - It does fire: Change the second trigger to remove the ammo of the mortar. To do this give the mortar a variable name and set the 2nd trigger's on Act to: magazines mortarNameHere apply {mortarNameHere removeMagazine _x}; B - It doesn't fire: Your mortar likely can't find a valid firing solution, either it's too close or too far or the mortar is on too uneven ground. Range is about 50m to 4km for the vanilla mortar if I remember right, may be wrong though. Post a reply even if it's solved. Your troubleshooting might help someone else in the future.

Please describe in more detail what is supposed to happen and how your results differ from the expected outcome.

I experimented a little and for someone wishing to reproduce a tense jungle patrol with lasers on this should do great. Only thing is they shout their combat voice commands a lot. Either use enableSentences false or wait to use the second version after 1.95 is released. Version 1: Version 2 (Requires 1.95):

Unless you got a backup or a version exported to pbo left somewhere or you can read ASCII-interpreted binarized data you're S.O.L. Sorry for your loss.

It might be that missionName is always the same for the menu and that would then be quite useful. At this point rule nothing out, try everything. Checking the displays out is also a good idea, keep in mind it's pre-init/post-init we're talking. Some stuff might not be loaded. Definitely worth investigating though.

@Leopard20 This thread belongs more in the mod-making section but it's an interesting problem. Found this, unfortunately solution not included: Your problem stems from that the menu is considered a mission from the engines point of view. Remember the good old menu with fighting in the background? Ye technical setup hasn't really changed much with A3. The solution seems to me would be to write your functions to detect when the functions run in menu and abort in those cases. I don't know what the condition could be but a good place to start is maybe looking at these: https://community.bistudio.com/wiki/missionName https://community.bistudio.com/wiki/worldName Run some tests and see if you can figure out what could work. If you figure it out please post back. If not qoute or @ me and I'll take look next time I'm on my PC. The way he phrased it the obvious answer seems yes. Besides, let's not begin replies by assuming a malign intent.

Looks nice! My kind of UI, simple, sleek and responsive. My only feedback would be to add a setting to ignore the requirement to be inside the vehicle.

Nice @Ninjaisfast but it is not very robust. If you ever need to use it on a separate object you're going to have issues with handles overwriting each other. A safer place to store your handle is in the variable space of the object it's attached to. //This is the code that goes into your action call params ["_target", "_caller", "_id"]; private _handle = [_target, _caller, _id, green] execVM "someScript.sqf"; _target setVariable ["someScript_handle", _handle]; //In the cancel action you use terminate (_this#0 getVariable ["someScript_handle", scriptNull]); Also keep in mind what happens if the player activates the action again before cancel is used and make sure you handle that in your script. --- Speaking of robustness. I wouldn't recommend the use of terminate, at least not as the go to make-awesome-script-go-stop tool. When terminate is used the script will stop immediately and you often can't be 100% sure at which stage your initial script is at when it's terminated. A bit like pulling the plug. Imagine a script controlling a set of traffic lights. While the light is on a script is running a loop switching the colors of the lights from green to yellow to red etc. When we want to simulate someone cutting the power the light is supposed to go dark. We don't need the script anymore since the light is off so we terminate it... and the light gets stuck on red, forever... but the power is supposed to be off? How the f...? Oh! We forgot to do cleanup on this particular set off lights... #VintageCurry Of course this is just a silly example that a quick band-aid fix can sort out. However in more complex work it is not always so trivial to 1. know what the last state was and 2. return to the Null-state. The alternative practice: Build the termination procedure into the script instead and allow for a graceful shutdown. Define variables and conditions that will trigger termination and use those to make sure the script terminates gracefully when the time comes. More work I know but not that much, and besides, it keeps things self-contained, reusable and reduces the risk for bugs to sneak in. Super-simple example of the alternative: Now don't get me wrong, terminate still has it uses. If there's no cleanup needed or the script in question is simple it can be a shortcut that saves a few cycles, or if something's gone horribly wrong terminate can save the day. Anyway... *end rant*

Loops aren't magical. They only repeat a set of instructions as long as the correct conditions apply. The for loop is built to iterate over a pre-determined set. In layman terms: Use for when you know how many loops you want. Use while when you don't. All for does is update the variable and execute the code you provided with the new result. It's better understood in this construct (which happens to be faster): for "_x" from 10 to 20 do {..code..} where _x is the variable we iterate (the name is arbitrary, keep it short and sweet though), 10 is the starting value of _x and 20 is the value _x will hold on the last iteration. If you want your looped-code to react to changes in the variable you have to provide conditions for it to do so e.g.: However that's a bit of an inefficient way of going about it. You want to "do 1 thing on the first loop, another on the next 4 loops, then another on the last 5.". So the first thing happens once, the next thing happens 4 times but never again and the last thing happens 5 times and then we're done. There is no need to put it all in one loop because once the first set of instructions has been executed they are no longer needed. So... second revision: I agree, great rule of thumb, but that code Ninjaisfast put up is taken straight from Nickorr's comment on the wiki which is an example on doing exactly that. ^^