vicx

I posted about this a way back in this thread. I don't know for sure but I think as soon as you hit the ground in some choppers your yaw control is converted from just controlling the rudder to controlling the rudder AND doing some wheel-brake steering. Even if you don't have wheel brakes ON; individual wheels might be braking. This is the only theory I could come up with that could explain the dynamics of the Kajman when I was trying to taxi it backwards. I was holding back cyclic and yawing right and instead of taxing back and to the right the helicopter was rolling back and to the left. WHY? So imagine if there is a wheel braking system in the game that is meant to help people taxi - it might not be a good idea to also bind that to the yaw control. If you come into land and still have some last minute yaw keyed in - during a tough landing; as soon as hit you hit the ground one of your wheel breaks might be on and your chance to flip goes way up. A free wheeling system for the helis with wheels (that only uses steering when you choose to engage steering) might be a better way to let you land a bit off and enjoy some self-stablising without rolling over. Then you can engage the steering control when you are ready, and engage full wheel brakes when you are ready.

Hi guys, sorry if this is deemed a cross post but I wanted to reach fixed-wing and rotor-heads with this idea. I just posted in the fixed-wing development thread a post that makes a feature request for Tacview export out of Arma. I have been testing the Rotorlib Helis in the DEV branch and lately I have been crashing them and wondering what just happened. I would really like to review what I did wrong and know if it is my bad flying or a bad modeling at fault. Using Tacview could solve a lot of those mysteries by allowing you to playback a technically rigourous recording of what happened. I have also been using Tacview to view my DCS: Combined Arms games and it models ground units and their actions just as well as aircraft. It is a great tool but it is also pretty fun just to watch a replay of a mission.

Hi fixed-wing guys. I've been playing two games lately, one called Arma and one called DCS; both these games rock and I am playing the hell out of both. Lately after playing DCS World I love playing back the action in Tacview. Watching Tacview solves a lot of those WTF just happened moments. It is a great tool and it is fun to just watch a replay of a mission. I have also been using Tacview to view my DCS: Combined Arms games and it models ground units and their actions just as well as aircraft. Now you might see where I'm going with this. I have been testing the Rotorlib Helis in the DEV branch and lately I have been crashing them and wondering what just happened. I want to review what I did wrong and if it is my bad flying or a bug. Just saying I'd love it if Arma exported ACMI logs for Tacview. It would be awesome.

VRS --- I am dying a lot from VRS or some effect that takes place when I am slowing to less than 10kph. I have noticed it in some of the choppers in the last build when I thought VRS wasn't enabled. Anyway it feels like VRS when you come into land slowly and you have to control the descent rate like a genius. I can manage this but sometimes I feel like I am being a genius and the wind changes and then I am a dead genius (I am going to have to blame the wind). It seems a bit over sensitive. I also noticed the VRS effect in the Kajman while attempting to use auto-hover while finding targets. Switching into auto-hover from near perfectly stablised flight will too often drop me like a stone. A stone that explodes when it hits the ground. I get a feeling that the VRS effect requires that the rpm model and torque model be running very consistently or the effects will occur too randomly. This is a complete guess. The fat bird --- It is shame the xH-9 are back to feeling heavy. Now they fly as if they are loaded up with soldiers even when they are empty. I haven't read any discussions about weight. Is carried weight and cargo modelled or do you just fly with a worst case scenario? Wheel braking OR steering? --- Are you using independent wheel braking for differential steering EVEN when the brake button isn't being applied. This might be problematic sometimes and lead to more exploding helicopters. I would suggest that if a particular helicopter uses differential steering, (use the rudder for input) and ONLY APPLY the steering when the the brake is applied. On real aircraft with a button rather than an axis for braking there are likely systems that manage the braking power optimally. You could write controllers for each heli (this would be IDEAL because you could add stablisation to reduce the number of helis that roll over) BUT you could also make the wheel brake an axis and let people manage some of the stuff themselves. Reverse taxiing is probably discouraged BUT seeing as we have no way to turn a chopper around in a hanger otherwise, consider the case of reversing choppers and how the differential brakes work with this situation. Engine On Switch. --- Love it to bits, feels cool to flick a switch on the HOTAS and spin up the blades. The only wrinkle is that the engine turns OFF when the pilot dismebarks. Annoying. If I want the engine to spin down I will turn it off using the SWITCH. Please consider. Having sampled the Engine On/Off swtich I now want other things to turn off and on on the chopper. I would like a strobe that is daylight visible to attract attention to the chopper (on a server we might have a procedure that strobe on means leaving in 1 minute. Eject --- God .. let me bail out when the chopper is about to explode. Sometimes I nurse a helicopter with a damaged engine onto the ground (or onto water) without exploding ... but then I can't eject or bail out before it sinks or slowly rolls onto its side. Then Boom! Let me live! Thats all. The helis are coming along nicely.

