Scripting Discussion (dev branch)

[SilentSpike 84]

Beware to anybody drawing anything on each frame (UI elements, drawIcon, etc). It's a one way ticket to massive performance issues. Not sure if anybody else has encountered this, but swapping my HUD rendering to occur every 250ms rather than on each frame raised my framerate by around 10fps.

Haven't figured out how much drawIcon has reduced performance by yet, have to replace all drawIcon statements with bullshit createMarkerLocal relative logic.

 

I haven't found this to be true. Unless you're drawing hundreds of icons there shouldn't be that big of a drop.

[SilentSpike 84]

Added: New attributes system for Zeus modules

 

Could we get an expansion on this? It's something I'm very interested in as certain aspects of adding new zeus modules can be pretty obnoxious

[fn_Quiksilver 1636]

onEachFrame will hit the FPS, but obviously it depends a bit on what is being evaluated.

 

I try to keep the evaluations-per-second low, so do try to avoid using it unless necessary.

 

Gossamer, what interface are you using 'DrawIcon' in?

 

If it's in the map, it shouldn't be an issue. On the contrary, a marker script is evaluating at all times, while a drawIcon inside an event handler is not performing any evaluations while the interface is closed.

 

I don't use onEachFrame+drawIcon though. I think at that point the costs outweigh the benefits.

[R3vo 2654]

Hey folks,

I want to hear your opinion first, before I open a new ticket.

 

I was thinking about 3 new commands, which I think are missing and would shorten many scripts and increase their legibility.

 

allUnitsEast

allUnitsWest

allUnitsIndependent

 

What do they do? Well they simply replace codes like this

{
   if(side _x == east) then
   {
   //code
   };
} forEach allUnits;

{
//code
} allUnitsEast;

Would be glad to hear your opinions.

[fn_Quiksilver 1636]

Hey folks,

I want to hear your opinion first, before I open a new ticket.

 

I was thinking about 3 new commands, which I think are missing and would shorten many scripts and increase their legibility.

 

allUnitsEast

allUnitsWest

allUnitsIndependent

 

What do they do? Well they simply replace codes like this

{
   if(side _x == east) then
   {
   //code
   };
} forEach allUnits;

{
//code
} allUnitsEast;

Would be glad to hear your opinions.

 

Not too big an issue IMO.

 

If there was a tweak, I'd say just add an optional param (sides) to the 'allUnits' function.

 

{
 /* code */
} count (allUnits east);

[rebelvg 281]

After unit loses his target targetKnowledge stops reporting target position for a second.

Is this intended behavior or is this a bug or am I doing something wrong? Because nearTargets reports position as intended without that pause.

[R3vo 2654]

 

Not too big an issue IMO.

 

If there was a tweak, I'd say just add an optional param (sides) to the 'allUnits' function.

{
 /* code */
} count (allUnits east);

Yes, I agree, it's not a huge deal, and I would also be fine with your suggestion.

 

A question for the professionals here; Would there be a large performance/speed increase if we had a c++ based allUnitsSIDE command compared to the if-forEach method? Because I imagin it quite performance intensive to go through all units to then select the ones of the correct side.

[gossamersolid 155]

I haven't found this to be true. Unless you're drawing hundreds of icons there shouldn't be that big of a drop.

I was drawing around 40 icons at the time, there can definitely be more than 100 depending on how late in the match you are. It's unfortunate because I find drawIcon to be much easier to use than local markers.

 

onEachFrame will hit the FPS, but obviously it depends a bit on what is being evaluated.

 

I try to keep the evaluations-per-second low, so do try to avoid using it unless necessary.

 

Gossamer, what interface are you using 'DrawIcon' in?

 

If it's in the map, it shouldn't be an issue. On the contrary, a marker script is evaluating at all times, while a drawIcon inside an event handler is not performing any evaluations while the interface is closed.

 

I don't use onEachFrame+drawIcon though. I think at that point the costs outweigh the benefits.

I draw the icons in via ctrlAddEventHandler's "draw" handler. They get drawn on a Mini Map I have present on my UI at all times (unless the user disables it). They also get drawn on the main map (accessed via "M"). They can get drawn in smaller dialogs depending on what the user is doing.

[fn_Quiksilver 1636]

I was drawing around 40 icons at the time, there can definitely be more than 100 depending on how late in the match you are. It's unfortunate because I find drawIcon to be much easier to use than local markers.

 

