Vitdom: Yea this is probably off-topic, but probably no better topic title then something concerning the Opposition Nymph! And the fact that I enjoy open source seem to go hand in hand.

From what I've seen so far and I've only written some random small snippets of the SQF syntax scripting, compared to C and Unix/Linux SH/Bash scripting; the SQF scripting language utilized by the ARMA series of games is called SQF, or a scripting language having a SQF syntax. (When using text editors, you'll want to use the SQF syntax for coloring your text or script within the editor.)

It does not appear that there is an all in one inclusive source of information concerning the language and functions used within each game version, but spread about Bohemia's domains.

If you have questions, people usually point you towards Bohemia Interactive's forums. Usually most developers are grateful and willing to help most people. And if you have an "Oh my God" great idea, you may see the idea readily employed. Just be advised some people you might come across do get hostile within the forums, and probably best to just avoid them.

Following are my URLS for referencing:
http://community.bistudio.com/wiki/ArmA:_Scripting_-_Getting_Started
http://community.bistudio.com/wiki/Category:Scripting_Topics
http://community.bistudio.com/wiki/Category:Scripting_Commands
http://community.bistudio.com/wiki/Category:Arma_3:_New_Scripting_Commands_List
http://resources.bisimulations.com/wiki/SQF_Syntax
http://forums.bistudio.com/topic/151099-scripting-discussion-dev-branch/#post2530202 (ie. The Developer Changelog may include function naming conversions, and maybe needed to update your scripts.)

After reading quite a bit of the already written scripting, I would suggest having some experience at writing SH/Bash and even C programs, as the scripting language is reminiscent of a stripped-down Sh or C shell. Be consistent with your spacing and know how the computer reads code. Use good variable naming and please please make sure you comment your code well! I would suggest ignoring the people claiming too many comments or statements not needing comments, as comments will not or should not slow the computer any. (I guess some people enjoy unreadable code, as it keeps them employed or fear becoming unemployed.)

Also within the 3D game editor, I think press ESC and you'll be given a menu for finding functions and/or classes. I've found this method difficult to use and maybe better streamlined when they deploy the Eden editor. But this method of finding the most current functions or classes to be the most accurate, but lacks the documentation similar to the above URL's.

Oh, and do not forget to make back-ups of your scripts. Use of a version system (ie. CVS, SVN, Git, ...) or simply backup your scripts be using a date suffix such as script-20151125.sqf. (On Unix/Linux, we just do script.sqf.20151125.) When packaging, make sure your file are contained within a version or dated suffixed sub-folder. (ie. MyScript-20151125/)

I included a few Windows related solutions to some hiccups I've seen within past Windows related packages.

Good luck!

WORKAROUND: Wearing night vision, players can just barely read the gauges.

Ditto. Looks like a duplicate of Bug #26027

However from my memory, this bug only effects certain aircraft, the To-199 Neophron being one of them.

I would have to say this issue is now fixed, with apparently reduced throttle/acceleration speeds. Hence, making safe landings more possible.

This might be fixed within version 1.54. I think I noticed the throttle was decreased significantly, but not sure if the one server tested had a modification.

Health damage does still occur at around 211 km/h, however I can now hover more precisely at a set speed over the runway before landing with the decreased thrust.

I will further test later within my editor to further verify.

Here are some tips for a successful landing of the Neophrone:

1. Start your landing approximately at least 3-4 kilometers out.
2. Approach at 150 meters altitude.
3. Approach full speed brake and full flaps, landing gear down. Enough throttle to keep vertical descent from dropping excessively.
4. Keep the flight path indicator on the beginning of the runway. Use rudder, and avoid ailerons. Use the throttle to control vertical descent.
5. Just prior to touch down, pull the nose up slightly and DO NOT drop or increase throttle. (If you do increase or drop throttle, this will likely require a divert from your landing.)
6. Let the back wheels touch the runway and then let the nose down easy.

The above is extremely easy with the slower jets. Using the Noephrone, this is virtually impossible without causing injury to the pilot when using a remove server or mutli-player game.

I've created a landing scenario, already lined-up with the runway, with all aircraft controls set for landing.

I've reproduced landing, and find landing still requires a level of expert control, along with having the awareness of using something like TrackIR. Very difficult but after practice, landing does get easier.

Watch everybody break-out into their "happy dance", as I think few expected this. (Note my sarcasm. ;-)

Shrugs. So leaving a parked vehicle along the runway (or elsewhere) and turning on the vehicle's (or aircraft's) exterior lights two hours before dusk and traveling elsewhere, and then returning after dark (or during dusk) at the airport (or elsewhere) is useless? Not too also mention by law, Canadians are required to drive with their headlights on.

Does this bug occur with all jets and all rotary aircraft, or just some of aircraft?

In the past, I've also seen some vehicles with the lights being unable to be turned on during daytime in general.

Wonder if recording programs include debuggers?

Fighting Power: I remember during Alpha or Beta, one of my playmates stated he flew better using an XBox controller.

