twistking

+1

Yes, i guess you could call it smarter self defense; If you put higher values for engage distance, it would function more as a type of CAP though, that's why my suggestion called for a CAP task, but of course it would functionally equally well as a new ROE option. I think your suggestion of an modified search than engage task (that lets you define which part of the flightpath counts for the task) would solve the same general problem... only coming at it from a slightly different direction... I don't think that "maximum distance from waypoint" would be a good trigger to stop pursuit though. First of all it would need to be "max distance from flightpath", but that might break if flight is not actually travelling along its path, because of other scripts or task (switch waypoint, racetrack orbit, falling back towards path after any location based push task). I think it should be something relative to leader's current position. I think a smaller distance setting for cold bandits with some seconds of timeout would solve that actually... don't you think?

Thanks for the answer. I have found a workaround for now: Basically checking if player unit is still alive and if in certain conditions and then with timers for delay just concluding (guessing) that enemies must be dead (or retreated). Simple and good enough for what i need. Your post make me a bit more interested in getting to start with LUA. Do you know a simple tutorial that simply recreates some triggers from the "trigger block". Basically just like "if condition x, then make AI do y and set flag a to b"? Also is there a database with scripting commands? I'm relatively used to scripting for ARMA and for that there is a very nice offical glossary with every command, explanation and even user commands/examples. Anything even remotely similar for DCS? Thanks.

