Jump to content

Luiz Renault

Members
  • Posts

    60
  • Joined

  • Last visited

  • Days Won

    1

7 Followers

About Luiz Renault

  • Birthday 10/10/1982

Personal Information

  • Location
    Rio de Janeiro - Brazil

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi. This is from before using DCS API: https://github.com/luizrenault/a-29b-community/blob/6bbe6452fd41c002305ded949f7800a48fde81f3/Cockpit/Scripts/Systems/weapon_system.lua#L504
  2. Hi. CCIP is calculated using DCS API. CCRP is calculated using the CCIP calculation and then taking into account the "impact distance" from target. At the beginning i was doing the CCIP calculations by my own and realized that DCS does not take into account draw or it was negligible in their calculation. Because when I used drag, the bombs always fell longer. avSimplest.dll was developed based on DCS API without the SDK, using headers that I've put together from the exported functions and methods from DCS dll files. Now the headers are so big that they work like a SDK, but with no ED support. It is why after each DCS update i need to check what have changed and modify on my headers. It is not impossible to make camera and laser designation work without the SDK. It is just hard. Took me about 7 months of very intense work to do it. Several guys asked me how I did it and I showed them on a Discord call. No secrets. I can show you. It only requires C++, VS Windows programming, assembly experience and patience. In four months I was able to create my own custom avDevice in C++ and in seven got FLIR and Laser to work. I was willing to release the source code but a bunch of jealous guys (which came from community developers to 3rd parties) created a narrative that it was against ED terms. At some point some ED guys said that as long as all the code was made by me (and it was) there wasn't a problem, but they would check it out. Since I never got a straight answer it is closed source by now. What i usually do is to "license" the dll to work in free open source public mods, when asked. I put that lock because I saw that some people were using my dlls to make profit in private mods.
  3. Will release an update in the next couple of days.
  4. Hi. It is not available on the Star Safire II implemented on the specific version of A-29B. With enough demand I can implement other versions depending on information available.
  5. Hi. I really appreciate any feedback in order to improve EFM.
  6. There is still FLIR that doesn't show any images in MT. Trying to solve that.
  7. I've just released an update for that one. Working ST and MT. Next releases will include lasing and better autopilot.
  8. There is a new update. I added a download link for the dll only. It's the only component required to update between DCS updates. To solve this, ED would have to send me their new dlls prior to releasing an update and add A-29B to the DCS update scheme, or add me as a 3rd party dev and distribute A-29B freely with DCS.
  9. Hi. I really thank @Rudel_chwfor the outstanding contributions he has been doing to the A-29B mod. Just a quick update: I'm currently working on a EFM version of the mod and plan to release it this month. The mod is compatible with 2.8 openbeta and can be obtained like it is explained above, using "Download Latest Release" on the readme. Sorry if the development speed is not up to some of you guys, but feel free to offer help and contribute like many have done. We don't need to create a different branch of this mod. After the EFM we will do the backseat 3d model and enable it. New features coming are Datalink, VOR, ADB, GPS/INS weapons, new FLIR with lasing capability, new autopilot and more. For other features, please post on github the wishlist because it is easier for me to keep track. Also a completely new cockpit and external 3d model is on the way. Sorry for not answering here before, but i changed my email address and forgot to update it here, so i wasn't getting any notifications.
  10. Are you using custom axis/button mapping with TM Target software? Will try to release source code that don't exposes what i can't disclose.
  11. Copy the contents to "Saved Games\Your DCS Folder\Mods\Services". Very early access. Works with TM Warthog, Cougar MFD, A-29B, F/A-18C and other untested modules. Please provide the feedback to improve it. DCS-HID.zip
  12. This is the result. I've created a Service Mod that controls ThrustMaster Warthog and Cougar MFD brightness using the DCS cockpit console and panel brightness setting. no need to install any additional software rather than the mod folder in Saved Games\DCS\Mods\Services Since i want to make this public and have very little time, i'm looking for contributors for creating Theme icons and options UI dialogs. TM throttle 5 leds and Cougar MFD 2 leds each can also be used for configurable indications like gear, master arm and so on. I think that something similar can be done for X52 and X52 Pro. Even with UFCP text on the LCD display. WhatsApp Video 2022-08-01 at 23.02.42.mp4 WhatsApp Video 2022-08-01 at 23.01.13.mp4
  13. Cougar MFD's USB HID descriptors are as folllows: Interface 0 HID Report Descriptor Game Pad Item Tag (Value) Raw Data Usage Page (Generic Desktop) 05 01 Usage (Game Pad) 09 05 Collection (Application) A1 01 Usage Page (Button) 05 09 Usage Minimum (Button 1) 19 01 Usage Maximum (Button 28) 29 1C Logical Minimum (0) 15 00 Logical Maximum (1) 25 01 Physical Minimum (0) 35 00 Physical Maximum (1) 45 01 Report Size (1) 75 01 Report Count (28) 95 1C Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit) 81 02 Report Size (4) 75 04 Report Count (1) 95 01 Input (Cnst,Ary,Abs) 81 01 Usage Page (Vendor-Defined 1) 06 00 FF Usage (Vendor-Defined 1) 09 01 Report Size (16) 75 10 Report Count (1) 95 01 Feature (Data,Var,Abs,NWrp,Lin,Pref,NNul,NVol,Bit) B1 02 End Collection C0 Consisting in a 4 bytes long HID Input Report for 28 buttons (OSS 1 to 20, Gain+/-, Sym+/-, Brt+/-, Con+/-) and a 2 bytes long Feature report. Analyzing the USB traffic during TM Target software controlling the MFDs and with the aid of USBLyzer (https://www.usblyzer.com/) I could figure out that the first byte of the Feature report can be 00h to set individually each of the two round leds on the top and 01h to set the MFD brightness. In this fashion, a SetFeature operation with 00h 00h shuts down both leds, while 00h 01h, 00h 02h, 00h 03h turns on the left led, the right led and both leds respectively. Additionally, a SetFeature operation with 01h XXh controls the brightness of the device from XX=00h being all lights off and XX=FFh the brightest setting. Note that the brightness setting also applies to both round leds, if they are set as lit. This way, the only thing that the Mod needs to do is to look for Cougar MFDs in the USB HID devices list, open it for writing and use SetFeature operations according to the plane's panels brightness settings. And if the user doesn't need the round leds to indicate the MFD number, they can benefit from using them as indicator for other status lights like landing gear and master arm states for example. These settings could potentially be customized in the mod's settings dialog. Another challenge for the mod would be to detect which aircraft is being used and where to look for the backlight state brightness information. i.e. if all electric systems are off, it would have to turn off all leds.
  14. So let's start with the Cougar MFDs, because they are the ones that are more annoyingly bright with default settings. Cougar MFDs are USB 1.1 HID devices. Here follow some of it's device descriptor fields: Device Descriptor F16 MFD 1 Offset Field Size Value Description 0 bLength 1 12h 1 bDescriptorType 1 01h Device 2 bcdUSB 2 0110h USB Spec 1.1 4 bDeviceClass 1 00h Class info in Ifc Descriptors 5 bDeviceSubClass 1 00h 6 bDeviceProtocol 1 00h 7 bMaxPacketSize0 1 40h 64 bytes 8 idVendor 2 044Fh 10 idProduct 2 B351h 12 bcdDevice 2 0100h 1.00 14 iManufacturer 1 01h "Thrustmaster" 15 iProduct 1 02h "F16 MFD 1" 16 iSerialNumber 1 00h 17 bNumConfigurations 1 01h Note that on the pair pack one is labeled as MFD 1 and the other as MFD2. They both differ by the idProduct and iProduct fields. MFD 2 has idProduct equals B352h. For the time being, I don't know a way to change the idProduct of a specific device. I have two sets and use MFD1 for the left MFD, MFD2 for the right counterpart and a second MFD1 for the central CMFD as the F/A-18C layout. My setup can be seen here, but the pictures are a little oudated: https://www.instagram.com/myezsimpit/ Sometimes DCS (or Windows, I don't know for sure) messes up my key bindings between both MFD1 devices. This is also annoying. If anyone has a solution for that, please tell. But this is another story.
×
×
  • Create New...