addaction radius too big. making it smaller

[Tankbuster 1746]

I note, with a slightly bitter taste, that ToH addactions have a new radius (and radiusView) parameter. I'd love to have it in Armahead.

I've found the Arma2 addaction radius to be 10 meters, if you point at exactly the right spot. Unfortunately, this is larger than the trigger radius of some of my custom IEDs, so players can disarm them with impunity. I could make the IED trigger larger, but it looks and plays rubbish if I do.

Burying the object the addaction is on.

So, I got cunning and buried the trigger below ground, thinking the radius might manifest in the form of a sphere and it does, but it's no decent solution. I hoped the action radius would only become active where it breaches the terrain skin, but no, looking down into the ground, provided you're within 10m of the action, makes it available to the player if you get lucky and blindly point right at the object with the addaction.

In the yt below, the traffic cone is at ground level and the addaction is on an object 5m below it. Note the hints that report the distances. As you can see, if I manage to point at it, even though it's below ground, the addaction becomes available.

LFbZ2vK8jdg

So, that's horrid. Bin that and move on.

Creating the addaction by trigger

So, I asked Google and came up with some ancient posts by Avon Lady (that's how old they were), which I now can't find. They talked about adding a 2x2 circular trigger. So I put it on top of another traffic cone to test with;

activation anybody
condition alive player && player distance cone2 <= 2
onAct cone2action = cone2 addAction ["addactioncreatedbytrigger!!", "test100.sqf"];
onDea cone2 removeAction cone2action

But is creating the addaction by trigger MP (and dedi server) sensible?

It works fine in editor preview. I was worried this wouldn't work in a dedicated server environment, but it does appear to. When I run up to the cone, the action appears at 2m, and goes away outside that.

But I thought player doesn't exist as an entity on the server? I suppose that's because the cone2 and the trigger were made in the SQM exist both on the server and player client. The Also, that test100.sqf will ONLY run on the client who uses the action?

I think I've cracked it, unless there's something nasty waiting to bite me? Is, for example, every connected player going to get the addaction regardless of where they are when someone gets close to an IED?

[Wolfenswan 1]

Unless I'm being dense adding this at the end of addaction should be enough:

((_target distance _this) < 9)

Obviously 9 is whatever you want it to be.

For example:

action = cone addAction ["Do stuff","script.sqf",nil,1,false,true,"","((_target distance _this)"]; 

Careful when testing on a dedi though. If you're the only player connected the game treats it differently then to several players being connected.

[Tankbuster 1746]

Ooooo. You can put a condition on an addAction! I didn't see that.

I will try that. Many thanks. :)

[Deadfast 43]

Careful when testing on a dedi though. If you're the only player connected the game treats it differently then to several players being connected.

In what way? The condition is local and shouldn't result in any different behavior no matter how many people are connected.

[kylania 568]

In what way? The condition is local and shouldn't result in any different behavior no matter how many people are connected.

Yeah, he's been having unexplained problems with that. No one else seems to be able to replicate it though.

[Tankbuster 1746]

Did some testing using Wolfenswans suggestion from post 2. Here's the code I put on the object in the editor.

And here's the thing in all it's working glory. Thank you, Wolfenswan!

498by-JULOA

This was done in editor preview. I've yet to test it in a dedicated environment with more than 1 client, but will do so soon.

[Tankbuster 1746]

Update: :)

This works in SP or editor preview, but not dedicated because of locality.

The objects (my IEDs) that are to have the addAction are all created on the server only. Using the techniques described here, I can put an addaction on the objects but they are never seen by player clients.

Having discovered this, I pushed this part of the project down the priority list and have been doing other bits, but as Kylania prodded me :) I'm back here now.

The idea was to have a "defuse IED" function that would simply do a random chance of a successful defuse, with an improved chance for an engineer.

I assume the solution is to use remote scripting to create the addaction actually on the player when they get really close to the IED?

But then, if they fail to defuse the IED, I have to remote script AGAIN to jump back to the server to create an explosion.

Likewise, if they are successful, I have to jump back to serverside to remove the explosion trigger. Or just set a public variable that prevents the IED going off. Would be better?

[kylania 568]

CBA events! :) Use it to add and remove the addActions, or put a variable in the action condition to hide it after it's defused maybe. Main problem is you need to add and remove actions for each person which can get annoying.

[Tankbuster 1746]

Yeah, I figured it would be CBA, or a homemade remote execution suite.

Although I originally wanted to keep the addon load as low as possible, the group of chaps that I play with these days use CBA so I might as well use it.

[blackmamb 2]

Yeah, but why not create the action on the object on each machine? As long as you remove it on each machine too.

That action would publicVariable something, and all you'd need would be another trigger (preplaced or created by script during the init of your script) that would execute the needed code on each machine (removing the action for clients, and all the rest, I assume randomly explode, remove the object etc. on the server).

Although, that'd need special attention for JIP issues.

[Tankbuster 1746]

It's the JIP problem that led me to create them on the server only. I do have the IEDs all stored in an array, so it's possible to publicvariable it.

At the moment, players can use an IED disruptor (a reconfigged satchel with a nice model) to kill the IEDs. So there is a way to kill the bombs, I was just thinking if there might be another way.

I'm really new to this remote execution stuff, so let me brainstorm this idea. This is my homemade remote execution trickery I mentioned earlier. Is it complete nonsense?

Each player has a trigger attached to them.

Each IED has a PV event handler on them.

When player get within 2m of the IED, the trigger generates an addaction saying "defuse". If they select it, it makes a random success or fail decision as to whether they've managed to defuse it.

If they are successful, we PV a variable that has the players location and a flag saying true.

....Each of the IEDs has a PVEH that when the EH fires, it checks to see if the PV data location is close to the location of itself. If it is, it assumes the IED has been defused and deletes it's trigger.

If the player is unsuccessful in attempting to defuse, we PV a variable with the players location and a flag saying false.

.... The PVEH on each IED sees the new variable and gets the public'd location. If it's close to itself AND that the flag is false, It assumes the defuse failed and set's off the IED charge. Boom.

It might break down if there's lots of players interacting with IEDs simultaneously, but I imagine that'd be quite rare.

What does the panel think?

---------- Post added at 19:32 ---------- Previous post was at 19:23 ----------

Note that it's quite rare that players get that close to the IEDs. Normally, the IED goes off at around 6m unless the player approaches it in prone. That's how they can get the IED disruptor in close.

Edited October 26, 2012 by Tankbuster

[Wolfenswan 1]

Here's what I'd try (bit of Pseudocode, sorry). It's ugly and def. not the best solution but it should work.

init.sqf

{
_x addAction [defusescript.sqf];
} forEach [iED1,IED2];

defusescript:

_iedpos = getPos _this select 0;
_id = _this select 2;
IED_var = [_iedPos,_id, round random 100];
publicvar "IED_Var";

PVeventhandler for IED_Var doesn't do anything but passes the values to yet another var that's server-exclusive and again PVed, this time by the server to *all* clients.

Another PVeventhandler either removes the action or causes a boom, depending on the round random 100.

The double PVeventhandlers are necessary to affect the client that called the action initially. Alternatively, you could write some redundant code in the action script and remove the PVeventhandler.