Jump to content

Recommended Posts

Hi,

I discovered recently a weird behavior, with addAction on a crate (or any object), while you're leader of a group.

With any of your AI team mate (so local to your PC), you can order him the addAction on the crate (if conditions are met), with the action menu (6). That means the code will run locally even if you are away from the object.

 

Just test:

write an addAction for a crate:

 myCrate addAction ["Arsenal", {    ["Open",true] spawn BIS_fnc_arsenal  },nil,10,false,true,"","vehicle _this == _this"];

 

Here is for arsenal opening, but any code will run a well.

Place the crate or any object named myCrate.

Place a squad with leader as player.

 

Run the preview. You can see your added action when closing the crate (within 15m as hard coded). Move away then order an AI o close the crate on his turn.

Now, you have an added line in commanding action menu (6) for this unit!

You can even ask him to open arsenal. The unit will start an animation to come closer to the crate but at arrival, you will open arsenal for yourself.

 

So, the conclusion is that the hard coded condition is checking the distance from object, not only for player but for all subordinates (not tested with several players in same group).

The working filter seems to be: vehicle _this == player but this remains a waste of code and performance, imho, because the hard coded distance condition should check only for player's distance.

As you can see, with no filter on player, you can open arsenal on crate, even if on the other side of the map. This occurred for me while an AI respawn point was too close from the crate.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 22.2.2018 at 7:01 AM, pierremgi said:

because the hard coded distance condition should check only for player's distance

Don't agree at all. The distance condition should check for the unit that wants to use the action. Which is the AI in your case.
Failure on your end to account for who actually executed the action, inside the script, is your fault and not addAction's fault.

 

Yes the action only works in the hard coded distance. So if you tell an AI to use it, then exactly like if a player wants to use it, the AI runs to the box and uses it.

Share this post


Link to post
Share on other sites
53 minutes ago, Dedmen said:

Don't agree at all. The distance condition should check for the unit that wants to use the action. Which is the AI in your case.

That's a semantic question. Only players "want" something in the game. I never saw an AI deciding to open and use an arsenal.

 

The problem is more related on a weird usage of the addAction condition, transferring the "caller" role" from player to unit (the unit can meet the distance condition instead of the player), then firing the code on player's PC as usual. I disagree with that because I initially added an action to the player (remember player addAction [...]), not on the whole squad.

And, I persist, checking distance for all subordinates can be a waste of performance and Arma can't afford that.

Just, imho.

Share this post


Link to post
Share on other sites
14 hours ago, pierremgi said:

That's a semantic question. Only players "want" something in the game. I never saw an AI deciding to open and use an arsenal.

 

The problem is more related on a weird usage of the addAction condition, transferring the "caller" role" from player to unit (the unit can meet the distance condition instead of the player), then firing the code on player's PC as usual. I disagree with that because I initially added an action to the player (remember player addAction [...]), not on the whole squad.

And, I persist, checking distance for all subordinates can be a waste of performance and Arma can't afford that.

Just, imho.

 

Not weird at all.

You can order an AI to enter a vehicle, disassemble a static weapon or even use artillery to fire at a position. So why should activating an action be any different?

The caller returns the AI unit, it also has to meet the condition criteria.

 

Now if addAction wasn't local but global, every player could use other players to trigger those actions.

If you don't want specific units to be valid for an addAction that's meant to be player only you need to add the appropriate check.

 

Edit:

On 2/22/2018 at 7:01 AM, pierremgi said:

The working filter seems to be: vehicle _this == player but this remains a waste of code and performance, imho, because the hard coded distance condition should check only for player's distance.

As you can see, with no filter on player, you can open arsenal on crate, even if on the other side of the map. This occurred for me while an AI respawn point was too close from the crate.

 

vehicle _this == player runs for roughly 0.0007ms. That's 0.0041% of one frames runtime (considering 60fps one frame takes 16.67ms).

Barely a performance issue.

Same goes for the 15m check, which I believe is using the nearEntities command, which also runs for 0.0007ms (someObject nearEntities 15).

 

The issue is not with the addActions condition parameter, but with what happens inside the addActions script parameter.

Not really sure why you think that the addActions condition should only evaluate for the player, since you can't assume that only players will activate the addAction on an object for the reasons mentioned above.

 

Cheers

Share this post


Link to post
Share on other sites
16 hours ago, Grumpy Old Man said:

 

Not weird at all.

