Bushmanni

Sct has a function to capture the group table of a group, ie. what kind of units it has and how many. Damaged units would be at full health at next respawn but dead ones at least would stay dead. All you need to do is copy the current group table to some variable before despawning and use that table to respawn the group next time. Anyway, great script. I will definitely try it at some point.

Dissymmetry of lift causes the rotor disks to pitch up (both of them), so it can't be responsible for the left-right tilt that happens at high speed. While I respect Erik's knowledge in general the reason he's proposing for blade collision in his article can't be right from physics standpoint and helicopter aerodynamics handbooks also disagree with him. Because of precession any tilting of the rotor disk is caused by a force roughly 90 degrees before the highest point of the rotor disk. As the lower rotor spins counter-clockwise and right side is tilting up, the force causing it must be acting at the aft section of the disk. There's no obvious candidates what could be the source of this mysterious lift but it's real world phenomena as a NASA article about co-axial rotor systems confirms. An article by Mangler and Squire from fifties has a mathematical aerodynamic study of helicopter rotor induced flow patterns in different flight conditions. It uses some very rough simplifications as they didn't have supercomputers at that time for flow calculations, but it does give a hint of what might be happening. In the appendix of the article there's some visualizations of the flow fields in different flight conditions, and you can see that there's some upwards flow at the aft section of the flow pattern at high speed. While in single rotor choppers this isn't able to overcome translational lift that causes the retreating side to rise, in co-axial choppers that might not be the case. I'm kind of speculating here as I haven't seen any studies of induced flow patterns in co-axial choppers but it's clear that blade collision can't be because of dissymmetry of lift. The induced flow pattern is currently the only thing I know of that could be causing it. It's also worth noting that blade collision indeed happens at both lower TAS and IAS at higher altitudes as induced flow increases. I repost the links to the NASA article and the other article I'm referring to. NASA article: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19970015550_1997024330.pdf The article by Mangler and Squire: http://naca.central.cranfield.ac.uk/reports/arc/rm/2642.pdf This one is also very usefull. Introduction to helicopter aerodynamics: http://www.cnatra.navy.mil/pubs/folder5/th57/p-401.pdf

Actually those are kind of smart bombs. The Huey would fly at high altitude to the GPS coordinates he was supposed to bomb, establish hover and then drop the bombs. Pretty clever improvisation I would say.

The right side of lower rotor disk raises due to induced flow through the rotor disk, not due to the blade traveling the same direction as the helicopter is flying. When air gets thinner the blades need to work harder (higher AoA) to produce the same amount of lift and therefore the induced flow is increased. How the induced flow decreases blade tip separation in forward flight is a very complex phenomenon that needs to be explained with complex math or wind tunnel demonstration as it's all about air particles interacting with each other. There's a thread about this behind the link, sadly without any comments from ED. http://forums.eagle.ru/showthread.php?t=99594

Rotor and engine have only an aerodynamic coupling, ie. engine exhaust turns a turbine that then turns the rotor. You need a certain amount of "wind" from exhaust for the turbine to generate enough torque to overcome friction in the drivetrain.

http://forums.eagle.ru/showthread.php?t=92722

What's the point of having the TGP in the loop if you are going to find the target with your eyes anyway? Why not just lock the target with Sidewinder in the first place?

I have also tested this and it happens also without submenus. I also submitteed a bug report on this. http://forums.eagle.ru/showthread.php?t=109298

Steps to recreate the crash. -Join as a client to the server running the mission and pick one of the Hueys. -Fly about 1km distance from FARP, land and eject. This will spawn a soldier to your ejection location -Respawn and check your F10 radiomenu that it's there. If not respawn again until you have it. Fly to the ejected pilot i.e. soldier, land less than 20m from him and use radiotrigger "Get to the chopper". This should crash the game. The function called by "get to the chopper" trigger starts from line 777 (PickUpTechnique) in Battlefield_init.lua. My initial suspicion is that the game crashes when a function RefreshChopperRadioCommands is called inside the PickUpTechnique function.

There's something strange with missionCommands triggers in multiplayer. They work only randomly for clients at best and usually crash the game for them while everything is fine for the host or in single player. The game crash is always associated with creating a new trigger for client when there's some already in there. Oftentimes radio trigger creation doesn't work and client doesn't get any triggers at all. When I test the mission in singleplayer, everything works without a hitch. The mission I have problems with is behind the link. Only Hueys on both sides have radio triggers. http://forums.eagle.ru/attachment.php?attachmentid=84287&d=1372509929

As I was afraid, the radio triggers crashed the game continuosly, so I'm taking the server down for tonight.