Dynamic systems are never simple. You build a model via trial and error OR lots of math and then trial and error. Anyway they make games so they are probably used to this sort of thing. So I just tested the latest dev branch FDM out after a two week break and I found it improved and I like the new sound effects. Testing Version 1.35.127815 (Last version I tested was 1.31.127352) Helicopter Flight Model: Advanced Show Gauges: Enabled Rough Landing: Enabled Wind Effects: Enabled Auto-Trim: Disabled Stress Damage: Enabled Inputs Saitek X55 HOTAS Throttle and Stick Razer Lachesis Mouse Razer Keyboard The HOTAS seems a more enjoyable way to control the helis compared to last time. Maybe they have done something here. Controlling the collective using a throttle feels good. I was able to make the controller customisation curve more flat. The cyclic control using the stick felt more direct without being too twitchy. Now to the individual choppers. It's hard not to like the Blackfoot. It is the most predictable and safe of all the choppers and it is armed to the teeth. There are no downsides; it is like an automatic that beats all the stick shifts. I would prefer that the Blackfoot was not such a safe experience. The chopper that should have the nimble and safe characteristics is probably the ORCA but as it is the ORCA feels the more performance oriented and edgy of the two. Some players will try and fly the Orca aggressively and they will die because it is easy to fly the ORCA like a genius, until you fly straight into the ground. I like the Orca but I crash in it a lot. The Ghosthawk feels really good to fly but it was also pretty fussy when it came to landing. Sometimes it wanted to roll over after I'd touched down more less perfectly. It tips over in slow motion, drives a blade into the ground and then explodes into the air.If Bohemia could make another way to wreck a chopper that might be cool I'd love to see a blade strike create a cloud of smoke, dust and debris. Then when the smoke cleared the injured chopper crew could be lying prone next to the wreck and inventory from the chopper (medkits) could be scattered nearby. That would be cool. The xH-9 choppers are fun to fly. Although sometimes you do a hard turn and end up flopping across the sky; it doesn't kill you but looks quite silly. You can land the xH-9 choppers harder than any other (a feature). People will like them. I like them. The Mohawk feels like a big ass chopper and you can make good landings only if you are patient. I just don't think people who fly the Mohawk now are going to like the new Mohawk. If the other big chopper is really good, who will want to use the Mohawk? Hellcat feels more raw compared to other helis - like it has a bit of Huey in it. Just like the xH-9s you can land it hard. I like it, but I should fly it some more. The Kajman is good but I think it needs to be damned good. I like the yaw and the way it side slips but it feels underpowered for a heli with two rotors. --- Now some comments on the HUDS that are in the Blackfoot and Hellcat. These HUDS are awesome for flying, not just for combat The green line velocity vector is really useful. I want that on every HUD. I think all the choppers should have a HUD available because the HUD can be made superior to using on-screen dials or looking down at the instrument panel. As good as the HUD is now it can also be better. the Green line could span across more of the screen. the HUD design could be made easier to read at a glance and offer slightly more information. Here I will reference the a modified Ka-50 HUD that a someone posted on DCS forum that improves nicely the original KA-50 HUD.https://www.digitalcombatsimulator.com/upload/iblock/a69/Screen_140722_130931.jpg Bank angles, pitch angles, and two sets of climb rates are shown (low scale on left, larger scale on right) That low scale is crucial for avoiding stall. I also prefer the larger digit size which is more readable. A nav mode could be built into the HUD. Waypoints. Some suggestions for the Opofor HUDS Give them the Green Line feature Replace the reticule shape with something more simple. The best shape would be one that resembles the nose of the chopper you are in. It is a handy mimetic. Put the pitch indicator digits down the sides instead of in the middle where it is hard to read. What should be in a 21st century helmet hud?

