Exorcet

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.

It's code that needs to me maintained. That combined with limited use is probably why it was removed. ED has a planned MAC product that is aimed at providing a less complex DCS experience, but it has long missed its original target date.

It was a little unclear to me, but I did see option mentioned in the post. Still I wanted to point out the potential issue just so it was considered. As an option, this is fine.

Double click can very easily unintentionally make switches hard to use. There are quite a few that I click through in quick succession to reach a given position. Hold click is also used for some dials and knobs. This can't be mandatory or it will interfere with these controls.

It very much would be needed even in that case. Smart AI still needs context. No matter how good the AI is, it won't know the difference between a training mission and a emergency interception unless the player tells the AI what is what. Floors are needed for common training scenarios, and would also be very helpful in setting up the AI for different types of missions. Other limitations may be desired for specific maneuvers like tankers, transports, or fighters doing a show of force. Better AI would mean less tinkering would be required, but you'll never be able to get rid of all of it.

The AI won't like trying to land at a FARP. There is a rearm/refuel waypoint option, I don't remember if it works with wingmen, but it will require a proper airport. If refuel/rearm doesn't work you can create multiple AI flights and just take control of them with the jump function (R Alt + J) to swap planes.

Update the code seems to have correct Syntax now, but the AI will not engage, even with the enemy in proximity, the radius massively increased, and AWACS and EWR support available: 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) > check this | LAlt + Y to show Vec2/3 in infobar live sdposV3.x, 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 = 185200, -- 185200 = 100 nmi, 92600 = 50 nmi, 37040 = 20 nmi, 27780 = 15 nmi, 14816 = 8 nmi targetTypes = {"Fighters", "Multirole Fighters", "Interceptors"}, priority = 1, }, } _f0c:pushTask(AAsd) trigger.action.outText('X: ' ..sdposV2[1] .. ' Z:' ..sdposV2[2], 60, true) -- Confirm Vec2 array handled correctly

I'm trying to bypass ME limitations and give ground attack planes STEIZ tasks for self defense. The annoying part is finding the position for the task. I thought it would simplify things to use a trigger zone in the mission to mark the position, but I'm not having success writing a script. I do get an error message running it in game, but the message is blank. Concept summary: -Place trigger zone in mission -Run script that: -Finds position of trigger zone -Translates position from Vec3 to Vec2 -Uses Vec2 position to define STEIZ task Code: local sdzone = trigger.misc.getZone('TZB1') --Trigger Zone Blue 1 local sdposV3 = sdzone.getPoint() --Vec3 local sdposV2 = { --convert Vec3 to Vec2, Vec3 = {x (N/S), y (alt), Z (E/W) > check this | LAlt + Y to show Vec2/3 in infobar live sdposV3.x, sdposV3.z } local _f0 = Group.getByName("B") --Get aircraft group local _f0c = Group.getByName("B"):getController() --Get group controller local AAsd = { id = "SDinZ1", params = { point = sdposV2, zoneRadius = 37040, -- 185200 = 100 nmi, 92600 = 50 nmi, 37040 = 20 nmi, 27780 = 15 nmi, 14816 = 8 nmi targetTypes = {"Fighters", "Multirole Fighters", "Interceptors"}, priority = 1, }, } _f0c:pushTask(AAsd) There may be a stupid mistake somewhere, but I'm just not seeing it.

Ground units have a setup/deploy time. Turn on time acceleration and take note of when they start to shoot. I know for SCUDs it's on the order of 10 minutes.

A video is better than nothing, but a track file is the most useful for debugging issues.