Scripting Discussion (dev branch)

[xendance 3]

...

if(call isFalse && {(call isTrue)}) then {...

Could this be improved sometime without breaking backwards compatibility? That is pretty obscure syntax for just getting boolean expressions to short circuit.

[Dwarden 1124]

it's been this way since it was introduced in OA year(s) ago ...

[xendance 3]

it's been this way since it was introduced in OA year(s) ago ...

Kind of an odd answer to a question if it could be improved ;)

[maddogx 13]

Perhaps it would be possible to add a kind of "mode switch" to SQF, similar to what strict mode does for Javascript.

Essentially, a single command you can invoke at the top of a script that tells the compiler to always use lazy evaluation (and perhaps some other things). This approach should prevent any backwards compatibility issues while allowing for cleaner code.

[rübe 127]

Perhaps it would be possible to add a kind of "mode switch" to SQF, similar to what strict mode does for Javascript.

Essentially, a single command you can invoke at the top of a script that tells the compiler to always use lazy evaluation (and perhaps some other things). This approach should prevent any backwards compatibility issues while allowing for cleaner code.

I do not agree at all. To me this sounds like bloat and a lot of confusion. Hell, I certainly don't want to have to read the header of each file to be able to decipher some code some lines below (and yes, macros can be evil too - my opinion). Syntactic sugar can be a nice thing, but here the reason is absolutely not sound.

You say "backwards compatibilty", and that's where I have to gnaaahhh.

Backwards compatibility? Yeah, I can see how that was the reason behind this. But IMHO this was and still is a mistake. So, what's the problem? What could possibly blow, in case conditions would be lazily evaluated by default? Just one thing: there could be side-effects to some (sub-)condition, that possibly wouldn't be exectued any longer. And that's it.

But really: having conditions with side-effects is simply moronic in the first place, and noone should be surprised to find his code break for one reason or the other, if you code in such a way. Therefor having a clean and unique syntax is clearly the better choice, than breaking a few old scripts (that could be easily fixed - just in case anyone still needs/plays them...) that make use of bad practices.

If you can't switch to lazy evaluation behind the scenes (or optimize other things...) without breaking things, then something is messed up in the first place. Better fix this, than introducing even more confusing options in the name of "backwards compatibility". :eek:

[maddogx 13]

On the one hand I really want to agree with you, but on the other this seems more like an argument based on programmer's idealism rather than a practical, workable approach to this issue.

If you can't switch to lazy evaluation behind the scenes (or optimize other things...) without breaking things, then something is messed up in the first place. Better fix this, than introducing even more confusing options in the name of "backwards compatibility". :eek:

This sums up the problem I see with your argument - yes, something was messed up in the first place, and no, switching to lazy eval can't be done without breaking things. Changing such a central element of code interpretation now would potentially cause a lot of people's code to break - silently. If it were something that caused a syntax error, sure, any problems would be easy to track down. This kind of change though, there could be a single if-condition in a thousand lines of code that suddenly branches differently and it won't throw any errors. Such things are a bitch to troubleshoot.

At least the "confusion" introduced by my suggestion would only occur in cases where you have to read and understand some other guy's code. I expect most people would choose to either stick with the old behavior or switch to the new one entirely, so the issue should be minor one.

[Deadfast 43]

I think it's also worth pointing out that "lazy evaluation" is actually slower in most cases due to having to initialize new context for the bracketed code. In other words, don't bother trying to optimize conditions such as alive player && count _array > 0, you'll only make it worse.

