"This video is private."

You probably want to change that to unlisted.

Is this the journalist behind the camera or the one in front? Or the one taken hostage that you need to rescue?

To me it sounds like we'd want a new unit named something like
TV Camera crew

That said, I really like your idea up there.

I think it would be useful if everyone posts what extensions they're using - and to the extent they know, if that extension is using threads of its own.

I have an extension that will stop a worker thread on process_detach, but that event may never actually be coming, since loading it was supposedly triggering this effect.

ACRE and TFR both use extensions.

I suspect this is really an "extra threads" problem; that the shutdown fails when there are extra threads present. Whether this happens from extensions or steam overlay or yet other factors.

The problem with VA is the export button. The resulting script does the above, and as a result it doesn't work.

More to the point is how you know which of addweapon and additem you need for any particular thing. If you get it wrong you can have subtle failures.

This is related to #17943 - nearly duplicate except this issue deals with one very specific implementation suggestion without many of the pitfalls I mentioned in a note there.

---

Even with all of the below resolved, I'd like to point out the nature of this proposal:
It's about moving complexity away from the extension (worker threads) to sqf (continuations).
Away from where a few 'highly skilled wizards' (relatively speaking) have tools and languages that help deal with complexity,
to where the majority of users (sqf scripters often with no "real" programming experience) appear to be struggling with things like code structure as it is.

---

There are some deeper questions that need answering.

• If several calls are made to the same extension, should they be queued up until the extension returns or should they be launched in parallel?

The latter would require that the functions are reentrant, and if the extension will "do something meaningful" it also has cross-call resources that need properly synchronized access.
In no case would it be appropriate to put all extensions in the same queue.

• How will you handle multiple extensions being called?

Analogous to putting them all in the same queue; you cannot suspend calls to one extension (e.g. acre) while waiting for another (a database call).
More importantly, how do you recognize which extension sent a return value back to you?
Two options OTOH:
addMissionEventHandler ["ExtensionReady_MyExtension", {hint _this}];
or making _this an array of ["extensionname","string"]

• How will you know if the return value is meant for you?

Imagine that when a player joins, you do a database check to get the data for that user.
Now two players joined at nearly the same time. You just got an answer back. Which object do you apply it to?
If we assume the queue above, you could track this manually in a sort of parallel queue, but it would be a chore and it would be error prone.
Another solution is to expand on the above: make _this ["extensionname",something,"output"] as a result of
"extensionname" callextensioncb [something,"input"];

• Performance? Return value latency?

At what times can the EH fire? I'm going to assume this will be checked at most once per frame.
Will a new thread be created for every request?
Will this be the game handling a "worker thread" for the extension instead of the extension writer?

• Backward compatibility

Can be achieved in two ways. Overloading on right side being string vs array, or a new command like callextensioncb.

----

"Then create a sqf loop that would call extension until the result is ready to be collected."
Actually, you could do it all as
_ret = call compile ("ext" callextension "input")
and let the returned "reference" be the code for that loop, with the reference number embedded.
Again, moving the complexity about to where we have better tools for dealing with it.

There are costs to doing this; many of which will severely _increase_ the complexity modders must deal with.

Current scenario requires the extension programmer to implement asynchronous mechanisms himself.
This is not that hard, with a tiny bit of extra code on the sqf side if you need the return value.
There should be an actual template around for doing this, but noone has made one afaik.
It's been on my todo list for over a year now.

What if multiple scripts asynchronously call the same extension? Now it better be reentrant, which is a different beast from making an extension async, and not so much simpler.
Going further on that line, if there's a resource you want to use across several calls - like database connections - you need multithread synchronization on these. Suddenly your complexity goes through the roof.

Alternatively arma3 would need to make a queue of those calls, and push them after the previous one is finished. Only, how often can it check for that? Because arma, probably every frame. That would require the protocol - and thus sqf side - to do some large amount of packing overhead.

Do we stop the script dead while it's waiting?
That won't really work from non-scheduled code, like (nearly) all of acre.

Most importantly at this point, it would severely break just about EVERY extension - and/or mod using extensions - already made. Counting those who handle the current setup correctly, anyway.

Given all that, I don't think any amount of upvotes will make a difference.

This was the first place I learned of the substrings method.

Combined with find, this makes it easier to make a parseArray ourselves.
Especially if you don't require the regular syntax for it.

But if you apply the magic words "fixed size records" then things can really take off.
_res1 = _res select [0,10];
_res2 = _res select [10,10];
_res3 = parsenumber (_res select [20,10]);

Setting performance aside for a moment, the other problem with the call compile is that it allows the parameter to have code in it, which will immediately be executed. Especially while there is no signing for extensions, this is a bad thing.

Back to performance:
I've gotten the compile function to lock the game up for >20 minutes. (It wasn't completely accidental but the magnitude was surprising.)
Basically I don't think the performance of a parseArray would get anywhere near as bad because there's a lot it doesn't need to handle, like the creation of a value of type CODE.

