Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

1003 Excellent


About beno_83au

  • Rank
    Sergeant Major

Profile Information

  • Location

Contact Methods

  • Youtube
  • Steam url id

Recent Profile Visitors

4622 profile views
  1. beno_83au

    laptop tasks

    Just add a distance check into your condition to stop it if they wander too far away: while {(_Progress < 100) && ((_unit distance _laptop) < 5)} do //_laptop being the object the need to stay near, and must be within 5m Then at the end of the process, and before any other code, just use something like: if (_Progress >= 100) then if ((random 1) < 0.25) exitWith {hint "Download failed. Try again."}; //25% chance of failure { hacked = true; You could also use BIS_fnc_holdActionAdd to make the player hold their action button down to complete the action, but it looks like they'd have to do that for over 4 minutes which probably isn't quite what you're going for.
  2. beno_83au

    fry carrier

    Are you spawning and attaching each individual part of an aircraft carrier to a helicopter? If so, why?
  3. beno_83au

    Jets DLC Terrains

    @BrendoB47 Short answer, you gotta do it yourself. I did it myself for Montenegro. But afaik you can only create dynamic airports, and that brings the issue of the AI only being able to recognise one airport. I worked around it by spawning and despawning airports when needed, placing any planes needing the airports into a holding pattern until it was their turn to have an airport spawn. Don't know if there's a better way.
  4. Attaching an object to something will mean that the object you're attaching, in this case the helicopter, will basically act like a child of the object you've attached it to and inherit it's simulation. The same thing will happen if you try to attach turrets to the static ships. They will update their animations infrequently, meaning that every few seconds they appear to snap their aim to a new target. It's not a bug, it's how attachTo works. I'm not sure why the command works that way, maybe it doesn't have to? I tried attaching turrets to the Destroyer a few months ago and ran into this, but it only took a little bit of searching to find this (including possible work-around):
  5. beno_83au

    Object Random Spawn

    setPos takes 3D locations, and a number of the examples on the wiki use z values. This line: akCACHE setPos (selectRandom [[3158.96,5770.6,3.36632],[3444.22,5934.86,6.1],[3487.09,5941.93,5.83216]]); Should work just fine, assuming you have named the object correctly (i.e. akCACHE). However, as the line is being placed in the object's init field, you can simply use this in place of the object's name, as this refers to that object. Hovering over the init field title (Init) gives you a tooltip that shows you various variables that can be used. Same goes for waypoints and triggers on their text fields. Edit: setPosATL does work in ArmA 3. just means it was introduced in ArmA 2.
  6. @Synchronized I did a bit of table for the GBU-31. If you want to run some of this through a real-world test that'd be nice. Otherwise I'll just go and compile the data for all the bombs from various speeds/altitudes over some period of time and see how it pans out. This was done on the F/A-18C ("FIR_F18C") in level flight on the VR terrain. ["Speed","Altitude","Distance"] [500,900,3504] [500,1000,3697] [500,1100,3871] [600,900,3877] [600,1000,4087] [600,1100,4265] [700,900,4240] [700,1000,4450] [700,1100,4650] [800,900,4570] [800,1000,4807] [800,1100,5004] [900,900,4913] [900,1000,5151] [900,1100,5371] [1000,900,5237] [1000,1000,5480] [1000,1100,5714] This was done by recording actual results, not through any equation. From what I searched, people gave up on trying to maths their way through this particular Arma problem a while ago. I spend much of my working life now days sympathising.
  7. Because the planes are taxiing they wont hold 100% throttle (I think that's it basically, it's what appears to be happening). At a guess you're on the PMC terrains? Either way, you could brute force it with an eachFrame event handler (setting velocity and direction constantly). But for proper runway operation that's not going to be enough. I needed AI to use the runways on one of the PMC maps, and also wanted some ILS functionality for players, so I worked out how to add modded in runway objects that add each runway as a class: https://community.bistudio.com/wiki/Arma_3:_Dynamic_Airport_Configuration I did it for the 4 airfields on Montenegro, including taxiways. It wasn't the easiest thing I've had to figure out.
  8. I don't think he means limiting weapon releases unless a target is in range or anything like that. I think he's just looking for a way to calculate how far a bomb will travel if released at a certain height and speed, which I would also like to know. Maybe dropping ordnance from different heights/speeds and recording the distances flown into a spreadsheet wouldn't be too ambitious of a task, in lieu of doing any form of maths haha. Good video though. Explains the use of the I-TGT nicely.
  9. Agreeing with what Pierre said. But also, why not just add the unit to an array as you spawn it: _objectArray = []; for "_i" from 1 to 2 do { _object = createVehicle ... //the rest of your code _objectArray pushBack _object; }; { _x enableSimulation false; } forEach _objectArray; OR, just disable the simulation when it spawns (probably much better if there's a lot to spawn): for "_i" from 1 to 2 do { _object = createVehicle ... //the rest of your code _object enableSimulation false; }; With the second method you can still add them to an array to manipulate them later, incase you want to re-enable their simulation. Just use pushBack or append (I'm not sure which is faster) as in the first example. And remember, enableSimulation takes an object, not a string, so trying to do "objectName" enableSimulation false is never going to work.
  10. https://community.bistudio.com/wiki/Category:Arma_3:_Scripting_Commands There if you didn't already know about it, but they're all conveniently grouped here: https://community.bistudio.com/wiki/Category:Command_Group:_Eden_Editor As for getting on everything when you leave the game, that depends on how powerful the 3den command are. I'm not overly familiar with them though, but assuming they can do whatever you need you'd just need to start figuring what info you need to capture (object types, positions, etc) and, i guess, feel your way from there. Then, I guess one way to do it, would be to save the data to your profileNamespace. Could end up being a bit of a learning curve if this is your first foray into arma scripting though, so I'd advise starting small and simple first. Edit: Honestly, if something like this doesn't already exist it'd be interesting to have a go at. But I'm not even working on my current project (kids and school holidays are THE WORST).
  11. Well, I've only ever touched on some of the 3eden commands but commands do exist to at least do a simplified version of this. However, I've never seen anything do this. Would be an interesting idea.
  12. @Christopher Ware https://community.bistudio.com/wiki/Magic_Variables This has details about _x and this, plus a few others, so have a look there. But in an object's init, this refers to the object.
  13. Guessing it's due to scheduled v un-scheduled environments, and that _x reference. Worth looking into them ( scheduled/un-scheduled) if you want to understand it, but basically you cant pause a script unless it is spawned or execVM'ed, whereas code written into an object's init is called and so cannot be paused. So, spawn your code: nul = [this] spawn { params ["_object"]; while { triggerActivated mt_1 } do { sleep 2; _object animate ["terc", 0]; sleep 2; _object animate ["terc", 1]; }; }; But, that then all depends on what _x is too. So I'm assuming here that this is the only code you've got in the init?
  14. While much of what can be done through the description.ext can instead be done through the editor, any description.ext settings will takes priority over editor settings and more can be done with it (e.g. declaring a large number of things). So while the editor is great for mission settings for something quick and easy or just for people not comfortable with scripting or editing the description.ext, at some point you'll want to move to it to open up more options for missions.