Exorcet

Those are all 3rd party aren't they?

So with 2024 we've confirmed a module upgraded from FC to FF and we'll have Iraq at some point. So here's hoping for 2025.

If the carrier is nearby, then bingo shouldn't be an issue, although unrelated to all of this I did observe some F-18's refusing to land on a carrier in one of the my missions the other day. I did not look into it very deeply, but I wonder if there is some issue with AI failing to recognize the carrier as a landing spot sometimes.

MiG-29 and Iraq. Big announcements.

There is a trigger for this specifically, Scenery Destruction Zone, it has a percent option to control how widespread destruction is: For fire specifically, use the Big Smoke static object, it can be turned on and off with triggers, has different sizes of fire and smoke, and moves with the wind (so they look kind of weird at zero wind because they go straight up): Note that each fire or smoke plume is one object. I suggest adding a few of the different sizes to the map, then copying and pasting the sizes you want around the area. Also, note that since building destruction can be randomized, fire might not line up with destroyed buildings unless you specifically destroy the buildings you want on fire, or just use 100% destroy to destroy everything in a zone.

I'm not seeing this behavior. I tested the function within my own script and the reporting always stops when the target far enough away. I use AWACS, EWR, and Patriot SAM as the detecting unit and the behavior was the same in all cases: local pri = "T" -- priorirty target unit name local outname = "ELINT aircraft" -- priority target text name (what AWACS will relay) --Bullseye data bullR = coalition.getMainRefPoint(1) -- Red Bulls --trigger.action.outText("Red Bulls X: " ..bullR.x .." Y: " ..bullR.y .." Z: " ..bullR.z, 60, false) bullB = coalition.getMainRefPoint(2) -- Blue Bulls --trigger.action.outText("Blue Bulls X: " ..bullB.x .." Y: " ..bullB.y .." Z: " ..bullB.z, 60, false) bullN = coalition.getMainRefPoint(0) -- Neut Bulls --trigger.action.outText("Neut Bulls X: " ..bullN.x .." Y: " ..bullN.y .." Z: " ..bullN.z, 60, false) --Surveillance Units cmnd = Unit.getByName('E3') -- Command, AWACS unit logi = Unit.getController(cmnd) -- Logic, Command Controller list = logi:getDetectedTargets(Controller.Detection.RADAR) -- Table of detected target, is a table (list) of tables (DetectedTarget) --Blue Side Detection local magvar = -2.2 for _,DetectedTarget in pairs( list ) do if DetectedTarget ~= nil then obj = DetectedTarget.object -- Get index Object from table Detected Target tgt = obj:getTypeName() --Get type of target tID = obj:getName() postab = obj:getPosition() --Get position table of target pospnt = postab.p --Get point position alt = (pospnt.y + 153 )/ 304.8 -- +500 ft for math.floor rounding xvec = pospnt.x - bullB.x -- X vector for target zvec = pospnt.z - bullB.z -- Z vector for target theta_r = math.atan2(zvec, xvec) -- angle calculation theta = theta_r * (180/math.pi) -- angle units theta = (theta_r * (180/math.pi)) + magvar -- angle units if theta < 0 then theta = 360 + theta end if tID == pri then magni = math.sqrt(xvec^2 + zvec^2) -- distance calculation range = (magni/1852) + 0.5 -- distance units trigger.action.outText("Detected " ..outname .."\nBulls: " ..math.floor(theta) .." for: " ..math.floor(range) .." Angels: " ..math.floor(alt), 10, false) --trigger.action.outText("Detected " ..tgt, 10, false) -- Output in text target type --trigger.action.outText("Bearing: " ..math.floor(theta) .." Range: " ..math.floor(range) .." Angels: " ..math.floor(alt), 10, false) -- Output in text target location end end end This script as written is looking for a specific target, but you can change that by commenting out the last if and choosing the appropriate outText at the end.

