This bug still persists within Linux ports 1.64 version.

I didn't think of double checking to see if the server is running with the updated patch.

I'll verify integrity, as a last resort as I've never had a problem in the past except during initial alpha/beta releases.

This bug is still not fixed.

They also desperately need to get audio (ie. microphone) working for the ARMA client within Linux! Steam even pickups the microphone audio just fine using something like the following:

Can confirm this bug when using my Saitek X52 Pro joystick as well with analog thrust mapped!

I say, leave this bug unfixed.

This is not bug is not solved that I'm aware of.

I would presume the air transport vehicles can also transport the heavier armored vehicles too using the vanilla version?

I think the UAV shake is now occurring because the AI system is fighting with the manual controls, etc.

Ah. I just heard about this and might have part of the golden bee bee.

Using the latest stable, 1.62.

I just noticed the IR flares will launch as yellow flares, and as such a new bug?

I think we can close this bug now. This appears fixed within 1.62 version of Apex/Tonoa.

In my experience, using any binocular or telescope regardless of magnification factor, the viewer will see more stars and the stars will appear brighter.

I scanned the post by Tillion, but could not distinguish the sentence he specifically states lights can be controlled by other vehicle slots. The post mainly detailed size and shape of lighting diameter.

Oh Wow Wee! You mean this issue is still open??

Wow! Night sky within Apex/Tanoa RC is looking really nice and dark, with nice bright stars!

I landed finally using 2016.06.27 version... not sure if this is fixed yet though. Damage sensitivity still seems extremely high.

Players should be able to just walk away from such incidents, unless they had a rotor get stuck-up their butt.

I agree. And I think the situation is two fold here. 1) Helicopters always explode on tip-over, when they should not with most being survivable and, 2) aircraft should have different non-explosive damage models.

The two videos show explicitly what should occur when entering the water, as long as no major electrical components acquire any moisture. I would imagine the landing gear contain all water proof parts, and all wiring is run elsewhere instead of within the bottom of the craft.

I noticed last night while simulated flying of the vortex aircraft, merrily touching the water with the wheels caused the aircraft to explode. Likely should be a new bug, as this seems dependent only on vortex aircraft.

Yup, using Tanoa/Apex developer snapshots, would really be nice to have amphibious ships capable of transporting heavy armor. Or some sort of heavy transport aircraft.

Ditto. I believe all vehicles likely on all runways, cause rising dust PhysX effects. Or it could just be local to this specific runway.

I'm wondering if the camera shake is causing excessive shaking while auto-hover is enabled within helicopters and VTOL aircraft, while targeting?

Using and getting experienced with Tanoa/Apex here on developer snapshots, the VTOL (vortex) aircraft still do not transport vehicles larger than common ordinary vehicles. (With the possible exception the NATO VTOL can carry a Marshall vehicle.) As such, all heavy armored vehicles still need to be driven to area of operations. And as such, the heavy armored vehicles remain at the base or around the base. So with Tanoa, would be nice to have a hovercraft or other boating solution. Similar could be stated for Stratis & Altis islands, as they are surrounded by water, and with a faster boat, could be much faster than driving.

I see the following errors/warnings at the beginning of the server logs:

Yesterday, the developer branch dumped my joystick settings. Wonderful, @#$@#$.

What version are you using? I'm using Tanoa/Developer snapshot and am starting to see some anomalies with the thrust axis again on a Saitek.

Thank you. I happened to catch a similar response of yours within another bug report elsewhere, but not before I attempted to download the daily developer snapshots for several days using ADSL.

Returning to downloading RC still ran about six hours, but unlike the impossible 6-24 hour download times of the Developer snapshots.

I thought the ARMA 3 Tools GameUpdater was an incremental update program, similar to RSync or Git? Anyways, we can close this bug as I'm sure everybody his on the right track, or (for all I know) I think the right track.