So you're stating there's no on-board equipment within real life helicopters to achieve auto-hover? (I could have sworn manual hovering was something left over from the 1970's.)

If you noticed as well within ARMA 3, auto-hover takes effect gradually upon activation. As if to display the feature was engineered intentionally to work alongside manual control. (During Apha and Beta, auto-hover took effect instantly and abruptly with no gradual effect.)

Although always a good exercise establishing good manual hovering skills in the event the on-board auto-hover ever fails, auto-hover allows pilots to concentrate on other instruments or perform other risk assessments. (And for the occasion the pilot has a magazine handy and happened along a really good article!)

If I'm not mistaken, restarting Steam client resolves this bug.

However, when I get this Access Violation error, windebug cannot produce a backtrace because of this bug. Any debugger should be able to provide a backtrace with ease.

Ditto. I too just noticed this bug within 1.52RC, and then verified the bug exists within 1.50 too. Likely within one of the near previous versions, this bug first appeared. I quite vividly remember the "Show" button would show the exact values the slider bars for the axis were set to, instead of reverting to the previous menu.

Good description and I was able to find this bug already opened with ease.

Don't forget to vote for your own bug. I know it sounds ridiculous, but voting for your own bug then creates a green bar highlighting the vote option for others to readily vote for your bug.

If I'm not mistaken, restarting Steam client resolves this bug.

However, when I get this Access Violation error, windebug cannot produce a backtrace because of this bug. Any debugger should be able to provide a backtrace with ease.

Currently within version 1.50, when multiple controllers are connected (ie joystick rudder and separate rudder pedals), the game averages both rudder devices instead of treating each device axis separate. I made mention of this bug elsewhere within another joystick bug.

I could have sworn I opened a bug for multiple controllers conflicting, but maybe not.

My Saitek X52 Pro cannot be mapped correctly using Steam Big Picture mode.

Gee, thanks everybody for mentioning the 'A' icon within the HUD is the auto pilot light!

But we still desperately need a Speed Brake ICON when activated or deactivated. You have no idea how many times I have been caught with my "pants down", only to find the speed brake is still on when I thought the brake was off!

"A" for air brake? Jet Air Brake icon not lighting-up on jet HUD when air brakes are applied.

However, rotary aircraft brake icon does light-up.

Hello. Uploaded in 7z compressed package.

I will try to get another back trace if I have more free time.

The back trace will likely just show the same debug backtrace as previously posted.

Looks like I'm still getting this crash within version 1.52.

I think I see what is occurring.

When the Area of Operations clears, the clear function tries removing all vehicles. Since assembled mortar tubes/bipods are assumed to be vehicles (for collision functions), the clean function is probably trying to remove the assembled mortar tube/bipod while the user is attached to the mortar.

I just saw my assembled mortar tube being removed upon the Area of Operations clearing while not being attached to the mortar tube/bipod.

What really sucks is I also keep getting a windgb.exe error "Access Denied 0xC0000022 error" when trying to connect to the arma3.exe using windbg.exe! Oh well.

Attached arma3_2015-09-06_23-41-36.bidmp and arma3_2015-09-06_23-41-36.rpt

(These dumps are when using the modification. However all dumps when not using the modification contain the duplicate back trace.)

This is going to be difficult and timely to test without using the personal virtual ammobox mod, as pilot roles are typically completely consumed.

Standby, as this was my next task but forgot to test without the mod within the past hour or so.

Just tested without the client side modification and the bug still exists.

A seemingly duplicate backtrace was produced.

From the looks of it, this occurs when the area of operations removes the red circular transparent overlay on the map. (ie. Remove circular color red from map designating the current area of operations.)

Guessing a lot of people find it difficult or cumbersome to either carry two backpacks or to load a vehicle with the two or more backpacks. And then trying to get a vehicle safely to the area of operations.

Bingo. I have the game successfully executing using the following method:

Change to the root application/game folder, replacing USER with your login name.
$ cd /home/USER/.local/share/Steam/SteamApps/common/Arma\ 3

Manually execute arma3 binary
$ ./arma3 --eon_force_display=0 -world=empty -skipIntro -window

This "inability to start the game using the Steam application" seems to be an upstream Steam or game specific problem. What's likely happening when executing the game via Steam (using what's provided within the ps output), I get the following stdout error "/home/roger/.local/share/Steam/SteamApps/common/Arma 3/arma3: line 3: ./saferun.sh: No such file or directory" It maybe, saferun.sh (or arma3.i386) is not being found as the Steam client or initial arma3 sh script is being started within another folder. This error is likely being silenced from both the game and Steam logs.

In my opinion, executing everything via the command line shell is by far the best option, unless you're executing an extremely well tested and stable application!

lpjtvalka: Hi lpjtvalka. I'm guessing you only translated the description and did not have time to further translate my follow-up descriptions. My follow-up comment stated I was able to run the game directly. I also described the possible cause of the (shell) bug. (Could also be caused by uniquely defined PATH variables by Ubuntu, but overall likely an easily fixed shell bug.)

However, had I not solved it or knew of a workaround, your advice would have helped greatly and the advice would have been timely. ;-)

I suspect there maybe other packages requiring 32 bit builds. If so, can somebody provide a complete list of 32 bit dependencies?

Updated Tue Sep 1 21:41:32 UTC 2015: Never mind. I was able to execute on Gentoo after doing the following: 1) Building SDL2 32 bit, 2) Specifying command line parameter "--eon_force_display=0" preventing using the HDMI connected monitor/display, 3) Changing to the root ARMA3 folder and manually executing the arma3 binary. (Seems the arma3 binary might not be able to find the arma3.i386 binary if not being executed within the ARMA 3 root folder when using the Steam client to launch the game/application.)

Ditto here using Gentoo. Seems SDL2 32 bit build is also omitted from the typical 32 bit profiles within the /etc/portage/package.use file.

cat /etc/portage/package.use

media-libs/libsdl2 abi_x86_32

emerge -uq media-libs/libsdl2

After recompiling libsdl2, I still get the above stated error.

I found something on Google using the error description stating this error is caused by an OpenGL 4 requirement, and only media-libs/mesa-11 provides OpenGL 4 as required by NVIDIA GPUS. AMD hardware may function fine as OpenGL version support is driver agnostic. See "M@yeulC commented on 31 August 2015 at 9:15 pm UTC" at http://www.gamingonlinux.com/articles/arma-3-available-for-linux-in-a-beta.5890/page=4#comments

FYI: Somebody questioned the dependencies or whether this was a native port, and from what I'm seeing from the logs, this ARMA 3 client for Linux likely uses a private Steam build of Wine. Please verify my information, so users know how to run the game client via command line instead of the graphical steam client. Also if this is using the user's client side Wine, then I need to focus my debugging there instead of here. But I speculate the working Wine version used is either provided by Steam or Bohemia Interactive, as it would be more cumbersome for users to maintain their own working version of Wine.

