Simas

I am interested in playing a 3D world-positioned sound effect and then stopping it at a certain point (using scripting). Here is what I tried so far: say3D and playSound3D when used on the same object do not replace/stop old sound but simply play the same sound again (on top of the old). Thus - not really possible to stop sounds started with these two functions. The createSoundSource and then deleteVehicle on the sound object does not work (reported as a bug #8231). Any other options I am missing?

This addon adds JavaScript scripting support for ARMA addons and missions. The JavaScript language is powered by the (very) speedy Google’s V8 Engine. V8 implements ECMAScript as specified in ECMA-262, 5th edition. Version: 0.7/3.21.11 (Addon/V8) - DOWNLOAD Addon is open source with code available under GPL 3. Be aware of the following limitations: You cannot use and call SQF commands from within JavaScript context (I have an idea how to overcome this callExtension limitation and will implement this feature before 1.0 release). The return value of JS_fnc_exec has a hard buffer limit (max 10kb output) – a limitation of the callExtension interface. You may have issues returning large strings or large arrays from JavaScript. Technically, I think I know how to bypass this limitation and make it transparent, so this issue is temporary and will be resolved in the upcoming updates. At the moment if you hit the output buffer limit - SQF will throw a "[OOB]" exception so you can still handle the issue with SQF code. Linux dedicated server is not supported at the moment (callExtension has no support for Linux shared libraries). Since (at the moment) you cannot directly call SQF commands from JavaScript – this addon can be used to offload complex algorithms and computations that require fast execution and do not depend on ARMA/SQF state. Also, you can use the following native JavaScript language features: Prototype-based OOP Regular Expressions Fast Math, Array and String operations Date and JSON support SQF functions and macros (API) The following SQF functions are provided by this addon: JS_fnc_exec - Execute JavaScript code and return the result. JS_fnc_spawn - Execute JavaScript code in parallel (non-blocking mode, separate thread). JS_fnc_terminate - Terminate (abort) a spawned JavaScript script. JS_fnc_done - Check if a spawned JavaScript script is done/finished. JS_fnc_version - Get addon and JavaScript engine version information. Please refer to the examples below. Detailed function documentation is still a TODO item yet. The "exec" and "spawn" versions differ in that the "exec" version runs the JavaScript code and returns the result to SQF in a blocking mode, while the "spawn" will return immediately (with a script handle) and will run JavaScript code in parallel (in a separate thread). An optional \JS\API.hpp header file is provided by this addon and can be included in your SQF scripts. This header file defines JS(...) pre-processor macro, which is an alias to JS_fnc_exec function. Note that the JS(...) macro skips SQF call command and is theoretically even faster than calling JS_fnc_exec directly! To include the header file and JS(...) macro in your SQF script file, do: #include "\JS\API.hpp" JavaScript functions The following functions are available for JavaScript code: sleep(seconds) - Suspend current background script for a given number of seconds. Note, that an attempt to use this function within a blocking code (executed with JS_fnc_exec) will raise an exception (just like with SQF sleep command). FAQ 1. How are JavaScript errors handled? If your JavaScript code has compile errors and you do not handle runtime errors yourself using JavaScript exception mechanism – the JavaScript engine will throw an unhandled exception. Once the unhandled exception is caught by this addon – it will be forwarded to SQF using SQF exception handling mechanism. Therefore, you can catch JavaScript errors in SQF with: try { "JS code with some errors" call JS_fnc_exec; } catch { hint _exception; // [line 1] SyntaxError: Unexpected Identifier: "JS code with some errors" }; 2. Can I execute a JavaScript file instead of a code string? Yes, using the SQF loadFile command: // Load and execute "script.js" file: loadFile "script.js" call JS_fnc_exec; // Or if you have "\JS\API.hpp" header file included: JS(loadFile "script.js"); 3. What data type is returned from JS_fnc_exec call? The results returned from JS_fnc_exec call are transparently serialized to SQF data types using the following scheme: JavaScript Number => SQF "SCALAR" type JavaScript Boolean => SQF "BOOLEAN" type JavaScript Array => SQF "ARRAY" type (including nesting) JavaScript null or undefined => SQF "VOID" type (nil) JavaScript String => SQF "STRING" type JavaScript Object with .toString() implementation => SQF "STRING" type Anything else => SQF "VOID" type (nil) 4. What about Unicode (UTF-8) strings? Both SQF and JavaScript are UTF-8 native. You can throw at JavaScript UTF-8 strings (and run string operations there) and get back valid UTF-8 results to SQF. Although be aware that SQF escapes quotes in strings using double quotes ("") while JavaScript does that with escape character (\"). 5. How to dynamically detect @JS addon availability? You can use configFile check to test if the JavaScript addon is available: _hasJS = isClass(configFile >> "CfgPatches" >> "JS"); if (_hasJS) then { // Offload complex computation to JavaScript } else { // Use SQF }; 6. Can this work with ARMA 2? Yes, with ARMA 2: Operation Arrowhead 1.61+ patch. Note that if you are not using @CBA addon - you may need to add "Functions" module (F7) to your mission for the JS_fnc_* functions to be loaded and available (only required for ARMA 2). 7. Is JavaScript multi-threaded by design? It is not. JavaScript memory model does not support parallel programming and does not have any synchronization mechanisms built-in (neither does SQF, really). The background scripts and parallel execution is implemented with constant V8 isolate (virtual machine) locking and unlocking. The locking/unlocking happens when you call JavaScript sleep function - therefore it is important that you use sleep within code having any (infinite) loops in it (so that other JavaScript scripts can get a window to execute). While I do not have internal knowledge of SQF implementation - I suspect the parallel execution is using something very similar. The difference is that the context switching in SQF happens every time you execute a command (and basically everything in SQF is a command). Examples For improved readability the examples below will use the JS(...) pre-processor macro. Otherwise, you can replace JS("code") with "code" call JS_fnc_exec for the same effect. Simple JavaScript statements and math: _result = JS("2 + (2 / 2)"); // _result == 3 // typeName _result == "SCALAR" SQF and JavaScript can then be mixed together: if (JS("false") || {JS("4 > 2")}) then { // true, SQF lazy evaluation works just fine }; Assign and access global JavaScript variables: JS("test = 123"); _test = JS("test"); // _test == 123 Call a built-in JavaScript function: _randomNumber = JS("Math.random()"); _year = JS("(new Date()).getFullYear()"); // "2013" Call your custom function with arguments: _result = JS(format ["myFunction(%1)", _number]); _result = JS(format ["myFunction('%1')", _string]); Regular expressions: _email = "my@email.com"; _emailValid = JS(format["/\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,3}/.test('%1')", _email]); // _emailValid == true Background scripts: // Execute a "dummy" JavaScript background script: _script = "sleep(100)" call JS_fnc_spawn; _isDone = _script call JS_fnc_done; // _isDone == false _script call JS_fnc_terminate; _isDone = _script call JS_fnc_done; // _isDone == true or false Note: JS_fnc_terminate does not block and does not wait for the background script to be terminated - it just sends a signal. Therefore the last line in the example above could either return true of false (depends on timing). Get addon version information: _version = call JS_fnc_version; // An array: ["0.7", "V8", "3.21.11"] TODO Allow calling of SQF commands from JavaScript (using sqf.* namespace). Add mission init script support: init.js, initServer.js, initPlayerLocal.js and initPlayerServer.js. Implement the workaround around callExtension output buffer limitation. Detect when ARMA is paused (suspend background scripts and use v8::V8::IdleNotification() internally). Add a second parameter to JavaScript sleep() function (to allow background scripts to continue when ARMA is paused). Do some JavaScript vs SQF performance tests (with startLoadingScreen to disable SQF throttling). Double check everything and do a final review of the code. Version History 0.7 (2013-09-07) Updated V8 to 3.21.11. Fixed: Serialize JavaScript NaN value as SQF nil. Fixed: Serialize JavaScript Infinity value as SQF scalar infinity. Added a total of 32 unit tests (use execVM "\JS\Tests\_Run.sqf" to run). Other internal tweaks and optimizations. 0.6 (2013-07-07) Updated V8 to 3.20.2. Implemented background script handles (returned by JS_fnc_spawn). Implemented JS_fnc_done and JS_fnc_terminate functions. Added sleep(seconds) JavaScript function. Added a common header file (#include "\JS\API.hpp") with JS(...) macro. PBO and extension DLL files are now signed with bikeys (server-side key is included). Other internal tweaks and optimizations. 0.5 (2013-06-07) Initial release.

Gorgon and Marid mirrrors are way off. I don't really need to see myself in a rear mirror.. (Marshall is good).

Hmm, anyone else spotted VAC in the Steam server browser? And is this a sign that the GameSpy MP server browser is finally being replaced? :)

