New ArmA Scripting commands

[dinger 1]

No need to allude to violence, I wasn't being condescending before, but I'm rethinking that choice.

When a discussion boils down to a difference of fact, no amount of shouting is going to change it. The only way to change it is to go out there, test and prove.

"Trial and error" is only when you attempt things without grasping the science of them. That's why we have the scientific method.

Yes, I appreciate that MP testing really sucks, and costs a lot of time and resources. For this reason, there are a lot of areas of MP usage that are still vague. But if you don't want to test stuff in MP conditions, then you have to rely on those who have. And if it so happens that they're full of crap, I'm sorry.

I wouldn't expect BIS to write a definitive guide to MP: if they did, very few people would read it, and of those who did, most wouldn't understand it. Besides, and here's the rub: most of the things we're doing involves stuff the good folks at BIS have less experience with than we do; ArmA has 700-odd commands -- you can't expect anyone to know in detail how well they work in every conceivable situation. And Heaven forfend asking one of the programmers to describe how the whole system works in multiplayer.

Crashdome is probably right: you shouldn't need a Ph.D. to figure out how things work in MP. That's why Bn880 felt OFP needed CoC_NS. But I don't seriously expect BIS to make our lives easier in ArmA, especially with such novelties as JIP. They've got their priorities, and we've got ours.

init.sqs: usually, yes. if there's no pause, and if there is enough time before the game starts (since lines in .sqs files are attributed a slice of game time, a really, really, really long init.sqs may not make it all the way through).

Waypoints "On Activation" and locality: I have locality problems with most things involving AI.

[mr.peanut 1]

Even a single comment from BIS about the order in which mission initialisations are processed would have been helpful. I realise that BIS is much too busy to spend any time on this, but surely they have some in-house docs that could be shared?

[Garcia 0]

I haven't either ever experienced any problems with pV or such (except the times I have had desync > 20000), and I have had a similar script to the one you described in that topic working 100% (though it only sets the starting weather...didn't read through the whole topic, so don't know if that was one of the problems).

[mr.peanut 1]

Yes, that was one of the problems. The test server was not entirely a piece of garbage yet the problems encountered with such simple scripts was infuriating. If a mission worked consistently on it you knew it was 100% MP bomb-proof.

[crashdome 3]

init.sqs: usually, yes. if there's no pause, and if there is enough time before the game starts (since lines in .sqs files are attributed a slice of game time, a really, really, really long init.sqs may not make it all the way through).

Actually try calling several sqs init files, alot of individuals have come up with some pretty nifty packages of scripts all of which usually init some of their code from within the original  init.sqs file.

e.g. init.sqs

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

[] exec "Scripts1\init.sqs"

[] exec "XYZMod\init.sqs"

[] exec "ABCStuff\init.sqs"

Mission start could be sometime after init.sqs but each of those three may never finish before start.

if they were all sqf (call...loadfile), yes it would delay mission start, but you get better control of when stuff initializes. For example, if you are trying to avoid some sort of stutter or visual change in the beginning of the mission (i.e. weather/time change).

This is way OT, but the relevance is that sqs is diminished anyways... sqf should and most likely will become the norm and FSM commands might replace event-based (or step-by-step) execution for controlling units. Since we can no longer be expected to control time-based execution as we do now in an sqs (i.e. "~1") per this quote:

Quote[/b] ]As for deprecation, check http://community.bistudio.com/wiki/Functions_-_SQF - SQS scripts still work, but are not recomended, due to worse performance and inferior style. SQS will almost certainly be discontinued in future products. --Suma 16:41, 5 September 2006 (CEST)

Can we be expected to rely on pV much longer if it needs delays or repetition to send data properly?

I also disagree about the fact that BIS could expect to help us here. Sending data in MP is not something rare or 'special'. This is something alot of people rely on and have non-working/sub-par MP missions because of this. Saying that adding a feature which makes makes coding in MP easier, more reliable, and more flexible is not worth their time is in itself contradicting alot of what has gone into ArmA. We have animals, swaying trees, and fancy smoke effects. I would like to believe adding something of this nature is as worthy as those were.

I can atest and so can a few friends which are close enough to me to be involved in some non-public projects understand that there is alot of possibilities that have ultimately hit brick walls because OFP is just too unreliable. For example, every sim I can think of since 2001 has the ability to send data out to various gauges and displays.. yet OFP (and it almost appears ArmA) has yet to be able to allow us an easy way via command to export a single value of data (other than their proprietary sav files and complicated OS hooks - which wont work with Vista btw). Now data between MP clients is left to rot too... I dont know.. it just looks very grim to me.

[Axek/Axyl 2]

What about writing content to an external file, while a mission is running? I can't seem to find anything in the wiki about doing that, but it was always something that I hoped would be possible in Armed Assault.

I can appreciate that there could be security issues with allowing that, but there are benefits too.

I don't own VBS1, but I would presume that it's mission recording/AAR system works like that. In some way, able to output data to an external file, as part of the mission script. (or Addon in that situation.)

Cheers,

Axek.

[Lou Montana 101]

{publicVariable "_x"} forEach [...]

doing that will drive you to a failure, you have to do something like<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{call format ["PublicVariable {%1}", _x]} forEach ["var1", "var2", ...]

No PublicVariable Problem unless you play with a 10000 ping.

Anyway, I always use PublicVariable line by line to avoid coding problems like this one.

Set a ~1 before a PublicVariable [russian accent]and all will be well[/russian accent]

[wamingo 1]

Not strictly arma related, but without the "~x" pause, are sqf functions capable of running an indefinite loop without hogging up the cpu? So as to completely replace sqs?

[vektorboson 8]

Not strictly arma related, but without the "~x" pause, are sqf functions capable of running an indefinite loop without hogging up the cpu? So as to completely replace sqs?

The sleep-command replaces the "~".

[mr.peanut 1]

Even with a sleep command, the timeslicing of functions will have to change to make them more thread friendly. Any word on this?

[mr.peanut 1]

{publicVariable "_x"} forEach [...]

doing that will drive you to a failure, you have to do something like<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{call format ["PublicVariable {%1}", _x]} forEach ["var1", "var2", ...]

Why will the first snippet drive to a failure if the variables are not changing?

[UNN 0]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{publicVariable "_x"} forEach [...]

It's the wrong way to do it. It's broadcasting every variable as _x.

In fact I doubt it will even broadcast the last vaiable in the loop, as _x is local. I thought you could only use global variables with the publicVariable comamnd?

The above should be written as:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{publicVariable _x} forEach ["Var1","Var2","Var3"]

[mr.peanut 1]

Damn typo making me look like an idiot.  I prefer looking like an idiot for real reasons...

I have always done it as in your second snippet i.e.:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{publicVariable _x} forEach ["x1","x2",...]

But why is this better?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{call format ["PublicVariable {%1}", _x]} forEach ["var1", "var2", ...]

[Lou Montana 101]

well I made it on-the-fly and didn't test other ways, but you should prefer using publicvariable function for each variable, not coding it; it dodges eventual code problem and if you need to do this for a good reading of the code, use : PublicVariable "var1"; PublicVariable "var2"...

That's my opinion, if you encounter a problem make code as simple as possible