Jump to content

jshock

Member
  • Content Count

    3059
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by jshock


  1. Ok, I understand here that you want to basically get the last known position of an object prior to it going null, that I understand. What Grumpy and sarogahtyp are getting pissed about is your're giving no context on what exactly is going on with the object, as you said there are multiple ways the object can go null, so that means there are probably multiple ways of catching the object's last known position prior to it going null. So it's not that we don't get what you want to do, we just can't help you without any extra insight into the issue other than a garbage code snippet.

    • Like 2

  2. Well, I'm trying to help you help yourself, so you don't have to ask as many questions, I try to do this when I can, sometimes it is just easier to hand out the information, but your're one of a handful that constantly ask questions and can't think on your own.....so myself and austin here are trying to get you to think about what your going to do so you can apply that in the future instead of just asking here in the forums.

     

    And honestly most of the time you don't give any impression that you know what the hell your're talking about and you rarely state what you've already tried unless someone explicitly asks, and even then you don't answer anything directly, making it damn near impossible to actually answer your question, simple as it may be to you in your mind.

    • Like 1

  3. I go to this page, do as austin recommends (CTRL+F), and I type a keyword, in this case "item" is the keyword:

     

    https://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3

     

    Then go through them until you see a page that could be what your're looking for look at it and keep looking til you find what you need, a lot of pages also have "related commands" at the bottom most of the time those are probably what you want as well.......

    • Like 1

  4. Firstly pass the projectile into the script, that way you don't need a nearestObject check, secondly, again, allUnits is highly unnecessary as you only need units within a specific radius, so I recommend:

    {} forEach (getPosATL _projectile) nearEntities [["Man"], 10];

    ^This will only loop through AI men that are within 10 meters of the smoke grenade projectile. Instead of all possible units.

     

    And again as well, for the effect wearing off portion I recommend spawning it in instead of leaving it to suspend within the script. You also don't need to keep a local array of "effected" NPCs considering this will be looping through all effected NPCs, and if you spawn in the wearing off portion, it will be handled locally on each NPC.


  5. Seems like firedNear has to do with the firing unit, and not the projectile destination?

    Let's see:

     

    • unit: Object - Object the event handler is assigned to
    • firer: Object - Object which fires a weapon near the unit
    • distance: Number - Distance in meters between the unit and firer(max. distance ~69m)
    • weapon: String - Fired weapon
    • muzzle: String - Muzzle that was used
    • mode: String - Current mode of the fired weapon
    • ammo: String - Ammo used

     

    Firer, the firing unit.....distance from the unit being fired at.....type of ammo used.....hmmm...everything you have in your conditional statements, seems pretty related to your needs. Now there may need to be a bit of a work around to get the actual projectile, but a Fired EH can handle that as already stated, it honestly shouldn't lag you out much.......

     

     

     

    You could also lose the first 3 lines of code, and replace line 12 with:

    if ( (_x getVariable ["Blinded",0]) == 0 ) then
    
    

    And if you keep your loop and such, and if this is only for AI, then you don't need to iterate through all units constantly you can do:

    {/*code*/} forEach allUnits - allPlayers;

    And to make the loop run a bit more efficiently you may want to prioritize your conditions, for example it may be more efficient to check to see if the unit is blinded before any checks on anything else because then you avoid a bunch of distance and position calculations from the beginning.

     

    And the "wearing" off of the effect you may want to make a separate function or script that you spawn in, instead of suspending the loop for a random amount of time before allowing it to continue onto the next unit.

     

    And to make a point on the Fired EH (well any EH), they run no matter if you end up using them or not, they are just provided to us so that we can access said information to accomplish said scripts. So, no "checking for every bullet fired" will not bog anything down, as it happens anyways, even when the information isn't explicitly used by us. Or at least that's how I understand them.


  6. [{your condition to set new delay},#,"New Delay Time Set"] call BIS_fnc_setRespawnDelay; 

    [{time > 300}, 15, "5 minutes after mission started, respawn delay is now 15 seconds"] call BIS_fnc_setRespawnDelay;

    I'm unsure of the locality of the function, but my educated guess would be on the server, but easy enough to find out after implementation.

    • Like 1
×