nomdeplume

Well in that case, I suppose ED could just declare that they, like every other developer/publisher who has tried it in the past, are dropping the notion of an integrated high-fidelity virtual battlefield, because supporting a game for 10+ years off of the back of a one-off payment of $60 per copy is not viable. Would that make you happy? If so, why? It's not as if you're forced to buy the upgrade. If you're happy with a game being released, patched a bit while it was current, and then receiving no further updates (like, say, every other simulator that's ever been released) - you already have that, and nobody's taking it from you. The products are separate, so you can have both BS1 and BS2 installed. If you want to fly with FC2 mates, you can run BS1. Just means you miss out on the new features and goodies, but you're no worse off. Software development is hard. :)

The command works exactly as it's supposed to, and is very useful for achieving its purpose - to set the value of a flag to a random number between the minimum and maximum you specify. Using the RANDOM condition to set one out of a set of flags to true is the 'traditional' way of achieving your goal - because the 'flag set random' action is a recent addition. If you're wanting to create a situation where exactly one of three (or however many) potential outcomes is randomly selected, then I think 'flag set random' is actually the easiest way of doing it. For just three items, setting individual flags isn't too bad, but it's a very complicated method to try to scale up to add more variations. Using the random value method instead just requires the addition of an extra trigger, with the exact same conditions as the others (just different values to test for), so it's simple to use.

Flags can be boolean (true/false) or integers (counting numbers, positive and negative). FLAG SET RANDOM sets the specified flag to a random value between the minimum and maximum values you specified (inclusive). So what you're doing is setting flag 10 to a value of either 9, 10, or 11. The boolean logic (flag is true/flag is false) will treat a flag value which isn't zero (or which hasn't been explicitly set) as 'false', anything else as 'true'. So in your case, flag 10 is the only one that's been set to a value, and that value is evaluated as 'true' by the boolean logic. For your logic you either want to have three separate triggers like: condition: RANDOM 50% -> action: set flag 9 condition: RANDOM 50% -> action: set flag 10 condition: RANDOM 50% -> action: set flag 11 However in this basic form, you may end up with any combination of those three flags (all true, all false, one true and two false, or two true and one false). You could also use FLAG SET RANDOM to set flag 10 to e.g. 1, 2 or 3. And then use separate triggers to check the value of flag 10. At present you need to use a pair of "flag less than" and "flag more than" in lieu of "flag is equal to", but that condition is [probably] coming in the next patch.

The boxed version has been available in many places around the world since June...

All the artillery will only fire a burst of ammo and then sit quiet for some time until they reload. You can't really influence the reload rate (maybe skill level has something to do with it?). If you need to have continuous fire you'd need to set up separate groups and give them individual targeting so they start firing at different times. Also bear in mind the mortar runs through its ammo pretty quickly and will likely have finished (or be nearly finished) firing by the time the first rounds start to land. You don't need anything to support them, although I usually add some kind of transport truck and some infantry so it in order to explain how it got there and how it was firing. Also you can put the infantry in a different group and have them run away if you want to add a bit of excitement to the proceedings. From the brief research I did these mortars are usually served by 3 soldiers per mortar.

Did you happen to use the 'prepare mission' option from the mission editor menu at any point? If so, this will save the DSMS configuration (as well as lots of other stuff) and those settings will be automatically loaded when the mission is run. If you later change the loadout then the DSMS configuration will be mismatched to your actual weapons load.

The custom radio options (via the F10 radio menu) don't transmit on any particular frequency. Ground forces also don't report anything on the radio at all (with the exception of JTAC), so unless a ground force is providing JTAC for you there's no reason to list their frequency. I like giving AWACS the callsign Magic, because I'm incredibly immature. :D

Just to confirm, you were testing with something after 1.1.0.9? So we can take this as confirmation the issue is fixed, or at least changed somehow? :)