Possible duplicate of Bug #18733 "Global chat is laggy in almost every server"

But at least this bug report provides a possible solution or workaround versus no solution!

When is the bug going to be fixed?

Is there not a main bug designated for this bug?

This bug has been on going for almost a year, I think just after Beta this bug was introduced.

I would have to say this issue is now fixed, with apparently reduced throttle/acceleration speeds. Hence with my bug, making safe landings more possible.

You'll notice the jet can still climb vertical, which is normal, however the acceleration rate during vertical climbs are much decreased from prior versions.

It would appear they have decreased the throttle thrust within version 1.54, to make safer landings according to my Bug #26228, "To-199 Neophrone: Difficult to land or runways too short".

However, this jet (like many other real world jets) can climb vertically.

I will try verifying within my editor that this is fixed, as I'm not sure if the server had any modifications.

For a good reason they divide the company. Military is military, and civilian is civilian use; or civilian is suppose to be for good clean fun. It's been awhile since I've viewed the referred to website.

I think we're right on with what we're asking here as far as the flight dynamics. If my cards are right, eventually the flight dynamics will be worked through as future features are implemented. Within the civilian sector, it's no fun if the game or simulation gets too real. In the military, they have all day to lay around and do nothing.

VTOL aircraft were slated for the official release of ARMA 3, but sometime during Alpha and Beta, the VTOL aircraft were silently dropped. I mean, it was like a secret government wiped all publications of the VTOL aircraft! I remember this vividly as one day they were in the line-up, the next day, nothing was present concerning VTOL aircraft. But there are still hooks residing within ARMA 3 (using the editor) for VTOL aircraft.

It maybe, the VTOL are only residing within some builds for the military. (ie. I heard some Countries really use ARMA for training.)

Back to the Neophron, I think we should create a "TODO list" listing each gripe we have for each of the aircraft. This way, the bug/feature gains popularity and the bug provides developers some focus instead of trying to muddle through thousands of individual bug reports. At most, maybe open one bug per aircraft, listing each aircraft faults that need fixing.

Oh and you're right concerning dog fighting with a Neophron. The A-164 only has a few options for evading confrontation with the Neophron.

By the way, twin engine jets are able to act like "rockets". ;-)

Landing this jet safely is next to impossible on the longer runways.

This jet likely needs the salt flats (or desert flats) for a safe landing.

The physics seem unreal for a safe landing on one the longer runways.

UPDATED: Think I've finally figured it out. Level out at 100m, full flaps and full speed brake. (I was previously landing with half speed brake.) At the runway, switch to 3D view to make sure you descent isn't too fast to the runway and touch down easy. My landings still hurt my health, even though I had an soft landing. Even auto pilot cannot be trusted landing the Neophron!

UPDATED: Watching the Decent Velocity seems to be required for this jet during landings. Still, landings are proving lethal to the health status. Likely landings are being registered erroneously as being too hard, and not taking into account for likely heavier shocks/springs on the landing gear. Something just doesn't seem right with this jet when trying to land! Watching via 3D view during the last moments of landing seems to be a requisite for this jet for performing safe landings.

Well with that stated, I've even landed and taken-off (within the game) from the Altis's small airfield in the north with an A-164. However, this is kind of hit or miss, or a gamble. I was trying to explain airport runway length from a realistic point of view, and landing and departing runways safely with jets. Again, from a realistic point of view. In real life, and within the US. ;-)

You did touch on one topic, heavily loaded aircraft should not be able to go vertical. Likely loaded with a couple of dumb bombs, aircraft would likely have a difficult time even maneuvering.

Another thought, this game was engineered slightly from a futuristic point of view. The enemy were supposedly initially designed as aliens. With that stated, it maybe the authors or engineers wanted a jet with maximum capabilities, for players to demonstrate all possible flight maneuvers, and then maybe a little more?

The Thrust/weight ratio table is extremely interesting!

I think you meant to say, "When the F22, F/A-18, and Eurofighter Typhoon can fly straight-up (ie. vertical), then according to the in-game physics, so can the A-10, Su-25 (bomber?), and civilian planes should be able to fly vertical?" In other words, the in game physics are unrealistic.

I tend to agree, however it would be nice to have at least one or two jets (especially within multi-player servers) that can fly vertical such as the F-15 within the game, but it maybe the game engineers ran short on time and resources, and had to compress aircraft features (or capabilities) into fewer jets, or had to work with what jets they already have within the game.

I must agree, I prefer flying the F-15 within game, but there currently are no F-15's within the vanilla game! I tend to agree the bombers should likely not be able to fly vertical, however on most servers, most map administrators will likely not put more than a couple or few planes on the maps at one time due to system resource requirements. So likely map administrators will only add bombers, and maybe one AA A-164 if you're lucky and pretty much useless unless there are plenty of enemy aircraft. (ie. AA only version of Neophron or A-164, etc)

But with that stated, there's this new virtual ammo vehicle and hanger idea, where players might be able to change load-outs extremely easily within a hanger.

With what is all stated here, it sure adds weight to my argument concerning safe landing of the Neophron! The Neophron acts like the flying weight of a tank, for which is manageable until landing. Landing on such a short runway of even the main airports, is nearly impossible with the Neophron! From my point of view, I think this jet needs double the length for safe landings.

Also, the Neophron should likely not be able to fly vertical with dumb bombs, etc. However, I'm more for waiting until the virtual ammo selection hangers are fully implemented and operational. However, I could always drop all munitions after take-off and then perform my aerobatics. But then there's currently absolutely no possibilities of performing aerobatics immediately after take-off unless I can somehow drop all munitions prior to take-off.

