Feature #24926

Add "Every Frame" eventhandler

Added by Sickboy almost 4 years ago. Updated almost 3 years ago.

Status:Closed Start date:09/27/2011
Priority:Normal Due date:
Assignee:Suma % Done:

100%

Category:Scripting: New command
Target version:1.63 BETA
Affected ArmA II version:Please select... First affected ArmA II version:Please select...
Reproduced by another DH user:No Single / Multi Player?:
I am using some Mods:No BIForumURL:
I am using: NGUrl:
Reproducible for you:No WIKIurl:
Related to content of DLC:

Description

By Suma:

If there would be an "every frame" event handler, which would be most useful for you:

- a global event (one for a game) triggered on each frame
- a per-entity handler (one for each vehicle or person) triggered on each frame
- a per-entity handler (one for each vehicle or person) triggered on each simulation

Note: it is important to be aware the two last are different. Units are not simulated in each frame. 
Currently this can be seen for far units, but if everything goes well, it will be soon true for most units: 
http://www.bistudio.com/index.php/english/company/developers-blog/230-experimental-betas-interpolating-the-future


I would prefer 1 (global, frame), but if possible would also like 3 (entity, simulation)


Related issues

related to ARMA2 Community Issue Tracker - Bug #31686: Script Scheduler Performance Issues New 05/22/2012
related to ARMA2 Community Issue Tracker - Bug #20426: AI FSM performance and FSM defaulting/nesting Feedback 06/15/2011
related to ARMA2 Community Issue Tracker - Feature #54314: Please add stackable/multiplexed versions of all onSometh... Assigned 10/10/2012

History

Updated by kju almost 4 years ago

Related comments after Suma's suggestion.

Sickboy

For me, if I had to pick 1, it would be the first, "global event (one for game)".
But, if a second would be possible, I would also like the per-entity handler, triggered on each simulation.
That would IMO cover most scenarios.

Xeno

Numero uno, global event triggered each frame.

Nou

The first option would be best, the second two options seem overly compensating
and probably ripe for abuse by people that do not understand the performance constraints
that come from running unscheduled code every frame.

Also, just to make sure, I would hope this would act like onDraw and be pre-frame render
(though I can see a benefit of it being post-render in some cases).

If this gets implemented on servers I can see a whole world of possibilities opening up!

zGuba

I'd like to see option one ingame. While I'm not very much into details,
I'm sure it'll provide the essential functionality for highest priority operations.
2 and 3 are not really needed, and will possibly cause more harm than good to overall performance if misused.

Updated by kju almost 4 years ago

  • Description updated (diff)

Updated by Xeno almost 4 years ago

Not implemented yet!

Updated by Xeno over 3 years ago

Is this still scheduled for A2/OA or moved to A3 ? (Or even completely dropped)

Updated by kju about 3 years ago

  • Category changed from Scripting: Problem to Scripting: New command

Updated by Dwarden about 3 years ago

  • Target version set to Upcoming version

i hope this is still on schedule, got asked in past weeks several times about it from various community scripters

Updated by fabrizioT about 3 years ago

I hope too, any news?

Updated by kju almost 3 years ago

  • Status changed from Assigned to Feedback

Try the new beta please:

[97917] New: Scripting function "onEachFrame code" defines a code called each frame.

Updated by Xeno almost 3 years ago

Finally in, works fine. Thanks.

Sadly it is like those other onSomething events and can be used only once. If some addon maker uses it and a mission maker too one onEachFrame will overwrite the other (like the onPlayerConnected/Disconnected events for example).
Would be cool to have it working like displayAddEventhandler for example, multiplexed events... (this is also true for all the other on events, like onPlayerConnected, onPlayerDisconnected, onTeamSwitch, onMapSingleClick, and so on)

Updated by kju almost 3 years ago

  • % Done changed from 0 to 80

Agreed. This would be a lot more important for this one even due to the potential more frequent use of onEachFrame.

One could make an API/"framework" ontop of it based on CBA to bypass that.
However it would still work only for those using CBA .. and as long as CBA does not become official, that doesn't work well.

Updated by Nou almost 3 years ago

CBA already has that also.

Updated by Sickboy almost 3 years ago

Thanks a lot for adding this!

At least there's a suitable replacement for (client-side-only) OnUiDraw 'hack'.
I agree with the others that a native way to stack these (besides being useful for many other EH's), would be very welcome.

Updated by Fireball almost 3 years ago

  • Status changed from Feedback to Closed
  • Target version changed from Upcoming version to 1.63 BETA
  • % Done changed from 80 to 100

Closing down, since we got now #54314 for the stackable issue. Thanks.

Updated by Xeno almost 3 years ago

Yeah, I hope it will be adressed as the command is useless in its current form.

Also available in: Atom PDF