Bushmanni

Actually ABRIS shows ground speed.

Those reference points are not what I meant. They are used for AI JTAC IP points and you can't use them like I described. Mainly it'll be pita to make lots of them and then access them in a handy way in SSE. For example if you wan't to build a network of waypoints (hundreds of points) you will lose your mind using those and I'm not sure if it's even possible to assign lots of them. While this could be done with unit waypoints it's a hassle both in ME and SSE.

It would be nice if there was a reference point object that could be placed in the ME that you could reference using SSE to get the 3D coordinates of the point. By placing lots of these you could define waypoints, areas, lines, grids, etc. for your scripts with much less work. These reference points should also come in groups (like units do) so that they are easier to manipulate both in ME and SSE.

Lets not make this too complicated. Building a model that almost exactly fits the data would be very hard but in this case an error of 5-10% in spotting probability isn't going to be a big problem. I think it's possible to get a pretty good approximation of the real data by hand tuning the parameters until the model gives good results. This problem doesn't need any custom probability distributions but only a function that gives the spotting probability as as function of some parameters (range, background, ...) and then you pick a random number with uniform distribution between 0 and 1 and see if it's larger than the spotting probability. There's no need to make any adjustments for multiple targets as if there are more of them it's natural that you are more likely to spot one of them. This would not be the case if scanning would be simulated in some way but that's not really necessary at least in the initial version.

I skimmed though the papers and they had multiple different scenarios where the detection probability was estimated from experimental data. I think an analytical solution would be hard to obtain that would consider all the data available. I suggest you design a mathematical model (you have probably done this already) for the detection and then extract lots of datapoints from the experimental data and fit the model to the data. ie. use some kind of algorithm that adjust the model parameters until the error between data and model is minimized.

Training is a full time job of real pilots and they do it often 10+ hours a day so it's a no contest when comparing sim pilots and real pilots. Even if a sim pilot would have no other obligations he would have to be pretty hard core to put in such training hours. Therefore no matter how talented you are there's no way you can bridge the gap created by amount of training. On top of that the real pilots are carefully picked to have the required talent for the job. The rate of learning will diminish with time so it might be possible for some hard core sim pilot to get relatively close to real fighter pilot standards if he can keep at it for a long time like a decade and has proper support. But I suppose that kind of people would be pretty rare. One problem is that we don't have professional instructors and backing of an institution that has accumulated almost century of knowledge and experience about air combat.

Not all bugs need to be fixed right away but there are some that have a big negative impact on gameplay. For example A-10C can live without CBU-87s but P-51D is having hard time with bugged guns. While you can't eat reputation it isn't something to be neglected.

What I'd like to see is DCS World that doesn't have game killing bugs introduced every so often that don't get repaired as soon as possible. P-51D tracer bug basically prevents larger scale MP dogfights and nothing has been done about it. It clearly isn't impossible problem as A-10s, Vulcans and Shilkas can pour out much more shells in the air than the Mustangs do without problems. Eye candy can't be more important than playability. While I accept that things are like they are it astonishes me that EDGE isn't designed from ground up to enable collidable trees as that is a very important gameplay element that has been killing immersion and giving headaches to mission designers and players since DCS BS. You can't have fun gameplay with AI units near forests which reduces the options with mission design considerably. While I love the eyecandy of EDGE it won't be worth the wait if the tree problem doesn't get fixed. Other thing is AI that seems to be constantly getting broken somewhere and if it gets fixed it'll soon break from somewhere else. My bottom line is that ED should pay more attention to working gameplay and keeping the main features playable and not kill all the potential with some strategically placed bug or lack of feature that renders lot's of other great features useless in practice. If the game becomes unplayable people find something else to do in the meantime and might forget about DCS.

A very big improvement would be to just block radar and AI vision through trees as that alone would enable realistic low altitude tactics for helicopters and aircraft.

The sound has been obviously changed. What you hear is LMG or multi barrel gun, not 2A42. This is 2A42.

Maybe because the sound in the video is from a gun shooting about 1200rpm instead of 600rpm which is the cyclic rate for the Ka-50 cannon.

I'm not so sure if all the colors are too much saturated but the sand definitely is compared to photos or what I saw with my own eyes when I was there. The other thing is the luminance level at horizon which looks too dark. It looks like all the hills in the horizon are in shadow or inside a rain torrent. But overall the engine and scenery looks really nice.

Would it be possible that soot would insulate the cylinder head enough to have an effect in heat transfer while there not being too much of it to prevent the engine running altogether?