You can order an AI to enter a vehicle, disassemble a static weapon or even use artillery to fire at a position. So why should activating an action be any different?

The caller returns the AI unit, it also has to meet the condition criteria.

 

 

That's not the problem. commanding action is not a player addAction, more a unit action. It's weird to ask a unit to open arsenal on a distant crate for you. Like it's also weird to ask subordinate to open his backpack  at distance for your stuff. Just a point of view.

 

 

16 hours ago, Grumpy Old Man said:

 

Now if addAction wasn't local but global, every player could use other players to trigger those actions.

If you don't want specific units to be valid for an addAction that's meant to be player only you need to add the appropriate check.

 

 

Never mentioned global instead of local. No added value in this comment.

 

16 hours ago, Grumpy Old Man said:

 

vehicle _this == player runs for roughly 0.0007ms. That's 0.0041% of one frames runtime (considering 60fps one frame takes 16.67ms).

Barely a performance issue.

Same goes for the 15m check, which I believe is using the nearEntities command, which also runs for 0.0007ms (someObject nearEntities 15).

 

 

 

No, vehicle _this == player is just an added filter due to the weird distance check on every team mates. The 15 m check depends probably on how many guys are in team.

So,  one hard coded check on whole team + one filter on player is definitely a waste of performance/code. You used to be sharper on this point in some of your posts. Why not here?

 

 

16 hours ago, Grumpy Old Man said:

The issue is not with the addActions condition parameter, but with what happens inside the addActions script parameter.

Not really sure why you think that the addActions condition should only evaluate for the player, since you can't assume that only players will activate the addAction on an object for the reasons mentioned above.

 

No, there is no issue about the local code. It fires locally on player's PC. All normal. Don't distort my words!

For me, the issue is just on the hard coded 15m condition, checking distance for whole team instead of the caller only. That's all folks.

Share this post


Link to post
Share on other sites
4 hours ago, pierremgi said:

That's not the problem. commanding action is not a player addAction, more a unit action. It's weird to ask a unit to open arsenal on a distant crate for you. Like it's also weird to ask subordinate to open his backpack  at distance for your stuff. Just a point of view.

 

It actually is a player action, since AI can't order other AI to use the action menu (6).

If you add BIS_fnc_Arsenal to the addAction I fail to see why you think it is weird that once the action gets activated the arsenal is opening, since that is the very thing you told the addAction to do.

The arsenal stuff is happening from the addActions script parameter and has nothing to do with the addAction itself, more with the person who wants that this specific addAction command opens the arsenal.

 

Being able to open a units backpack via action menu has been added for convenience, so you don't have to run up to every single unit if you want to know which one still has for example a FAK left or want to manually mount/dismount a suppressor on that unit.

The AI unit can also open the nearest Inventory with the same called action, or if wanted the players inventory, so you can easily swap items with a unit without having to spot where he is and walk up to him.

 

4 hours ago, pierremgi said:

Never mentioned global instead of local. No added value in this comment.

 

Just pointed something out, hope no one got injured. :yay:

 

4 hours ago, pierremgi said:

No, vehicle _this == player is just an added filter due to the weird distance check on every team mates.

The 15 m check depends probably on how many guys are in team.

So,  one hard coded check on whole team + one filter on player is definitely a waste of performance/code. You used to be sharper on this point in some of your posts. Why not here?

 

The check happens on the object the addAction has been added to.

There is a single check happening for a single addAction at any time, and only when within 50m of the addAction object..

 

If you want an addAction to be only activated by a player simply use "isPlayer _this" when adding the action on an object, simple as that. No AI will be able to see the action any longer.

I still fail to see how giving up 0.004% of a single frames runtime is bad. Even with 10.000 addActions on 10.000 objects you'd start using more than 40% of a frames runtime.

Maybe you can elaborate a bit further of where you think this is a waste of performance/code or provide some numbers where having an addAction causes significant fps loss.

 

4 hours ago, pierremgi said:

No, there is no issue about the local code. It fires locally on player's PC. All normal. Don't distort my words!

For me, the issue is just on the hard coded 15m condition, checking distance for whole team instead of the caller only. That's all folks.

 

The distance is actually 50m, at least last time I checked.

If any player is further away than 50m the condition won't be evaluated at all and can't eat up any performance whatsoever.

 

Again, please provide some numbers to back up your claimed performance loss or what exactly is causing issues for you regarding the so called hard coded distance condition.

 

Cheers

Share this post


