The only time I've experienced dropped frames nowadays, are when map scenario makers bump the AI skill level to insanely intelligent/smart levels to cope with 25-50+ players on a server. When playing on such server map scenarios with only approximately 1-5 people, the actions of the AI enemy become so quick, it appears the AI enemy drop frames between movements. (eg. Enemy AI move from resting stance to firing stance within apparently one frames per second!)

Sounds about right to me.

Your imaginary 10-30 people sitting in an EVAC chopper, tipping over and exploding constantly occurs within the game.

Try disabling third party mapping software.

Last night I used the Game Updater and the updater downloaded ~13 GB of the total approximate ~26 GB developer snapshot/archive, although I have not used the Game Updater (or synced) the archive for almost ~2 weeks. Seems a bit high unless they're updating all the graphics. I'll try checking this again within 7 days, or next weekend.

The Jets DLC is bringing engine flame and can only be seen internally from the rear of the aircraft (eg. using 3D view), but not the afterburner thrusters glow which extends beyond the frame of the aircraft during afterburner usage.

I completely agree!

I believe you're stating TrackIR depth translation (eg. XYZ) rather than just tracking X and Y angles.

From memory after the previously mentioned incident and after restarting the mission scenario, I pushed the F/A-181 to around 51,000-59,000m, but flight control surfaces became inoperable. You mean there's a limited height, or adequate height, or content heighth a pilot should want to fly? ;-)

As with all developer snapshots or developer source code trees, the very latest is the best to file a bug against.

Bottom line, the A-143 GROUND CAS jet, although a preferably used jet versus A-164 for game playability, is currently useless within the Tanoa map.

Switching the memory allocator to (I think) "-malloc=tbb4malloc_bi" if you're on an Intel platform may slightly improve this bug's effect.

The stupid stand-up bug is back again.

WORKAROUND: Use one of the BlastCore Explosion Effects mods/modules providing more realistic explosions as well as significantly increasing flare brightness to realistic levels as well as increasing chemical/glow stick brightness. (eg. extensions.) Most servers ban though any 3rd party mod, regardless of the 3rd party modifications intentions or usefulness. Server administrators are paranoid of hackers or are just lazy.

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"