nomdeplume

There's a separate hover-hold button, which does activate the four AP channels but also utilises a doppler radar to try to detect movement away from the current position and correct for it. You'll get some different HUD symbology and there's an indicator on the left side of the overhead panel that lights up when hover-hold is engaged.

The first ones are CBU-103s, which are the WCMD version of the CBU-87. The new model is for the CBU-97 SFW (and the CBU-105, WCMD version thereof). Completely different weapon systems. The CBU-87's a 'conventional' cluster bomb. The overhead view of the -97's doesn't really show the skeets well at all.

What would constitute a 'valid' sequel, then? Improvements to the (already very good) flight model? Updates to the graphics to bring it closer to modern standards? A new campaign? A larger map? Additional units and factions? Improvements to the capabilities of the mission editor? An overhaul of the AI including dynamic radio chatter and lots of settings that the mission designer can use to tailor AI behaviour to their mission? All of the above? Something else?

Some people have suggested you might be able to just rename the data files, but I've got both the original 'patch' files and the updated 'upgrade' files (from the torrent) and they have different MD5 checksums; so I think it'd be safer to download the whole installation again. Also, the file sizes are a bit different as well. So the data files (.bin files) have definitely been updated with the new release of the upgrade installer.

Yes, but it's worth noting that when you engage hover hold all your autopilot channels will become enabled (well, unless the requirements aren't met, in which case they'll all be disabled :D). This includes altitude hold. While you can override the autopilot's altitude hold with sufficient collective input, life will be easier if you disable that channel and just maintain your altitude yourself. I think there's also an altitude hold lever on the collective which resets the altitude the AP wants to hold, but it's been a long long time since I've flown this so I'm pretty fuzzy on that one. Don't think I used it much. But yes, hover hold works nicely for pop-ups. I had some fun with a few Rolands last night, popping up from a hill, ducking back down if they shot at me, or sending a Vikhr their way if they didn't.

It's a graphics term; http://en.wikipedia.org/wiki/Normal_mapping

My understanding of Weta's idea is: 1. Set a flag (call it flag #1) to true whenever you want a new scenario to be started. 2. While flag #1 is true, set another flag (let's call it flag #2) to a random value representing the number of scenarios you have. Let's say there's 4. So flag #2 gets set to one of {1,2,3,4}. 3. Each of these scenarios has a corresponding trigger to start the scenario, whatever that entails (setting flags, activating groups, etc.). But they'll all follow the following basic form, where 'scenario flag' is a flag which indicates if that particular scenario is activated (let's call it flag #11 for scenario 1, #12 for scenario 2, etc.): CONDITIONS: FLAG #2 is equal to {scenario number} and FLAG #{scenario flag} is false ACTIONS: SET FLAG #{scenario flag} true CLEAR FLAG #1 (i.e. make it false) CLEAR FLAG #2 <anything else required to start up the scenario> Doing this ensures that a) only one scenario is active at a time and b) each scenario only gets run once. 4. Once the scenario ends, you just need to set flag #1 again and the trigger that sets flag #2 to a random value will activate again (it'd be a 'continuous' type of trigger). If it sets the value to a scenario that's already been used, then its scenario flag will be true and therefore it won't be able to trigger again. That means it'll keep setting flag #2 to a random value until it finally picks a scenario which hasn't been used yet. Technically you don't really need to track if the scenario has been used or not (since if the activation trigger is of the 'once' type, it will only be able to activate once). However you would want a way to track which scenarios have been used so you can notify the player once they're all exhausted. Or, you might want to count the number used so you only run a certain number of them in each playthrough. Anyway... hopefully that helps, or at least doesn't make things even more confusing.

