Bushmanni

If you can read between the lines that book gives you lot's of info about being a good attack helicopter pilot. There's also some descriptions about actual tactics used but it's not very detailed as you can guess. Apache and Hellfire are some of the few books that tell you something about what happens in the cockpit and in the mind of the pilot (thought processes) instead of just history and experiences.

No you can't. You can activate groups but only in the location where you set it in ME. In order to do it properly and in a more interesting way we need to be able to specify the location run time where the group activates. With this we could have truck column that spawns a MANPADS if it gets attacked from air or infantry unloading from or loading into APCs according to battle situation. You could carry troops, vehicles or supplies where you command a helicopter to go with CA module. Basically it would allow more randomness and dynamic adaptation in missions making them more realistic, immersive, entertaining and replayable.

If using circular zone you can see in ME exactly where your zone border is. But making it rectangular isn't too hard to imagine if you use the radius as a half length of the squares side. You would use then a condition if pos.x > zonepos.x - zonerad and pos.x < zonepos.x + zonerad and pos.y > zonepos.y - zonerad and pos.y < zonepos.y + zonerad then ... end I suppose there's not much noticeable difference in execution speed? A square or rectangular zone check is faster to compute but I would think there's noticeable difference only if you are checking 20+ zones.

The article doesn't mention any problems about Ka-50 being single seat. Have they just chosen not to talk about it or wasn't it really a problem. Choosing Ka-52 over 50 makes you think. Then again it would be nice to get DCS Ka-29 to see how it would change things. But otherwise not very surprising conclusions about Ka-50 :).

He wants to see if the plane is under 300 AGL, instead of 300 AMSL. This can't be done using just triggers. Otherwise it would go just like Sabre described.

You need to use SSE to get the result you want. I would suggest creating a lua script file that is continuously run to check for required conditions and either set a flag or output some text if the player gets too high. First you need to get coordinates of the aircrafts and the trigger zone. Then you check each aircraft in turn to see if they are in the zone and if their AGL altitude is too high. The trigger containing the script should be continuous action type. Here's an incomplete script for doing what you want. I don't know how to get the coordinates of a trigger zone so maybe someone else can help? The code can have some other problems also but the general idea how to do this should be clear (at least if you know something about programming). You could modify this code to check only one aircrafts altitude, create separate version for each airplane and then create triggers for every plane that checks the unit in zone condition before running the plane specific script. That will get you over the zone position problem but will need more work

Some kind of side slip butt feel in DCS Mustang would certainly be useful.

Laws of physics are the same for both. The same laws that explain single rotor behavior must explain coaxial rotor behavior when you add another rotor to the analysis. I'm not just applying single rotor behavior to the coaxial but using it to illustrate the laws of physics that govern the behavior because single rotor systems and the physics of them are much better described in western literature.

PeterP: Sorry, I can't understand what you are trying to say. Yodosha: Thanks for the link. I still need to study more to understand the math but I'm hopeful that my program will help me get there some day. But the plots were something I could possibly understand. If I got it right, there's air flowing upwards ahead of the rotor and also through the central part where there are no blades or the blade speed is so slow that they basically don't generate lift. In forward flight this upwards flow gets dragged aft and increases lift at the aft sector of rotor disk. It could be assumed that in coaxial rotors this phenomenon is more pronounced and actually capable of overpowering the transverse flow effect.

Dissymmetry of lift causes pitch up moment which needs to be countered by pushing the stick forward. This is because of precession. In a rotating system a force causes movement 90 degrees after the point where the force acts. Both rotors have more force acting on them at the advancing side and this force causes motion for both rotors when they are at forward position. Dissymmetry of lift works in exactly similar manner for coaxial and single rotor helicopters. Sideways tilt is caused be different phenomenon. In single rotor helicopters while at forward flight the blade tips in forward phase move in undisturbed air and generate more lift and because of precession they lift up when at the retreating side. This needs to countered by moving the stick to the retreating blade side. In coaxial choppers something weird happens and the rotors tilts to just the opposite direction but I haven't been able to find or figure out why this happens but that it definitely happens. NASA had some paper published where this phenomenon was discussed but it's cause wasn't revealed. For some reason blades generate extra lift while at aft position in forward flight which causes the advancing side to lift up but where that extra lift comes from is mystery to me. To recap you need to have stick offset on aft-forward direction because of asymmetrical lift in left-right direction and left-right offset because of asymmetrical lift in aft-forward direction. Here's a link tot the NASA paper: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19970015550_1997024330.pdf US Navy Helicopter aerodynamics workbook: http://www.cnatra.navy.mil/pubs/folder5/th57/p-401.pdf

Druid and Grimes, thanks! Seems I got to work with what I got for now until 1.2.3 comes along.

chromium: Go ahead as long as your creation is also free to use by everybody. I have a working alpha version of the coordinate reader up and running. Currently it will play the sound for everybody. I have a problem getting trigger.action.outSoundForCoalition to work. I suspect the problem lies in the arguments. Currently I have tried using (coalition.side[3], 'one.ogg'), (BLUE, 'one.ogg') and (3, 'one.ogg') as arguments but the result has been the same every time, no errors but no sound either. Can anyone help? In general what are you supposed to give as argument if the type is "enum sometable"?