If they took the same amount of effort to implement then you'd have a point... And these are functions I don't use/care about anyway, so it's a bit of a strange argument to make to me. Kind of like, "ED wasted time implementing these useless features, so surely that justifies wasting more time implementing more useless features"? I'm not saying the features are completely useless. They're nice. But I didn't miss them when they were absent. I get that ED's priorities aren't my priorities, and I don't expect them to be. If they decide to add some version of the Sniper pod then I won't complain. There's just many other aspects that would add to my enjoyment much more than a different looking pod. Sure but there's an endless list of minor things that aren't modeled. We can't have everything, and if we get to choose what not to have, then I'd choose not having duplicates of existing functions unless they actually provide materially different abilities/options. Well, yes. Training weapons provide an additional ability, i.e. the option of dropping inert weapons. Personally I'd like to see more time spent on training rounds, like having the ability to determine where they landed and decide if that was a 'hit' or a 'miss'. Even further than that, dry firing would be nice to have since that's something real pilots do a lot of. I don't know anywhere enough about this to determine how it's used and how it could be simulated, but every book I've read has included mention of it. Combined with the Nevada terrain that would provide a fabulously immersive training experience and a real clear line between "training" missions and "real" missions - given this is a sim and nothing is actually real. :) It would also help to relieve the cognitive dissonance I'm fairly sure I'll suffer when performing "training" missions in Nevada with live ammunition against maneuvering targets that fire back... especially air-to-air scenarios (which I'm presuming will be a feature of the next module). In contrast, the Sniper pod wouldn't provide any additional abilities/features/functionality beyond what's already present, but it would take resources that could be used on other things - be it more work on DCS Warthog or getting the next module finished 6 hours sooner. Both would, IMO, be more valuable to me as a customer than another targeting pod that provides the same functionality as the existing one. If there's actually a functional reason to take one pod over the other in the sim, then that'd be a different matter. But I think they're probably restricted in terms of what technology/capabilities they're able to present, so another pod would be functionally the same as the existing one. That's a pretty big assumption to base my opinion on, but I haven't seen anything contradicting it so far.

But by the same token, the cost-benefit analysis wouldn't really stack up. It'd take some doing to implement the other pod and how many more sales would it yield? I'd estimate close to zero. Although I don't have any data to back it up, I'm pretty confident the number of people who chose not to buy Warthog because it only modeled the Litening II pod and not the Sniper pod could be counted on ones' fingers. If you're using the "but it's their job!" argument, then they're going to expect to be paid for it, therefore there needs to be a revenue prediction from spending that time. Nobody's going to run out and buy it because OMG Sniper pod! I also don't really see at as being something that's 'missing'. We have a targeting pod that's contemporary with the avionics and weapons that are modeled. A clone of the targeting pod with some inconsequential changes to the symbology and visual model isn't an interesting feature, IMO. I'd actually prefer TISL to be implemented, since it'd only be a borderline useless addition instead of a completely useless addition. :)

I don't think this would be the case, as you'd need to be supplying pitch-forward input to cause that to occur. In my testing, I was in a shallow dive and definitely not pitching further forward. I used the same technique when dropping longer sequences and they all rippled off completely fine. I'm very confident this isn't the case - I watched the weapon release button on the virtual stick and it stayed depressed the whole time. During a CCIP run unless you're carefully guiding the aircraft into the ground, the pipper should be moving across the terrain at a reasonable clip. In both mine and Doum76's tracks we kept the weapon release button down for several seconds. It definitely feels like the system is simply not proceeding to release any additional munitions.

Additionally even when it was an option, it was only as an option to also install the 32-bit binaries when installing on a 64-bit platform. So on a 32-bit platform it would always install the 32-bit version. On a 64-bit platform, it would always install the 64-bit version, with an option to also install the 32-bit binaries.

You need to put the units in the same group. Each unit in a [ground vehicle] group can be a different type. When you save the template the selected group's composition and relative position is saved in the template so they can be easily re-used in a different mission. That's the purpose of templates. For air defences, it's especially important to have all members of the same battery in the same group. This is because target information isn't transmitted between different groups. So if you have your launchers in one group and your radars in a different group, the launchers will never engage the enemy because the radars cannot tell the launchers what to target.

This was due to the introduction of some left rudder input. After your 'rude manuevers' it was reset to 0. Maybe dodgy twist axis or something? You can use RCtrl+Enter in-game to display a dialog showing your input state. I've attached screenshots during the erratic period and just after - the rudder input is indicated by the vertical tick on the horizontal line along the bottom. I don't know why your bombs stop releasing, though. You're outside of the minimum range bracket, and that's just an indicator anyway - you can still release if you have those indications. Edit: I think this might be a bug with the weapon releases (or I could just be confused :)). I can reproduce it fairly easily with the same kind of loadout (slightly different though). First two bombs ripple fine, but the second two don't ripple - you get a single release instead. Then the same thing happens on the third try. Once you're down to one bomb on each pylon, they ripple correctly again. Will do some more testing and upload a track shortly. More: Simplest reproduction is attached in a very short track. Loadout is 3xMk82s on TERs on stations 4 and 8. According to my beliefs and the chart the wonderful paulrkiii posted (see this post), I would've expected a ripple sequence of 2 bombs would drop one bomb from each of stations 8 and 4 on each pickle. What instead happens is this: Pickle 1: two bombs dropped from station 8. Pickle 2: one bomb dropped from station 4, 'release aborted' message. Pickle 3: one bomb dropped from station 4, 'release aborted' message. Pickle 4: one bomb dropped from each station. Only the last one matched my expectations. Is this expected behaviour for some obscure reason? Last edit: it seems like only the inner stations (5+7) follow the sequence depicted in that diagram. Stations 3+9 exhibit the same behaviour as 8+4. I also tried with longer ripples (4 bombs), and it dropped 3 from station 8, and then one from station 4. So I think it selects the first station to drop from based on the TER diagram, but refuses to continue a ripple started from a lower-priority station on a higher-priority station (so if you start a ripple from station 4 and the next one it should release from is station 8, it'll just stop releasing weapons). It also seems like it only advances to a different station if the first selected station is empty. So, rippling all your bombs works fine, even if they do come off in wrong order. Mk82Ripple.trk

