Add "Every Frame" eventhandler
|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:|
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)
Updated by kju over 3 years ago
Related comments after Suma's suggestion.
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.
Numero uno, global event triggered each frame.
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!
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 Xeno about 3 years ago
Is this still scheduled for A2/OA or moved to A3 ? (Or even completely dropped)
Updated by kju almost 3 years ago
- Category changed from Scripting: Problem to Scripting: New command
Updated by Dwarden almost 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 kju over 2 years ago
- Status changed from Assigned to Feedback
Try the new beta please:
 New: Scripting function "onEachFrame code" defines a code called each frame.
Updated by Xeno over 2 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 over 2 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 Sickboy over 2 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 over 2 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.