You need to understand that the SET FLAG RANDOM function does not set one out of a bunch of numbered flags to true. It sets the value of one particular flag to a number. So 'set flag random' when given the parameter 'flag 1' and min '2' max '5' will result in FLAG 1 having a value somewhere between 2 and 5 (inclusive). It will not ever set flags 2, 3, 4 or 5. Calling them "flags" at this point is a bit incorrect - more of a holdover from when they really could only be true or false values. While you can treat them as true or false, they also now have the ability to store whole numbers/counting numbers/integer values. You can test for them with the "FLAG LESS THAN" and "FLAG MORE THAN" conditions, and in 1.1.1.0 when it's available, "FLAG EQUAL TO" and "FLAG LESS THAN FLAG" (to compare the values of two flags).

Yes, FUNC+8 on the UFC selects mark point mode. FUNC+7 sets you back to flight plan mode. Look at the labels underneath the buttons on the UFC to see what they do in FUNC mode. By 'FUNC+8' I mean, press the 'func' button on the UFC and then press the '8' button. You don't need to try to press them simultaneously. :)

Setting the ROE to 'hold fire' (or 'return fire') will do the trick - they won't engage anyone. Also you can delete the default tasking (so they have no tasks), or set their task as 'nothing', and they won't do anything since they haven't been told to. You can also use the 'set invisible' command to prevent AI units from noting the presence of the enemies. However I don't think you'll be able to do what you want, without a lot of messy scripting. And even then I doubt you could get it right, because a human player is never going to be flying at the exact altitude, airspeed and flightpath that you need them to be. The game simply doesn't have coordination between different groups. You could perhaps have some AI A-10's flying around and have the MiGs intercept and escort them. If the player's told to fly in formation with those guys then there's a reasonable chance they'll be close enough to witness the goings on. It'll also help with the narrative aspect, because a player can easily 'break' the mission by performing evasive maneuvers or what-have-you; but an AI flight will just do what it's told and the player will have to helplessly watch (assuming they have no weapons). Also - don't forget the 'set radar usage' option for AI flights - you can set it to 'never' while they're en route and then change it to 'continuous' to make sure they're picked up by the player's RWR at just the right time.

There's an option in the gameplay options screen which I think is called 'easy communications' or something to that effect. If you enable that, then your radio will auto-tune to whatever frequency it needs to be on in order to communicate with whoever you selected from the menu.

Just tested it and the FARPs do indeed show up in the airbases list, presumably sorted amongst the airbases in order of distance. Also noticed something strange - Senaki-Kolkhi airbase is listed as "callsign Kolkhi" - see screenshot. I think it should just be "Kolkhi".

Not sure if I read it specifically anywhere. It's just how it works in DCS A-10C and it seems the same in BS2.

Was this at a FARP or on an airfield? I've repaired a few times on an airfield without problem - after the repair is complete you're dropped onto the ground but only from a short height and the gear copes with it fine. Maybe the FARP physics are a bit different? If not a FARP, were you in any particular location when you did this?

I haven't tried with a FARP so I've no idea! Will try that when I get a chance. The list of airfields is sorted by range, i.e. the closest one is the one at the top of the list. So probably the FARP you're at will be at the top of the list?

Does this only happen in multiplayer or in single-player too? It might be helpful if you could post a track of your shutdown and restart procedure. That way if the procedure is correct, the friendly testers can add it to the bug database. Perhaps try a simple runway start mission (to get into a running aircraft quickly), and then shut the aircraft down, and then re-start it.

