Scripting Discussion (dev branch)

[SilentSpike 84]

Just hopefully bringing some more attention to two of my scripting related tickets from a few months ago:

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

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

The missing toolbox commands are only really going to be useful to people working with dialogs, but I'm sure loads of people would find a new setVisibleGPS command useful.

[das attorney 858]

Doing a bit of testing and it appears the allGroups command is local; that is to say, it can only detect groups if the group is local to the machine running the command.

So if you spawn some groups on a HC and check on the server, it won't return those groups.

It just seems odd that you would have a command to return all the groups created, but it won't detect non-local groups.

Can anyone else confirm? If so, I'll make a ticket and see if BIS can/want to change it.

[chronicsilence 13]

No problem, tweaked it a bit to account that getPos and it's counterparts actually return ASLW heights instead of ASL when water is the factor. Hence the disparity in Feints heights between ASL and getPos variants.

I haven't heard about that, but the simulation and rendering should be separate anyway, I currently have no reason to believe they're tied, even tho time acceleration does result in some questionable behavior.

I'm not 100% sure what I'm about to say is correct, but this is how I currently think it is:

"Render time" is updated on a very high frequency (each frame), it's responsible for things you see on the screen, where things visually appear to you.

"Simulation time" is updated on a lower frequency than frames, and then the changes between two simulation "ticks" are interpolated visually on your screen.

So let's say first tick of "Simulation time" says a bullet is at [0,0,0] and the next calculates that the bullet is at [0,0,1]. Between two simulation ticks, let's say 10 frames have elapsed.

In those 10 frames, the "render time" commands will return [0,0,0.1] on the first frame, [0,0,0.2] on the second and so on.

If you position, let's say an icon, on each of those frames according to the "simulation time" commands results, that position will be on [0,0,0] on all the frames until the next "simulation" tick happens. While going by the results of the "render time" you will have correct visual updates at all times.

The difference between the two only matters when something is changing positions and it becomes more obvious the faster that something moves.

Additionally, probably irrelevant to all this, simulation probably runs at a fixed rate, while the render is dependent on how fast your system can push frames. When you change the time acceleration in editor in SP, either the rate of simulation updates increases or they multiply the delta time each frame receives.

When the simulation is tied to the rendering, you get the problems of the old games where if you have a good computer the game will play at an accelerated rate. A good and a hilarious demonstration of this oversight in recent times is in NFS Rivals, observe what happens

when he unlocks the FPS limiter.

So this brings up an interesting point. Using render time is excellent for drawing 3D icons or lines, and updates smoothly with vehicles moving at high speeds. However, is there a way to force something in the simulation to happen at render speed? For example, I have a #lightpoint object that I would like to attach to my vehicle. Under normal cirumstances using lightAttachObject, the light jitters and bounces around because it's only updating with simulation time whereas the vehicle's position is updating at render time. Even if I force it to update the lightpoint's position using modelToWorldVisual and onEachFrame, it doesn't help because it still doesn't update it's position until the next simulation step. What we need is a way to force something in simulation to happen at render time (like a "drawObject3D" function), because I really need these lights to update their positions as smoothly as 3D icons do.

[killzone_kid 1330]

Doing a bit of testing and it appears the allGroups command is local; that is to say, it can only detect groups if the group is local to the machine running the command.

So if you spawn some groups on a HC and check on the server, it won't return those groups.

It just seems odd that you would have a command to return all the groups created, but it won't detect non-local groups.

Can anyone else confirm? If so, I'll make a ticket and see if BIS can/want to change it.

Haven't checked myself, but could this be HC related? (saw your video with AI targeting on HC)

---------- Post added at 20:46 ---------- Previous post was at 20:43 ----------

So this brings up an interesting point. Using render time is excellent for drawing 3D icons or lines, and updates smoothly with vehicles moving at high speeds. However, is there a way to force something in the simulation to happen at render speed? For example, I have a #lightpoint object that I would like to attach to my vehicle. Under normal cirumstances using lightAttachObject, the light jitters and bounces around because it's only updating with simulation time whereas the vehicle's position is updating at render time. Even if I force it to update the lightpoint's position using modelToWorldVisual and onEachFrame, it doesn't help because it still doesn't update it's position until the next simulation step. What we need is a way to force something in simulation to happen at render time (like a "drawObject3D" function), because I really need these lights to update their positions as smoothly as 3D icons do.

There was a ticket on FT about attached light jittering, developer replied and said this is how it is, something to do with how the light is simulated.

EDIT: there http://feedback.arma3.com/view.php?id=18337

[chronicsilence 13]

There was a ticket on FT about attached light jittering, developer replied and said this is how it is, something to do with how the light is simulated.

EDIT: there http://feedback.arma3.com/view.php?id=18337

My understanding was that the developers weren't going to make it so that attached lights updated every render frame by default. However, I would think that there should still be a way to force something to update on the render frame since it's obviously done that way with vehicle headlights.

Edited November 8, 2014 by ChronicSilence

[gossamersolid 155]

I've been experiencing a rather annoying issue with onPlayerDisconnected (either directly called or via the stackedEH).

It seems that sometimes it plain old doesn't fire at all, then it causes a massive amount of issues for me. Does disabledAI (in the description.ext) have to be set to 0 for this to fire reliably (I have mine set to 1 as I didn't want empty player slots sitting around on the map).

[killzone_kid 1330]

I've been experiencing a rather annoying issue with onPlayerDisconnected (either directly called or via the stackedEH).

It seems that sometimes it plain old doesn't fire at all, then it causes a massive amount of issues for me. Does disabledAI (in the description.ext) have to be set to 0 for this to fire reliably (I have mine set to 1 as I didn't want empty player slots sitting around on the map).