Firstly the amount of work that has gone into this and is going into this is amazing. I applaud your insanity. Secondly these last few pages of the thread gave answered a lot of questions for me about the AiA projects. Gal, Cap, and Def basically asked all the questions I would have asked if I was more bold. I have been wondering about the projects longevity considering the obstacles to success that even with thousands of hours of free labor the problem of distribution will remain. It was a shame to read that. It seems like all the heavy content lifting projects will need a sickboy at some point. This problem of manageability and distribution is one that will not be going away. As the size of CUP increases it will inherit the same problems faced by AiA. You mention Steam. What does the Steam solution look like?

Green I will be trying out your batch file method next. Right now it bugs me when I can't use Diag tools with the console in the dev branch. See if you have the problem too. Bring up the console in VR. Enter -> [b]diag_toggle "HitPoints" [/b] EXEC LOCAL It should pop up a window in your viewport showing hitpoints of the parts of your vehicle and/or player. What you don't want to see is ... 'diag_toggle |#|"HitPoints"' Error Missing ; Right now I can fix this problem temporarily by deleting all files in 'Arma 3' and 'appdata/Arma 3' (just to be sure). Re-downloading the main branch (to make a copy of it) Wipe everything in main branch directory and select dev branch in steam. Wait for the download of patch. Overwrite the files in my main branch copy with the new patch of files Now I have a fully functional Arma 3 dev branch and I can use the DIAG tools. BUT ... If I use Game Updater, I end up with an Arma3-dev branch where I CAN'T use the DIAG tools. If I switch from one branch to another in Steam, I end up with an Arma3-dev branch where I CAN'T use the DIAG tools. I am more noob than expert so I don't have much idea where the problem comes from. I'll use your batch file if it can allow me to have fully-functional branches of the game I can switch between.

I think Arma 3 reveals a problem that is already there. It might be that Saitek has minor electronic issues It might be that Windows is running Arma3 incompatible power saving routines Maybe Arma expects well behaved devices to remain attached and not reset themselves or take micronaps. All I know is that I don't automatically blame BIS until I have tested every other possibility. Personally I wanted to reduce the number of things that could be the problem so I isolated the the x55 devices so they would have their own electronically isolated bus. Absolutely nothing else is plugged into that bus. I'm not talking about USB ports. Many USB ports and downstream usb hubs share a common power bus even though you might think they are separate. With DEVICE MANAGER you have some tools to see what devices are using power and which devices are hopefully electronically isolated in terms of their power requirements. Just now making this image I see that Win8.1 has forgotton my settings for power-saving sometime during the last week. I uplugged the Dell monitor yesterday so it might have been then. Now I have to right-click every usb hub on the x55 branch and disable that power saving feature. It would be great if that was a 100% fix but it isn't.

Maquez I am also having problems with the DEV build acquired via Game Updater in Arma3 Tools. Errors in the editor indicate missing configs.

I have the same setup and I HAD the same the problem. I solved my problems with the x55 HOTAS incrementally. 1. Win8.1 has a FEATURE that turns off USB ports to save power and it does this very aggressively. This causes problems in Arma but probably in a LOT of other games too. You can find a patch to fix this on the MS site. There was talk of MS making this patch a default setting and that may have taken place. Use google to find the MS page for the patch. 2. Important. You MUST use a dedicated powered USB hub to plug the throttle and stick into. I won't go into the full detail of why, but it matters and it also helps in the next step where you manage the power settings of the usb hub chain. I use the USB ports built into my DELL monitor and I'm fortunate that this is sufficient. 3. The next step is related to step 1 and 2 and is absolutely required. You need to go into Device Manager and the properties for the complete chain of usb hubs from your PCIE bus all the way out to the controllers. For EACH, USB ROOT HUB in the chain you need to go into the Power Management tab and untick [ ] Allow the computer to turn off this device to save power. Incrementally I found that all 3 steps were required to get reliable usage of my x55 HOTAS in Arma3. Every now and then the HOTAS can still drop out (blame Saitek) but it is much rarer. Good luck.

It seems that the game delivered by Game Updater is different to the package delivered via the Steam development branch. At the moment the development version downloaded via Game Updater is broken. What would be the best method for comparing the two packages to see what is going wrong?