Unless they've changed things dramatically, you can't move 'forward' to a new mission in the same stage. If you only have one stage then when you finish that first mission successfully you should be winning the campaign. The following is based on my recollections of the campaign system, but it's been a long time since I've used it and things might have changed. I don't think they have, though. The way it works is if the mission ends with a score of exactly 50%, you remain on the current stage. A new mission is selected that's valid for a score of 50%. If your mission ends with a score less than 50%, you go to the previous stage (or lose the campaign if it was the first stage). If there was a previous stage, then a mission that's valid for the score from your previous mission is selected. If your mission ends with a score higher than 50%, you go to the next stage (or win the campaign, yada yada). So, to do what you'd want I think you'd want the first mission in stage 1, then both the other missions in stage 2 but with different score ranges available. So if you can end the first mission with a score of 51% then you'd make sure the appropriate ending was valid for that score. If you could also end with 100% score, then the ending for that one you'd constrain to only be valid if they score 100%. You need to cover the entire score range, so you might set your "not as good" ending to be 0 .. 80 and your "really good" ending to be 81 .. 100. Also if your ending missions end with a score of 50 the campaign system will reselect a mission from that second stage... Another way to do it would be to have a "success" and a "failure" ending - so have the campaign start on stage 2, then if the player wins (score > 50%) they go to stage 3, play the good ending which sets a 'win' score, and so after the ending the player wins the campaign. If they do badly, you set a losing score (<50%) so the campaign goes to stage 1, plays the scene which also sets a losing score, and then the player loses the campaign.

A bit different. Seems more in line with the hardware available for Georgia; more SAMs available and even T-72s. Notably absent is any kind of infantry. I haven't looked really closely, but they seem kind of somewhere between insurgents and Georgia/Russia in terms of unit types. Which might make sense if they're intended to represent regional militia that's receiving support from Russia.

Probably also worth explicitly noting that the 5 mil and 3/9 CR (consent to release) modes don't affect CCIP delivery itself - if the calculated impact point is actually within your view on the HUD you'll get the usual symbology with the solid line, and the weapons will release as soon as you hit the pickle button. When one of the CR modes is enabled, you get some additional functionality: if the impact point is off the HUD, you'll get a broken line to the pipper. You put the broken-line pipper over the target as usual for CCIP, but you need to hold down the weapon release button. That designates your target, and you'll get CCRP-style steering to your release point. So long as you keep the weapon release button held the entire time, once you reach the right place your weapons will release. As Jona33 says, the particular CR submode just affects how accurate your run-in needs to be in order for the weapons to release. Edit: oh, I made a video ages ago that goes through the various CCIP bombing methods. Here's a link.

Yep I've got this issue too. Thought I was going mad. :D I've tried binding it to the autopilot engage/disengage button the TM Warthog throttle, and also to a button on a VRinsight panel. Neither works - it lets me bind it but is ignored both in-game and in the options screen. The 'M' key does work. Other commands seem to work fine, although with some oddities: 1. 'Burst length - long' and 'Burst length - short' options can only be mapped to the TM Warthog throttle or keyboard - every other controller is disabled. Also, it seems to require being held in position; I've mapped it to the pinky switch on the throttle forward/back positions and it works as hoped for in that configuration, i.e. putting it forward or backward selects either long or short burst as appropriate, and putting it to the middle position selects the normal burst length. 2. 'Shkval narrow view 23x' and 'Shkval wide view 7x' is a bit weird too. Seems like the narrow view one needs to be held down, and it automatically reverts to 7x when it's released? I initially mapped this to 'china hat fwd' for narrow and back for wide; so it didn't really work out as I'd hoped. Changed it to use the boat switch instead so the forward position will be held in and it works that way. But, it seems very odd...

I've used US infantry and they appeared (and shot at me). Didn't try cycling to them with the F7 key though. Okay, I see what you're talking about... the new Russian 'Infantry Soldier' units don't appear in the game world, but do have icons on the map. Even if you select one of their icons and press F7, it'll take you to a different ground unit. The standard 'Paratrooper AKS' and 'Paratrooper RPG-16' units wihch have been in the sim since forever work fine. Also I've noticed the Abkhazia and South Ossetia factions don't have any infantry units available..? :(

So what's the harm in charging less and then charging additional for updates to the older modules? I mean, what's the benefit of charging more up-front rather than doing it like this? I can see some negatives in the form of making it harder to get retailers to stock your product, and putting people off buying it because of a higher purchase price. I can't really see a benefit, especially if people actually are willing to paying more. As for the whole 'they should have developed it as a modular system' thing... given that they were the ones who described the concept as aircraft modules, I'm fairly confident that at some point over the last few years they did give some kind of consideration to the idea of implementing them as pluggable modules into a common engine that was updated as they went... and rejected it for some reason. Reasons that we're not privvy to and would only embarass ourselves if we tried to guess (not that that'll stop me :D).

