jshock

This is a relatively new event handler, I've never messed with it, and it's EntityKilled, but going null may as well be "killed", so worth a shot (not sure if it works for objects either, but eh): https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#EntityKilled

Well without prior montioring, I honestly don't believe there is a solution, so there's your answer. Cause null objects don't have a reference anymore because, well, they're null... Unless I'm missing something....

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.

So we are your lackeys for your "simple" problems, how do you honestly expect to move onto more difficult shit if you can't debug simple stuff??

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.

Correct a specific command does not exist for what your're trying to accomplish, but all this searching gives you all the commands necessary to deal with your particular issue.

Save the original item cargo information an array, delete the one thing you don't want, then replace the item cargo information again. Though, I'm making the assumption that you already tried removeItem, you should try that if you haven't (I'm not 100% that it will work with vehicle inventories or not, but worth a shot).

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

Hello Scripting Community, Is there a way to use something like MISSION_ROOT, but with the configfile instead? Here is a standard configfile directory path to the desired class: (configfile >> "CfgGroups" >> "East" >> "OPF_F" >> "Infantry" >> "OIA_InfSentry") I'm wondering if there can be anything like this: (CONFIG_ROOT >> "OIA_InfSentry") Main reason behind this is that the group class being defined (in the example: "OIA_InfSentry") is randomized, and I want to be able to fill the array with group classes from all sides, not just EAST, so if I can define just the final group class name, and then have the rest of the configFile directory filled in, it would make life much easier.

https://community.bistudio.com/wiki/Description.ext#CfgSounds https://community.bistudio.com/wiki/say3D Define them in your description.ext then in the init field of the radio use the say3D command. No trigger necessary, loop may be necessary though.

I don't believe on the fly (aka scripted) game master modules are possible for security reasons, that may have changed, but last time I remember it was not possible (or I could be thinking about something else entirely :p).

Where is this all being executed?

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.

Fair point and I agree, I looked at the info on FiredNear a little too quickly (been a while since I used one :p), forgot it had a cap working distance.

Let's see: 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.

Might be easier to use a FiredNear EH, no loop needed just distance and conditional checks like you already have. Looping through all units every ten seconds is relatively intensive while EHs are provided inherently and don't bog down the game at all so long as you don't press the conditionals too far.

Amazing no, simple so others can hopefully learn something, yes :D. Appreciate the complement though. I made it readable, not optimal :p.

You sure DAC doesn't provide access to an array of all DAC spawned AI?

Could you not just set _trg1 activation to: ["EAST", "NOT PRESENT", true] or does DAC need a specific trigger activation?

Recommend you start learning the new editor before Apex comes out.

So... _trg1 setTriggerStatements ["true",format ["fun = [""%1"",[1,0,0],[3,3,20,6],[],[],[],[0,0,0,0,1]] spawn DAC_Zone",name _trg1], ""];

What script, can you post it, lots of things can cause an AI to crash...

So, the first parameter into DAC_Zone is the reference to the trigger? If so: _trg1 setTriggerStatements ["true",format ["fun = [%1,[1,0,0],[3,3,20,6],[],[],[],[0,0,0,0,1]] spawn DAC_Zone",_trg1], ""];

I'm kinda confused with what your after but I'll take a shot. If the server is launched with the mod enabled, and the mod has some sort of "initialize" function, then yes, in the admin console on the server you should be able to execute that function (with a server exec) to start up the mod (theoretically).

The arguments passed in are useful in certain circumstances, in this case, you shouldn't need them, and yes you can use a isServer check in the init, however the initServer does this inherently, the init (after the introduction of the event scripts) is basically depreciated.