Fast-roping?

Graphics > Gameplay. You should check out the new fancy light shafts :) Seriously tho, I have noticed the same thing. I keep checking the changelog hoping to find "bipods have been implemented" or something like that for a while now. Although don't lose your hope just yet, the latest Dslyecxi community video did drop a hint of some new multiplayer functionality coming soon.

I had this problem in 5.1/7.1 sound configuration. Had to switch to stereo.

Speaking of water, has anyone noticed how looking (and zooming) at an empty water has a large impact on FPS? I can get stable 60 fps at Kavala, yet a simple glance at an empty water will get me to 50 fps and my GPU is 99% tasked.

I am waiting for NVIDIA ShadowPlay :) The things will use dedicated H.264 video encoding hardware, the recording performance drop should be minimal.

I would wait at least another month. AMD just announced a series of new GPUs and I bet NVIDIA will have to respond with either a drop in existing prices or introduce some new models in November. Does your motherboard and PSU support SLI? If it does, GTX 760 should be a good option as you will be able to upgrade to 2xSLI GTX 760 setup in the future.

The CPU frequency alone means nothing, have to look at the IPC (instructions per cycle). I have upgraded from 3.4 Ghz Phenom II X4 to 3.5 Ghz (3.9 turbo) 4770k Haswell and my fps literally doubled. Can't really tell that by CPU frequency alone.

