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.
media-libs/libsdl2 abi_x86_32
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:
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.
Please refer to Bug #14924, "Opening joystick config in game results in joystick disappearing as input option"
This bug you reported as well as the supposedly duplicate bugs reported by T-Bone within his Comment #92012 (ie. Bug #14924, Bug #20950, Bug #21856) may also be duplicates of Bug #14924, "Opening joystick config in game results in joystick disappearing as input option"
Within Windows 8/8.1, it's mostly futile trying to reconfigure power options as this bug with the USB controller is unavoidable. The only fix is to upgrade to Windows 10 or downgrade to Windows 7. Due to the amount of time this bug has been open and the fact this bug is supposedly an upstream bug, I do not ever expect this bug to be fixed for Windows 8.
I'm using Windows 7 for production, even though I also do have Window 8.1 installed. However most, if not all of my work is performed using Linux, including Wine if needed.
Which version of Windows are you using?
I wouldn't mark this as resolved, as this bug is still open and supposedly actively being worked on.
Should be marked as a duplicate only, and closed as a duplicate.
However granted, strange unexpected things do happen when people write the word "puck" within their statements. (ie. pucker factor)
I was shocked to not see any tracer packed ammunition cases for the newer weapons within the arsenal!
However, maybe they're still making adjustments and do not want the added overhead of maintaining duplicate ammunition types as of yet. However, this MarksMan is paid content. Personally, I would have waited to release, and released on a Monday allowing five days for any needed hot fixes. (But that's just what I would do if I were planning.)
Yup. AI problems are such a common occurrence, it's no longer considered a bug or issue.
I'm going to close this bug because this looks like the expected behavior, but I have no ability or permissions to close.
This bug occurs because of my following key mappings:
VIEW
Toggle View = NUM+ENTER, NUM+'.' key
Tactical View = NUM+'.' key
I've had to work around a dysfunctional NUM+ENTER key on my keyboard, and guessing the NUM+ENTER key might have broke due to over use. As such, the best workaround aside from buying a new $100 keyboard (for which is still always going to type worse than a 1980's era electric typewriter), was to remap and make use of the NUM+'.' key.
Funny, I see no other conflicts or usage of this NUM+'.', so I don't know why I'm getting this bug. But unmapping/deleting the default mapping of the NUM+'.' key from the Tactical View function solves or works around this bug.
VIEW
Toggle View = NUM+ENTER, NUM+'.' key
Tactical View =
This bug is still not fixed on Phoenix servers. There are still a few statements constantly resetting camera shake! (ie. The statements start with double quotes within the scripts, and contain camshake commands.)
After some testing using the Editor and entering similar scripting commands posted above, it would appear this bug is localized to the Phoenix server and it's usage of resetCamShake, more specifically and like the addCamShake. Likely this specific scripting is proving dysfunctional and acting erratically when using TrackIR hardware and/or using free-look extensively. Although CamShake appears to work well within my Editor, on Phoenix servers, the camshake feature is acting extremely odd, or not fluid with movements or experiencing significant Internet lag or a bottleneck whenever a CamShake movement is experienced.
If you notice, the shaking we experience now is the same rhythm as the prior persistent shaking. Just much less, and almost apparently completely omitted while using scopes and binoculars.
Also mentionable is the fact this same shake bug (in it's current state as documented within Comment #0088612)) I'm now experiencing, has been in ARMA 3 since likely alpha or beta, but isn't usually seen unless users make constant use of free look, or use TrackIR which makes explicit use of free look.
Hence, the root of the bug is still likely there, it's just back to being not noticeable or not detectable by the normal everyday user, or users not knowledgeable.
I'm pretty sure they only fixed half of this bug. If you also notice, there's almost absolutely no shaking when looking through scopes & binoculars, while the shake I experience now documented above within Comment #0088612, is only seen or provoked usually within third person usage. That's the other thing, camera shake is more noticeable within third person usage.
If they did hack around and now are negating camera shake while using scopes and binoculars, might be a good idea to omit or apply the same fix for this massive camera shake bug within the third person as well. But from a player's face value point of view, or from an unknowing point of view, this bug might only "look" fixed.
I have also just fgrep'ed the Phoenix Realism mission game files, and definitely see the only reimplementation or reactivation of CamShak is also apparently commented-out via double quotes.
$ fgrep Phoenix_Domination_V4G.Altis/ -r -e "CamShak"
Phoenix_Domination_V4G.Altis/fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
Phoenix_Domination_V4G.Altis/fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: " addCamShake [15, 999, 0.7];" \n
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;"/*%FSM</STATEINIT""">*/;
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;" \n
However, CamShake is definitely somehow being reactivated by some other means than just the Mission Files on the Phoenix Realism servers. As I try to read this scripting, it looks as if the double quotes, are just quoting a further embedded listing of commands? Hence, "resetCamShake" should also be further deleted/removed? (Actually, the recommended method is likely just commenting the sections out within C style /* */ comments.)
I think I've successfully proven this bug still exists within 1.40129533 version.
If you have TrackIR, you can reproduce by flying and sometimes either zooming in (with your head) or moving your head to the border region of the extent of head movement. You'll immediately notice the shaking is extremely reminiscent of the CamShake bug. Briefly looking elsewhere or doing something, the problem quickly dissipates, however very annoying while aiming at something.
If you don't have TrackIR, you can likely reproduce by using Free Look.
I'm using the Phoenix Realism server.
Playing on some of the demo servers using the RC (developer) build, I think there is still the reminiscent camera shake bug still present. (Come to think of it, I still think I have camera shake turned-off on my client here.) It's almost like the server is spamming the client, creating a sporadic screen jitter.
What's making it really difficult to further test, there are very few demo multi-player servers for testing in or very few other players. As well as some set to night without night vision and with non-working flares. The AI difficulty are also set to experts. So basically bump the expertise of the AI to dumb & dumber so they don't take over the compounds within two shakes (or two seconds), and provide night vision or please fix the flare lighting bug.
(Within the next day or so, I'll bump back down to stable version, log into Phoenix and download the map and grep the script to verify you commented the two script lines re-enabling the camshake upon death. But since it's only two lines, I don't see how anyone could have missed them. So I'm swayed to believe you likely did disable camshake.)
W. Carruthers: Make sure there are no routines calling fn_injuredBloodloss.fsm or bloodloss.fsm, as I can obviously see something calling reset resetCamShak and addCamShak. Matter of fact, I do not remember seeing these calls previously, unless I was just searching for "CamShake" without prefixed spacing. But with Bash history here, I'm using a previously used fgrep incantation! Did you just add these in?
roger@localhost4 /cygdrive/c/Documents and Settings/roger/My Documents/Arma 3/missions/Phoenix_Domination_V4G.Altis
$ fgrep ./ -r -e CamShake
I just updated to 1.40129533 and it does seem like the CamShake bug is solved using the Phoenix_Domination_V4G.Altis map. I just ran the chopper into the antenna tower, respawned and all is well still.
./fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
./fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
./scripts/ais_injury/fsm/bloodloss.fsm: " addCamShake [15, 999, 0.7];" \n
./scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;"/*%FSM</STATEINIT" "">*/;
./scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;" \n
Somebody has stated that there is no server side option for enabling or disabling camera shake.
I've found "enableCamShake false;", but somebody else has also stated this is a global variable on the server side, that can be modified by user modifications. I would imagine the fix to this is defining the variable as static or local to the server?
Looks like this issue is still occurring on Phoenix Realism servers regardless of this setting.
2015.02.26: I just did some grepping of the Phoenix server mission files (ie. Phoenix_Domination_V4* -r -e CamShake) and found several files resetting Camshake values, likely re-enabling CamShake server side and regardless of whether the server explicitly disabled CamShake. These mission files should not have access to the CamShak server side variable, hence should be a local/static value and not globally accessible. Hence, the likely fix.
Per FeralCircus's post above, Comment #0087903, I heard someone state they may have disabled camera shake on the Phoenix Realism server within the past day or so.
I cannot confirm the work around for this bug, aside from the fact I haven't seen this bug within the past day or so. (Not enough time to set up a server within Windows', dealing with DRM, etc..., easier & quicker debugging on Linux... etc.)
Another possible past related issue, I remember the camera shake in ARMA 3 Alpha/Beta or early release versions of ARMA 3 while within the AH-64 gunner seat. If auto-hover was enabled, camera shake would occur while looking through the gun camera. Disabling auto-hover would cease the camera shake. I somewhat assumed this was an issue with the joystick axis, and think I created a dead zone to either relieve this or a fix was published.
As already noted above, very likely related to Bug #0022394, "UAV camera shake at specified altitude"
This bug is extremely active within Phoenix Realism server. It's using the Domination maps customized by Xeno. This bug makes the game almost unplayable, unless the weapons are locked guided to their target. Even guided rockets are missing because of this bug.
From my perspective, this could be network lag causing camera shake? Like I"ve stated, the bug is reproducible on Phoenix Realism server using the Domination map customized by Xeno.
This bug also seems to be being caused by the server. I've restarted the client, and the bug still exists. Upon first joining the server, and apparently after a fresh restart, the bug was not present until once I died. And then after death the bug became persistent. I think I smell a hot fix!
I also tried disabling camera shake within the Difficulty settings which had no effect. Possible the camera shake is mandated by a server side setting?
After reading all the comments, the overload on logs can cause this with overloading the network, but I'm speculating.
Likely related to Bug #0022400: Camera shake after 1.38 update
I think it's most noticeable while flying, but it's also somewhat noticeable while running around and viewing in third person.
Adjusting the TrackIR software settings has no effect, to include the Precision setting.
I was encountering significant problems while flying the 3D aircraft last night, along with also noticing the selected aircraft ammunition type being reverted to guns after each time viewing through a UAV aircraft using the UAV terminal. All these small bugs are seemingly increasing over the past months, with no apparent substantial fixes except what looks like hacks. :-/ (Shrugs. Significantly detracts from the fun of playing games.)
Thanks St. Jimmy for further confirmation and further clarification of this continuing bug/issue!
Fast roping would be more required if the terrain were more cluttered with trees. The terrain cannot be more populated with trees due to likely frame rates? And as such, this feature/bug is probably depending on the frame rate issue.
Wish they'd publish bug dependencies or what is holding up the integration of feature!
Count your blessings. At least the feature is scriptable!!!
Maxyzzz940: I didn't understand the question, but yes all those actions are possible within the current menu.
With all these scripts, there should be an official repository, using something like GIT, and a script utility to enable/disable script/feature for server administrators to pull and enable/disable scripts without manual fuss. (ie. Something like Gentoo's Layman which pulls official and personal repositories, using CVS/SVN/GIT.) And, scripts should be published with standard version numbers, unlike within the Windows world. Whether by date or version. (ie. script-20141221 or script-1.12)
I think you still need to use a custom module/script to enable this feature?
Fast roping within the *1776* servers is already possible. However, PhsyX and rope graphics are currently missing.
So fast roping is currently possible, just missing graphics & PhsyX. Also, people cannot be extracted by deployed rope rigging, which is previously mentioned within this Bug/Feature. (You see the rope extractions being commonly performed by US Coastguard; As well as within other Army related Movies. ;-)