Scripting Discussion (dev branch)

[R3vo 2652]

As a total programming noob, could someone explain me what's the use of those bitwise functions in layman terms?

[Sniperwolf572 758]

I can't think of any actual practical use in Arma other than for bitflags that they added.

Bitflags is basically useful if you need to pack a bunch of boolean properties. Bitflags are used for certain things in Arma configs like AIAmmoUsageFlags or weaponLockSystem.
Imagine you have 3 booleans to describe an animal. Let's say canFly, canSwim, canWalk. Each of those can be represented as a 0 or 1.

Binary  Decimal        Description
000     0              Can't do anything
001     1              Can fly
010     2              Can swim
100     4              Can walk
110     6 (2 + 4)      Can swim and walk but not fly
111     7 (1 + 2 + 4)  Can do all

So instead of having canFly = true, canWalk = true, etc., you pack them into a single int which you can read from.
So knowing that, you can use BIS_fnc_bitflagsCheck to see if the AI will use some ammo against air targets:

private flags = getNumber (configFile >> "CfgAmmo" >> "MyAmmo" >> "aiAmmoUsageFlags");
private aiCanTargetAir = [flags, 256] call BIS_fnc_bitflagsCheck;

[R3vo 2652]

 

I can't think of any actual practical use in Arma other than for bitflags that they added.

Bitflags is basically useful if you need to pack a bunch of boolean properties. Bitflags are used for certain things in Arma configs like AIAmmoUsageFlags or weaponLockSystem.

Imagine you have 3 booleans to describe an animal. Let's say canFly, canSwim, canWalk. Each of those can be represented as a 0 or 1.

Binary  Decimal        Description
000     0              Can't do anything
001     1              Can fly
010     2              Can swim
100     4              Can walk
110     6 (2 + 4)      Can swim and walk but not fly
111     7 (1 + 2 + 4)  Can do all

So instead of having canFly = true, canWalk = true, etc., you pack them into a single int which you can read from.

So knowing that, you can use BIS_fnc_bitflagsCheck to see if the AI will use some ammo against air targets:

private flags = getNumber (configFile >> "CfgAmmo" >> "MyAmmo" >> "aiAmmoUsageFlags");
private aiCanTargetAir = [flags, 256] call BIS_fnc_bitflagsCheck;

 

Thanks, that's a good explanation.

[ceeeb 147]

Bitwise operations in other languages are very fast, hopefully these functions perform well compared to other methods already available in Arma.

If not, at least they provide a familiar set of basic functions for people with general programming experience.

 

I cobbled together my own set of bitwise and bitshift functions (using arrays of booleans rather than numbers) to create an encryption/random number generator function in Arma. Functions like this are obviously not very useful to most users, but they also aren't possible without bitwise functions.

[R3vo 2652]

Can anyone confirm that the UGV example on this page doesn't fully work anymore?

 

https://community.bistudio.com/wiki/animateSource

 

For me, only show/hide turret works, left/right/up/down has no effect.

[killzone_kid 1326]

Can anyone confirm that the UGV example on this page doesn't fully work anymore?

 

https://community.bistudio.com/wiki/animateSource

 

For me, only show/hide turret works, left/right/up/down has no effect.

Works for me, todays dev

[R3vo 2652]

Works for me, todays dev

 

It only seems to work when I create the vehicle first with createVehicle, but not when I place the UGV and name it ugv in the editor.

[reyhard 2082]

It only seems to work when I create the vehicle first with createVehicle, but not when I place the UGV and name it ugv in the editor.

did you selected turret less ugv? that command doesn't override turret sources

[R3vo 2652]

did you selected turret less ugv? that command doesn't override turret sources

No, I used the one with the turret ;)

[killzone_kid 1326]

It only seems to work when I create the vehicle first with createVehicle, but not when I place the UGV and name it ugv in the editor.

That is what you asked, that is what I answered

[.kju 3239]

documentation also for these please

 

 

b:OBJECT triggerdynamicsimulation BOOL

b:STRING setdynamicsimulationdistancemult SCALAR

u:cantriggerdynamicsimulation OBJECT

u:dynamicsimulationdistancemult STRING

[Tom_48_97 523]

 

documentation also for these please

 

 

b:OBJECT triggerdynamicsimulation BOOL

b:STRING setdynamicsimulationdistancemult SCALAR

u:cantriggerdynamicsimulation OBJECT

u:dynamicsimulationdistancemult STRING

 

