pyroflash

Would it be possible to get the RTDynamics' RIME graphical editor for helicopter AFM's added into the official tools package at some point? It's relatively workable in the textual editing environment right now, but editing tables for aerodynamic coefficients is a pain. Something with which access to the graphical editor would greatly ease.

I have considered it. The biggest feature of such a set is rapid prototyping and visualization/logging. A xml GUI editor could take care of the rapid prototyping part along with file patching, but AFAIK the in engine logging and visualization of resultant forces is very limited. Often this means I spend more time testing a certain feature than actually developing it.

Yes, so far, I have not received a response to any of my inquiries.

Is this what you are looking for? BLUFOR "rhsusf_weap_CMFlareLauncher" --"60Rnd_CMFlareMagazine" --"120Rnd_CMFlareMagazine" --"240Rnd_CMFlareMagazine" --"60Rnd_CMFlare_Chaff_Magazine" --"120Rnd_CMFlare_Chaff_Magazine" --"240Rnd_CMFlare_Chaff_Magazine" --"192Rnd_CMFlare_Chaff_Magazine" --"168Rnd_CMFlare_Chaff_Magazine" --"300Rnd_CMFlare_Chaff_Magazine" "RHS_LWIRCM_MELB" --"RHS_LWIRCM_Magazine_MELB" OPFOR "rhs_weap_CMFlareLauncher" --"rhs_128Rnd_CMFlare_Chaff_Magazine" --"rhs_60Rnd_CMFlare_Magazine" --"60Rnd_CMFlareMagazine" --"120Rnd_CMFlareMagazine" --"240Rnd_CMFlareMagazine" --"60Rnd_CMFlare_Chaff_Magazine" --"120Rnd_CMFlare_Chaff_Magazine" --"240Rnd_CMFlare_Chaff_Magazine" --"192Rnd_CMFlare_Chaff_Magazine" --"168Rnd_CMFlare_Chaff_Magazine" --"300Rnd_CMFlare_Chaff_Magazine"

Hello, I am writing a bunch of custom control system logic for helicopter AFM's, but right now, interaction with these systems is very limited. Specifically, I was wondering if it would be possible to say, create a custom keybinding to link to a function inside the AFM to allow things like enabling/disabling/selecting different autopilot modes. In addition, is there any functionality that would allow things like programming SPAD pins to allow a system like BUCS in the Apache to be implemented? It would require modification of the checks used to determine control of the helicopter between pilot and co-pilot, and the ability to switch between one system control logic to another on the fly.

Sure, check your PM's

UH-80 AFM Revision I apologize for not having pretty pictures, Download: https://www.dropbox.com/s/ymn94ir0ja0njwx/KEP_UH80_AFM.7z?dl=0 ----Description---- This mod aims to bring increased accuracy to the vanilla UH80 flight model. I felt that this was worthwhile due to deficiencies in the flight model that do not represent, or reflect the visuals/expected performance of the Ghosthawk (the vanilla flight model only has 4 blades per rotor, T700-701C 30 min. engine power, etc.). The largest implications of this include more hover power, crisper and lighter cyclic response, slightly faster top speed, and more coordinated anti-torque control. Also try to avoid large cyclic movements at high airspeeds. The main rotor may come off. Included: - BIS UH-80 AFM revision ----Installation---- Simply extract the contents into a mod folder, then add it as a local mod folder in the launcher. ----Changelog---- 02 MAR 2017: Changed: - UH-80 AFM --Increased SL tip speed to M 0.72 --Increased engine HP and torque limits to conform to UH-60M specifications. --Decreased gear ratio of main gearbox (be careful, high speed transmission failures and main shaft shear are now extremely likely) --Increased blade root size of main rotor. --Decreased blade radius of main rotor. --Increased main rotor blade count to 5 (previously 4). --Canted tail rotor by 25 degrees. --Decreased tail rotor blade radius. --Decreased tail rotor blade chord. --Changed tail rotor blade count to 5 (previously 4). --Some other stuff.

That's another thing that kind of frustrates me too, because there is no support for the programming of additional flight control systems as part of a single package. There is support for a single controls "set" with two three channel AP's. I can pretty much do anything mathematically that I want to these sets. I can simulate stick control curves, ranges, incorporate rate based autopilots, proportional controls, whatever. But, I can only do one per helicopter because there has to be an in-game button for switching, and the buttons right now to my knowledge are hard coded into the game. I can't add, for example, buttons to turn autopilot channels off that would exist IRL, which means that I either have to code the controls as if there is a damper on no matter what, or code them as if the damper is off all of the time. The exception to this is the rate based auto trim, which works similar to trim compensators in real life. That works as a function, but it is kind of clumsy because it's a setting in the menu. Or I could turn auto-hover into something else, but the downside there is that there would be no auto hover then for that aircraft. But just to be clear, if I wanted to, there is definitely nothing stopping me from making a mathematically unstable helicopter fly like a dream with the AFM on. Also, I could, if I wanted to, completely re-define what exactly auto-hover and auto-trim do in the helicopters under AFM. Auto trim could for example, be made into an attitude or altitude hold autopilot mode. Thanks for your response.

