nomdeplume

I really wish DCS helicopters would offer the method of the Dreamfoil 407 in X-Plane: while you hold the trimmer button down it ignores the physical joystick movement, and releasing the trim button updates the centre/neutral position. So you just fly around as much as you like and when you want to relax hold the button, return to neutral, release. Even if you change your mind while re-centering you just release the button and control from the new position. Never accidental inputs because you were too slow or unexpectedly ignored inputs because it's only ignoring it when you're telling it to. You could maybe invert this as well - i.e. ignore the movement and re-set the neutral position unless the trimmer button is being held. Might make it a bit more natural for actual pilots that way, at least for the helos where you naturally depress the trimmer button whenever you're holding the cyclic.

Fixed how? It worked fine for me when I tried it the other day.

The group waypoint actions are run when the group reaches the waypoint. They do need continuously evaluate them. Therefore, the ROE will depend on which flag is set when the mission is started. You need to add the ROE as a 'triggered action' on the group (3rd tab in the group properties). Then from the trigger, in the actions add a AI TASK PUSH action and select the appropriate triggered action to change the group's ROE.

Not impossible, but requires the use of extra triggers and flags to guard the 'not-selected' activation. Also it depends exactly what your goal is - to only activate one of the groups ever, or if you want to activate them all but one at a time in a random order, etc. Sedlo's method is good for "just one of these groups" - the key here is setting a flag to a random value to select the group, but only doing it once. Then the additional triggers are never executed because the flag can't be set to the value they're looking for. I do prefer to use lua though as this method is inefficient - if you want to select 1 of 4 groups, then three of the triggers will never do anything but will be considered every second regardless. I usually use random groups to give me different layouts of the 'same' threat (e.g. an area is guarded by 2 AAA, so make 5 groups of 2 AAA at different locations around the area and select one of them at random to actually use). If you have a lot of these then it's a heap of triggers continuously being evaluated without any chance of executing. In your case, you could just change your "unit in zone -> set flag 2" trigger to "unit in zone -> set flag 2 to random value (1,4)" and then for each of your groups, modify the condition to be "flag equals value" instead of just "flag is true". The 'RANDOM' trigger is mostly useful for ON MISSION START triggers, since if it returns false then the trigger's actions won't be run. For other trigger types it's more of a random delay function, e.g. a ONCE trigger with a RANDOM 1% condition is almost certain to eventually trigger, and very likely within 100 seconds of its other conditions being satisfied. Even a trigger with 10x RANDOM 1% chance conditions will eventually execute, if the mission runs long enough.

+1 to this. Needs a method to more readily select the target you want. Some ideas: format the list of targets as a grid, to show their locations relative to each other (left/right and closer/further). Would need a control scheme adjustment though and might take up a lot of space, which might especially bad for VR users. present the current list, but also show a small graphical display of the targets (perhaps with targets as simple dots or as icons representing target class). Selecting a target in the list would highlight it in the display. highlight the target in the 'real world' so you can just look outside as you scroll the list to select the correct target. align each target name in the list to the left, centre or right of the listbox based on their relation to the centre of the scan area. This could be a way of providing "low-resolution" spatial information within the existing framework (just need to add some padding to the target names).

+1 should be a user preference, not set in the mission editor per-aircraft.

In DCS sure, but that's because DCS makes choppers hard to detect for 'balance' reasons. Realistically the rotor prevents the helicopter from notching the radar, as it's spinning super fast and is not particularly stealthy (in terms of radar return). It probably requires special processing, so maybe older radars would just see it as a pulsing signal they couldn't do anything with, but I would assume any modern-ish fighter radar would be perfectly capable of tracking helicopters even if they're sitting motionless on the ground (so long as the rotor is spinning).

Would be worth noting the visibility conditions (particular time of day, but maybe weather plays a part as well?) as this still needs tuning. Usually if I set a mission right after dawn Petrovich won't be able to see anything even though they're perfectly visible to me, but set it an hour or two later and he's fine.

I think probably impossible since I don't believe you can give ground units specific targets. You could invert it and make anyone approaching via the safe lanes execute the 'invisible -> true' command to make them invisible to the AI (and then 'invisible -> false' when they leave the safe lane). If there might be combat with AI occurring in the safe lanes then that's not going to be an option since it will prevent any AI from engaging them, not just the specific Patriot launcher.

It's not by any chance same problem as this thread, i.e. button is also mapped in the UI layer?

I think the graph is just misleading when Inverted - so yes that's probably a bug. Though the bug might be our brains trying to properly comprehend what "inverted" really means. It looks to me like you can do what you want using the Deadzone setting rather than Saturation X. At least I got it to ignore the top 50% of the travel range of my throttle with these settings: deadzone 50%, sat x + y 100%, no curve, slider enabled, invert enabled.

Normally this is due to the playable aircraft having their start time changed in the mission editor, so they aren't activate when the mission starts. If you want to change the time the mission starts, you need to use the weather panel. Changing the start time of groups just prevents them from being spawned into the game world until that time.

If you set the group's task to 'Ground Attack' then you can add a waypoint action 'Perform task -> Bombing' which allows you to set the weapon type (rockets), release quantity (All) and enable the 'Group attack' option to have all units in the group carry out the attack. You do need to permit a bit of space for them to organise the attack and for a rocket run they'll probably ignore any height you specify and just do what they want.