So, the summary of this is "clickable cockpit buttons and switches" ?

TOH and A3 are by all accounts siblings, so it's not certain that it "should already support it somehow"

Workarounds

1. Static compilation. This isn't always feasible, but it sure makes it simple when it is.

2. Make sure the dependencies are delay loaded, call a win32 function that allows you to set a dll search path (it gets searched before the normal ones) before you immediately call something from each dll. (other things could set that dll search path elsewhere later)

I believe you can find the path of your dll from other win32 functions using the hmodule passed into the winmain.

3. Put the dependencies in the main arma 3 directory; this obviously won't happen automatically with most installers.

If you present the easiest target around, they should be shooting at you. Are you standing around in the open, or are you crouched, peeking out from behind a tree?

More importantly, the mortar available in the a3 alpha has an optics view, allowing "direct" fire on line-of-sight targets.

I can confirm this bug. What's more, I was unable to open the door myself when I tried to around 10 seconds ahead of the door being opened by the snake. (The option did not appear.)

There's a problem if a script for the attitudes of civilians/resistance fighters are affected by the killing of a snake.

I've seen some of these effects in single player, and I assume I'd see them all if I spent the time looking into it.

In limited ammo missions, e.g. 5 rifles 15 magazines, having a backpack would tend to deny the others ammunition.

In addition, with #104 fixed, right clicking them across should be easy enough.
(Does the field manual explain that you can right click? Haven't checked that section.)

Collective refers to the (collective) pitching of the blades. (All of the blades, hence "collective".) As you pitch them up so they add lift, they will also meet increased air resistance, and thus slow down to a lower rpm.

The engines will normally not be working at full capacity, because a governor caps the rpm. So the engine output will then be automatically increased to try to keep the rpm constant, but it shouldn't be a surprise if this lags a bit.

(In my observations, I've noticed real helicopters being the most noisy when hovering; presumably related to the aerodynamics of a rotor blade in the wake of another.)

I am unable to reproduce it.

I create a mission with me (rifleman) and an empty mh6. If I get in as passenger, it gives me the "gear" option, but neither dragging nor right clicking my sidearm across makes it blow up.

With the ah-6 I didn't get the opportunity to use the inventory dialog with the chopper, not even using the I key outside the helicopter.

I also tried the ka50, but that didn't work much better.

So, did you check it?

I'm wondering if maybe this is reproducible only if you get out very immediately - as if the sound plays a long time before the shell actually leaves the tube, and so when you leave the artillery computer screen and manually disturb the aim of the tube, you're also affecting the shot.

Try this:

1: Aim at target
2: Use the sight zeroing keys, default pgup/pgdown, to match the two numbers in the lower right of your screen
3: Fire
4: Observe the round land on target

In my experience it may bias towards landing short at long ranges, so if you're aiming at a target >2km away you may want to set your elevation slightly lower. (.1 to .5 degrees in my preliminary experimentation.)

No idea - the only tests I've done so far are with infantry, but that has shown that although addweapon doesn't give an error, it doesn't always work. But additem does. As I understood it you encountered something similar wrt itemradio?

I'd love a technical explanation from BIS on the difference between the two in the game code, and why one is appropriate over the other.

I'm thinking to perform this test when I can:
Place a hunter MG
1: Remove its weapon by script. (Expected: Weapon no longer selected, cannot fire, can still look around in the sights)
2: Add by addweapon (Expected: The behavior described in this ticket)
3: Remove addweaponed weapon.
4: Add by additem (Expected: The weapon is again usable.)
with both 2 and 4 also adding at least one magazine for it.
Probably easiest done by putting the code for 1&3, 2 and 4 in radio triggers.

Is this yet another case of needing to use additem instead?

I successfully reproduced this. However, it's not zooming, it's the optics mode that crashes the game. (I have that on another keybind.)

Crash dumps at
http://mahuja.net/arma/a3a635.zip
though in this case it's trivial for a dev to generate his own.

There's one additional problem to avoid; the chambered round should be of the type of the magazine it was loaded from. E.g. if you tactical reload from tracer rounds to normal rounds, the chambered round should not magically turn into a plain round.

And then you have the possibility that they didn't want to fire that type of round - that typically being the reason they switched.

The workaround we found is to pull out a sidearm.

There are plenty of waterproof NVGs around. Rain-proof is a given, but there are ones used by divers too.

Let's pretend that feature can be added without increasing cost so much they buy the lesser ones, and that this is therefore what we have :)

Maximum speed: 152 knots (175 mph, 282 km/h)
I think maybe they simply took the number and put it in a place that expected a different unit.

Cross-faction uniforms are forbidden - while it's also prohibited by the geneva conventions, the main reason is that it's practically impossible to balance the point at which AI would figure you out.

That said, under no circumstances should the uniforms actually be destroyed, or as in a case I tried (taking civilian clothes) duplicating mine.