There's no performance numbers available but all the flight phenomena of co-axial choppers are modeled that can be modeled with current PC technology. We have to take ED's and Ka-50 pilots word for it flying like a Ka-50 but there's lot's of proof that it flies like a co-axial chopper. There has been lot's of questioning about some strange behaviors that people have noticed but in the end in each of those cases it has been concluded that the same thing should be happening in the real world also. The only major thing officially not modeled is compressibility when diving at high speed.

New version out. Changes include one Mi-8 per side and some code tweaks for better stability. Download link in the first post.

It's likely that that I inadvertently had multiple quotation marks in one piece of string as a result of concatenation that caused the error. I already changed the code to be completely different so I can't test to verify but it's likely the line breaks weren't the issue.

MGRS grids overlap in real life also so it's unlikely this "problem" gets "fixed". If you mean that in-game coordinates and bearings don't match with real world coordinates and bearings, then that should get fixed by using curved ground.

I was trying to use textOut with linebreaks in a very long string to break it to multiple lines. Is there some other way to do this besides using linebreaks? I was able to find a work around that doesn't require that kind of formatting but I think it would be useful to be able to do that if it's possible. The same line runs without problems without the dostring.

I found out that having "\n" in the string when using mist.utils.dostring() fails the execution of the code because of improperly ending string. It the behavior is like intended then maybe add mention of this problem in the wiki. The explanation of the function in the wiki is also a bit messy ("... If false, then this value will be the compilation error. ...", which value?).

I will host DCS Battlefield next Friday 19-22 (GMT+2) and longer if there's players around. I just decided I can have time for this so I haven't got dedicated ground commanders yet but I'm working on it. If you think you can be around during the allotted time, can (own CA) and know how to command ground units and have basic knowledge of the mission send me a PM. You can still fly if you want but your main responsibility would be to keep the ground war going and try to capture flags with ground units. If you have buddies with you that's ok too.

You don't have to floor the collective all the way to autorotate. Keep it high enough that the chopper can be controlled and you should be able to make a fine landing. The strange behavior of Ka-50 in autorotation is most likely pretty close to how it should be. Remember that the yaw force in Ka-50 is produced by torque differential of the rotors that is transferred to the fuselage through the gearbox. In powered flight the lower rotor blades have a slightly larger angle of attack to offset the downwash from the upper rotor to balance the torques of the rotors. When in autorotation the larger angle of attack of the lower rotor makes it have less torque (to the direction of the spin) than the upper rotor. As the upper rotor spins clockwise and has more torque in the spin direction the fuselage will spin clockwise also unless corrected with pedals. Ka-50 can momentarily turn 90 degrees sideways (at least towards right) at 200km/h speed with full pedal depression. While I was testing this maneuver I also found out that Ka-50 can also fly sideways very very fast. I think my top speed was pretty close to 200km/h but I'm not exactly sure of the numbers other than that it was close to 200km/h. The tail is short and the fin isn't really big and it isn't that powerful either in order to enable the previously mentioned unmatched yawing and sideways flying performance.

I have been having strange issues with my DCS Battlefield mission. One of the strangest has been some variables being assigned the value of another variable in a semi random fashion. I say semi random as the mission executes always the same as long as I don't change the code, but if I add or remove stuff before the problem line the behavior changes in a seemingly random fashion. I'm suspecting this is somehow related to scheduled functions interrupting the flow of other functions and maybe altering the variables being evaluated in other functions. My question is if my problems can be caused by function scheduling or must it be something else? I'd like to know also if alteration of a table is even possible to happen because of other function starting to run when other one is still executing. I have already figured out a possible solution to scheduling problems but it would be quite a lot of work to make the changes and as such I'd like to get some verification that trying to fix scheduling conflicts has at least a theoretical chance to help. Basically I'm planning on using scheduling and events to only raise a flag when some function needs to run and calling all the functions inside a loop that reschedules itself after it has run through instead of right in the beginning. It would also have some kind of watchdog system to reschedule it if it stops for some reason. This way I think it's guaranteed to never have one function to run and change data some other currently running function is also using and changing.

Try climbing at 150kts with WEP on. It's not smart to do in any way but will demonstrate the heating and cooling model very nicely. You might also wan't to try redlining the temp gauge and then diving at idle and at about 300kts for few thousand feet and see what happens.

I have no objections for that. I have built this mission for others to host and modify for their taste so that there could be more multiplayer action available.