I managed to get the smoke system working, ie. Huey pilot can request the downed pilots to throw a smoke grenade and every pilot within 1.5km will do so, unless they are clumped together in which case only one of them will. I also built a message system, so now it's possible to show messages to players along with the info screen. When pilot ejects, he's LL coordinates and beacon frequency is shown in a message for the pilots coalition. Updated mission file in the first post.

Next Saturday is confirmed, 19-22, timezone GMT+2(+1 for summertime).

The Huey transport script is ready and working and it's pretty cool. As I previously said now all the playable units will reduce your tickets when they get killed and aircraft will be much more expensive than ground units. With aircraft the ticket penalty is divided between aircraft and pilot, with the pilot being much more valuable. If aircraft crashes you will lose some tickets and if pilot dies or ejects you will lose some tickets. Ejection will now spawn a "pilot" (thanks to Wolle for an example script) and if you manage to bring him back to base you will get back the ticket penalty associated with the pilot, ie. about 70% of the initial loss. You can either order the pilot to walk home (using CA) or bring him home with a Huey. With this in mind it's most favorable to bring the aircraft back home and repair it. If you can't land back to base the second most favorable option is to land safely somewhere and then eject and then get the pilot back to base. The third most favorable option is to eject over friendly territory and then get the pilot back to base. The least favorable option is to destroy the aircraft and get the pilot killed in the process or have him eject somewhere (like behind enemy lines besides AAA site) where he can't be brought back to base. Huey is able to transport both ejected pilots and MANPADS. The cargo unit is loaded with radio trigger and this will generate another trigger for unloading him. You can have 9 units aboard before running out of room for triggers in the menu. The load trigger will search if there's transportable units within reach (<20m) and load the closest one if found. If the Huey crashes while transporting cargo, the cargo units will die also and you will get the associated ticket penalty. If you crashland and survive, you can eject and the cargo units will also safely eject and can then be transported home or somewhere else with another Huey. For some reason you can eject Huey while in midflight but this will not spawn rescuable pilot and the cargo units will also die. I will polish the mission a bit more by adding smoke markers for downed pilots and some voice messages about the game situation. I have also some other things planned but don't know if I have time to implement them. I'm considering to make the Battlefield script so that anyone can build their own DCS Battlefield missions by simply placing units and trigger zones and then naming them correctly so that the script recognizes them. I might do it anyway as building more missions myself would be much more easier and faster that way. But does anyone else have interest in building this kind of missions? The latest version of the mission is in the first post. I will put up my server possibly next Saturday at the usual time. I will confirm this later. EDIT: I haven't been able to test this mission in multiplayer and there might be issues. If anyone can try it out and report I would appreciate it.

Engine and rotor aren't connected mechanically but only aerodynamically. Rotors are connected to the gearbox which is connected to two turbines behind each engine. The engine exhaust makes these turbines to spin and provide torque to the rotor. So in effect the RPM limit only limits the power of the engine ie. torque to the rotor but the rotor RPM depends also on the drag of the blades. You can have the engines limited by RPM but still have nominal rotor RPM if you your collective setting doesn't provide too much drag to the rotors. DCS doesn't model any kind of updrafts or downdrafts currently besides some turbulence. I'm sorry I got somehow confused what you were asking originally and gave you the wrong answer in previous post. The proper answer is: "In general the nominal rotor RPM is the most efficient, so in general you should have less sink rate with less collective." Everything after the first sentence should be correct. With light load having lower than nominal rotor RPM could be more efficient but there's no proper control in Ka-50 for that except the low RPM switch that might or might not put the RPM to proper range. To really understand what's going on with the rotor and the engines you will need to read some aerodynamics like this: www.cnatra.navy.mil/pubs/folder5/th57/p-401.pdf

In some cases, but generally not. Just like with aircraft wings the helicopter rotor blades have some certain angle of attack that generates lift most efficiently. This angle is mostly relevant in hover as other things become more relevant in forward flight. You would need a fuel flow or torque meter to see how much power you are using and then slowly changing the rotor RPM and collective in unison to keep the altitude you would seek the minimum in required power. When hovering with light load you might find that lower RPM actually gives you more lift with less power but in general the difference wouldn't be great and you would be sacrificing flight safety in the process. In single engine flight it's very easy to choke the engine with too much collective and drop out of the sky as a result. The default rotor RPM is a result of optimizing multiple variables to get a happy compromise and generally not adhering to it isn't going to do you any good but usually just the opposite.

I'm pretty much near completing a pilot rescue feature to my DCS Battlefield mission. It's a Battlefield game series inspired PvP flag capture mission. You lose score for every friendly destroyed unit, but aircraft will cost you much more than ground units. If pilot manages to eject, the mission will spawn a lone soldier to ejection location. If he manages to get back to base his side will gain most of the lost score of the aircraft back. The mission also includes transportation script for Huey so they can pick the pilots onboard and take them back to base besides transporting MANPADS. The distances in the mission are quite short and there's going to be lot's of pilots shot down so the SAR pilot shouldn't get bored. And there's also other stuff for him to do in the mean time.