I can agree with most of what you say, but i think even mentioning gunship operations is a bit of a stretch: The only similarity is with the airframe. A gunship would surely be an easier sell to a broader audience (not saying that a transport won't sell - it's just a bit more niche, i'd guess). I would also argue that cargo helicopters are more engaging for "average" combat sim flying, because the flight profile is more engaging. It's easier to come up with missions that throw a chinook pilot in crazy and daring raids... If you want to keep it somewhat realistic, a C-130's mission profile will always be less "daring" -whatever you wanna call it- than a transport heli's could potentially be. Not trying to argue against fixed wing transports in DCS in case you wonder: I'd welcome a vintage transport plane. I just wanted to also make clear that i'm (personally) not completely sold on them... Just in case devs actually use these threads to gauge user interest.

A very small item, that would help a lot with mission creation: A "search and engage" task for CAP (but maybe also other tasking types) that is valid for a moving zone of definable size on the the group leader (alternatively for multiple zones of definable size with one for each group member). In practice this would mean that CAP would only search and engage targets near to the CAP flights position. A similar behaviour could be archieved by adding a new ROE option ("defend aggresively") where the group is only "weapons free" for targets within a certain range. The result would be the same, but i think it's more elegant to have this as a continuous Task type. In practice you would often want to combine this new task with f.e. a "search and engage in zone", but you could make the zone much smaller, since the flight would still be somewhat aggresive while cruising to it's CAP area. There is the obvious problem that a CAP zone moving with the group would mean that the CAP flight will never disengage unless the bandit group is fast enough to build distance quickly. This is not terrible, but ideally there was another parameter to control disengage criteria: This would need some creative thinking: Maybe the engagement radius for "cold" bandits could be set manually. If set very small, the CAP flight would be quicker in disengaging from bandits turning cold and not pursue them endlessly as would be otherwise. Again: The goal would be to have the AI in a defensive, but still somewhat aggresive stance (without going full berserk, as they would do with ROE "open fire"). Thanks.

Fair enough. I forgot to mention that i look at it only from a SP/Coop perspective only as i have no interest in public PvP. I think your argument is more valid for those massive, public PvP scenarios, right? That said, the dynamic campaign - if it ever marterializes - will maybe give more merit to those otherwise more "mundane" transport related sorties even in Sp/Coop.

Those vintage super rugged transports are the only "heavies" i'd be somewhat interested in. I think there are a few other iconic aircraft that are similar... C-119 for example... Beautiful, interesting aircraft... and probably a joy to fly. The obvious issue is gameplay... not sure how much DCS can offer for those aircraft, that the civil flight sims can't...

maybe i missunderstood what you are doing, but if you want a task that allows for the JTAC to target different group, why not just use the normal "FAC" task? the difference between this and "FAC Assign Group" is precisely that the latter has the option to restrict to a certain group only. In any case, you only need one item. Athorwise both would be active and JTAC would target everyone in sight, making the "Assign group" irrelevant. If you want the JTAC to target some groups, but not other groups, the correct procedure is - i believe - to have multiple FAC Assign Group tasks, each with one group selected. Those task will "stack", so they will basically run at the same time, with the first in the list having highest priority.

... and remember that all aircraft of the flight need to catch up to lead, before the AI begins to climb properly. it's good practice to have a first waypoint at very moderate airspeed to allow flight members to catch up... on 4-ships flights you could even consider having a short orbit task at a first waypoint for the same reason...

Thanks for the answer. Will have a lok at it. I fear this will be a bit too complicated for me to pull off (not really good with lua, so i'm still using the ME script "blocks" exclusively), but maybe i will give it a try anyway!

oh... i somehow didn't realize you were doing a WWII mission, even though you clearly stated it. i think my post is still valid, however i want to add, that i also found the warbirds more finicky. i don't have a rule of thumb for warbirds unfortunately... the good news is, that it will work eventually, if you figure out the correct speed. maybe try with one or two intermediate waypoints and i would try with lower airspeed. 250 seems rather high. make one flight with 200 and another - just for science - with 150, run the mission and check AI behaviour, as well as power setting (in f2 view status bar for the unit you have RPM or some other metric for power output). I use this a lot to make sure AI is not struggling: you want it high, but also not stuck at 99 or 100%... in your case, i'd guess that airspeed is a bit too high, BUT AI can struggle in the same way, if airspeed is set too low. check AoA or RPM to see what might be the issue. good luck!

you have to set an appropriate airspeed. also the aircraft must be capable to actually reach 30k in it's set configuration. the editor prevents you to set super unrealistic values for altitude and airspeed, but you will still be able to set combination that the given aircraft struggles to match. setting the speed too low can be as problematic as setting it too high. also set enough distance for the climb and be aware that a flight of multiple aircraft wll only begin climbing when all aircraft are in formation, so you have to account for that...

tested some more without "at start" checkmark. still does not work reliably. really frustrating...

anyone?

Personally i also don't care for those UI sounds, because i'm not into highly curated or highly scripted scenarios, BUT i'm perpexled that those don't exist yet: Things like this seem very important for tutorials, where you want to guide players very tightly... could also be useful for more "gamey" scenarios or modular training scenarios that allow "meta" input to shape the scenario. Nothing that i do a lot, but nevertheless a good suggestion. Atmospheric "world" sounds and ways to place them in teh world as per OP's suggestion would also be a great addition. Especially different alarms, as mentioned already. Other sounds should be systemically driven though. It seems tedious to rig a scene with different sounds and set up triggers to fire them manually. Soundscape should react to what's happening dynamically. Only "standout" sounds should be rigged manually by the mission editor. Somehow related i would also like to see improvments in how the mission editor handles custom sounds, for example to delete unused sounds from the mission file in editor to prevent bloat: Last time i used custom sounds, the only way to delete them, was to rip apart the miz file manually.

I've made a wishlist entry. If you do care about DCS night ops, please visit the linked thread and give it 5 stars ("rate this topic" at the top right) to improve the chances of it getting the attention it deserves.

Is this about adding it as an AI only aircraft, or as a flyable module? Or maybe as Ai aircraft with the option of players operating the boom?

thanks for the reply. that's really sad. i think i will try once more without the "at start" checkmark. if this still gives random errors, i will just not use embarkment until it will be fixed eventually...

thanks for all the replies. i think my main problem was that i thought having the green lights was enough. i was still wobbling (within the margin) though. yesterday i managed to minimize the wobble, was patient enough for the boom to finally connect and got several thousands pounds of gas before disconnecting. disconnect was accidental still, but i think i'm slowly getting there nevertheless.

Hello, i have trouble getting infantry out of a ground transport. Sometimes no unit will disembark, someone only 1 single unit will disembark; only once did i manage to get the whole group disembarked. Every time i followed the same steps, so i don't know if my procedure is wrong, or if this is still super buggy. My process: Place infantry group and another group with only a truck. Give infantry group embark order and give a second waypoint where they should go after disembarkemt. Give truck an order for embarkment, make checkpoint "at start" (so that group will start already embarked), select infantry group from the list and "add" them to cargo. Notice that cargo now has "6/30" to verify that all infantry are accounted for. Give truck a move waypoint and a disembark order. On disembark select infantry group and verify that cargo now shows "0/30" within the disembar screen. In mission verify that infantry group is not visible on the map to verify they must be "embarked". Watch mission play out and notice that in most cases noone or only one of six infantry will disembark the truck. Did i do something wrong?

Yes, i totally agree. There still could be some smouldering fire or smoke on equipment that has neither fuel nor weapons on it, but no secondary explosions.

External aircraft lighting is still terrible. On all aircraft except Hornet ext lights are not visible after only a few hundred (!!!) feet, while Hornet's lights - while having better visibility distance - don't look realistic (but rather... ugly... depending on the distance). In fair weather lights should be visible for at least 25 miles. Strobes should be seen way further even. Also Nav lights should be somewhat distinguishable (red/green) at "reasonable" distances. If you use the search function, there are a ton of similar requests going back to the beginning of time and light itself. Please ED, finally tackle this longstanding shortcoming. It's not rocket science! Ps: Please also add AI option for ext. light usage in ME! Thanks, you are great!

I think what you describe is an alignment issue. If you do a normal alignment and forget to confirm the positional data on the DED, you can get that. Please quickly describe how you do your alignment, as normal alignment has changed a bit and that might not yet been reflected in the manual. Or try again with a stored heading alignment, as this is more straight forward (and faster).

I thought that at this point it was "common knowledge" that trees in caucassus are too big. Even if you'd argue that it was theoretically possible for trees of the given kind to grow this tall, you are talking extremes and not common sizes. Also the actual tree models do actually represent smaller specimen, that are just scaled up: The proportions are that of small or medium trees, not those of 200 year old giants. A simple way to spot it, is to place a tank besides one of those road-side trees and have a look with F7. It's very obviously wrong. You don't need to be an arborist to spot it. I think from high up it looks good enough though. It's probably done for performance. It's still a reasonable wish for ED to take another look at it and maybe tune it a little to make it a bit less obvious. I could also imagine that it would help a bit with sense of speed, even though the lack of finer ground detail in caucassus map is probably the bigger culprit here.