I don't think that'd be especially viable. A lot (i.e. most) of the work would have to be done to make it compatible. Come to think of it, I think it'd actually be a significant project to simply determine what updates needed to be made and what could be left alone, let alone actually implementing them. And even if you did, you'd then end up with two versions of Black Shark you need to support, and when the next module comes out, do it again with Warthog? So now you have "BS compatible", "BS upgraded", "A10 compatible", "A10 upgraded", and "New module". And then when the fourth module comes out ... I don't think anyone treats the simulation market as a cash-cow, otherwise Electronic Arts would still be producing simulations.

And I'd rather pay $2 per month for my electricity usage than $100+ per month. I guess it costs more to generate and provide me electricity than $2 per month though. That was a bit facetious and I do understand what you're saying - but you're pretty much making numbers up based on pretty much zero understanding of the costs, time, etc. it takes to develop the modules. On the basis of pretty much zero knowledge of what they actually do in order to put these products in the market, you're saying "if they'd done it this way it'd be way cheaper!" I don't have any better understanding of those things than you, but I'm willing to give them the benefit of the doubt and assume that they're trying to deliver the best product possible for the best price possible, within all the constraints they have to deal with -- military contracts, publishing deals, desire to develop new airframes and features versus desire to support previous products, etc. So what you're saying is that ED/TFC decided to go with the option that would cost them and their customers more, when there was a perfectly viable option that would've allowed them to develop the products at a lower cost and with less customer frustration? That they, as a private company that lives or dies based on being able to deliver products their customers think are worth paying for, have chosen to use the least efficient development method that resulted in higher prices for their customers, so as to ensure their success in the marketplace..? I'm not sure the logic stacks up, and I think that may be due to starting that particular train of thought with false assumptions. Not being a developer of high fidelity simulation software, I can't really judge how much it actually costs to develop this stuff, and what kind of prices are viable. And given the dearth of any kind of competition (aside from some prior efforts by companies who went out of business in the process) there's not really anything to use a comparison. But, if the cost is somewhere in the region of $1,000 in order to fly 6 or so incredibly detailed aircraft with authentic flight modeling and avionics, then that seems like a reasonable price to pay, IMO. After all, I've spent at least that much on hardware, and the hardware wouldn't be worth a squat if there wasn't software available that made it worthwhile. Actually by the time 6 modules are out, I'll have spent way more than that on hardware - probably at least one if not two entirely new systems, even assuming it only took 6 years for 6 modules...

Anything's possible, it's just a matter of where you spend your time; i.e. priorities. The directory structure of BS/FC2/A10C etc. strongly suggests they're keeping modularity in mind. It's just not the highest priority at the moment so they're not delaying development and improvements in order to maintain the modularity. That assumes an engine upgrade wouldn't require any additional work/updates made to the aircraft themselves. That seems like a pretty bold assumption. Unless of course you're talking low-fidelity aircraft with little integration with the game world and only a set of generic parameters to adjust in order to give them unique flight models, weapons, sensors, etc. Or engine upgrades which have no meaningful effect on the flight experience...? I don't think there's any reason to assume that the current model is the only one they'll ever use. Then again, it may be the only that's actually viable. Maybe having an integrated battlefield with every platform simulated in high detail costs more than $60 per product... I think ED/TFC could have and should have communicated this plan better, but I don't think it's a bad plan. The main issue I can see is with die-hard rotorheads who only bought Warthog in order to support development of the engine, when they were under the impression they'd eventually get the new features developed for Warthog 'for free'. Now they're finding they actually have to pay for them 'again'. Many are probably happy to do so, but it'd be nicer to have the options presented up front rather than being 'tricked' into being extra-generous.