For the maximum accuracy fire the gun with zero LOS rate and only single shots. LOS rate means angular movement, ie. if the gun is turning while tracking the target, LOS rate isn't zero. Basically this means you have to wait for the recoil movement to stop before firing the next shot. The servo control logic that keeps the gun pointing where it should will always have some inaccuracy if the there's change in LOS rate. While steady LOS rate would do the same trick as zero LOS rate, in pratice it's hard to achieve because of the small gun constraints.

You can get direct hits on tanks pretty consistently if your release altitude is only 3000ft. You can kill tanks easily from 4000-5000ft heights. Lighter armored targets like Shilkas and Strelas can be killed from 7000-9000ft release altitude without them getting a chance to shoot back at you (Strela doesn't have time to launch before you have climbed back at safety and Shilka just can't hit you that far away). With strong winds your accuracy won't be this good though. You should fly in a relatively straight path (velocity vector staying on the same spot on the ground) when releasing the bombs for the pipper to be accurate. Other thing is to have correct altitude for the target. Usually the DTS mode (digital terrain height map) gives you accurate enough altitude for the bombs to hit but in certain areas the DTS altitude is off considerably causing the pipper to not be accurate. Basically if the ground isn't pretty much flat around the target, there's a chance that the DTS altitude isn't accurate. To get around this problem you can change the DTS mode to "hot elevation" so that the pipper will then use manually set constant elevation. By changing the "hot elevation" to the targets altitude, your pipper will be accurate at the spot where the target is but most likely not anywhere else. You can get the targets elevation by locking the target with TGP and lasing him to get accurate coordinates which also include target elevation. Without lasing him the altitude showed will be DTS altitude. You can set this altitude manually or you can make a target point and when changing to hot elevation it will automatically use the selected target points elevation as default elevation. I can't remember the exactly the buttons you need to press but it was either DATA or SEL rocker in UFC that made the change. Manual should describe this procedure.

This is a good idea. To take the idea further, AI should also be able to retreat or hide when facing superior enemy or taking too much casualties. Basically suppressing enemy is forcing him to take cover and hide.

The updates to AI detection logic sounds really good. Finally we can start using more realistic tactics against AI.

This is what fm3-04-126 Attack Reconnaissance Helicopter Operations has to say: (Chapter 3: Employment - section IV Security Operations - Guard p.3-41) Critical Tasks 3-183. When operating as an element of a guard force,the ARC conducts the following critical tasks for the ground maneuver commander: - Performs reconnaissance along the mainbody’s axis of advance. - Performs reconnaissance between the mainbody and guard force BPs. - Maintains continuous surveillance of threat avenues of approach larger than a designated size into the AO. - Maintains contact with threat forces, not allowing threat ground elements to pass through the AO undetected and unreported. - Maintains contact with the lead combat element of the main body. - Destroys or repels threat reconnaissance and security forces and impedes or disrupts threat forces in accordance with guidance and capabilities. - Defeats, repels, or fixes threat ground forces before it engages the main body with direct fire. - Locates and causes the threat main body to deploy, determining its composition and direction of travel, if applicable. This is the doctrine, the guiding principle the practical plan should follow, ie. the practical details depend on the situation and judgment of the commanders and pilots. Basically you need to have some kind of idea who you are fighting and what weapons and tactics he uses and what are his goals. From that you can derive a threat assessment and figure out what you need to provide required firepower and what are the distances and tactical details. For example the tactical details are different in Afghanistan and Iraq for convoy escort and they have also changed along the years as the situation has changed in these countries. The basic idea though is to have someone searching the area ahead and at the same time someone else staying close to the convoy to provide immediate fire support if needed.

I tweaked the capture zones positions for better gameplay and more intense ground battles. Also as a precursor for adding Huey, I gave each unit certain ticket value you will lose when it gets destroyed. For aircrafts you will also lose tickets if the pilot gets killed or ejects. Getting both plane and pilot blown to pieces will cost your side considerable amount of tickets as will quitting or switching planes in mid flight. If you get damaged but can bring the aircraft down safely and only then eject, you will lose less tickets than if you eject and let the aircraft crash. You won't lose any tickets if you can bring the airplane home in repairable condition. Of course it's also beneficial to eject closer to home base than behind enemy lines as it's faster to pick up the pilot and get him home for the tickets reward. The next step will be adding ejected pilots on the ground that can be transported back to home base for getting back the lost tickets from ejection. With this I will also add the transportable MANPADS.

Found and fixed a bug related to updating the ticket count. The updated mission file is attached to the first post.

Thanks for all who participated, comments are welcome as always. Next time will be monday night 19-22.