I draw the icons in via ctrlAddEventHandler's "draw" handler. They get drawn on a Mini Map I have present on my UI at all times (unless the user disables it). They also get drawn on the main map (accessed via "M"). They can get drawn in smaller dialogs depending on what the user is doing.

 

Don't worry about performance too much while the clients map is opened. A bit of CPU is freed up when the map is opened anyways. The client doesn't really notice performance when they're looking at the map, as long is its smooth.

 

For GPS, I limit the radius of draws to ~300m, no need to evaluate objects/units which are out of the GPS frame. That being said, when I do get time to play, I close my GPS when not in use, partly due to this awareness of the script running while its opened :) I open it when I need it but leave it closed by default. Am aware however that most of the players just leave it open always.

 

If the objects are static I'd use markers instead of icons, and just control the alpha to hide/reveal them.

 

 

 

 

Another hidden performance drain is addAction. The condition code gets evaluated constantly unscheduled. With lots of addActions they can pull down performance a bit with so many concurrent calls. Probably on par with the drag of onEachFrame if there are enough actions on the player. If possible try to nest actions and put the least intensive condition evaluation in the outer-most scope if possible.

[h - 169]

at this point it seems to be about getting it out there either way.

I hope this link shows what I see, so here are some of my whislist (took some time to weed it through because it has accumulated ever since like OFP...).

http://feedback.arma3.com/view.php?id=25300

http://feedback.arma3.com/view.php?id=25299

http://feedback.arma3.com/view.php?id=25298

http://feedback.arma3.com/view.php?id=25295

http://feedback.arma3.com/view.php?id=25294

http://feedback.arma3.com/view.php?id=25293

http://feedback.arma3.com/view.php?id=25292

http://feedback.arma3.com/view.php?id=25250

http://feedback.arma3.com/view.php?id=25259

http://feedback.arma3.com/view.php?id=25258

http://feedback.arma3.com/view.php?id=25249

http://feedback.arma3.com/view.php?id=25248

http://feedback.arma3.com/view.php?id=25000

Not all are strictly scripting related but anyway, and like I said, nothing that special in them.

Not sure should I start holding my breath now in anticipation of dozens of new scripting commands appearing shortly :P

Edited August 27, 2015 by h -

[Greenfist 1863]

I hope this link shows what I see, so here are some of my whislist (took some time to weed it through because it has accumulated ever since like OFP...).

http://feedback.arma3.com/view_all_bug_page.php?filter=293209

It shows 11670 issues for me. I agree, they are on my wishlist too.

:icon_twisted:

[h - 169]

lol..

Stupid tracker software :P

 

OK, so here's the list of urls then:

http://feedback.arma3.com/view.php?id=25300

http://feedback.arma3.com/view.php?id=25299

http://feedback.arma3.com/view.php?id=25298

http://feedback.arma3.com/view.php?id=25295

http://feedback.arma3.com/view.php?id=25294

http://feedback.arma3.com/view.php?id=25293

http://feedback.arma3.com/view.php?id=25292

http://feedback.arma3.com/view.php?id=25250

http://feedback.arma3.com/view.php?id=25259

http://feedback.arma3.com/view.php?id=25258

http://feedback.arma3.com/view.php?id=25249

http://feedback.arma3.com/view.php?id=25248

http://feedback.arma3.com/view.php?id=25000

[gossamersolid 155]

Don't worry about performance too much while the clients map is opened. A bit of CPU is freed up when the map is opened anyways. The client doesn't really notice performance when they're looking at the map, as long is its smooth.

 

For GPS, I limit the radius of draws to ~300m, no need to evaluate objects/units which are out of the GPS frame. That being said, when I do get time to play, I close my GPS when not in use, partly due to this awareness of the script running while its opened :) I open it when I need it but leave it closed by default. Am aware however that most of the players just leave it open always.

 

If the objects are static I'd use markers instead of icons, and just control the alpha to hide/reveal them.

Limiting the amount of markers drawn to ones only being in the "viewport" (per say) of my GPS would be a good idea. I'll give that a shot.

I see your point about static markers rather than icons. The issue lies within me not being able to serve up custom PAA images via createMarker, while I can with drawIcon.

 

Another hidden performance drain is addAction. The condition code gets evaluated constantly unscheduled. With lots of addActions they can pull down performance a bit with so many concurrent calls. Probably on par with the drag of onEachFrame if there are enough actions on the player. If possible try to nest actions and put the least intensive condition evaluation in the outer-most scope if possible.