:(

[rübe 127]

[...] this seems more like an argument based on programmer's idealism rather than a practical, workable approach to this issue.

It's a fine line. But really, if it's about (script) languages, then I clearly prefer a good dose of idealism/cleanliness over more "practical" or "workable" approaches in the form of ugly hacks and in the name of good ol' backwards compatibility.

Since we're talking about a script language for some game, and not about a general purpose programming language, IMHO backwards compatibility shouldn't be a K.O.-criterium as much. At least at each major switch (from arma to arma2 to arma3 ...) at bit more "risk" could be taken to clean and tidy things up a bit.

Granted, this is a very difficult topic. But overall I think BIS does a good job at maintaining their own language. They even pulled of a "Python 2 to Python 3"-stunt while going from SQS to SQF without much hassle and great success. So, I'm not too worried ;)

At least the "confusion" introduced by my suggestion would only occur in cases where you have to read and understand some other guy's code. I expect most people would choose to either stick with the old behavior or switch to the new one entirely, so the issue should be minor one.

I still don't feel comfortable about such toggles in such a context. That's not complexity you want to introduce (from a user's perspective and also from behind the scenes), you'd rather get rid of such burdens (and introduce lazy evaluation with Arma4. Bam. :D).

On a similar note, I expect that SQS-support is dropped at some point alltogether (...assuming that still works in Arma3 :p). Would that bother you?

[maddogx 13]

It's a fine line. But really, if it's about (script) languages, then I clearly prefer a good dose of idealism/cleanliness over more "practical" or "workable" approaches in the form of ugly hacks and in the name of good ol' backwards compatibility.

Since we're talking about a script language for some game, and not about a general purpose programming language, IMHO backwards compatibility shouldn't be a K.O.-criterium as much. At least at each major switch (from arma to arma2 to arma3 ...) at bit more "risk" could be taken to clean and tidy things up a bit.

Granted, this is a very difficult topic. But overall I think BIS does a good job at maintaining their own language. They even pulled of a "Python 2 to Python 3"-stunt while going from SQS to SQF without much hassle and great success. So, I'm not too worried ;)

If we're talking about changing script behavior in a new product (ARMA 4 or whatever), then there is no reason not to do it. In fact, even during the A3 Alpha or Beta I think such change would have been perfectly fine. It's just after stable release where making deep changes to the underlying platform would cause more problems than it would solve. After all, we're talking about making a change primarily for "prettier" code. Not some major new feature that would justify some code breaking here and there. :)

I still don't feel comfortable about such toggles in such a context. That's not complexity you want to introduce (from a user's perspective and also from behind the scenes), you'd rather get rid of such burdens (and introduce lazy evaluation with Arma4. Bam. :D).

On a similar note, I expect that SQS-support is dropped at some point alltogether (...assuming that still works in Arma3 :p). Would that bother you?

As far as I am aware, SQS was declared obsolete a long, long time ago. So no. ;)

[John Kozak 14]

I think potential problems in both approaches are just not worth possible speed increase. Just as in the world of C++, the code in real addons is far from ideal. Risking breaking everything because of questionable performance improvement is hardly an option. Imagine consequences of disabling lazy evaluation in C++.

And adding header switches is another bucket of worms. What if a funtion written in "lazy" file is called in "old" file? And what if vice-versa? What to do of includes?

If you worry about performance - split it up by two ifs or do as Dwarden said, really :) Such things are just too painful to change.

Edited June 23, 2014 by DarkWanderer

[Dwarden 1124]

I had talk with programmers about it

by default standard AND and OR does strict eval where all operands are evaluated

and using oper1 && {oper2} you get lazy evaulation (and that means it's short circuited)

ofcourse if something slower than it should (for two or many e.g. 10 operands then please back it up with some poc/measurements) etc.

Edited June 23, 2014 by Dwarden

[DomZ 15]

Now than it is possible to get the number of rounds in the magazines of a unit, vehicle cargo or turret, it would be useful to be able to set the number of rounds in magazines added.

If an extra optional argument was added to the commands below (and other similar commands) it would be easy to transfer round numbers accurately between objects in scripts.

vehicle addMagazineTurret [magazineName, turretPath]

vehicleName addMagazineCargo [magazineName, count]

vehicleName addMagazineCargoGlobal [magazineName, count]

could be expanded to (ammoCount optional):

vehicle addMagazineTurret [magazineName, turretPath, ammoCount]

vehicleName addMagazineCargo [magazineName, count, ammoCount]

vehicleName addMagazineCargoGlobal [magazineName, count, ammoCount]

---------- Post added 06-24-2014 at 12:06 AM ---------- Previous post was 06-23-2014 at 11:44 PM ----------

Script parameter passing

It might be possible to speed up scripts by passing their arguments by reference.

Currently multiple parameters must be passed in an array which seems to be passed by a deep copy. This must be expensive in CPU time especially when arguments contain large arrays.

An extra parameter passing mechanism might need to be added for backward compatibility.

For example a function could be called by:

{_a, _b, _c} call FunctionName;

where its parameters are declared in the script as:

parameters {byval "_Param1", byref " _Param2", byref " _Param3"};

[AgentRev 22]

vehicle addMagazineTurret [magazineName, turretPath, ammoCount]

In the meanwhile, it is possible to use "vehicle addMagazine [class, ammo]" for vehicles. However, it doesn't work with all types of magazines, for instance smoke shells and flares. It also doesn't seem to work for commander HMGs on tanks.

The only vanilla vehicle for which addMagazine shouldn't be used is the Ghost Hawk. Since the command tries to determine in which turret the magazine should be loaded based on the ammo it shoots, and it has 2 turrets shooting the same ammunition, they all end up in the left gun.

---------- Post added at 23:20 ---------- Previous post was at 23:07 ----------

Script parameter passing

It might be possible to speed up scripts by passing their arguments by reference.

Currently multiple parameters must be passed in an array which seems to be passed by a deep copy. This must be expensive in CPU time especially when arguments contain large arrays.

Also in the meanwhile again, it is possible to "emulate" passing elements by reference, by passing them inside an array, accessing the value using "select 0", and changing the value by using "set [0, ...".

It sure is a bit wacky, but it works. All arrays are always passed by reference, so as long as you change the values inside using "set", any other script accessing that array using "select" will see identical values.

It is particularly useful when you need to spawn 2 threads that must share info, without using public variables.

[DomZ 15]

The scripting commands cannot determine where you want to put your magazines. That would be too inefficient so it is better to tell them where. A get vehicle turrets function would be useful without having to write low level ones for scripters.

One variable can be passed to a subroutine by reference and altered. However, the current method is not know by most people. Parameter passing currently, is too clumsy, error prone, not documented and not used widely efficenly. Therefore, it needs super seeding, with backward compatibility supported, by an easier to use more understandable mechanism.

[AgentRev 22]

The scripting commands cannot determine where you want to put your magazines. That would be too inefficient so it is better to tell them where.

I'm not asking for it to be done, I am saying that it is the current behavior of "addMagazine" for vehicles. It allows you to add a magazine without specifying the turret, the command loads it automatically in the correct one, with minor exceptions as I mentioned. Try it, you'll see.

[noubernou 77]

Any chance we can get a unit vector command with the new vector commands too?

[xendance 3]

Any chance we can get a unit vector command with the new vector commands too?

Wouldn't that be just: vect vectorMultiply (1/(vectorMagnitude vect))

[noubernou 77]

Wouldn't that be just: vect vectorMultiply (1/(vectorMagnitude vect))

Yes, but it is an extremely common vector operation, and it'd be nice if that was fully implemented in one function instead of multiple operations in SQF which is inherently slower.

[Guest]

:) Hi !

The little nooby in scripting that I am want to increase the health of a target.

I've try this :

; target addEventHandler ["HandleDammage", {null = call fhealth}]; 

and fhealth is

_d = 0.1 + _d;

if { _d == 1 } then
{
target allowDamage true;
target setDamage 1;
}
else
{
target setDamage 0;
};

But the unit still die after one or two hits (instead of the 10 wanted).

If anyone can help me...

Edited July 1, 2014 by Guest

[Guest]

It doesn't matter, I can do without.

However, does somebody know how to launch a script when a player join ?

The objective is to create a dialog each time a player join/spawn, but the dialog will be displayed only for this player.

Thank you

[bad benson 1733]

i think this thread is more intended for dev branch related script questions, for example new commands, rather than general scripting help. you should check out the editing section. the mission and scripting section there is better suited for these kinds of questions.

however. my first guess would be the init.sqf since that runs on each client when they connect.

[AgentRev 22]

However, does somebody know how to launch a script when a player join ?

Create a file named "initPlayerServer.sqf" at the root of your mission, and there you have it.

_this select 0 = player object

_this select 1 = JIP boolean

[fn_Quiksilver 1633]

Create a file named "initPlayerServer.sqf" at the root of your mission, and there you have it.

_this select 0 = player object

_this select 1 = JIP boolean

He wants the dialog to be local for the player who joins .. That event script runs on the server when the player joins, meaning there'd have to be an existing event handler on the client and then from initplayerserver there would have to be a publicVariableClient command somewhere to make sure that client got the message.

maybe easier just to run this dialog from initplayerlocal event script.

It doesn't matter, I can do without.

However, does somebody know how to launch a script when a player join ?

The objective is to create a dialog each time a player join/spawn, but the dialog will be displayed only for this player.

Thank you

[noubernou 77]

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

Seriously it'd take a whole 2-3 minutes (AT MOST) to do this.

[mr_centipede 31]

May I bring your attention to this issue:

Deleting all waypoint using 'deleteWaypoint' command doesn't work as expected

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

Description is in the ticket