Personally have never heard of onPlayerDisconnected fail. You can try HandleDisconnect event handler instead and see if it does the job better.

[gossamersolid 155]

Personally have never heard of onPlayerDisconnected fail. You can try HandleDisconnect event handler instead and see if it does the job better.

I'm going to try disableAI=0 and see if that helps. If that doesn't help, I'll try the HandleDisconnect EH.

[killzone_kid 1330]

I'm going to try disableAI=0 and see if that helps. If that doesn't help, I'll try the HandleDisconnect EH.

It is disabledAI and I doubt this is the reason.

[gossamersolid 155]

It is disabledAI and I doubt this is the reason.

Still had problems today, I'll test out the handleDisconnect EH, see if that deals with the issue.

[killzone_kid 1330]

https://community.bistudio.com/wiki/getObjectDLC should return -1 if object is vanilla but not nil.

[noubernou 77]

With the new commands in the dev branch for getting all namespace variables, could we get the ability to create our own namespaces as well, plus a namespace operator for variables (using :: preferably since that seems to be the most common in languages)?

Would be nice to not have to use hard coded prefixing and macros anymore for a lot of stuff. It would make SQF much cleaner and make the language itself feel much more mature.

[Tonci87 163]

Can someone poke Iceman to look into this here?

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

The new JSRS is closer to release each day but this stuff needs to be implemented first!

[-PzGrenBrig37-commy2 10]

I'm having an issue with setVariable. Even though I use setVariable on a soldier with the third paramter set on true, the value is not always restored on JIP. If the unit respawns after the value is set and I then join the server, the value is lost for the JIP client.

If the unit doesn't respawn everything works fine. Even if the unit respawned once before the value is there after JIP. This only happens if the unit respawns after the setVariable was executed (on the client) and I then reconnect.

I never observed this behaviour prior to v1.36. Is this a bug or am I missing something? Can anyone confirm this?

[SilentSpike 84]

That's because it's not the same object

[-PzGrenBrig37-commy2 10]

But the value gets restored after respawn. And it is there after JIP, unless the unit respawns once. That makes absolutely no sense to me.

Was this the case prior to 1.36?

[killzone_kid 1330]

commy2;2840487']But the value gets restored after respawn. And it is there after JIP' date=' unless the unit respawns once. That makes absolutely no sense to me.

Was this the case prior to 1.36?[/quote']

The variable will be on previous body on JIP not on the new body.

[-PzGrenBrig37-commy2 10]

The variable will be on previous body on JIP not on the new body.

Is that documented anywhere? What would be the best work-around? Reseting all variables via respawn eh?

[esteldunedain 10]

The variable will be on previous body on JIP not on the new body.

Summarizing, the unit variables are on the dead body, but they are also copied to the new body on respawn. The issue is that this copy seems not be JIP compatible, while the values on the dead body are.

Edited December 17, 2014 by esteldunedain

[pabstmirror 34]

Here's a video of it in action:

for debug: player1 constantly copies it's value of "test" into "selftest"

To reproduce:

1. player1 setVariable ["test', 11, true];

2. player 2 JIPs in

3. Kill player1

4. player 2 JIPs in

5. Kill player1

6. Player 1 sees "test" as 11, JIP does not

player1 and the JIP see different values for getVariable "test" on the same object even though it was set globaly

[killzone_kid 1330]

Added: Code performance button for the pause menu debug console. Allows checking how expensive the code in the Expression field is.

current default value is 10000 iterations. I suggest 1000 for gui button, because 5ms code will take 50 seconds and there is no way to abort. For more precise measurement there is always bis fnc codeperformance.

[Dwarden 1125]

+ scripting news/dedi<>HC related:

Major change on horizon for AI locality changes (in relation to HC transits)

from 1.40 onward the 'setOwner' cease work with AI entity (will work only with non-AI object)

new command 'setGroupOwner is added for AI groups

(syntax is same as setOwner just the param is group instead of object)

note: locality transfers only if leader isn't player

[bumgie 49]

+ scripting news/dedi<>HC related:

Major change on horizon for AI locality changes (in relation to HC transits)

from 1.40 onward the 'setOwner' cease work with AI entity (will work only with non-AI object)

new command 'setGroupOwner is added for AI groups

(syntax is same as setOwner just the param is group instead of object)

note: locality transfers only if leader isn't player

Will it keep waypoints that are already assigned for the group?

[das attorney 858]

+ scripting news/dedi<>HC related:

Major change on horizon for AI locality changes (in relation to HC transits)

from 1.40 onward the 'setOwner' cease work with AI entity (will work only with non-AI object)

new command 'setGroupOwner is added for AI groups

(syntax is same as setOwner just the param is group instead of object)

note: locality transfers only if leader isn't player

Also, can you also implement groupOwner or similar command? (or update owner to work with groups) At the moment, you can only query if the group is local, not who owns it if it isn't local (without spamming all machines to find it).

Additionally, is it possible to come up with deleteGroupGlobal command? (as deleteGroup only works for local groups).

edit: excellent news btw :)

[Dwarden 1125]

yes, that's the point of those changes to ensure the locality transfer is done right for AI including linked brain, statuses w/e ;)

---------- Post added at 14:26 ---------- Previous post was at 14:24 ----------

Also, can you also implement groupOwner or similar command? (or update owner to work with groups) At the moment, you can only query if the group is local, not who owns it if it isn't local (without spamming all machines to find it).

Additionally, is it possible to come up with deleteGroupGlobal command? (as deleteGroup only works for local groups).

edit: excellent news btw :)

"owner leader" is equal to "groupOwner"