Damnit... I do have a decent amount of actions. I'm not sure what a good solution would be. I do already make sure to have the least intensive part of the conditions on the outer most scope of the condition code. Might have to write my own method of updating availability of actions maybe every 500ms instead of how frequently addAction's condition block checks.

[bad benson 1733]

OK, so here's the list of urls then:

....

 

 

 

that's some great stuff.

 

the particle stuff made me think of something that would be very useful. when you create a particle and make it a "spaceobject" instead of a "billboard" it will get random rotation applied to it by default, which is insanely annoying.

this might sound very specific but if you think about this, it could be a great way to "spawn" a p3d without actually having to create a real entitiy will all kinds of stuff in it happening (aside from maybe the particle source, which is super minor in comparison though).

 

a very specific example would be NeoArmageddon's Map Builder. at some point he tried to make the objects you place be rendered like i just described by the particle system to save performance. it turned out to not be feasible at all due to described random rotation.

 

if someone with access to that could just remove that random default rotation and let us set some rotation ourselves IF WE WANT IT, that would be amazing.

[neodammerung 8]

Since they're on a roll, any news about this one ?

http://feedback.arma3.com/view.php?id=19734

[Larrow 2823]

a very specific example would be NeoArmageddon's Map Builder. at some point he tried to make the objects you place be rendered like i just described by the particle system to save performance. it turned out to not be feasible at all due to described random rotation.

 

if someone with access to that could just remove that random default rotation and let us set some rotation ourselves IF WE WANT IT, that would be amazing.

I had a similar idea with some experiments i was doing. Yes very &$£$% annoying the random angular velocity. Would be so handy to be able to create a static model via a "spaceObject" particle.

[bad benson 1733]

just had another idea. it's a very general thing but i bet some people would have some use for it. you know how you can make a camera move smoothly to a position using the "commit" command instead of having it snap/pop/skip (or whatever) to the destination like with "setpos"?

 

i can't remember the situation i needed that. we all try all kinds of things and abandon alot of it due to lack of a clean method or something. but i think this could be useful for all kinds of things. same goes for "setdir".

 

i think the latter would even be needed for cameras. last time i tried "camsetdir" was not working at all so a smooth progressive "setdir" could even help there while opening up many other possibilities.

 

in general it would be great to be able to move anything via scripting in a smooth manner. i know one can somewhat hack it using the existing commands and oneachframe but i would love to have something more solid on the engine side being synced with everything and just moving inside the main loop. or maybe something SP based only? i dunno.

 

summary: "setpos", "setdir" and maybe even "setvector"-commands being able to be used with something similar to "commit" for any kind of object.

[SilentSpike 84]

I've always understood it that setVelocityTransformation is for just that. However I've never bothered to actually learn how to use it.

[bad benson 1733]

I've always understood it that setVelocityTransformation is for just that. However I've never bothered to actually learn how to use it.

 

aah! interesting. i need to check that one out then as soon as i can. thx for the heads up.

[inlesco 234]

aah! interesting. i need to check that one out then as soon as i can. thx for the heads up.

How did it go, Benson? Any fruits?

[gossamersolid 155]

Another hidden performance drain is addAction. The condition code gets evaluated constantly unscheduled. With lots of addActions they can pull down performance a bit with so many concurrent calls. Probably on par with the drag of onEachFrame if there are enough actions on the player. If possible try to nest actions and put the least intensive condition evaluation in the outer-most scope if possible.

I decided to have one global var for the condition evaluation of each of my actions, then perform the actual condition code in a seperate thread that runs every second. Massive performance boost. To anybody else out there with custom actions, avoid running code in the condition parameter of actions like I've done.

[R3vo 2654]

Just a random though, would it be possible to add a sleep to the addActions's condition? Like with waitUntil?

[bad benson 1733]

How did it go, Benson? Any fruits?

 

nah. i have no access to the game currently. kinda stuck with the theoretical side for now :lol:

[gossamersolid 155]

Just a random though, would it be possible to add a sleep to the addActions's condition? Like with waitUntil?

Honestly I didn't try because the other guy said it was unmanaged. You could attempt that. I've already re-written code, so there's no point in me going back now haha. Helps if you have multiple actions with common conditions.

[Greenfist 1863]

Is there any documentation about all possible "map types" used with nearestTerrainObjects?

It seems to work with such filters as "tree", "rock", "bush", "chapel" etc. But I can't find anything like these in configs? Or are they defined in the map itself or something?