PeaceSells

Yes, of course, thanks for reminding me. Attached pics of the mod during the day, dawn and at night.

That's what I did, I lowered the friction as much as I could (just be carefull not to unscrew it completely, the manual says the screw may fall out) in order to minimize the stiction. It did make a difference and I'm pleased with it. I don't have any curves on it, but I don't do any carrier landings yet...

Just in case someone missed it, this is the thread by Nero with an example of how to use the DCS's own radar: https://forums.eagle.ru/showthread.php?t=220666

As always, pretty useful stuff. Thanks a lot for sharing!!

In my honest opinion the current cockpit still look awesome to my eyes. I know many people comment on it's age and resolution, but the Ka-50 cockpit for me is one of those examples of how you can have immersive and good-looking appearance without being extremely high-res. I still love the feeling of sitting in that cockpit. All that was just to say that ED fixing the button lights is much more urgent than doing the new high-res cockpit, if that's what ED is waiting for...

Nice video!

Jesus Christ, the radar is working! The most valuable thing to extract from this example, IMO, is how DCS expects you to interact with the radar. As I understood so far: The contact's data is contained the "RADAR_CONTACT_[number]_" param in conjunction with the "RANGE", "AZIMUTH", etc. params. Now I look in the strings extracted from the CockpitBase.dll (as indicated in this thread: https://forums.eagle.ru/showthread.php?t=182020 ) and I see strings like RADAR_CONTACT_%02d_ RANGE AZIMUTH etc. Now how on earth you discovered that those strings, among the zillion other strings in the same file, would be used as params (and after concatenating them) is what right now I can't understand. These params don't appear in the list when you call list_cockpit_params() from the cockpit lua environment... (unlike "RADAR_TDC_RANGE", "RADAR_TDC_AZIMUTH", etc.). I still have things to test and figure and this example is helping a lot... thanks again!

Hey Nero, that was so cool of you to share this... I will have to take a good look into it as soon as I can to see what I was doing wrong... Again, invaluable information in a few lines of code, thanks a lot for this!!

^^ But if you're using the real DCS radar, then the work around isn't necessary...

Wouldn't the AI be actually responding to the weapon launch, instead of to the radar, because I would find it pretty spooky if the AI was responding to this radar simulation...

Wow, Nero.ger already figured how to link that to the weapon system, I'm going to have to edit my post above lol...

I was planning on sharing code only after this alternate radar was a bit more advanced, but considering that the main curiosity around this is probably how to get target data in your cockpit lua environment, I guess I should show the working code behind that. On top of that we can add our own logic for simulating a real radar's detection limitations (which I plan on gradatively try and implement), but looking at it at the state it is right now has the advantage that it becomes easier to visualize the channel used for communicating enemy data (not just enemy, any possible unit) to the cockpit environment. So far (I still haven't investigated this thoroughly), the current lua environment for cockpit scripts seems to give us no access to data from other units flying around (such as position, etc.). The environment for the Export script does have access to these data, so we need to bridge the two environments. One possible bridge is "cockpit argument values", since the Export script can set_argument_value() on your mainpanel, and your avLuaDevice (for example) can get_cockpit_draw_argument_value() from your mainpanel. All you have to do is create new gauges in your mainpanel_init.lua (through the CreateGauge() function) and have the Export script write the target's position coordinates to these gauge's argument values. Then have your avLuaDevice read these argument values. We won't export anything, despite working in the Export script. Basic code for that is in the zip file attached. Good news is that it's relatively simple. Getting enemy data inside you cockpit is by far the easiest part in making a target designator box appear on your HUD and superimpose his exact position. That's why I included in the code attached the part that transforms the target's world coordinates in local coordinates for your aircraft, calculates where exactly he appears to you from your point of view when looking through the HUD, and draws a box there (despite no one asked). Without coding something like that, having the target's data inside the cockpit environment is completely useless. So you should be able to get a working radar target designator box on HUD in your mod if you incorporate the code attached into the corresponding scripts in your mod. Since your HUD device, page, elements, etc. probably have different sizes and positions than mine, you'll probably have to adjust the numbers. Also, since your entire cockpit and mod setup is probably different than mine, I expect that other adjustments will be necessary. I can't predict at the moment what these adjustments will be, so tell me if it doesn't work. Also, I only tested this so far on a mission that has only myself (must be set as "Player" in the mission editor, and not as "Client") and another unit - the F-15 that you see in the video. The code will get the unit that's not you and treat it as the target, no matter where he is in the map and who he is. If you have additional units, I guess it will lock on a random unit, might lock on tanks etc... If he is exactly behind you, the target box will wrap around and appear in front of you, because I haven't done yet the angle restrictions. Naturally, this will not guide any weapons or cause a RWR alarm on the target. As far as DCS's engine is concerned, this isn't a radar. The objective of this simulation is to simulate, so we can practice our coding skills and try to simulate the workings of a radar. This not an attempt to do a fully functional aircraft... RadarSimulation.zip