I've taken a look at the engine and transmission in order to refine it a little with known values from the aircraft manual (MD 530F). This means less available shaft horsepower, but at the same time, nominal RPM has gone up a bit. This should equate to more lift at lower mach numbers, but the lower engine power means that the aircraft is now susceptible to loss of control from RPM fluctuations if handled incorrectly. The biggest things that would help me with understanding maneuverability are: 1. Detailed weight and balance specifications for the MD530F or MH-6M/X. (Mx/mfgr.) 2. Rotor balance. (Mx/mfgr.) 3. Any test reports of the MD-530F or MH-6M/X that describe control response and stability (dynamic and static) in detail. (NASA/mfgr./Military Test Program) Also, if you know anyone with a copy of an engineering manual for any of the Rolls M250-C30 series engines, RR has them behind a registration wall so I can't just poke at them. I would love to talk to someone with access to any of them. Thanks, and I am looking forward to your input.

Certain things are easy here, and certain things are hard. Any original aero work though, requires me to CFD some parts. If you have sim quality rotor models that would help. For the most part, I think a simple model is enough to get a good estimation on the fuselage values via CFD. Regardless, it takes time. I have a gaming computer and openFOAM, so yeah :). That being said, the superior work done by BIS for ToH made modeling certain helicopters relatively easy. Really an outstanding effort put into that game. I don't think BI gets enough credit for it really. I would love the chance to get these into something like CUP and RHS, but I am reluctant because with such high-profile mods, I really want to put my best foot forward in order to ensure that any work I do is of high quality and thoroughly tested. Sorry, but due to the nature of how the AFM works in ArmA 3 (as an API), it must be installed in a mod on each client's computer. What about the other helicopters in Vanilla ArmA 3 do you think is lacking? I modified the vanilla Ghosthawk because of some issues that popped out at me, but looking through the other helicopters, most of them, except the Blackfoot are based off of real life models and I am assuming are modeled correctly. I do not see any glaring mistakes. If you can provide concrete examples on what you think is wrong, that would help. Documentation to back it up is of paramount importance as well. See above comment :)

How would you like to see me expand this?

Hello, I have a few questions regarding flight model editing in ArmA 3. 1. In class RotorLibHelicopterProperties What relationship to maxTorque, stressDamagePerSec, and maxMainRotorStress/maxTailRotorStress have? Additionally, what does the value maxTorque apply to? It is universal across all rotor systems? Is it specific to the main rotor? Tail rotor? What about coaxial/tandem/side-by-side? The example simply says "90% of both engines in XML". 2. In class RotorLibHelicopterProperties Do the defines: maxHorizontalStabilizerLeftStress, maxHorizontalStabilizerRightStress, and maxVerticalStabilizerStress do anything? 3. In class RotorLibHelicopterProperties What does retreatBladeStallWarningSpeed do? 4. In class RotorLibHelicopterProperties What do horizontalWingsAngleCollMin and horizontalWingsAngleCollMax do? 5. In the RotorLib XML, what reference is there to main rotor and tail rotor as far as the model.cfg is concerned? Can there only be two rotor systems? 6. In ToH, it was possible to define multiple stabilizers per geometric plane. e.g. two horizontal stabs, two vertical stabs, etc. In ArmA 3, this appears to be limited. The engine no longer recognizes <HorizontalStabilizerLeft> and <HorizontalStabilizerRight> as valid flight surfaces when used together. Did something change?II had an error in one of my edits that caused the flight model to not load if one of the stabilizers loaded. It is still possible to define as many stabilizers as desired. 7. What is going on after Effective Translational Lift? It should be a dynamic inherent to all rotor systems, so is the engine automatically compensating for it? It does not appear to have a noticeable effect. 8. Is it possible to have a list of all functions of RotorLib that are integrated into ArmA 3? The XML documentation is not all inclusive, and it would be helpful to know exactly what can, and can't be done with the flight model. 9?. I also have a some questions about the vanilla Ghosthawk .xml, but I'm not sure how to list them. The .xml as it stands, appears to represent a UH-60L model aircraft (aerodynamics and the newer model main rotor blades, but lower engine power '30 min rated power for the 701C as opposed to the 701D which is slightly higher', etc.) but the Ghosthawk is a substantially different aircraft (worse aero, probably, different rotor blades, different rotor configurations, etc.) Was this an oversight of some sort that has gone un-noticed? Thank you for taking the time to read through all of my questions!

If you look at the original sqf, that's how it is done. I'm assuming because for some reason the damage handling is unreliable or the actual damage is unreliable. I just didn't want to change too much of the original code, so I left it like that.

Yeah, unfortunately.