So I think we can all see some of the possible limiting factors here!

Sorry. I'm not sure if my comment is relevant to this bug. I'll delete my previous comment.

At first it was difficult to read your bug or feature request, and I assumed this bug were relevant to my bug.

Concerning your bug is feature request, I think I now see what you are saying. Part of which; some jets are not able to land at the smaller airfields.

In my opinion, none of the other airfields are jet capable, except the salt flats (or flat desert on Altis) aside from the major airports. The runways at the remote airfields are obviously for single and twin engine light aircraft.

If you've ever been around aircraft, you would easily understand safe landings and take-offs require a specific length of runway, of which, jets usually require very long runways for safe take-offs and landings!

And concerning my first (now deleted) comment, the Neophron is very likely designed for much longer runways similar to the Space Shuttle!

COPYING EXECUTABLE IS PROBABLY NOT A GOOD IDEA.
This is another reason why I relish the Linux command line console. One cannot screw-up by confusing the two "ln" or "cp" commands when typing. Click and play Windows interface is evidently too easy to perform incorrect actions, I must have copy/pasted the darn program into my desktop games folder.

So this bug is caused by two issues, missing files and missing depends when incorrectly copying the arma3launcher.exe executable to the desktop instead of specifying a shortcut. (Albeit, the later is dumber, but quite easy to do so from within Windows.)

UPDATE: I was just thinking, although upstream and Microsoft's responsibility, within a Linux console symbolic links (or just links) are often highlighted or colored differently within text when compared to other file names. Microsoft should change the gamma color for the icon when they're links. Appending "Short Cut" to the file name isn't the brightest idea, nor is putting a tiny arrow at the bottom corner where the arrow can be easily looked using larger resolution monitors. (And I do have one of the larger resolution monitors where I have to screw with the DPI to get text larger, but icons likely remain the same size.)

APPARENT HANGING OR GHOSTING ARMA3.EXE PROCESSES
After solving this, I'm also finding a separate intermingled bug (or maybe a now planned feature) where the arma3.exe executable cannot be run via either, shortcut or directly. It would appear this is now disabled without steam running in the background prior to executing. The only shortcut to arma3.exe that does work, albeit not a direct shortcut to arma3.exe, is a shortcut pointed towards, "steam://rungameid/107410" Without Steam running, executing arma3.exe directly results in the arma3.exe hung process in the background apparently doing nothing. Once steam is working, executing arma3.exe directly or by shortcuts is then possible. I'm not seeing anything really relevant currently within a bug/feature search results.

I'm almost absolutely positive I selected "Create Shortcut to desktop" for the executable files within "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3".

Maybe Windows 10 is doing something differently versus Windows 7 or Windows 8.

For verification, I'll go back later and verify that those are shortcuts, but I do believe they are shortcuts, and we do not see this problem with Windows 7 and Windows 8 with the same exact files. (I still have Windows 7 on one partition, with a Windows 8.1 partition upgraded to Windows 10.)

Exactly as I speculated, but I must say, I so much more enjoy the logging/debugging facilities of Linux/Unix versus Windows! All what you just stated, I can see so easily via simple text log files.

The "C:\Users\roger\Desktop\Games\arma3launcher.exe" file is a simply Winodow's shortcut. (Or link file within Linux/Unix.) According to your explanation, the arma3launcher.exe is looking for it's program files within ./ or the immediate folder the program is executed from. The arma3launcher should be programmed to look either within both the immediate folder and "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3" folder, or just statically using "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3". (Forgive my previous confusion, I tend to get AND|OR logic mixed-up easily for some reason after twenty years of programming!)

I get this bug when either using a desktop shortcut, or trying to execute any ARMA 3 desktop shortcut. And further makes sense now as to why all desktop shortcuts fail launching the launcher?