It's a restriction, so 'restrict afterburner = on' will prevent the unit from using afterburner. Though I'm not sure it 100% prevents it in all cases, e.g. direct combat. You say 'vs' so I assume you're fighting the 29, and in that case I don't think there's anything you can do* to change their combat behaviour. DCS AI is notorious for being UFOs with impossible acceleration and climb capabilities, so your best bet is probably to just try different AI opponents until you find one that provides sufficient challenge in-game, and not worry too much about what 'should' be a well-matched opponent. * - you could probably find the data file that controls the AI MiG-29 thrust/speed etc. and tweak them to get something more reasonable.

Heh, I was expecting they flew into the ground but no, they crash into each other. The reason is because it's five completely separate planes performing the "same" maneuvers, but they gradually get futher out of sync with each other due to very small differences in how they do them, wind effects, etc. Since they're not trying to maintain formation or anything - the aerobatics tasks basically "take over" the AI and prevent it from doing anything else - they eventually collide with each other. The only way to fix it would be to tweak the initial position of each aircraft, or the parameters of the maneuvers until you get something that works okay. And once you do, future updates might well break it - even small changes to the AI flight model will change how the maneuvers occur, and in such close proximity it only takes small changes to result in a collision. I tried putting a group but only the lead does the acrobatics; and I tried having a separate aircraft group do a Follow task on the lead, but that ignores it as well. So I think for AI group aerobatics your only method is going to be trial and error - running it over and over, tweaking it each time to try to correct any drift. Even that might not be guaranteed to work, I'm not sure how deterministic the AI behaviour and flight modeling is. Another option could just be to move the aircraft a bit further apart so there's more room for errors, though of course that makes the display less cool.

I believe this is because the pathfinder is trying to generate a path between the two locations, which takes a while for such a long distance. One workaround would be to do it old-school style: have two separate groups with the one at the destination inactive at the start of the mission. "Pick up" the first group by deactivating it with triggers when the helicopter is on the ground, and "unload" the soldier by activating the other group once the helicopter has landed at the destination. This was the standard method for doing "troop transport" things before they added the embarking tasks (which of course now don't even work for the player...). Alternatively you could create a lua script to issue a move command to the unit after it arrives, so the pathfinder doesn't have to try to work over a long distance. I think transported units will get out whereever the transport takes them. I guess if you're really lucky and the scenario doesn't require the soldier to move after being dropped off, you could just not have that additional waypoint. Or possibly look at using CTLD? Not sure if it supports AI aircraft doing the transport, but it wouldn't surprise me if it did.

I think I understand the question, so if the player uses the "engage primary target" command (for example) it sets a specific flag, so you can know it's happened and then trigger other things in the mission. I don't think it can be done with the mission editor. It might be possible with lua scripting to check the current tasks on the wingman aircraft, and deduce that the player has issued a command to the wingman? I don't know how reliable that would be though.

Pretty sure this isn't possible for a standalone mission, as there isn't any state associated with a mission outside of the mission itself. Basically as @kontiuka said. You can use the goals system to set the "Results" score displayed on the debrief screen for players who actually pay attention to that, but mostly you'll just tell the player in-game that they've completed the objective.

You need to add the 'Start' command to the group as a triggered action. The triggered actions are below the group properties, where you set the waypoints and payload.

Only Easy Comms works for now. I think I also saw somewhere that Comm2 isn't working; but Easy Comms should tune Comm1 automatically for you. You also need to be in the correct position for 'ready pre-contact' to respond with 'cleared contact'. Can't remember if you get some other response if you're not in the right position or if it just ignores you. If the initial join request got a response so you're confident the radio is working, then maybe try getting a bit closer before reporting pre-contact.

Have you checked the control bindings to make sure the things are actually bound as expected? It might be worth comparing them to another module's bindings. I'm not actually sure about the external view thing, since I don't have button bindings for rotating the view. Didn't actually know they worked in external view! So, makes sense that could be overlooked by the developer, or maybe there's different bindings for external views.

No, Maverick missiles have either an optical or IR sensor; none of them have both, and the Viggen never used the IR versions. In US usage the AGM-65D, F and G use the IR seeker. The RB-75 is an AGM-65A, and the RB-75T I believe uses the same seeker but has a heavier payload. The RB-75B in-game is an AGM-65B and never actually used by Sweden; it's essentially the same as the AGM-65A but with an optical zoom. There's also the E variant which uses a laser spot seeker for guidance. From when I first read through the manual I thought the A0/A1 switch was supposed to change the colour of the symbology the Maverick overlay; but re-reading it perhaps it's actually used to modify how the seeker algorithm detects a target, i.e. whether it looks for a dark area on a light background or a light area on a dark background. I expect this would have no effect in DCS.

Is the waypoint correctly set as a target waypoint, i.e. does it show as Mn when selected? If it's a navigation point then taking a fix will update the aircraft own-position.

You'll probably also need to make sure the mission has at least one 'game master' or 'tactical commander' or similar slot, depending on how much control you want the Combined Arms player to have. And also I think you need to make sure "player can drive" is enabled for the units you want the CA player to be able to directly control. Otherwise I think you just have tactical control of them (i.e. can use the F10 map to order them around). "Player can drive" is the default setting when placing units, however.

Yes, but keep in mind the first post in this thread (for the DCS Gazelle module specifically): Your TRIM will keep the current angle of the Gazelle itself, not the cyclic one. So it is not acting quite like a normal magnetic brake trimmer would, and does in other DCS helicopters. Well, I don't know either, but if it didn't move the centre position it would IMHO be extremely bizarre behaviour.