Jump to content


  • Posts

  • Joined

  • Last visited

Personal Information

  • Location
  • Occupation
    Mechanical engineer
  • Website
  1. Yes, of course, thanks for reminding me. Attached pics of the mod during the day, dawn and at night.
  2. 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...
  3. 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
  4. As always, pretty useful stuff. Thanks a lot for sharing!!
  5. 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...
  6. 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!
  7. 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!!
  8. ^^ But if you're using the real DCS radar, then the work around isn't necessary...
  9. 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...
  10. Wow, Nero.ger already figured how to link that to the weapon system, I'm going to have to edit my post above lol...
  11. 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
  12. ^^ Thanks, I will post code and more info on what I'm doing, I just can't do stuff right now.
  13. 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.
  • Create New...