Jump to content

mrcurry

Member
  • Content Count

    401
  • Joined

  • Last visited

  • Medals

Community Reputation

240 Excellent

6 Followers

About mrcurry

  • Rank
    Gunnery Sergeant

Recent Profile Visitors

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

  1. I didn't want to necrobump the Motion Detector thread, so I was wondering if you could shed some light here; The script doesn't seem to be working as the explosives spawned by a script aren't being detected by the mine detector, is this just on my end or am I doing something wrong?

     

    It seems like any and all explosives spawned by script or not being natively placed down by someone aren't being detected by the mine detector at all.

    1. mrcurry

      mrcurry

      I can't replicate your results, the detector pings as expected though the AI seems to have gotten better at spotting the charges meaning they'll spot the charges momentarily which makes the beeping stop... not pretty.


      I've played around with the idea of doing a custom GUI based on the mine detector one so you don't have to rely on mines, I'll see what kind of R&D I get time for this weekend.

    2. Nirrti

      Nirrti

      Hmm, maybe it's because I'm setting the player's score to negative, making them their own side (SideEnemy), not sure. But that sounds really awesome, I'm mostly just playing around the idea of a free for all deathmatch gamemode relating motion detector, I'm just kind of not very good with arma scripting 😛

       

      Edit

       

      Okay, seems like player addrating -10000 is definitely the cause of the problem on my end.

  2. From allUnits biki: "Return a list of all units (all persons except agents)... "
  3. mrcurry

    Passcode for addaction

    Soooo I may have spent a few hours to throw together a simple framework for adding the ability to start up PCs, password them, assign categories to them and add actions to PCs dependent on their categories... Woops. It was mostly for fun but if you're interested take a look at this:
  4. A trigger with the repeated flag set can activate when the condition is true, then deactivate again when the condition is false and keep doing that as the world state changes, in your case that means as the player enters then exits the area then enters it again. TL DR: What @Von Quest said. To create what you want I would go for a loop. WaitUntil could do it but I'm a sucker for a good ol' while-loop. Put this in your trigger's activation: Sorry for no code format, I'm on mobile 0 = [thisTrigger, player] spawn { Params ["_trg", "_obj"]; private _dDamage = 0.1; private _interval = 1; while {triggerActivated _trg} do { _obj setDamage (damage _obj + _dDamage); sleep _interval; } ; } ;
  5. An alternate solution for those that want dabble as little as possible in script files and only use the editor: 1. Set the trigger to detect "Any", "present" 2. Use condition: vehicle player in thisList Since player refers to a different object on each client and trigger conditions are evaluated locally there's no need to mess about with script files if you don't want to. If you have a lot of these triggers might be better perf-wise to use "Any player" instead. Haven't investigated if that's viable or indeed better. But then again if you have that many triggers... What the heck are you doing!?
  6. Where did you experience this, Single or multiplayer? If multiplayer were you the host or a connected client?
  7. 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;
  8. @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:
  9. 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.
  10. 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?
  11. Well don't leave us hanging... Your problem description is incomplete. More info, hard data, not words. Code, examples, steps to reproduce.
  12. Magazine =/= Ammo BIS_fnc_addVirtualMagazineCargo requires magazine classes. Check that the classes you provide are from Cfgmagazines
  13. 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.
  14. 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.
  15. 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.
×