^^ Thanks, I will post code and more info on what I'm doing, I just can't do stuff right now.

Yes.

This is most likely not possible... the probability that we'll find improvised ways around to each one of these limitations is very low... in my current opinion, at least.

That's my intention, but I have to warn you that it's not what you're expecting. This is not the DCS engine's own radar simulation, as I don't know if it's possible for us to interface with that. So I improvised and I'm writting a radar simulation of my own. Since this is not DCS radar, it's not reckognized and it seems that it's not possible to guide weapons or cause a RWR alarm on the target with it. But we are able to write our own logic for detection, tracking, performance limitations, etc. It needs work before I can share it (in case someone is still interested), and on the next days I need to work in something else not DCS related.

Update: a working radar target designator box on HUD. Still needs adjustments, but here is a demonstration video of it:

Yes, adding placeable trees to the Mission Editor would be a good idea. Sorry, I thought the request was to increase the number of trees in the default Caucasus 2.5... only now I see this is the "Mods" subforum (a little side effect of clicking on threads at the "New Posts" section... I sometimes miss which subforum the thread belongs to...) Better yet if this was done by ED, instead of as a mod. BTW, I haven't looked at the list of static objects available in the ME, aren't there any trees/vegetation in there?

In my opinion, Caucasus 2.5 has A TON of trees for a 3D sim. Unfortunately, hardware technology isn't there yet to give us the same amount of trees of real life, specially with the view range we have in DCS, on maps of the size we have in DCS. I guess more trees could be added if view range was decreased (look at Arma, Battlefield, etc., they all have very unrealistically short range view), but the long view range is so much more important for immersion and realism than just amount of objects. If anything, I would reduce the amount of trees in Caucasus 2.5 and increase view range.

DCS update replaces the modded .json file with the original one again, so, in ordert to continue using it, copy the modded file again to the correct directory (as instructed in the Readme file).

Forgot to say that you will probably also have to adjust the location of your wheels inside the same file: nose_gear_pos = main_gear_pos =

Hey, look in your aircraft's main lua file (usually named youraircraf.lua) for these two variables, they define the diameter of your wheels. Looks like you have to lower them in your case: nose_gear_wheel_diameter = main_gear_wheel_diameter = Regarding the engine exhausts, I'm pretty sure the variables for them are in the same file, but I haven't used them and don't remember their names... but you should find them easily.

sorry but some things are even beyond the most skilled coder Well, who knows what's in ED's SDK...?

Yeah, but in the mean time you can fly during the day with this fix... Which for me is enough, because I don't fly the Ka-50 at night... (AFAIK the Ka-50 was not designed for night combat anyway).

Yes, I've intentionally made them 100% transparent, left only the glass edges visible so you know there's glass there. A computer screen has limitations compared to your vision IRL, so I don't find it realistic to hamper it even more through unrealistic opaque glass with unrealistic sun reflections. In a perfect sim world we would have high res textures simulating realistic dirt, scratches and sun reflections on the glass, to a realistic degree, but the cost may be not worth it. You can make a rough comparison with your car... Even when it's not washed for a while, how many times during your drive do you think "I can't see that thing I need to see because this glass is on the way?"