If anyone wants to get this to work properly with ACE3 advanced medical systems, replace the code in "acedamage.sqf" with: _target = _this select 0; _typeDamage = _this select 1; _damage = 0; switch _typeDamage do { case 'manNormal': { _damage = Ryanzombiesdamage; }; case 'vehNormal': { _damage = Ryanzombiesdamage/25; }; case 'manDemon': { _damage = 0.3; }; case 'vehDemon': { _damage = 0.03; }; }; _selection = selectRandom ace_medical_selections; _hitpart = _selection; switch _selection do { case "hand_l"; case "hand_r": { _hitpart = "hands"; }; case "leg_l"; case "leg_r": { _hitpart = "legs"; }; }; if(isPlayer _target) then { [-2,{ _target = _this select 0; _damage = _this select 1; _selection = _this select 2; _hitpart = _this select 3; if(player == _target) then { [_target, _selection, _damage, objNull, "Bullet", -1, "", (_target gethit _hitpart) + _damage] call ace_medical_fnc_handleDamage; [_target, _selection, _damage, objNull, "Bullet", -1, "", (_target gethit _hitpart) + _damage] call ace_medical_fnc_handleDamage; [_target, _selection, _damage, objNull, "Bullet", -1, "", (_target gethit _hitpart) + _damage] call ace_medical_fnc_handleDamage; }; },[_target,_damage,_selection,_hitpart]] call CBA_fnc_globalExecute; } else { // note that this damage won't be applied to AI group members of a player-led team on a server (because AIs are local to group leader) - low priority... [_target, _selection, _damage, objNull, "Bullet", -1, "", (_target gethit _hitpart) + _damage] call ace_medical_fnc_handleDamage; [_target, _selection, _damage, objNull, "Bullet", -1, "", (_target gethit _hitpart) + _damage] call ace_medical_fnc_handleDamage; [_target, _selection, _damage, objNull, "Bullet", -1, "", (_target gethit _hitpart) + _damage] call ace_medical_fnc_handleDamage; };

I am extremely new to mods, I just started two days ago after getting notions on how to make the game better for my personal play style, however cannot figure out, for the life of me, what is going on. So far I've figured out: 1. You need to define external dependencies if you want to use them. 2. Unless you are creating a custom class, you need it to simulate something else before it does anything. 3. You can do most normal operations, call other functions, and the structure is pretty normal. What I can't figure out: 1. Why BIS repeatedly writes code like this class ViewOptics: RCWSOptics { }; class ViewGunner: ViewOptics { }; 2. How to remove things that have already been put into effect in previous code structures. (e.g., if I wanted to remove night vision from a scope or a turret camera). 3. Where some of the stuff is originally defined. F.e. I can't easily figure out where RCWSOptics is originally written. 4. How EXACTLY the class structure works, and where it is appropriate to simulate another item, an item's "base", or have a class simulate itself. Thank you in advance for helping me through the start of this journey.

I am trying to play the ArmA 2 flash game, but when the game starts and the main road map appears, it won't let me do anything from there. I have tried this in both IE 8 and Firefox.

It can use its afterburner, doesn't mean it does IRL. plus, would still be a useful game mechanic even if it is not used IRL.

No, the F-35B can use its afterburner during VTOL operations, but the problem is that it does melt the runway surface. The F-35B cannot however use the full extent of its afterburner in VTOL mode, it can only use its first stage of afterburner.

the only way an F-35B can take off with even a slight warload is to use afterburner. the only reason it doesn't use it in RL is because it melts the Carrier deck. As for the cannon. The F-35B/C models can both use cannons, but they have to be mounted directly aft of the Lift fan and under the weapons bay. I believe the ammo is also carried externally via ammunition pods, but i could be wrong about that.

The main difference between the AV8B2+ and the F-35B is the Afterburner which allows the F-35 to make proper vertical takeoffs with a near full air to air combat load.

the F-35B is capable of VTOL with some armament not over the weight of 8000 LBS I belive. Meaning internal air to air armament as well as very limited external A-A arms.

Eble, great addon, but why not make use of the lovely afterburner while in auto hover mode to climb. that way when running full military power you descend, and while running afterburner you climb, just like in the real F-35B. I am not sure how the afterburner scrrpting controls the thrust, but am I correct that it does modify the base thrust by a certain factor? if so, should it not modify the altered auto-hover base thrust as well?

The M4A1 sound is just a little bit off. you may need to lower the bass a little bit and make it more in line with the HiFi 1.5 M4A1 sound. the explosions too, they need a massive overhaul, they sound good, but real explosions echo and create enourmous shocks that can be heard from great distances. a 250 LBS bomb for example could be heard from 20 miles away.Albeit at a great time after impact. small explosions should still be heard, and not just scoreted out of existance if you are more than 250 feet away. Other than that, great mod and good work, I really like the AK74 sound, best yet. M136's should be deafening when they fire. I mean an enourmous amount of bass. When an m136 fires, you know it.

if you thing that changing scopes mid-fight is a bad idea, and that no one ever does it then you are wrong. I have talked to many guys that repeatedly swap their scopes on the rifles for something more suited for the situation. For example, your squad was just doing some long range recon in an open environment, now you are moving into the city. In an urban environment, you suddenly come to the conclusion that a 6x scope on an m14 is not the best urban configuration, so you switch to a more adept ironsight. Now, I do agree that you should be able to use the mini-iron sights on the top of the trijicon 4x ACOG Too bad ArmA supstituted the trijicon scope with the RCO.