Thanks for your attention concerning the quality, although a multi-platform game is almost just as important. (An unrelated note, I'm literally pulling my hair out after working with a software tuner within Windows, even while trying to desperately utilize the software tuner tools within Cygwin.)

Suggest closing this bug, as it's too general, and the purpose was to highlight quality issues.

One, if not all of these bugs have already been posted at one time or another. (ie. "Error compiling shader PSSpecularAlpha" for using old mods from older ARMA 3 versions.) So since my download took a long time over DSL, a lot of these bugs are already going to be already in processing.

The mods were all disabled within the stable version, but starting the new version experienced some Workshop mods still being enabled. (ie. @Nam) This required using the RC snapshot arma3launcher.exe to further ensure that all Workshop mods were further deactivated. (ie. @Nam)

My main point was, I encountered numerous bugs or stability issues with this RC version within a very short period of time. (No need to apologize, as I'm volunteering. ;-) Since I experienced so many bugs, and not being able to really spend much time at all for further bug searching within the 3D world, felt it was important to report this aspect.

My question was, is the RC snapshot going to see any incremental updates, or should those of us testing just move onto the daily development snapshots.

On the flip, although I was only able to spend 20 seconds within the 3D editor, I'm impressed with the engineering and direction of this 3D editor. And what coding style I have seen, albeit most is proprietary, I am also somewhat impressed with the clean coding style and the direction of a multi-platform environment.

I have a gut feeling with the bugs I've witnessed so far, I should definitely migrated to daily development snapshots, as most are likely going to be fixed.

Ditto here.

Here's a copy/paste of the error GUI dialog. CTRL-C over the error GUI and then paste elsewhere using CTRL-V. Copy & Paste via keyboard.

---------------------------

Arma 3

File C:\Users\roger\Documents\Arma 3\missions\Phoenix_Domination_V4G.Altis-20150605\mission.sqm, line 0: '.': '�' encountered instead of '='

OK

Upon final exit, I get a further error:
Exit Code: 0x000000001 UNABLE_TO_INIT_DXGI

Likely an unrelated error.

Slept on this and realized the slope of the center of gravity is similar to the center of gravity during take-off. When thrust is applied or removed, the slope or the speed rate the center of gravity is raised or lowered is applicable to the rate the thrust is applied or removed.

When landing, the slope of the center of gravity is likely not being lowered fast enough. Likely the slope just needs to be inverted to the slope of the center of gravity during taken-off. Hence, the model is apt to always tip-over during landings as the center of gravity is not lowered fast enough.

Also during rough landings, the gear is likely integral to the framing of most vehicles, as for the past 20-30 years vehicles have been designed to collapse around the passengers. However 3D model designing of the gear collapsing might be more tedious then adjusting, or even inverting the slope of center of gravity as mentioned above.

Bottom line, there may not be any slope of raising or lowering the center of gravity of the model, and these values might just be statically assigned. In which case, would be easier to just assign a strength of impact or collision equation or limit value until an explosion is caused. (ie. hardness of landing) Also, delaying an explosion can also be easily integrated alongside further simulating realism. Randomness can also be included, as we cannot account for every factor, even in real life.

It really kills me (even further than being dead after the explosion) to see all my passengers dead every time I execute the auto-rotation maneuver almost flawlessly.

I could probably upload hundreds of redundant tipping-over and exploding helicopters screenshots and videos!

My last *.mdmp file I have was arma3_2015-09-06_23-41-36.mdmp.7z. I see no other *.mdmp files, and I do not know why. (ie. If I have a arma3_2015-09-06_23-41-36.mdmp.7z, where is the original I ask myself.)

Oh wait, I replaced the Windows system debugger, and now they're being handed to Windbg, per the Additional Information. But then there is nothing within my /mnt/windows7/Windows/Minidump/ folder. (Performing a more extensive search for the Mini Dump files.)

UPDATED 2015.11.24 0032: I went back and restarted ARMA 3 developement version and I am not getting handed a Mini Dump file via WinDbg.exe. I am guessing at this point ARMA 3 is not loading far enough or executing far enough to generate a Minidump file. I'm guessing the answer to this bug already lies within the attached files already.

UPDATED 2015.11.24 0037: Examing the .rpt file a little further, I see a "error X3501: 'PSPostProcessGlowNewFinalNightNone': entrypoint not found" and seems to be a subsection of the DirectX 11 Engine initialization. No entrypoint might be as critical as a file not found or function/variable not defined.

JustinK: I was getting this error with apparently 1.54 RC. (Forgive me for apparently forgetting to further state within the description, as I do not think the version slots have a further list of possible versions to file against.)

Odd little error as I no longer see this with the current 1.54 version. I was almost ready to speculate this was related to the memory run being seen within the server application, but now remember I wasn't even starting to run the client. I'm currently starting & running the now stable 1.54 release without this error. Wonder if it's something localized to the ARMA Tools I used to download this version with? Or something localized to the other than stable branches?

I just re-executed the GameUpdater and still getting this error & crash.

After disabling the "-noLogs" parameter, I now get a "Error creating Direct 3D 11 engine"

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.