Sérvalpilot

This is pretty nice! There's one big problem though, avSimpleRadar can't track targets less than 300 m away and tends to unlock for no reason. By the way, how awesome would it be if we could get other "simple" devices like a laser designator or camera?

My suggestion would be new "simple" devices. It would be fantastic to have more space for creativity, if they're not very good like avSimpleRadar which can't track targets less than 300 m away.

UPDATE: I finally managed to get something! It's not perfect, and I still don't how the drag coefficient table works, but it's definitely usable. The script I made essentially "simulates" the projectile's motion with all the physics calculations along a series of time steps. It's fairly CPU intensive and there might be a better way to do it, but this works well for now. I'll clean it up, add annotations, then probably share it at some point soon!

I absolutely agree that there should be limiters. I found out that the "limit afterburners" in waypoint actions for AI does NOT stop them from using afterburners in combat. I found one way to reduce their maneuverability. Make them carry really heavy things that they won't use in a dogfight (like bombs), then set the option to restrict jettisoning. That slows them down a bit.

Some weapons like bombs and shells have a cx (drag) table instead of a single number. For example: cx_coeff = {1, 0.29, 0.71, 0.14, 1.28}, What does this table mean? I know it defines the projectile's drag properties, but how exactly?

I would love to see more cockpit devices available for mods. Already, the devices that are usable with functions and parameters are: avLuaDevice avSimpleElectricSystem avSimpleWeaponSystem avSimpleRWR avSimpleRadar avNightVisionGoggles avIntercom avUHF_ARC_164 avILS These are several other devices that technically exist, but are inaccessible for mods: avTVSensor avIRSensor avBasicSensor avLaserSpotDetector avRangefinder Having these devices available with functions and parameters just like those in the previous list would be great. So, in the same way avSimpleWeaponSystem has functions like launch_station() and parameters like "WS_IR_MISSILE_LOCK", avRangefinder stuff would look like is: function: set_laser_code(), parameter: "LR_AIM_ELEVATION". This would make it possible to have laser designators, cameras, and IRST, etc., without needing a third-party dev license and the SDK.

I got the HUD indicator correct. I tested it by using a custom gun that shoots bullets with almost no drag. The problem now is adding drag to the calculations. I'm going to try several methods, but no luck yet.

This doesn't really work. The reticle's movement seems delayed compared to my method, and its also inaccurate like mine. I saw the latest A-29's weapon_system file has lines like this: local valid, az, el, travel_dist = Calculate() The calculations themselves seem to be done in avSimplest.dll, not in the Lua environment. I thought you meant there was some built-in function in avSimpleWeaponSystem, similar to "WS_IR_MISSILE_LOCK" or "WS_GUN_PIPER_AZIMUTH" but specifically for CCIP. On the topic of drag, I tried several equations which didn't work, so I'll try using the Runge-Kutta method next.

@Luiz RenaultThanks for the reply! I'm doing my own experimentation with DCS systems, and I don't see these "DCS API calculations" for CCIP you're talking about. Feel free to PM me or reply on my thread about CCIP calculations or using the API just to keep this thread about the mod itself. By the way, some documentation on creating something like avSimplest would be great, but that's up to you.

Hi! Do the CCIP/CCRP modes account for drag? If so, what do the calculations look like? Also, are there any plans to share the source code for avSimplest.dll? Was it created using the SDK or something? As far as I know, it's not possible to make a camera or laser designator device without the SDK, so I wonder how it's done here.

Hi! Does the CCIP mode account for drag? If so, how is it done here? Also, are there any plans to share the EFM source code?

I managed to get a little further, now I'm trying to incorporate drag. Here's a breakdown of some of the code I have so far. rpx, rpy, rpz = self.getSelfCoordinates() -- Release point coordinates, lat, alt, lon vx, vy, vz = self.getSelfVelocity() -- Release point component velocities, lat, alt, lon g = -9.81 -- Gravity t = (-vy - math.sqrt(vy * vy - 2 * g * (math.abs(h))))/g -- Flight time to impact ipx = rpx + (vx * t) -- Impact point x coordinate ipy = self.getBarometricAltitude() - self.getRadarAltitude() -- Ground level ipz = rpz + (vz * t) -- Impact point z coordinate dx = -ipx + rpx -- Distance along x axis dy = -ipy + rpy -- This should be radar altitude dz = -ipz + rpz -- Distance along z axis dist = math.sqrt(dx * dx + dy * dy + dz * dz) -- Total distance scalar horiz_dist = math.sqrt(dx * dx + dz * dz) -- Horizontal distance scalar hdg = pi - self.getHeading() ip_azimuth = (math.atan2(dz, dx) - hdg) % (2 * pi) if ip_azimuth > pi then ip_azimuth = ip_azimuth - 2 * pi end ip_elevation = -math.atan2(dy, horiz_dist) -- Some stuff to correct for roll and pitch cos_roll = math.cos(roll) sin_roll = math.sin(roll) azimuth_correction = ip_azimuth * cos_roll - ip_elevation * sin_roll elevation_correction = ip_elevation * cos_roll + azimuth_correction * sin_roll -- Final corrections, sent as parameters for HUD ccip_x = azimuth_correction + pitch * sin_roll ccip_y = elevation_correction - pitch * cos_roll I tested this by making a custom gun that shot bullets with almost no mass or drag and it was very accurate. Now the challenge is adding drag. Any ideas?