Unfortunately I can't answer your question, but I can tell you that despite being unable to answer, I've managed to do some scripting. There is some documentation for DCS scripting that you can use to get into it: https://www.digitalcombatsimulator.com/en/support/faq/1253/ https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation The hoggit wiki is particularly nice because it has some examples, which is mostly how I learned. Take an existing script, try to understand, and tweak it. If I need any general Lua knowledge I typically just search online and find the info I need. A place to test code outside of DCS is very useful: https://www.tutorialspoint.com/execute_lua_online.php I'm far from an expert but I like to help out when I can. I've been considering writing up a document with example scripts to share with others interested in scripting/learning, but this will be a long term thing. I don't mind sharing scripts if I have any relevant ones though.

I've not built a cockpit, but I imagine that it would be preferable if you didn't need to construct or program as many switches. This is a good sim option, sometimes you just need to consider practicality. Having the option to auto handle switches also won't prevent anyone from using them realistically.

ED could expand FC3 yeah, though I thought it was considered feature complete. The Eagle radar range was treated as a bug if I remember because it was so far off. I didn't think the missing features would be treated the same, but if they were it would be a nice FC3 upgrade. Though of course a FF F-15 would still be the best outcome.

Interesting improvements. As great as a DC will be, I'm hoping to also use some of the new features for traditional mission making.

Easiest way to do this would probably be to modify the plane jump feature. It used to be that planes jumped out of could be ordered to do tasks, which was helpful for many things beyond refueling. Now they just RTB. This should be fixed so that the planes stay around when jumped out of. A workaround for now is to setup an AI flight for the specific purpose of jumping into. You can fly the same route as this flight, give it a task to refuel, and then jump in when refueling is done. The downside is it's hard to setup unplanned refueling and it won't work in MP.

Part of the Eagle allure is the systems. FC3 after many years finally gave the Eagle its proper radar range, but it is still missing tons of capability. You also can't even change the MFD page. The FC3 Eagle is not a bad module, but it's painfully evident that it's not FF and you cannot escape that fact any time you fly the other teen series fighters. Cannibalization shouldn't be a problem either, the F-16 and F-18 probably couldn't coexist if that were the case. If that was the case one could ask why even make the E in the first place. Just add bombs to the C. FF is a selling point for DCS. Not for every single player, but enough that FC3 is for now at least considered the end of the line. I've enjoyed the FC3 Eagle, and for many years it was my staple aircraft, but it's extremely hard to go back to after the Hornet and Viper. I can't speak for others, but I don't think the F-15 would struggle to find a presence in offline DCS. MP wouldn't be the sole driving force behind buying it. As for the Eagle being the top selling module ever, I don't know, there is some stiff competition, but I find it really hard to see how it's at a disadvantage in terms of desirability. DCS is FF at this point. If someone isn't in to that, then it's probably not a series for them. The forums are a niche, yes, though that doesn't necessarily mean all opinions found here are niche. Perhaps counter intuitively, DCS has drawn from more casual crowds precisely because it's hardcore. You will always have people that prefer FC3, which is fine, but if those were the people DCS relied on, FC3 would likely be the norm and not an exception.

The limits used to be larger on the Crimea map. It was amazing. Then they reduced the limits. Terrible for placing units on the edge of the map, inconvenient when zooming out, difficulty simulating units flying out of bases on the borders. I've asked for this to be reversed years ago, and to be expanded on all maps. Very much needed.

It doesn't end very well for the downward ejection seats... But a workaround exists, use the remove scenery in zone trigger to get rid of the boxes:

@Flappie @Rolds While the fuel transferred seem right, the issue persists. It is a bingo fuel issue. If the S-3 is too far from an airbase, it holds too much for bingo: Here the Tomcat is forced to abort because the S-3 suddenly ends refuel task. It's because I moved everything out here: S3Fuel2.trk EDIT - I went back and added a carrier under the S-3's route and this seemed to fix the issue, unlike in the original case. So maybe it is actually working as intended. EDIT 2 - I converted the original track to a mission and added a fuel script, turned on RTB bingo and it looks like the S-3 gave as much as it could, so I guess it's fixed now.

It seems to make sense with my testing: S3Fuel.trk

