Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

227 Excellent


About mrcurry

  • Rank
    Staff Sergeant

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. mrcurry

    Script help

    Yes. //Find players: assumes variables _marker and _distance has been defined private _selectedPlayers = allPlayers select {_x distance2D markerPos _marker < _distance}; //Remote execution: assumes the function "fnc_someFunc" is defined elsewhere, preferably using the A3 Functions Library. ["someParameters"] remoteExec ["fnc_someFunc", _selectedPlayers]; //fnc_someFunc could look like this (note this is an inappropiate definition, use the A3 Functions Library's CfgFunctions to define it properly) fnc_someFunc = { player setPos markerPos "baseMarker"; }; Note that if you're only teleporting players (like in the above example) you don't need remoteExec, setPos is plenty enough since it's an AG EG command (Argument Global, Effect Global). private _selectedPlayers = allPlayers select {_x distance2D markerPos _marker < _distance}; { _x setPos markerPos "baseMarker"; } forEach _selectedPlayers;
  2. @SnowmanDK Well it's been awhile since I worked on this... Time sure flies. I've update the script to support parameters for number of targets per pop up and I've added a more free form exercise mode as well (right now not very configurable). See the new version at the bottom of this post. Before we jump into the issues you're having a quick disclaimer. I strongly recommend using the execution method in the parameters. Only edit the script code if you know what you're doing. Any changes to the script is on you. If you do not know what you're doing stick to using and editing the execution example(s). No hard feelings just a good thumb rule for working with other people's work. Now with that out of the way let's get down to business. The third parameter is only used to define the different target groups (or lines). You have modified it appropriately for your range but this parameter has nothing to do with the configuration of the rounds. The fourth parameter is what defines the rules for each round. The fourth parameter is an array of arrays that looks like this: So to achieve 3 rounds with all targets on a range with 12 lines at 100 m intervals with only 1 target being used at once the whole execution would look something like this: ========================================================================== NEW VERSION BELOW ========================================================================== Updated version: *Insert arbitrary version number here* What's new: Added "Free exercise" mode Added ability to configure number of targets to pop up each time Added ability to review the results of the 10 last trials (during the given session). (Useful for Rangemasters and competition organisers.) Known Issues: When targets are hit by a client in multiplayer they will after a short while pop back up slightly before going back down. If anyone find a workaround for this please let me know. Example mission: https://www.dropbox.com/s/uivwyl8z9bfdv8k/firingRangeTest.Malden.7z?dl=0 Full script:
  3. mrcurry

    GUI behavior (Dialog)

    So it's not input that's the problem. I did some of my own tests and decided to document them here. It does seem like opening a dialog (I tried with MP score table 'cause why not) activates some sort of half-arsed autopilot. In the air, like you say it, it works alright, like a level flight-autopilot (I use the term "level" loosely). It seems to put you in a coast or cruise mode depending on a bunch of different seemingly random factors and then stops updating. It kicks back in when it you're about to crash and sends you of on another climb/cruise. It gets a little bit wonky with different flyInHeight values, like setting you off on a steep climb which the aircraft can barely hold and doesn't stop even after the "desired" altitude is reached. On the ground it behaves more like a taxi throttle-assist. The plane takes off at taxi speeds in a straight-line (hence the throttle up/down). It will stop when it reaches a runway start/end (either end seems to work) and put the plane into take-off configuration when it does stop. If it never moves the plane near a runway endpoint it will go on forever. As you've realised this "ground mode" only activates when the engine is on. Barring any new commands to interface with this "feature" your current hack seems to be the only way to prevent it. The odd thing is that this entire system seems like something BIS would, at least, want to give their players a heads up about but as far as I can tell it's completely undocumented. Maybe it's a remnant from older games in the series. I suppose it's just one of those things that makes Arma that little bit harder to get into. Seems like either BIS fixed it or it's a problem exclusive to the analog throttle. If you ain't using a joystick then that might be why you've never seen it. I'm not getting the issue anymore but I'm also not running a joystick (for now). That issue really seems unrelated at this point though.
  4. mrcurry

    GUI behavior (Dialog)

    @wogz187 Have you actually observed an autopilot-like behaviour or just the throttle jumping in your video? Seems to me like it's misreading throttle input when the gui is open. Seems similar to the issue where your plane stops reading throttle input when opening the map. Does it happen on all planes? Do you have some kind of controller plugged in and does it go away when you unplug it?
  5. Well don't leave us hanging... Your problem description is incomplete. More info, hard data, not words. Code, examples, steps to reproduce.
  6. Magazine =/= Ammo BIS_fnc_addVirtualMagazineCargo requires magazine classes. Check that the classes you provide are from Cfgmagazines
  7. mrcurry

    OPFOR help please

    Looks like this is a problem directly related to the Altis life framework. You're better off asking in the Altis life forums tbh.
  8. 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.
  9. 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.
  10. mrcurry

    Class attributes

    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
  11. 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; }; };
  12. @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"];
  13. 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.
  14. Deleting won't do. Couple of ways to do it: setPlayerRespawnTime RespawnTemplate MenuPosition combined with BIS_fnc_removeRespawnPosition
  15. mrcurry

    how to...

    @{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.