New ArmA Scripting commands

[lwlooz 0]

Well sure,but I can't see how using a "setVehicleInit"-hack to get stuff around the network is any different from using a "createUnit"-hack these days. If you had specific official functions to go like "Activate my.sqf on PlayerY,PlayerZ pc" and similiar stuff that would ease MP-scripting a lot. I mean, even tho CoC NS is one of the best additions to OFP ever,who uses it? Almost noone

[UNN 0]

As to why BIS did or didn't add particular commands, you will probably have to ask them directly. I have my theories, but there are enough of those kicking about, without adding more.

I took this threads title literally "New ArmA Scripting commands: Discuss". Not to be confused with the next generation PC game's thread,  "Requests for new functionality".

[mr.peanut 1]

Any word on whether the publicVariable command has been fixed?

Also, to repeat myself, it seems like a serious oversight not to have a function to query what a group's present and past waypoint are.

[mr.peanut 1]

A few interviews and media releases and this thread sinks like a stone. How typically superficial.

[Scrub 0]

We're just eager to actually get our hands on it and see what is ACTUALLY there. Is that so wrong?

[UNN 0]

Quote[/b] ]Any word on whether the publicVariable command has been fixed?

Was it broken?

Quote[/b] ]Also, to repeat myself, it seems like a serious oversight not to have a function to query what a group's present and past waypoint are.

I thought you could already with waypointPosition, although I never actually got round to trying it. I assumed you could store each position for reference, when the mission starts.

Quote[/b] ]A few interviews and media releases and this thread sinks like a stone. How typically superficial.

There is not much more, for us lot to discuss. Once we list our favourite new commands and what we think might be possible with them.

[Lou Montana 101]

About the "PublicVariable" question, I would like to see PublicVariable for arrays and strings !

Maybe it's what he noticed as "broken"...

[UNN 0]

It was never supposed to support string or arrays, so that does not make it broken in my book

There are certainly issues with arrays and how they are referenced in memory. That might prevent them from including support in MP.

The power of arrays also lies in how they are referenced in memory, not just the ability to group data together. Perhaps it's not arrays you should be asking for, but multiple parameters for the publicvariable command.

I'm sure there are other issues as well. Let's face it, enough people have brought the topic up so many times over the years. It's not like they are not aware of peoples wants.

[Garcia 0]

Umm, seeing that CoC managed to make it possible to PV arrays, shouldn't BIS also find a way? Of course CoC got some funky workaround, but BIS could at least do a similar workaround so you don't need a addon/lots of scripts to PV arrays.

[UNN 0]

Aren't we are just covering the same old ground again? Anyway, another new command I was glad to see added:

animationState

I might actualy get one of my old addons, into an almost fit state now. I just hope I can also get the AI to point it's binoculars, up and down aswell. Instead of always pointing straight forward.

[Blanco 0]

I read an Hongarian interview where Placebo said there are 776 commands atm, that's 400 commands more then 1.96. So I guess the reference in the wiki is far from complete.

[mr.peanut 1]

publicVariable is broken in the sense that it is not always reliable.  Read through this thread to see what I mean by "broken". This is a far more serious problem to my mind than not being able to send (character) arrays.

When I talk about querying a waypoint I mean being able to check which waypoint index is active for a group.

[UNN 0]

Quote[/b] ]publicVariable is broken in the sense that it is not always reliable.  Read through this thread to see what I mean by "broken".  This is a far more serious problem to my mind than not being able to send (character) arrays.

Yes, I already posted in that thread. I take it the issues both Crashdome and myself raised, did not help?

Quote[/b] ]When I talk about querying a waypoint I mean being able to check which waypoint index is active for a group.

Yeah, thats what I thought. I did plan on trying to use deduction based on current pos and the list of waypoint positions. But thats far from ideal. Perhaps the new formationTask might provide the answer?

[crashdome 3]