The dynamic simulation is still work in progress and will be documented in a batch ;)

[R3vo 2652]

The dynamic simulation is still work in progress and will be documented in a batch ;)

 

Any update on the Pixel Grid System examples? ;)

[.kju 3239]

can we get an engine solution for remoteControl of units please finally.

it is super ugly design having to replace every "player" use with "(missionNamespace getVariable ["bis_fnc_moduleRemoteControl_unit",player])"  <_<

 

defined in .\a3\modules_f_curator\Misc\Functions\fn_moduleRemoteControl.sqf

 

seems with locality in MP this can get even more ugly..

 

 

remoteControl should have behave as selectPlayer in so far as the "player" variable points the currently controlled unit.

However changing this now would wreak too many scripts.. as such fn_moduleRemoteControl.sqf should be rewritten to use selectPlayer (probably too complicated), so instead a new sqf cmd introduced based on remoteControl showing the desired behavior, or remoteControl another signature added: "who remoteControl[whom,isPlayerVariableUpdated]"

[Sniperwolf572 758]

can we get an engine solution for remoteControl of units please finally.

it is super ugly design having to replace every "player" use with "(missionNamespace getVariable ["bis_fnc_moduleRemoteControl_unit",player])"  <_<

 

defined in .\a3\modules_f_curator\Misc\Functions\fn_moduleRemoteControl.sqf

 

seems with locality in MP this can get even more ugly..

 

 

remoteControl should have behave as selectPlayer in so far as the "player" variable points the currently controlled unit.

However changing this now would wreak too many scripts.. as such fn_moduleRemoteControl.sqf should be rewritten to use selectPlayer (probably too complicated), so instead a new sqf cmd introduced based on remoteControl showing the desired behavior, or remoteControl another signature added: "who remoteControl[whom,isPlayerVariableUpdated]"

 

While I agree it's shitty to do the whole getVariable dance in that case, but if anything, player command shouldn't be touched for what it does. There are many things that depend on player actually belonging to the context of "you" belonging  to the player unit. Switching units with selectPlayer actually switches your "you" player context in a very meaningful way which should absolutely not be used for remote control.

 

Simplest example is if you selectPlayer something, and the old unit dies, you do not expect to see a death screen. While remote controlling, it's the opposite. If remoteControl behaved as selectPlayer in that case, theoretically you could continue remote controlling something when your original unit is dead. And then you'd have to account for such cases, and who should be the one accounting for it, etc.There are so many similar problems for such a thing.

 

This would be much better solved with a new command, which was tailored for the problem, which returned the Man/Logic that the player is actually currently controlling, something like cameraOn, maybe controlsOn, whatever. 

cameraOn also shows the specific problem that I'm talking about. Yes, you are controlling the vehicle you are the driver of, and the camera is attached to the vehicle, but contextually, "you" is still the unit inside of it.

 

Writing a macro for the thing you want after that is a trivial thing.

[commy2 188]

Was planned years ago and even appeared in a changelog. Never happened though.

https://github.com/KoffeinFlummi/AGM/issues/327#issuecomment-48922880

[killzone_kid 1326]

playerControlled was added and removed because it was duplicating existing functionality. If I remember correctly you could get the same results with cameraOn.

[commy2 188]

That's wrong though. cameraOn will report the vehicle your remote controlled unit is inside.

 

It's not the same as:

missionNamespace getVariable ["bis_fnc_moduleRemoteControl_unit", player]

[.kju 3239]

I don't consider rewriting all scripts to work with remoteControl acceptable.

At the same time players expects Zeus and other systems to work always.

 

I can't see why you would, from a technical side, expect the mission to end when using remoteControl.

If this should happen, you can easily script it.

However flipping the logic and forcing everyone to change the default logic is unacceptable IMHO.

 

PS: remoteControl should not be considered just steering an UAV or something. However even just for that

its to be expected that this is the player entity while the player has control.

 

If something to the actual player unit happens in the meantime, you can again easily script the desired behavior.

 

PSS: If you don't want to change remoteControl, introduced a new version as suggested and adjust the Zeus scripting.

 

[killzone_kid 1326]

That's wrong though.

Wrong? Wrong it was removed? I don't think so. Wrong it was duplicating functionality? This is why it was removed.

[commy2 188]

Wrong? Wrong it was removed? I don't think so. Wrong it was duplicating functionality? This is why it was removed.

 

You said:

>playerControlled was added and removed because it was duplicating existing functionality. If I remember correctly you could get the same results with cameraOn.

 

But the changelog says:

>Arma 3 1.24: New command playerControlled (like the player command, but it will return the remote-controlled unit)

 

"cameraOn" is not the same as this "playerControlled", because "cameraOn" does not report the remote-controlled unit (if it's inside a vehicle).

But you said it was removed because it would be the same.

Something is wrong here. And actually having "playerControlled" would be usefull, although not perfect as kju described.

[Sniperwolf572 758]

I don't consider rewriting all scripts to work with remoteControl acceptable.

At the same time players expects Zeus and other systems to work always.

 

I can't see why you would, from a technical side, expect the mission to end when using remoteControl.

If this should happen, you can easily script it.

However flipping the logic and forcing everyone to change the default logic is unacceptable IMHO.

 

If this is aimed at my comment, I'm not sure you understood what I meant. I don't expect the mission to end when using remoteControl.

 

This is how I expect the system to work:

• player - The "man" unit the player contextually is (working as intended)
• selectPlayer - Change the player context (working as intended)
• playerControlled - Whatever "man" unit the players controls are bound to (missing, necessary, should not behave the same as cameraOn)
• remoteControl - Change the control context, in turn changing playerControlled (working as intended, minus playerControlled not existing)
• cameraOn - Whatever the camera is attached to (working as intended, but is not what playerControlled should be)

The problem with cameraOn is:

// Situation: player is driving a vehicle
cameraOn === player // returns false
cameraOn === vehicle player // returns true

Which is what commy2 is saying.

 

Just because you are remote controlling a different unit, the context of "you" that the player provides should not change. If you truly wish to switch the player context, selectPlayer is already something that exists.

Zeus remote controlling an AI soldier, a soldier remote controlling a UAV pilot, and anything remote controlling anything, should not change the context of "player" away from his actual unit, just the playerControlled.

That's why it's called remote control in the first place, because you are remotely controlling something, not because you have become something. It's why it was implemented and why it exists even though selectPlayer existed for a long time before.

selectPlayer on the other hand should change the context of player, which clearly indicates that you, indeed, have become somthing else.

 

By leaving things as they are, and introducing playerControlled, you have full control of what you actually want to happen and the behavior is well and truly defined. There is no room for ambiguity.

• "player setDamage 1" - The simplest problem you have with changing player. I wanted to kill the player there. Not the UAV pilot they're in control of, not their remote controlled body.
• "playerControlled setDamage 1" - I wanted to kill either the player or their remote controlled unit. In reality, this would rarely be what anyone would want to do.
• "player === playerControlled" - Gives me the information if the player is having an out of body experience (remote controlling something).
• "if (player != playerControlled) then { playerControlled setDamage 1}" - Is a clear and fully reasonable code that I wanted to kill the players remote controlled unit (be it UAV or anything else) and not the player himself.

And so on. Just switching the player mindlessly to whatever he is in control of will cause many more problems than it will solve, especially with all the existing scripts.

 

To me, in an insane example, arguing that player should change to remoteControlled unit is like arguing that when you control an RC car in real life, your consciousness should move to the RC car.

 

TLDR: playerControlled is absolutely necessary, cameraOn is not a solution, player should stay as is.

 

@commy: Can you clarify why you think changing player instead of adding playerControlled is better?

 

@killzone_kid: If cameraOn === playerControlled at all times, then that's a problem with playerControlled or cameraOn not doing what it should do, not an argument that playerControlled shouldn't exist.

[commy2 188]

@commy: Can you clarify why you think changing player instead of adding playerControlled is better?

I have no strong opinions about this. I would be fine with either one. Would be easier if everything that uses "player" worked out of the box, but I guess changing it now would cause a myriad of other issues.

[SilentSpike 84]

Just to add, I'm pretty sure `switchCamera` will change the value of `cameraOn`, so it's not necessarily even the unit being used with `remoteControl`

[Sniperwolf572 758]

I have no strong opinions about this. I would be fine with either one. Would be easier if everything that uses "player" worked out of the box, but I guess changing it now would cause a myriad of other issues.

Ok, but the bold part is not clear to me. Why do you think client "identity" and client "control" should be combined into a single "player" variable? What is not working out of the box?

 

Even if we were at step zero and started from scratch, to me it would still make much more sense to have "player" return the "identity" of the client, while something like "playerControlled" returned the control of the client.