First off, wingmen aren't in the greatest state in DCS right now, so be ready for the occasional quirk. If using realistic radio, you do need to use the correct frequency and radio to communicate with your flight. Ideally this should be one of the preset channels on your radio. The blue target lines appear when the AI attacks, you don't need to do anything special to see them.

Weapons do spin in DCS. Rockets are the most noticeable. Missiles will spin to the correct alignment when dropped (120 or Sparrow fired from F-15 semi conformal stations). Rifles induce spin because their projectiles don't have fins. Most aircraft weapons do have fins for stability and don't need nor want to spin.

Well for that we could just have the CATM's and other training weapons fire simulated rounds, maybe with a toggle option for visibility, and a training only option for the BDA. That's probably the only think I'd use the BDA for as it's a real immersion breaker in actual missions.

There could be multiple aircraft on a channel. That doesn't matter to the radio, but announcing who you're talking to can matter. Also, beyond selecting the recipient, you may need to choose dialogue options anyway.

You probably still have Late Activation ticked. You don't want both. Only use Uncontrolled and the aircraft will be visible.

This is a good suggestion and one that has been asked for over the years. Adding a direct respawn mechanism is probably the simplest way to achieve it, and that alone would be very useful, but the concept can also go deeper. Previously I suggested the idea of adding controllers to airbases that would manage aircraft at these bases and send them out on missions or to defend the base/other areas: This would allow the scheduling of CAP, Escort, etc but also have the advantage of tying that to real limited resources. The same might be possible with a spawner, it could have an option for limited number of spawns, be tied into the warehouse system, or be controlled via scripting or triggers.

Thanks for taking a look, but the code seems to work the same with both formats for that variable. Further testing shows it is a bizarre AI issue. For some reason the AI refuses to attack in this particular setup: The code works, without any changes, in another mission where the red plane is in a different location. It also works in this mission if I move the red plane. This would all make sense if it was an issue with the AI being able to detect the other plane, but it's not. I added an AWACS and a player controlled fighter. I can see the enemy on the DL. The AI can't see what is on its left. EDIT I've looked deeper and it is actually even more strange, but at least now I think there is a solution. @toutenglisseis correct. However my incorrect code somehow only fails to work when the target is on the left. I guess what's happening is coincidence based on how the Vec2 variables are being handled. EDIT 2 The broken Vec2 positions made the zone default to Bullseye. By nothing but chance, this put the target out of the zone on the left, but not on the right. Problem solved. For reference, here is the correct code for anyone wishing to use it: local zr = 30 -- zoneRadius input nmi local sdzone = trigger.misc.getZone('TZB1') --Trigger Zone Blue 1 local sdposV3 = sdzone.point --Vec3 local sdposV2 = { --convert Vec3 to Vec2, Vec3 = {x (N/S), y (alt), Z (E/W) | LAlt + Y to show Vec2/3 in infobar live x = sdposV3.x, y = sdposV3.z } local _f0 = Group.getByName("B") --Get aircraft group local _f0c = Group.getByName("B"):getController() --Get group controller local AAsd = { id = "EngageTargetsInZone", params = { point = sdposV2, zoneRadius = zr*1852, targetTypes = {"Fighters", "Multirole Fighters", "Interceptors"}, priority = 1, }, } _f0c:pushTask(AAsd) -- trigger.action.outText('X: ' ..sdposV2.x .. ' Z:' ..sdposV2.y, 60, true) -- Confirm Vec2 positions

It is beginning to feel like STEIZ doesn't work at all, but that doesn't seem remotely right unless it's bugged in the current DCS version? I added the task to a CAP flight and it still won't work. Essentially the code for STE, not using a zone, works fine. If anyone has done this before some guidance would be really helpful.

What is it that is taking you the most time? FF shouldn't really take any more time commitment than FC beyond maybe the learning stage. Start up can be automated or skipped. You can jump into the action anytime with proper mission design, or taking control through an accelerated track. If time is the real obstacle, then I think you can get around it even without a simplified mode.