Hi, I am experimenting with different systems in DCS and I'm currently trying to get a constantly computed impact point (CCIP) indicator/reticle or "pipper" working for air to ground weapons. I think I got the basic prediction calculations right, like flight time and x,y,z coordinates of the launch and landing points, and factoring in gravity and altitude above ground. The problem I have is turning it into a HUD element. The left/right movement (azimuth) seems to be OK, but the up/down movement (elevation) isn't working right. The main problem I have is this: when maintaining a downward pitch angle, the dot should move up on the HUD but never be above the nose. Maybe there's some equation or factor I'm missing or I'm doing something wrong, but I don't know. Examples of something similar in other games seem to place the indicator in the actual 3D environment, which is not possible in DCS to my knowledge. Also, the two community mods that have CCIP functionality (A-29 Super Tucano and T-45 Goshawk) seem to do the calculations in a .dll file for which the source code has not been shared. Any ideas or suggestions are welcome, and code snippets will be greatly appreciated!

UPDATE: I finally figured out a way around this! The solution is to go to the aircraft declaration file and state that there is more than one pilot. The cockpit sound muffling bight be disabled for some reason, but that can be fixed. Also, the cockpit view and maybe even controls might still work, but that's a minor issue in my opinion compared to DCS crashing.

There is a flight model template you can find in your DCS main install directory! In the "API" folder, you can find an external FM template. It is a C++ project you can open with Microsoft Visual Studio, and the output is a .dll file. null It's fairly open so you can do whatever you want with inputs. The main physics outputs are add_local_force() and add_local_moment() for forces and moments respectively, using vectors for orientation and position. A basic understanding of C++, aerodynamics, and vector math is useful here. You can also handle commands, fuel drain, damage, and parameters. A section of the main file looks like this: I would also recommend checking out the EFM source code for the A-4, F-104 and AH-6 mods, you can learn a lot from them. I am also thinking of making an enhanced template to make it easier to learn the basics. Good luck!

That worked! Turning off SSAA fixed it. That's a weird problem regardless. I hope it gets fixed soon.

I'm using one monitor. I was using 2.8.7 stable, but when I tried the multi-threading preview, NVGs worked fine. It seems to be a problem with the current stable version, at least for me.

I don't know when this bug appeared, but NVGs are misaligned to the main view. It's very disorienting. I need to move the camera to the right slightly to see through the HUD. KA-50: Mirage-2000C:

Yes. I'm trying to make a dogfight practice mission. For now, I just equip the fighters with heavy weapons like bombs and set them up to engage the player with guns only. That slows them down, making dogfights a little bit easier.

UPDATE: I discovered something a bit unfortunate. Using FC3 avionics (Su-27, F-15C, Su-25, etc.) combined with a custom flight model AND a custom main panel leads to DCS crashing when the pilot ejects or is killed in the cockpit. My guess is that DCS doesn't know how to handle this, so it crashes. This makes aircraft mod creation a lot more difficult because all the avionics, targeting systems, and other stuff from FC3 would need to be done separately like the A-4 mod, but maybe there's a way around this. Again, the only problem, which is a big one, is that DCS crashes when there's no pilot controlling the aircraft. Everything else works fine.

Maybe I'll put that on the mission editor wishlist. The restrict afterburners option should have three settings: allow, combat only, and never use.

Nope. Still not working. After a bit more research, it seems like the AI will always use afterburners in combat, which is what I'm trying to restrict in my mission.

UPDATE: After doing a lot more testing, it seems to be linked to the cockpit's main panel. Leaving out the main panel declaration in the device init file fixes it, but at the expense of breaking all the cockpit panel stuff like gauges and indicators.

Maybe a bug was introduced at some point because it doesn't work for me either (DCS 2.8.7 stable). Restrict afterburner and jettison are ignored.

I did some more tests and the restrict jettison and afterburner options never work, but other options do. That's right. It's an unintuitive design choice and it confused me a little bit. I thought there was another step to getting the actions to execute.