I made a script that gives you latitude and longitude in a neat format when you give it coordinates as Vec3. The outputted coordinates are strings. The output format is for example "+42 50.345" for northing and "+041 21.654" for easting. My main goal is to build a script that will read the coordinates out loud, this is just a preliminary tool to get the characters for the script. Here's an example on how to use the code. You need to load the LLtool.lua like you load MIST. There's no error checkings in the function so you need to give it proper data or it will bug you with an error message. I have attached an example mission using the code to get continuous LL coordinate updates for a flying helicopter. For a more useful purpose you would need to concatenate the coordinate strings into your own text. player = {} pos1 = {} player = Unit.getByName("shark") if player ~= nil then pos1 = player:getPosition() LLposNstring, LLposEstring = LLtool.LLstrings(pos1.p) trigger.action.outText('N ' .. LLposNstring .. ' E ' .. LLposEstring, 1) endLLtool.lua contents: Speed and Grimes, if this code is of any worth feel free to use it for MIST. And maybe it would be time to create a sub forum for lua scripting in DCS? Few big threads containing all kinds of noise will make it hard to find the scripting advice you need or share scripts. LLtool.lua SSE test 3.miz LLcoordinates.lua

Big pixels are easier to spot. You might not see as well what it is but it easier to see that there it is.

It seems to me I haven't told anything contrary to the BS manual. Anyway I base my analysis on laws of physics and US Navy helicopter aerodynamics course book. I assume what you wanted me to consider is that blades have three regions ie. driving, driven and stalled regions instead of being uniformly in one of these states. For the purposes of understanding how the fuselage experiences different turning moments in normal flight and in autorotation I felt this detail was unnecessary as only the net force acting on blades or rotor is important for understanding the phenomena. I have explained the three regions of the autorotating blade previously in this thread. Was this what you meant?

The forces that turn (in general all motions of flying helicopter are caused by aerodynamic forces, here we focus on the yaw axis) co-axial chopper are aerodynamic forces acting on the rotor blades. In normal flight the forces are drag forces that oppose the turning of the blades. Hence the fuselage turns to the opposite direction in regards the rotor that has more force (drag) acting on it. In autorotation the aerodynamic forces acting on rotors are driving them, ie. they act in the same direction as to where the rotors spin. In autorotation the fuselage turns in the same direction as the rotor that has more force driving it ie. has lower pitch angle. Basically in any situation the fuselage turns to the direction where the net torque caused by aerodynamic forces acting on rotors is acting. The aerodynamic forces can either oppose or drive the rotation and hence act in the opposite or same direction of the rotation respectively. In helicopters the rotor (or rotors) applies torque to the fuselage as long as there's some kind of mechanism in fuselage applying torque to the rotor. This is according to the newtons third law of motion. When a body exerts a force on another body it exerts back with a opposite force that has equal magnitude. In autorotating single rotor helicopters there's no mechanism in fuselage acting on the rotor, ie. it's "freewheeling". If you are precise the main rotor bearing have some friction and tail rotor shaft is applying a small torque to the main rotor due to the drag of the tail rotor but these are cancelled by the thrust of the tail rotor. In co-axial helicopters the gearbox has a mechanism that forces both rotors to turn with the same speed in regards to the fuselage. If one of the rotors has more torque the gear linkage will transfer some of the torque (through the fuselage) to the other rotor to balance the torque and make them accelerate or slow down at the same rate. Imagine you have a very small (like 30cm long) ka-50 that you hold from the upper rotor. Then apply a torque to the lower rotor ie. you turn the lower rotor with your hand. How the fuselage would turn to keep the rotors spinning with same speed in regard to the fuselage but in opposite directions? If you turn both rotors slowly with same speed but then start to spin the other faster, how will the fuselage move now to keep the both rotors turning with same speed in regards to fuselage? I hope I managed to be understandable and didn't just get you more confused.

One thing that I forgot that is simple to do is minimum altitude. I don't have enough knowledge of how the targets altitude above ground affects it's visibility in radar but DCS simulates this with some radar specific minimum altitude under which airborne objects can't be seen. Someone who knows better could shed some light on this.

It could be because the lower rotor has higher blade pitch angle in normal flight and in autorotation the lower one therefore isn't "driven" as much as the upper, ie. the force making the upper rotor to keep turning is greater than the one for the lower. The moments acting on the rotors are not in balance and because the gearbox forces the rotors to turn at the same speed the difference in torque is transferred to the gearbox and from there to the fuselage. The upper rotor turns "to the right" so if more "driving" torque acts on it that to the lower it will make the fuselage to turn to the right. Reason for the difference in pitch angles in normal flight is because the lower rotor is in the downwash of the upper and hence has higher induced velocity overall that must be compensated with higher blade pitch angle.

I'd also like to know if this is possible. I have tried forcing FFB on from options and through config files but neither helped.

Are you asking for a more simpler model that models the effects of your current model or more advanced one that's still not much more complex than your current one? I think it only makes sense you asked for the latter but the wording could make it sound like the former. I don't have much knowledge of radar either other than your model covers all the basic phenomena with most simplicity. You could drop the "ground as background"-check but I assume you included it only for clarification anyway. I think the next step would be to model RCS but if that's feasible with scripting engine is another matter.

Center the mav seeker if its not centered already, put AP in path mode and point your TVV roughly towards the target, trim if necessary and engage autopilot. After this its much more easier to slew the mav seeker on target using either HUD or seeker picture. You can also lower seeker slew speed by changing the value for "slew" OSB.

If HE AAA shell explodes on contact with a bomb, shouldn't that be enough to set off the explosives in the bomb?

Tracers coming at you can't be seen now. Could that be it? For me the said tracers appear just fine if viewed from side or rear aspect.

There's four (4) switches for anti-ice. Engine-, rotor-, pitot- and AoA-heat.

There's option to choose whether you want hull or turret that's kept immobile in the hull-turret indicator.