Create your group as usual. Once your happy with its composition and orientation, click on the Templates button while your group is still selected. In the Templates panel you'll see a heading "Create new template", and under that it will have the name of the group you have selected. Type in a name under there in the "Template name" field (e.g. 'SA-11 Battery'), and press the Save Template button. Now that it's saved, if you want to recreate that group in another mission (or in the same mission), click on the Templates button in the toolbar, and then in the top section of the templates panel select the country for the group, choose the name of the template from the dropdown (e.g. 'SA-11 Battery'), and then click on the map to place the group. It takes a moment for the editor to generate the new group so be sure to only click once and have some patience.

A track would be better as it makes it much easier to look at how the DSMS is configured, and be able to take control to try it ourselves. The only times I've experienced 'release aborted' is when using CCRP or CCIP-CR mode and releasing the pickle button prior to actually getting the release cue. But you don't seem to be using CR mode so the bombs should be releasing as soon as you start holding the button down. But, I can't work out what's happening from the video. If you can post a track where the problem occurs as early as possible that'd be very useful - ideally a mission where you start airborne close to the target area.

You'd have to test. My hunch is it won't, since the game isn't actually rendering an image and then scanning it for sufficient contrast in order to decide if it's locked or not. It'd just be doing something along the lines of "they're using force correlate, so lock it onto that spot on the ground" or what have you. When you lock onto a vehicle in the normal method, the sim knows you've locked that particular game world object, and therefore can guide the maverick to it if it moves. At least, that's my understanding.

Bumpity bump! Any testers want to comment? I'll even attach a sample mission to make it easy. :) Has two F-15Es attack some Russian armor in a tactically sound defensive position, followed by two F-16Cs. The F-16's also have the gun mounted in the wing root, but their tracers come from the appropriate location on the model instead out of the radar. F15Eguns.miz

It speaks what it can. US, UK, France, Spain I think all have voice files, possibly some others. Germany does too but aren't currently played due to an error in the configuration. Russia has voice as well but they may not have Nato phrases like the callsigns. The AI flight text messages are all assembled from known words though, even if they're not actually played. I suspect the callsigns may be a deeper thing that just aesthetics, although possibly it's not and may just be how it was designed.

Already exists - that's how the original Nevada terrain was started. There's also allegedly some groups working on Aghanistan type terrain. It's just a difficult and time-consuming task. http://en.wiki.eagle.ru/wiki/All_about_land

Yes, 'Mk 1 eyeball' is a common expression referring to using your eyes - the original and (often) best sensor. Zooming is generally not considered cheating because a) your monitor has a limited resolution and size which can't simulate the capabilities of actual human vision and b) many pilots actually use binoculars to get a closer look at stuff. Also, it's not a magic elixer of detection - the more you zoom the narrower your field of view, so you sacrifice general situational awareness in order to get a better look at a specific area.

Not all countries have voice recordings. What nation are the Ka-50s from? May be same issue, but also AI flights don't interact with ATC at all, anyway. The most you'll get is an "airborne". Not sure if helicopters report when they're airborne though. Might only be fixed-wing. AWACS and tankers have two callsigns; the one you set in the mission editor is what the 'backend' of the flight will be known as. They also have a 'frontend' callsign which is always Enfield at present. So for an AWACS, the guys you talk to use the backend callsign (e.g. Overlord or whatever), while the pilots talk to ATC etc. using their flight's callsign (which is always Enfield in sim at present, and of course - AI flights don't actually interact with ATC).

LHX Attack Chopper had an Osprey as one of the aircraft you could fly.

I'm not sure, I think it should record the kills. The mission score is another matter. Did you definitely exit the sim cleanly, i.e. it didn't crash? Whether you progress in the campaign is determined by your mission score (which I think is shown as 'results' on the debrief screen?) - this is separate to the points awarded for destroying hostiles (which are essentially meaningless in singleplayer, and only marginally meaningful in multiplayer). Some missions may require you to RTB and land before they give you a 'passing' score. Others may require you only to complete your objective, or you might need to complete the objective and egress from a certain location. It's really up to the mission designer; I don't know what the campaigns require. Also it's possible to remove your score from the mission, so even if you've got a passing grade, if you then get killed it might take points away so you fail the mission. Note that for scoring purposes, I'm pretty sure there's no difference between ejecting and going down with the plane. However the latter will be recorded as a death in your logbook, and if your pilot isn't set as immortal then you won't be able to fly more missions as that pilot.

It's a known issue though I don't know where or not it's going to be addressed in the next patch. Only workaround is to get a new plane, i.e. leave the slot and rejoin.