nomdeplume

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.

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.