What methods are the people in this thread using to test the FDM choppers. I am opening the editor and placing a heli in the Stratis Airfield just for starters and adding some wind every now and then. There are few wrinkles in my testing at the moment. A few dev betas ago I started to get an error after adding a chopper and previewing the map. No entry 'config.bin/CfgVehicles/B_Heli_Light_01_F.tailBladeCenter'. //I get it for Attack and Transport choppers too. I am also trying to view the diag tools on the choppers but the debug console in the DEV build is playing up giving me errors about a missing ';' 'diag_toggle |#|"Hitpoints"' Error Missing ; And after the engine startup sound fades away I get no engine sound whatsoever in any of the FDM choppers while I am controlling that chopper. I can hear other choppers flying around but not my own. I will most likely report these in the feedback tracker but first I want to know if it is just me having the problems.

OK I just tested the dev branch FDM out again after a two week break and I found ... new features (which is normally cool) BUT because these features are being stacked on top of stuff that is maybe still broken, the new features are ... unpredictable. So I returned to this thread to see so how people might be responding and I find a lot of comments from people having experiences like me. Actually I was hoping to see less 'yo stuff be broken' and more helpful reports but it takes time to type stuff out I suppose. So yeah like you other guys I am getting strange behavior in certain situations in the FDM helos. My observation from an hour in DEV FDM testing with different combinations of input from a HOTAS, mouse and keyboard. Version 1.31.127352 Helicopter Flight Model: Advanced (duh!) Show Gauges: Enabled Rough Landing: Enabled Wind Effects: Enabled Auto-Trim: Enabled Stress Damage: Enabled Inputs Saitek X55 HOTAS Throttle and Stick Razer Lachesis Mouse Razer Keyboard I get broken main rotor (a bit) and tail-rotors (a lot) and CTD (crash to desktop often) almost only when I have Auto-Trim: Enabled. So yeah this looks like a culprit BUT this might not be just Auto-Trim at fault. Next I tried being hyper-careful not to break my rotors but I got an odd behaviour where I was able to eventually saturate an input analogue axis (anti-torque pedals all the way left or right) with no effect at all on helicopter. BIG problem. The FDM model has become disconnected from the reality of my input. As soon as I feed in a tiny opposite anti-torque input the tail-rotor explodes. I only have guesses as to what is going on. It could be that Auto-Trim combines with problematic INPUT sampling and feeds the FDM models garbage. Who knows? I did wonder if this broken behavior is cropping up because BIS is trying to do a nice thing by supporting keyboard users who want to fly the advanced flight mode. It would be a nice thing if it could be made to work but I don't think it has much of a chance of working WELL. A realistic FDM is either demanding on input OR it is nothing (I don't think a keyboard will ever work as input to a demanding FDM. Mouse probably could work but as mentioned below I have a problem with the BIS implementation right now.) I tried flying MH9 with [Auto-Trim: Not Enabled] and I was able to fly with the HOTAS Throttle and Stick (Collective, Cyclic, Anti-torque and Trim) but it feels terrible. It feels like my Stick(Cyclic) input is lagging. It is flyable but feels not quite right. :/ I tried flying MH9 with [Auto-Trim: Not Enabled] flying with HOTAS Throttle (Collective, Anti-torque, Trim control) combined with Mouse (as Cyclic) and the mouse feels GREAT (the mouse seems to be the most responsive cyclic controller) BUT the manual Trim does not work properly with the Mouse input. So close :/ I tried flying MH9 with [Auto-Trim: Not Enabled] flying with keyboard. Try it yourself. :/ At the moment I am judging the FDM on how I can control my helo and right now none of the input schemes are very satisfying. (If I could use Trim with the mouse(cyclic) - I'd be in the game flying right now) I would agree with other recent comments in this thread that the MH9 when it is hovering in ground effect (especially with Mouse as Cyclic) feels quite dynamic. It feels like you are in something being held up by a whirling piece of metal over your head and this means that BIS is getting parts right, but I think they really have to sort out the input side of things before we can even start to judge the individual helo dynamics. Just my opinion for now. *Update* I did some more flying and it seems like you can fly passably with the keyboard with Auto-Trim on, which means there is a lot of blackmagic being done to keep the FDM fed with a compatible input. I sincerely hope the keyboard hacks aren't the reason why HOTAS control feels so poor. You can dumb down a model and instead of becoming easier to fly - it actually becomes harder.

This has been noted previously in this thread and in bugs in the bug tracker. It isn't enough to just have a damage model for the transmission. Ideally excessive forces on the rotors should cause damage to the rotors.

This is still a problem. Perhaps it is a windows problem but we still need a solution.