Curious what has been improved exactly? Anyone had a test run and noticed anything?

Been playing from the start of Alpha and had no crashes so far.. until 1.02. Switched to a stable branch last night and tried some multiplayer - got two crashes during my session. Definitely something happened with 1.02 update as the MP was kind of stable during the 1.0 launch.

The way I understand it - the Mantle is a low level graphics API (while the Direct3D is considered a high-level). It essentially removes the abstraction of DirectX and gets the developers as close to the metal as possible. Thus less time is spent on the CPU preparing the frame/draw calls - meaning the GPU is less bottle-necked in the end. It makes sense where this comes from considering that AMD is the supplier of next-gen console hardware and how weak the CPU is on those machines. And this actually sounds perfect for Arma given how the CPU is always an issue. Not sure how hard would be to port a DirectX engine to Mantle. I guess on December (when the BF4 will get Mantle patch) we will see some real-world performance data. ---------- Post added at 12:10 AM ---------- Previous post was at 12:01 AM ---------- have to read this

Driving model.

Most of the command line switches are auto-detected and configured by the game. You should't even bother with them in Arma 3. Those two are quite heavy on GPU. Have you tried using something like MSI Afterburner or EVGA Precision with the built-in On-screen display server? Essentially a tool that will let you display all kind of hardware related (and not just FPS) stuff on-screen in the game. Configure it to display GPU/CPU usage and see where your bottleneck is (use another HWiNFO tool to configure display of per core CPU usage). If your GPU is at 99% - then you need to lower some GPU related settings. If one of your CPU cores are at ~70% - then you are already CPU bottlenecked. Another possible thing that is happening is that your notebook is overheating and the CPU is downclocking itself (make sure it's actually running at that 3.5 Ghz turbo mode). Arma maps are streamed. You can't really load the entire Altis under 32-bit 2 GB memory limit. SSDs are very very useful for Arma.

The "boxer" version of the truck lights are messed up: normal: http://i.imgur.com/ptIBl9A.jpg (176 kB) boxer: http://i.imgur.com/XAVYUSV.jpg (212 kB)

Noticed some LOD issues with vehicles. Are those dev build related or also in stable? http://www.youtube.com/watch?v=DS87gmkrf0w

The clouds are messed up in the latest dev build. Could be related to the per-pixel-lighting change? http://i.imgur.com/Lb94UIr.jpg (123 kB)

Some serious issues with those benchmarks? They have run their benchmarks using the relatively simple "Infantry Showcase" mission which is hardly stressing Arma at all.. Not only that, they even set the AI skill to 0 - which probably means the AI is slower reacting overall (meaning even less CPU cycles used). Essentially - they were testing only GPU performance here.. thus never bottle-necked by the CPU (and I suspect that's why the 4770k is only a couple of frames better than the FX-8350 in charts). Still, what's interesting is how well the SLI/Crossfire setup seems to scale for Arma.

This is sad :| The textures are also quite bad and no attempt was made to add some extra details with normal mapping and stuff. To be honest, I think the best "cockpit" we have right now is probably in the Offroad..

You can still select and copy the class name - the changelog entry just means the label was made read-only. And about the PIP-mirrors: they don't seem to work on Zamak support trucks (ammo/repair/medic etc). And could we get working PIP mirrors for Gorgon AFV? It strikes me that the PIP mirrors work on various civilian vehicles just fine (where they serve mostly as a gimmick), but do not work for something extremely useful as a turned out Gorgon driver.

The dev and stable branches are now identical, so no re-download will happen (only on Monday after they will update the dev branch again).

Curious, what's wrong with Arma 3 UI exactly? Seen it mentioned in a couple of post already. Other than the stupid radar HUD for vehicles it's a vast improvement over Arma 2.