Under the current arma3launcher code, users must either navigate to the "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3" or use the Steam interface to start ARMA 3. (If I'm not mistaken, using the Steam interface still avoids the arma3launcher and immediately executes arma3.exe?) All other methods of execution likely result in the above bug description, or with no debug log file on the desktop but with a backgrounded arma3.exe process, likely in a slave mode awaiting further arma3launcher commands.

This bug seems like an issue with folder and path names within the source code. (ie. Include paths and Include path names.)

I can run the arma3launcher.exe directly under the ARMA 3's program folder. (ie. "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3")

I cannot run the arma3launcher.exe via a desktop shortcut, or the arma3.exe from desktop without Steam running and have the Launcher appear. The arma3.exe process does show active though within the Task Manager. (ie. Likely the system might be looking for the included libraries from c:\Users\roger\desktop instead of the arma3 installed program folder.)

The arma3.exe Desktop Shortcut has the following contents, "arma3.exe4C:\Program Files (x86)\Steam\SteamApps\common\Arma 3h-noSplash -Skipintro -world=empty -noLogs -cpuCount=4 -exthreads=7 -maxMem=32768 -maxVRAM=3712 -enableHT" (I forgot to check for the "-noLauncher" yesterday.)

Like I said, the reason why I think this is a simple programming path name or path location issue, path name or path location bugs are very common here on Linux as well and assume the "Includes (paths)" are within a specific location when the Includes are not. As such, you see the exact problems we're seeing here. (But why is the arma3.exe in the background does sound odd to me. As if the launcher might be appearing on a different monitor/display when all other displays are disabled.)

If you still need further information, such as the Fusion Enable Disable, can I acquire such files and info from microsoft.com?

Sun Aug 2 18:58:58 UTC 2015: Also, I'm setting several loops in some current bugs after my experience with Windows 10. Some features (or bugs) are now working upon initial execution of arma3.exe without having to use the arma3launcher under Windows 10. Whereas in the past with Windows 7, 8, or 8.1, the features required the arma3launcher in order to be detected and work within the 3D world. I likely need to run the arma3.exe and arma3launcher several more times in order to properly dictate what is happening within text.

Mon Aug 3 01:23: Oops. Now that I'm in Windows and looking at going over enabling Microsoft .NET Fusion logging, I see that you're just sending registry settings within a compressed archive. After performing all this manually and verifying with your registry files, I get absolutely no Fusion log files written when running the arma3launcher, whether from the desktop or just clicking on the arma3.exe desktop shortcut with no Steam running. However upon running the arma3launcher.exe from the C:\Program Files (x86)\Steam\SteamApps\common\Arma 3 folder location, Fusion log files are then written within two folders. I think this further cites that something is going on with the Include files not having a global/static search location. (ie. Cannot find Include files within subfolders of C:\Users\roger\Desktop ...) NOTE: Also I already have Microsoft Visual Community installed, albeit regretting it now as it was only a 30 day trial. So I do have fslogvw.exe installed and running.

Mon Aug 3 01:42: I now reproduced the bug with ensuring steam.exe is running in the background and trying to run the arma3launcher from a desktop shortcut. Which spawns this bug's "System.IO.FileNotFoundException: Could not load file or assembly 'SharedResources, ..." bug/exception. With the Fusion logging running as well and then compressed the archive accordingly. (Took the liberty of using 7z compression, as 7-zip seems to run great here.)

Yup. Just updated my information as well. Personally, I think this looks quite unprofessional carrying-on such a conversation above.

$ ls /mnt/windows10/Program\ Files\ \(x86\)/Steam/SteamApps/common/Arma\ 3/Launcher/ -al
total 3.3M
drwxrwxrwx 1 root root 8.0K Jul 28 11:01 ./
drwxrwxrwx 1 root root 8.0K Jul 28 11:01 ../
drwxrwxrwx 1 root root 0 Jul 28 11:01 cs-cz/
drwxrwxrwx 1 root root 0 Jul 28 11:01 de-de/
drwxrwxrwx 1 root root 0 Jul 28 11:01 en-us/
drwxrwxrwx 1 root root 0 Jul 28 11:01 es-es/
drwxrwxrwx 1 root root 0 Jul 28 11:01 fr-fr/
drwxrwxrwx 1 root root 0 Jul 28 11:01 it-it/
drwxrwxrwx 1 root root 0 Jul 28 11:01 pl-pl/
drwxrwxrwx 1 root root 0 Jul 28 11:01 pt-br/
drwxrwxrwx 1 root root 0 Jul 28 11:01 ru-ru/
-rwxrwxrwx 2 root root 144K Jul 28 11:00 SharedResources.dll*
-rwxrwxrwx 2 root root 568K Jul 28 11:00 SteamLayer.dll*
-rwxrwxrwx 2 root root 259K Jul 28 11:00 SteamLayerWrap.dll*
-rwxrwxrwx 1 root root 127K Jul 28 11:00 Utils.dll*
-rwxrwxrwx 2 root root 928K Sep 4 2014 Xceed.Wpf.Toolkit.dll*
-rwxrwxrwx 2 root root 2.7K Sep 6 2014 Xceed.Wpf.Toolkit.txt*
-rwxrwxrwx 1 root root 608K Jul 28 04:11 config.bin*
-rwxrwxrwx 1 root root 294K Oct 25 2014 log4net.dll*
-rwxrwxrwx 1 root root 12K Sep 4 2014 log4net.txt*
-rwxrwxrwx 1 root root 5.1K May 26 18:26 logger.xml*
-rwxrwxrwx 2 root root 12K Jul 28 04:04 notifyicon-wpf.txt*
-rwxrwxrwx 2 root root 193K Sep 6 2014 protobuf-net.dll*
-rwxrwxrwx 2 root root 12K Sep 4 2014 protobuf-net.txt*
-rwxrwxrwx 2 root root 143K Mar 26 18:15 steam_api.dll*

Shrugs. My ARMA 3 Launcher still refuses to open. I get no exception. But there is an "arma3.exe" process within the task manager. And all files are verified using Steam.

Looks like I'm looking elsewhere for the problem.

UPDATED: On the flip, just looks like I narrowed the problem down significantly just now.

UPDATED 02:50 AUGUST 01 2015 UTC: Bingo! I have this same apparent exception, "System.IO.FileNotFoundException: Could not load file or assembly 'SharedResources, Version=1.2.131.647, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified." And I believe I know the exact cause of this problem now. Verifying files is likely not the solution, and marking this bug as resolved probably is not correct. I would post the likely cause of the problem and the temporary workaround, but BIS Wizard has yet to reply to his above private messages to myself.

I've unchecked those ARMA 3 Launcher options (mentioned within Bug #24041) after re-installing (ie. repairing) MS C++ x86 redistributable and haven't seen a crash for the past several hours. Although I've also upgraded from RC to 1.48.

Although some others have experienced crashes and are posting to Bug #24041

Adam: Negative Adam. This bug originates with the ARMA 3 Launcher period. Having users manually reinstalling drivers, downgrading drivers, reinstalling DirectX for a verified bug with the ARMA 3 Launcher are only going to give users further headaches!

Matter of fact the URL & section you reference, I happened upon long ago searching and realized immediately the section referenced (with albeit generic sounding advice) was not the solution for a well kept box or operating system; and knew this bug was very likely originating from within ARMA code itself due to the lack of problems elsewhere within the operating system.

UPDATED: However I will make further note I did recently just install MS Visual Studio Community within the past month. I only started using the ARMA 3 Launcher due to using the execute, TrackIR USB hardware was loosing detection. Using the Launcher, TrackIR USB hardware is no longer lost. Installing MS Visual Studio Community required uninstalling "Visual C++ 2013 Redistributable x86) etc, and letting the MS Visual Studio Community install it's own version else MS Studio Community would not install at all. I'm wondering if others have also installed MS Visual Studio Community?

Within Bug #24041 "Unusual Exit Code and game crash on MP servers" and at Comment #94730 by 10Cwaites on 2015-06-24 01:20, he stated configure the following within the ARMA 3 Launchers Configuration Settings:

1. "Disable Launcher's UI hardware acceleration"
2. Action after game start: "Close launcher after clicking play"

I can confirm omitting either, and the game will still crash. I've yet to see any crash with the above settings.

As I briefly speculated in my reduplication scenario, it maybe because of using the Artillery Computer map for mortars, as I haven't seen this bug elsewhere within ARMA 3 for the past month(s) until using the mortar with Artillery Computer map.

I can reproduce this bug pretty redundantly by logging into the 69th Infantry Division (http://sixnine.enjin.com/) and using the "FSG Gunner" profile. Setup a mortar bipod/tripod using the ammo truck in the parking lot, assembling the mortar next to the ammo truck. Lob some flares/HE rounds and after awhile, the game crashes. Not sure if a "FSG UAV operator" spotting enemy is also required to reproduce the crashes.

Sometimes I can go for awhile without seeing a crash, but the bug is pretty imminent in that it will eventually appear regardless.

I can reproduce this bug pretty redundantly by logging into the 69th Infantry Division (http://sixnine.enjin.com/) and using the "FSG Gunner" profile. Setup a mortar bipod/tripod using the ammo truck in the parking lot, assembling the mortar next to the ammo truck. Lob some flares/HE rounds and after awhile, the game crashes. Not sure if a "FSG UAV operator" spotting enemy is also required to reproduce the crashes.

Sometimes I can go for awhile without seeing a crash, but the bug is pretty imminent in that it will eventually appear regardless.

As far as I know, there is no default Australia map for ARMA 3. (You're intending to say either Stratis or Altis.)

You can translate the graphical error into text here, so other's searching for this bug would be able to either find this bug easily or tag the bug as a duplicate.

There are many of the same (likely duplicate) bugs opened elsewhere. I think Microsoft should be made to clean-up these duplicates for not making copy/pasting the error using text easy for users!

Updated Mon Jul 6 16:04:56 UTC 2015: A little more research elsewhere shows you're using an add-on Australia map. As I briefly speculated in my reduplication scenario, it maybe because of using the Artillery Computer map for mortars, as I haven't seen this bug elsewhere within ARMA 3 for the past month(s) until using the mortar with Artillery Computer map.

I, myself, have reinstalled "MS C++ x86 redistributable" and haven't seen a crash so far, although I've also upgraded from RC to 1.48.

So it's completely unknown if 1.48 or the redistributable solved the problem for me. I think I have seen one sporadic crash since, but I didn't bother spending time trying to forcefully extract details using this operating system.

If this were Linux/Unix based, I'd have the log files copied and compressed within several seconds.

Guess we'll wait and see if the original author is still experiencing this bug.

I can reproduce this bug pretty redundantly by logging into the 69th Infantry Division (http://sixnine.enjin.com/) and using the "FSG Gunner" profile. Setup a mortar bipod/tripod using the ammo truck in the parking lot, assembling the mortar next to the ammo truck. Lob some flares/HE rounds and after awhile, the game crashes. Not sure if a "FSG UAV operator" spotting enemy is also required to reproduce the crashes.

Sometimes I can go for awhile without seeing a crash, but the bug is pretty imminent in that it will eventually appear regardless.

Yes this looks fixed when starting the Launcher (without Steam already running in the background) and then joining a multi-player game.

I did accidentally initially start Steam, but should have stopped all instances prior to testing only using the Launcher.

So looks like version 1.50 somehow fixed this bug. I have also not tested further on Windows 10. (Windows 8.1 partition was used for upgrading to Windows 10.) Other operating system ports, such as Linux, were not tested as the Linux port does not apparently support any detection of input devices. (It maybe qjoypad or other applications can adequately handle such tasks or functions, and with far better reliability versus Saitek's applications.)

Just tried to mark Fixed in version 1.50, but was denied. God how I enjoy open source bug trackers versus corporate! ;-)

I avoid using the launcher because of this and run the game directly after starting Steam on Windows. Nor have I tested using the launcher with version 1.50.

I'll try to remember to test later on.

On Windows 7; TrackIR 5 software is already started.

ARMA 3 is started long after TrackIR software has started.

Start ARMA 3 (arma3.exe) separately from the Steam menu.

Prior to the last month's release, I had no problems. After last month's release, I now always have this problem.

And the quickest and easiest method is just to go into the ARMA 3 Controls Menu as you stated. To me, this is obviously an ARMA 3 issue. If I were on Linux, I could easily run things through gdb or strace, for which I pretty much already use the Windows equivalent and you can see within the log the TrackIR is not being picked-up upon arma3.exe execution.

UPDATED 2015.06.04 12:41 UTC Looks like I am getting TrackIR initialization upon startup by watching the LED lights on the TrackIR 5 device. However upon entering a multiplayer game, the TrackIR 5 light deactivates. The light then reactivates upon going into the Game Controller settings.

UPDATED 2015.06.04 03:06 UTC Further research shows this bug is only occurring when only joining a multiplayer server. Seems to be working when only using the Editor or single player mode. Would appear I need to perform further tracing using the Process Manager noted above.

UPDATED 2015.06.04 20:50 UTC Tested Arma3Update146RC, and there are no multiplayer servers available to join! I have tested creating my own multiplayer LAN session, and TrackIR works there. So back to stable 1.44 to see if multiplayer LAN is effected. (Just wish Steam would cache these extensive downloads for testing bugs against other versions as I only have DSL! One hour download times!)

UPDATED 2015.06.05 01:26 UTC Just tested current 1.44 stable and find even the local LAN multiplayer has no apparent problems either. So just when connecting to remote servers as a client, is there then problems with TrackIR 5 devices disconnecting requiring the workaround mentioned above. Unknown if this affects Arma3Update146RC, as there were no remote test servers available to test on but is very likely as this bug has yet to be verified by in-house developers.

UPDATED 2015.06.07 01:18 UTC Using the ARMA3 Launcher, avoids this bug as well. This bug is only seen when executing first Steam.exe and then arma3.exe.

Without the use of strace (or at least GDB even though compiled without flags), I cannot further pinpoint this issue as it's likely your code causing problems.

The ports this device is plugged into, has always been used in the past without issues under Windows 7, and even in Windows 8/8.1 for which there are more joystick problems.

Give me two seconds with the abilities of strace or GDB, and I'll have this problem targeted. Keep giving me only proprietary code, and all I can give you are the prior comments.

UPDATED 2015.05.25 21:30 - I've just added a Windows Process Monitor file (Windows' equivalent of strace). You may need to add a filter for "arma3.exe". I simply had Windows Process Monitor open in the background and started arma3.exe, went directly to the controller menu and you can see TrackIR being only initialized until this point. I then immediately stopped Process Monitor to avoid any arma3.exe exit system calls prior to exiting. Your answer lies within this tracing, and to why TrackIR is not being initialized upon the start of arma3.exe.

UPDATED 2015.05.25 21:50 - Within the Windows Process Monitor I likely just posted, set a filter for Process is "arma3.exe" and (likely not needed) "TrackIR5.exe" Click apply and you'll only see arma3.exe and TrackIR5.exe process, if not already as my file likely only contains arma3.exe processes. Set another filter for "contains" "track". You'll notice call "CreateFileMapping" (related to TrackIR) fails initially with "File Locks with Only Readers" error. And then you'll notice near the end of the log, CreateFileMapping (likely when going into the configure/controller menu), you'll finally see success. (I also noticed the Buffer Overflow errors, of which most of the Buffer Overflows appear to occur within the TCP/IP or network stack.)

BadVolt: Bug #24463 is a duplicate of Bug #0014924

I didn't get much with the logging of ARMA 3, but I think I have something. The following is reported when going into the Configure > Controller menu.

I'll try disconnecting other joysticks before assuming this is a TrackIR axis issue. Also attached arma3_2015-05-25_13-20-05.rpt in case there's prior input initialization failures or lack of initialization.

13:20:22 Attempt to override final function - rscunitinfo_script
13:20:22 Attempt to override final function - rscunitinfo_script
13:20:23 SimulWeather - Cloud Renderer - noise texture file is not specified!
13:20:25 SimulWeather - Cloud Renderer - noise texture file is not specified!
13:20:29 EPE manager release (0|0|0)
13:20:29 EPE manager release (0|0|0)
13:21:25 Invalid Joystick Axis!
13:21:25 type=702 (7), dwOfs=32, name=Move Up/Down
13:21:25 GUID = a36d02f3, c9f3, 11cf, ...
13:21:25 wUsagePage = 5, wUsage = 26
13:21:25 Invalid Joystick Axis!
13:21:25 type=802 (8), dwOfs=36, name=Move Right/Left
13:21:25 GUID = a36d02f3, c9f3, 11cf, ...
13:21:25 wUsagePage = 5, wUsage = 24
13:21:25 Detected Joystick: Saitek X52 Pro Flight Controller
13:21:25 0 ... STR_INPUT_DEVICE_STICK_AXIS_X [1,30]
13:21:25 1 ... STR_INPUT_DEVICE_STICK_AXIS_Y [1,31]
13:21:25 2 ... STR_INPUT_DEVICE_STICK_AXIS_Z [1,32]
13:21:25 3 ... STR_INPUT_DEVICE_STICK_ROT_X [1,33]
13:21:25 4 ... STR_INPUT_DEVICE_STICK_ROT_Y [1,34]
13:21:25 5 ... STR_INPUT_DEVICE_STICK_ROT_Z [1,35]
13:21:25 6 ... STR_INPUT_DEVICE_STICK_SLIDER_1 [1,36]

Further removing the Saitek joystick and restarting, only shows this within the logs when going into the Configure > Controllers menu:

13:27:56 SimulWeather - Cloud Renderer - noise texture file is not specified!
13:27:58 SimulWeather - Cloud Renderer - noise texture file is not specified!
13:28:01 EPE manager release (0|0|0)
13:28:01 EPE manager release (0|0|0)

Such as?

About the only other odd thing, I did go to Windows Update for Windows 7 several times after the latest update.

It is sad game isn't available within Linux, else I would be happy to provide an strace and GDB log of the problem.

The only other idea, I could switch USB ports, as I am using USB ports and not the a hub. Also, the TrackIR software does show the device properly working prior to the game loading.

Obviously and based on my experience with proprietary software, the ball is obviously within your ball park here.

I could also turn on logging or debugging within the game and maybe provide the log. But I speculate this is going to provide little useful information when compared to strace and GDB.

/windows7/Windows/Minidump/

You may need to setup the system to dump minidump files to this folder because Windows is not user friendly debuggable.

CUSTOMIZING THE MICROSOFT WINDOWS MINIDUMP SETTINGS

To customize how Windows handles and creates the minidump, follow the steps below.

    Click Start, Settings, Control Panel, and open the System icon.
    In the System Properties window click the Advanced tab.
    Click the Settings button under Startup and Recovery.

Within this window you can change where this file is saved and how big of dump you want. Changing the size of this dump can be helpful if you're encountering a frequent error and the small dump is not giving you all the information you need.

If it's not there and you have Windows 7, you may need to read, "CUSTOMIZING THE MICROSOFT WINDOWS MINIDUMP SETTINGS" section within my above post. From memory, there's also some variables that can be customized.

mdmp sounds like an abbreviation for the operating system mini-dump files. (These are found within the operating system folders, and everybody should be able to advise of the proper folder location.)

I do not know what bidmp means.

If BIS Wizard performed a diff of the logs and PhysX is not being initialized, then you might seriously want to perform another reinstall of PhysX and completely uninstall and reinstall your graphics drivers. (I would perform both, reinstall of PhysX and uninstall/reinstall of the drivers!)

I'm also seeing a crash (Not Responding or CPU run) at random during game startup after the last upgrade. Also, Track IR is not being detected on initial game start until going into the Configure Controller menu. Once done, the game seems to not respond (or CPU run) while initially logging into a game server. Once the game is restarted (no cold boot), the game seems to run fine. ... An interesting issue and might be related.

Apparently now fixed within the Change Log:
http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog/page54

20-05-2015
EXE rev. 130815 (game)
EXE rev. 130818 (launcher)
Size: ~84 MB

DATA
Fixed: Player can now vault (step over) while standing with binoculars

But as usual, always test to verify first that the bug is really absolutely fixed before closing this bug!

Read Comment #0095386 above.

Also read my notes concerning reinstalling/repairing MS C++ x86 redistributable, as I recently installed MS Visual Studio/Commmunity. Seems the MS Visual Studio/Community version of the MS C++ x86 redistributable may be flawed or incompatible.

Schultz8100: Read Comment #0094730 by 10Cwaites on 2015-06-24 01:20

10Cwaites: I've unchecked those options after re-installing (ie. repairing) MS C++ x86 redistributable and haven't seen a crash for the past several hours. Although I've also upgraded from RC to 1.48.

10Cwaites: Yes I made those exact changes within the launcher.

One thing I did do within the past month, is installed MS Visual Studio Community. The MS Visual Studio Community required uninstalling the MS C++ x86 redistributable, else the install would error. Uninstalling the MS C++ x86 redistributable allowed working around the install issue, and MS C++ x86 redistributable was reinstalled by MS Visual Studio Community. So it maybe this bug might be caused by this if you can verify you to have been playing around with similar packages or performing similar actions.

I have repaired the MS C++ x86 redistributable package. (ie. similar to reinstall as the package was already installed);

MS C++ x86 redistributable
vcredist_x86.exe

But so close to 1.48 release, this bug maybe solved already.

(I wish the launcher would do something useful, like the ability to switch between locally installed Stable, Developer, and RC versions instead of having to download each version each time. Benchmarking and bug testing is hell on DSL or anything less than Cable Internet speeds!)

BIS Wizard: I merrily referenced a work around.

Referencing 10Cwaites's above comment; I can confirm omitting either configuration option, and the game will still crash. I've yet to see any crash using his above mentioned settings!

Yup... I haven't seen any of these crashing game bugs until using the GUI launcher. And when the GUI launcher was first instituted, I started also having TrackIR problems.

I prefer starting ARMA 3 using the executable.

Just experienced this bug and performed Comment #0094730 by 10Cwaites. Hopefully all my crashing will finally stop. If not, I'll report back or away for the next patch. Could also be something with minimizing the game and/or using TeamSpeak.

This bug appears to be a duplicate of Bug #14924, "Opening joystick config in game results in joystick disappearing as input option".

Bug #14924 is already acknowledged with BI developer feedback and Bug #14924 already has 94 votes.

As of 1.46, I don't think there's an empty click sound anymore!

If I'm not mistaken, it's easily mistaken for being resolved or being fixed. (When one resolves something, something is usually fixed.)

ie. http://feedback.arma3.com/view.php?id=9319#c91342

Instead, Status should likely show "Closed" and marked as "Duplicate" instead of "Resolved". Basically semantics is involved here, and I think Bugzilla also uses the more easily understood marking of showing a bug "Closed" and "Marked as duplicate" status. (However, some do not mind others wrongly assuming incorrect meanings. Shrugs.)

Subscribers to this bug should also realize, Bug #18397 "Flares are useless" (along side Bug #9319 "Flashlight is too dim...") is also relevant to this bug.

In brief, this bug should also be marked a duplicate of Bug #18397, but there's probably only one slot for specifying one bug number.

The "Resolved" status is kind of a misnomer. More like "Resolved" due to being a Duplicate. However I've already pointed this out within another post, and the status itself should state "Duplicate" to prevent comments wrongly assuming.

Humorous, as there's few available sea worthy methods for deploying as of yet. But you are likely correct, in that there's no fatigue. On the flip, why would you want to deter further use of sea assets at this point of the game? ;-)

Shrugs. Maybe the 3D modeller got laid-off?

More importantly, they need a light switches for indoor lights!

Just for kicks, I've seen an issue where TrackIR controller is also lost, but only when not using the ARMA 3 Launcher and just prior to logging into the 3D world of a multiplayer server game.

It might be worthwhile to see, if starting ARMA 3 from the ARMA 3 Launcher, instead of the arma3.exe executable. To do so, make sure Steam is not running and/or stop steam.exe. Launch ARMA 3 using the ARMA 3 Launcher. (ie. arma3launcher.exe)

I really doubt this will workaround this issue, but it's worth.

PabloTheGreat1: You are slightly incorrect assuming the only time this bug occurs is when people enter the ESC Configure panel, or press ESC.

On my Windows 8.1 platform, this bug can occur at anytime while flying the simulated aircraft without pressing the ESC key or entering the Configure panel.

And the only method currently able to reproduce this bug, is by pressing the ESC key or entering the Configure panel. However, DarkWanderer has stated he also now has reproduced this bug within a memory debugger under Windows, and needs further testing from Windows 10 users. (ie. See DarWanderer's previous comments for testing instructions.)

As previously mentioned above within comment #92289 above: Please refer to Bug 0014924, "Opening joystick config in game results in joystick disappearing as input option"

All of these bugs appear to be duplicates of Bug #14924. Bug #14924 is already acknowledged with BI developer feedback and Bug #14924 already has 94 votes.