Link to post
Share on other sites

50 m ? never seen this distance in BIKI or during tests.

1 hour ago, Grumpy Old Man said:

The distance is actually 50m, at least last time I checked.

If any player is further away than 50m the condition won't be evaluated at all and can't eat up any performance whatsoever.

Again, please provide some numbers to back up your claimed performance loss or what exactly is causing issues for you regarding the so called hard coded distance condition.

 

Same for you. From where do you issue 50 m? I've never seen this distance in BIKI or during tests.

 

15 m seems the default distance to display the addAction menu, as said in midNigthers last comment on BIKI addAction page. And tested.

It's not the same distance for the condition check overall.

In fact, the condition check seems to work like the action menu for other equipment/object. Not an affirmation, more a deduction:

- place a crate on the end of Altis airfield, place your team not too far.

- in the init of the crate:

this addAction ["test",{},nil,10,false,true,"","hint 'ok';true"]

- run the preview and "wait" (it's almost instantaneous) the team have a "knowledge" about the crate (important),

  So, you can have the hint (that means the condition code is running). Wait for fade out (I accelerate time by 4)

- go where you want, on the other side of the runway, far, with the whole team.

- now, each time you select a guy, no matter the distance of the crate, you run the condition code, prior to any menu choice.

 

At least, it's better than i thought. The condition code is not a question of distance, but a question of:

- object perceived by the team (like other weaponholders. I don't know how it works as AIs can "detect" a gun on ground for hundred meters)

- and the opening of the menu (just by the selection of a team mate).

Share this post


Link to post
Share on other sites
On 23.2.2018 at 5:58 PM, Grumpy Old Man said:

vehicle _this == player runs for roughly 0.0007ms. That's 0.0041% of one frames runtime (considering 60fps one frame takes 16.67ms).

Barely a performance issue.

Same goes for the 15m check, which I believe is using the nearEntities command, which also runs for 0.0007ms (someObject nearEntities 15).

No a in-engine thing is 100% not using some script command (nearEntities).

And yes.. "vehicle _this == player" might be quick.. But " 0.0007ms" is absolute bullshit, I guess you converted seconds to milliseconds by multiplying by 1 which is absolute bullshit.

Also you are not taking into account the oldness of the implementation. Aka addAction might compile that string into a script every time it's executed just like the eventhandlers. So you also have to take that into account.

So profile

call compile "vehicle _this == player"

and use these results and convert them correctly and then you'll see what a performance issue it is.

 

On 23.2.2018 at 5:25 PM, pierremgi said:

That's a semantic question. Only players "want" something in the game. I never saw an AI deciding to open and use an arsenal.

 

The problem is more related on a weird usage of the addAction condition, transferring the "caller" role" from player to unit (the unit can meet the distance condition instead of the player), then firing the code on player's PC as usual. I disagree with that because I initially added an action to the player (remember player addAction [...]), not on the whole squad.

And, I persist, checking distance for all subordinates can be a waste of performance and Arma can't afford that.

Just, imho.

 

It doesn't check distance for all subordinates. If you tell AI to do it they walk into range. Check once. Execute.

Also why don't you just check inside the code that a player executed it?

In-Engine distance checking is so cheap it's basically free. Executing one script command like "true" is like 10x as expensive or more.

 

Do you expect the action to be executed on the AI's machine?

If you are the teamleader then the AI's machine is yours. Everything is working exactly like it's supposed to be.

 

On 23.2.2018 at 5:25 PM, pierremgi said:

That's a semantic question. Only players "want" something in the game. I never saw an AI deciding to open and use an arsenal.

 

Not really. You told it what it should do. Meaning it now want's to finish it's assigned task.

Share this post


Link to post
Share on other sites
4 hours ago, Dedmen said:

No a in-engine thing is 100% not using some script command (nearEntities).

And yes.. "vehicle _this == player" might be quick.. But " 0.0007ms" is absolute bullshit, I guess you converted seconds to milliseconds by multiplying by 1 which is absolute bullshit.

Also you are not taking into account the oldness of the implementation. Aka addAction might compile that string into a script every time it's executed just like the eventhandlers. So you also have to take that into account.

So profile


call compile "vehicle _this == player"

and use these results and convert them correctly and then you'll see what a performance issue it is.

 

 

It doesn't check distance for all subordinates. If you tell AI to do it they walk into range. Check once. Execute.

Also why don't you just check inside the code that a player executed it?

In-Engine distance checking is so cheap it's basically free. Executing one script command like "true" is like 10x as expensive or more.

 

Do you expect the action to be executed on the AI's machine?

If you are the teamleader then the AI's machine is yours. Everything is working exactly like it's supposed to be.

 

 

Not really. You told it what it should do. Meaning it now want's to finish it's assigned task.

 

Not sure what you're on about, but multiplying something by 1 gives the same number as a result.

Performance checks using execution time as a measurement are always hardware related, so you might get different times on your rig, the percentage difference between tests should be of the same magnitude though.

Right out of the debug console:

Result:
0.0007 ms

Cycles:
10000/10000

Code:
vehicle player == player

 

Maybe the console can't properly convert from seconds to ms, who knows?

Well let's do another check:
 

Result:
0.0003 ms

Cycles:
10000/10000

Code:
true

 

Sounds about right, no? Or do you expect a modern CPU to take a few milliseconds to evaluate bool?

Stuff like that needs a few hundred nanoseconds (0.0007ms = 700 nanoseconds) to evaluate at most, even as a script command.

 

Now to your call compile example:

Result:
0.0013 ms

Cycles:
10000/10000

Code:
call compile "vehicle player == player"

Not really surprising, is it? Almost twice as much time needed, still nothing to worry about and most certainly not problematic in terms of performance loss.

 

Now lets check the evaluation time of the addActions condition field:

GOM_debug_check = {

diag_log diag_tickTime;

true

};

testCrate addAction ["Check",{},[],0,true,false,"","[] call GOM_debug_check"];

//writes the following to the debug .rpt:
14:00:35 841.678
14:00:35 841.695
14:00:35 841.712
14:00:36 841.729
14:00:36 841.745
14:00:36 841.762
14:00:36 841.779
14:00:36 841.795
14:00:36 841.812
14:00:36 841.829
14:00:36 841.845
14:00:36 841.862
14:00:36 841.879
14:00:36 841.895
14:00:36 841.912
14:00:36 841.928
14:00:36 841.945
14:00:36 841.962
14:00:36 841.978
14:00:36 841.996

So just to refresh everyones memory again, 1 second = 1000ms. Now taking the imprecision in arma regarding numbers into account (read KKs comment) you can clearly see that the condition is being evaluated roughly every 16ms.

Since I had 60fps while testing, this sounds about right.

So addAction only evaluates once per frame.

 

Also why am I the only one in this thread providing actual numbers?

If you claim I'm bullshitting at least have the courtesy to provide a counter argument. "It's bullshit" doesn't hold much weight in an objective discussion.

Provide some numbers to your "oldness of the implementation" argument, I'd like to take a look at that.

 

Cheers

Share this post


Link to post
Share on other sites
3 hours ago, Grumpy Old Man said:

Now lets check the evaluation time of the addActions condition field:

So just to refresh everyones memory again, 1 second = 1000ms. Now taking the imprecision in arma regarding numbers into account (read KKs comment) you can clearly see that the condition is being evaluated roughly every 16ms.

Since I had 60fps while testing, this sounds about right.

So addAction only evaluates once per frame.

 

Not sure addAction evaluate once per frame. Probably more. The once per frame is for EH "onEachFrame".

I'm not skilled at performance testing, even with console, but i wonder why such command should be framed.

So, i wrote that:

counter = 0;

Player addAction ["test",{onEachFrame { counter = diag_TickTime}},nil,0,false,true,"", " hint str [counter,diag_tickTime,diag_tickTime-counter],true"];

 

It seems there is "a life" between frames, if you consider the 3rd term of the array after calling the action. Of course diag_tickTime is same at each frame.

 

 

2 hours ago, Grumpy Old Man said:

Also why am I the only one in this thread providing actual numbers?

If you claim I'm bullshitting at least have the courtesy to provide a counter argument. "It's bullshit" doesn't hold much weight in an objective discussion.

Provide some numbers to your "oldness of the implementation" argument, I'd like to take a look at that.

 

Numbers? I maintain 50 m distance is not an "actual" number (see above). My 15 m as presence condition is more reliable. My consideration about any team member awareness condition, regardless of the distance (so, no number) is tested and probably right (see above).

For ms in tests, you're probably right.

 

For the fact, addAction uses the same (very bad) engine as any action menu, just checking team members and knowledge on objects, it seems I'm the only one thinking it's a weird solution. No problem, I can live with that.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×