publicVariable works as designed. Suma has said (can't find source right now) that it is unreliable by design. I can understand why too.. it isn't really broken.

By design it is meant to broadcast something that updates frequently and where history is not needed. For example: You have a levitation script which allows a player to levitate. You handle locally to player the function which detemines the positional data (x,y,z integers) of the player as he levitates around. By triggering a script to position the player using three globals (x,y,z) and calling pV from the original client every 0.5 secs you can give the illusion that the player is floating around on all the other client machines. If packets drop and a client misses it a few times.. oh well.. no loss we just wait for the next packet of positional data.

What is the real problem is a lack of true system to send guaranteed data like arrays and properties. Even BI might disagree with my suggestion to not use pV to handle such data. I came to understand by everyone's suggestion in the BI wiki that they wish to expand pV to fit this data but leave it remain non-guaranteed. That is fine. It is merely just another engine limitation.

This Talk page is a good discussion about that very topic..

Ref: http://community.bistudio.com/wiki/Talk:setVariable

I agree with you, Peanut. There needs to be a command to sync some basic data. I've seen other games handle this concept without much problem. However, everyone seems to think pV is the key and I say pV is fine as it is... we just need something new.

[suma 8]

publicVariable works as designed. Suma has said (can't find source right now) that it is unreliable by design. I can understand why too.. it isn't really broken.

I really doubt I would say that, you probably misread the Wiki pages you mentioned? Message sent by publicVariable is guaranteed and it is always sent to all other players, while normal game state updates (positions, animation etc) are non-guaranteed and sent only as needed. Because of this publicVariable can exhaust bandwidth when used extensively. What I suggested is to have a way which would enable to build custom scripted objects which could be synchronized the same way as normal game objects do.

The ability of publicVariable to send strings and arrays is quite high on our list of improvements desired for ArmA scripting.

[Lou Montana 101]

The ability of publicVariable to send strings and arrays is quite high on our list of improvements desired for ArmA scripting.

Yipeee ! Hurraay !

I dreamed about that    

Now some of my missions are possible !

[mr.peanut 1]

Message sent by publicVariable is guaranteed ...

How can it be guaranteed when we have all experienced situations where packet loss causes it to fail? Recently I have started double PV'ing critical variables (especially those sent near the mission start), with a tiny pause in-between, which seems to work reliably.

One of the major uses of PV is to guarantee that eventhandlers, and triggers with sensitive conditions, synch properly.  An option to set trigger/waypoint activation locality would be a good idea?

[dinger 1]

Bah. I've never had trouble with PVs not synching. And I like to think I know something about it.

Your problem sounds like you're PVing before the game synchs. If you want to PV in an init.sqs, or anywhere else, send it after mission start. The way to force this is

~.0001

Otherwise, it will transmit before synchronisation.

Oh yeah, and if you've got PVs failing in mission other than that, you have bigger problems to worry about.

[crashdome 3]

publicVariable works as designed. Suma has said (can't find source right now) that it is unreliable by design. I can understand why too.. it isn't really broken.

I really doubt I would say that, you probably misread the Wiki pages you mentioned? Message sent by publicVariable is guaranteed and it is always sent to all other players, while normal game state updates (positions, animation etc) are non-guaranteed and sent only as needed. Because of this publicVariable can exhaust bandwidth when used extensively. What I suggested is to have a way which would enable to build custom scripted objects which could be synchronized the same way as normal game objects do.

The ability of publicVariable to send strings and arrays is quite high on our list of improvements desired for ArmA scripting.

Actually I was refering to a thread that is probably 3-4 years dead. I very well could be wrong in what I am stating, but it certainly was the impression I got 3-4 years ago. I'm not perfect with my memory and I admit if anyone would know how it truly works, it would be you. So if you say it is guaranteed, I believe you.. but I also believe my own experiences. I have experienced what appears to be random and frequent loss of data during pV broadcasts.

@Dinger

Just because you haven't experienced any difficulties doesn't mean it can't or doesn't happen. I can reproduce unreliable pV very easily, and yes it happens after briefing. The irony is that I experience more unreliability of pV once CoC_NS has been loaded (latest ver). It is also not related to 'abusive' code unless your meaning of 'abusive code' means everything that is code that you personally wouldn't do. I can experience this unreliability with even the simplest of pV calls. It is possible it is related to hardware or even net traffic in general, but truly it does happen otherwise Mr. Peanut and I wouldn't be so strongly motivated to voice our opinion.

[deanosbeano 0]

Quote[/b] ]How can it be guaranteed when we have all experienced situations where packet loss causes it to fail?

i think therewithin lies part ofyour problem , having played on the LOL server manytimes myself,i noticed the server itself in even times of basic missions ,suffers considerable lag and or desync.i think in order to help solve your problem ,you would have far greater result in trying on a more stable server.i am also not talking ping which is at times 16ms it is the bandwidth ? here is stop because my knowledge does .

just my two cents.

[dinger 1]

Crash -- no of course I'm not calling "abusive" anything I wouldn't do.

there's a lot of things I wouldn't do because I'm too lazy or not interested in.

And I do things that are abusive too, from time to time.

And, sure CoC_NS isn't a silver bullet. I don't use RemoteCall for artillery fuzing, for example, because it doesn't give me the bandwidth or response I need. So I write my own transport, and it's one that can be much more abusive.

But what I am trying to say, is that when I have PV break, a lot of other things are breaking too. For example, the OFP environment reacts much differently when someone with a ping >300 (well, >200, but we'll give some slop) is in game, as the whole MP system starts to break down. This "breakage" is not always noticeable until we start doing a lot of things that require these handshakes. then the packets pile up, get lost, and things go awry. Suddenly bullets aren't flying any more, people can't get into vehicles, then suddenly die when they're shot five minutes before, and in short, all network hell breaks lose.

Still, I'm curious about other "breakage" scenarios, since we all need to use PV or some variation on it quite regularly.

[mr.peanut 1]

Bah. I've never had trouble with PVs not synching. And I like to think I know something about it.

Your problem sounds like you're PVing before the game synchs. If you want to PV in an init.sqs, or anywhere else, send it after mission start. The way to force this is

~.0001

Otherwise, it will transmit before synchronisation.

Oh yeah, and if you've got PVs failing in mission other than that, you have bigger problems to worry about.

This thread is drifting quite far away from its topic, but I need to get my last 2 cents in. I was not PV'ing from the init.sqs but in a script called from there. If I understand correctly, all scripts called from the init.sqs will not execute until the mission starts and will in fact pause execution of the rest of the init.sqs until the mission starts.  The thread I linked to earlier has the full details.  The script almost never worked.

When I moved this script to be called from a trigger that activated as soon as the mission started, it would work about 50% of the time. It was only sending about 5 values. When I made the script PV the same values 3 times with a 0.5 second pause in between it worked every time. Nobody expects a game to run 100%, but pings/bandwidths of 200/50 are still common.  Triggers that have sensitive conditions (e.g. a side present trigger with a small area) are also susceptible to packet loss/desynch failures.  Mission makers should not have to double trigger mission-critical conditions, nor multiply PV mission-critical variables. MP debugging is challenging enough without these difficulties.

[dinger 1]

actually, any scripts called from init.sqs without a ~ pause will execute immediately, and therefore pre-sync.

So at the very least, put ~.00001

if you wonder about this, put in some debugs to your current mission: a player sidechat "HELLO WORLD" right before you PV stuff, and see when things go. You and I can pontificate about who's right all we want, but _evidence_ really shuts people up.

As for the further problems -- I can't honestly say I know the answer. "It's worked for me" is what I usually say. But when transmitting stuff, I try to load up a few datagrams at a time: if you PV stuff at the same time, it tries to go out at the same time. Since in the absence of a >200 ping, OFP seems to sync at 5 Hz, I find (after a ~(random 1)) one-second spacing to be nice and conservative. Such systems send hundreds of PVs without problems (we've tried to break it).

Triggers and the rest are probably in the same boat. Triggers with their condition set to "TRUE" fire once every half-second or so: plenty of time for things to drift in and out of sync: someone could walk/drive/through a small trigger on one client, and not through another. Even with a condition other than "TRUE", and the trigger firing every frame, you could still get things mixed up, as the position updates only come through 5 times a second: so while locally someone may appear to walk through a space (and fire the trigger), on other machines, he'll appear on one side, then on the other.

These are getting to the level of limitations of the network.

It's true that the reality portrayed on any client is different from the reality anywhere is in the world. This is only a problem for ontological realists.

[crashdome 3]

Quote[/b] ]Crash -- no of course I'm not...

I am seeing your point fully now.

In a round-about way, I guess what I am trying to suggest that your points might be the reason to incorporate a top-level system like CoC_NS.

In all honesty, I believe what you are saying can help explain the failures we have probably 100% of the time.. but to exaggerate a little, does the average MP mission maker/scriptor need to have a PhD in scripting to use pV properly? IMO, there should exist a top-level system which works and manages bandwidth properly to alleviate the mission maker from having to worry about all that. You send the function what you want to show up on specific or all clients and the system will address it according to low-level standards and guarantee the data. If a scriptor needs/wants low-level (as you cited in the fuzing example) you can use the existing pV command - no need to modify it necessarily (although I'm not saying adding string support is bad). If someone abuses the top-level system than that is an education lesson learned: Don't abuse the system or your mission/addon will be crap.

Also, I might be the one that suggested to Mr. Peanut the script calling before briefing might be an issue. From what I've seen, I could never get an sqs to execute properly during the pre-briefing stage. Only sqf's via "call...loadfile" worked for me. That is my opinion though and not based on a battery of tests or anything.....I have some evidence but it is by no means scientific. It could merely be something within my sqs itself causing an issue. However, I do try and suggest only using sqf's during pre-briefing stage for consistancy and safety because it is executed fully and not line-by-line. Your sqs could very well only be half finished by the time briefing starts in which case it will halt until game start.

Quote[/b] ]Such systems send hundreds of PVs without problems (we've tried to break it).

True, once I added a ~1 delay between sends of my pV in SOW v1 (pre-CoC_NS) the problems mainly disappeared - only resurfacing if ping was high (which cannot be known! and must be expected!. However, the 1 sec delay thus guaranteed a 2-5min wait before mission start while all values were sent. It made the mission completely unplayable and restarts not an option. CoC_NS cut it down to 20secs and required less code in my mission. You might argue for optimization in theory, but in real-life I will take CoC_NS over pV any day. I could care less if it is less optimal.. it is less of a headache.

[mr.peanut 1]

@HumDinger - not sure if your tone is deliberately pejorative or not.

{edit:allusion to violence, 3M adhesives  and choo-choo posteriors deleted}

You mean:{publicVariable "_x"} forEach [...] ? I did this. BTW, even with a small pause at the script start, it still failed most of the time

I have also had problems with desync breaking unit init called scripts, scripts that are as simple as removing and adding weapons.

I have also had locality problems with waypoint on activation fields.  Without a definitive MP guide from BIS, it is all trial and error.

So, if no pauses exist in the init.sqs it definitely runs head to toe on all clients before the mission starts? Not all of us have unlimited access to ded servers to test every pinpoint detail, and some of us are old farts without the time to do so.