OutOnTheOP

How do I change the default cockpit view angle? I have set up a 4-monitor array where 3 monitors show external cameras and the MFCDs display in the upper corners of a fourth monitor (set below the other three), along with Helios running the gauges for a virtual control panel. The problem is that right now, when I hit my "view center" button, it centers on the bottom of the HUD... showing both outside view and control panel- which I don't really need to see. I want to change the "view center" default angle so it is pointing out the top of the HUD, to maximize external view. I already tried editing the cockpit view settings (I used "3camera.lua" as a basis, made a new one called "3cameras+MFCD.lua"), and found that if I put 0.3 as the "viewDy" variable, it DOES center on the HUD... but it also skews the viewing angle between the center and side screens. Basically, it's telling the program that the MONITORS have moved, not the view angle... if that makes any sense. SO, I'm pretty sure I have to edit "snapviewsdefault.lua", can anyone help me out here?

ArmA? Oh, lord no. Who said anything about making a game like that? The key flaws there are an overabundance of vehicles, no class restrictions, and a scoring model based upon "kills" rather than accomplishing mission objectives. The fact that Joe Rifleman can jump in an abandoned tank or aircraft at a whim really kills it too. No, you'd have to have defined roles, an established rank hierarchy, and assign score to the accomplishment of mission objectives (which should ideally be terrain or key unit focused) rather than based on number of kills. Besides, ArmA is the ultimate expression of a "survey" sim, that attempts to simulate everything, but does nothing well. A DCS series would simulate each and every weapons system in minute detail.

You're missing the point. It's not about "letting the armored guys do their thing"; it's about having the full digital battleground. The ideal is to have a series of modules covering EVERY force on the battlefield. The T80U armor company trying to sieze town? Human players. The Stryker infantry task force trying to stop them? Human players. The A-10 CAS they're calling to help? Human. The SA15s trying to shoot them down? Human. The F-16s providing SEAD? Human. The Sukhois scrambling to intercept them? Human. The Ticonderoga targeting their aircraft shelters with tomahawk to catch them on the ground? Human player. The Akula trying to sink it?.... well, you get the point. It's a lot more fun when both the guy trying to kill you AND your target are human controlled. It makes things a lot more challenging and a lot more unpredictable- one might say, the ultimate dynamic campaign. Of course, fighter and attack aircraft are simply easier to simulate, because they are naturally single-man systems, so you can simulate EVERYTHING. Other systems would require some simulation compromises- after all, who really wants to play the part of the loader on a howitzer, or damage controlman on a destroyer? If we could get a simulation of armored vehicles allowing each player to play as a platoon leader or company commander (with direct control of his own tank, of course), SAM simulation at the battery level, ships simulated at the command level (with the option for human players down to the ship section level), and some "higher command" interface for support arms such as supply convoys and the placement and allocation of artillery assets (their fire missions requested and controlled by human FOs and armor or infantry players), it would be amazing. Of course, it would also be a HUGE project.

Pilot did the right thing by ejecting; in a modern fighter aircraft, you have roll rates of around 270-360 degrees a second. Even if you had the reflexes to work the stick fast enough to modulate up- and down-inputs fast enough to correspond with a direction you'd like to turn (or climb), I'm not sure the aircraft would respond fast enough to overcome inertia before continuing the roll. At any rate, best you could do would be to maintain altitude until you got out of populated areas before you punched out. If you couldn't get the ailerons un-stuck, you're NEVER landing that bird

regarding the SA3 engagement, yes, it's designed as a low altitude system, but it's still an early-generation missile with relatively limited low-altitude capabilities. And it's not the missile I'm taking exception to as much as the radar system. I'm not entirely certain the Low Blow tracking radar will give a solid track against a target that small at 8km; certainly not fast enough to get a solid intercept solution and get a missile off in time. The SA15 I can believe- at least in engagements at 3-5 km against missiles or bombs with low crossing angles. SA3, not so much.

Personally, I am ANNOYED beyond belief at this SAM behavior. Now, I can understand a late generation radar-guided SAM (be it active, SARH, or radar/ command-guided) hitting a Maverick in a frontal, no-lateral-motion engagement. HOWEVER, my first experience with SAMs shooting down my Mavericks was an SA3. And it wasn't even the SA3 I was shooting at- I was shooting at the tracking radar of one site, and the missile was hit by an SA3 fired from a SECOND site, about 8 km away, with a 90 degree crossing angle, during an engagement window of perhaps 20 seconds (I had fired during a quick pop-up engagement at around 3 nm after acquiring the TR with my TGP from 20nm, then terrain-following flight in to engagement range). I'm sorry, but I just don't think SA3 is THAT capable. Granted, Mavericks aren't terribly fast; right below mach 1- but still... a high-angle crossing shot with a low acquisition-to-hit time at an almost NOE target?

I should hope it's only an option at night. I had several laser markers at my disposal as a Fire Support Officer, and none of them would provide a good sparkle in daytime- to include the GBD-3, which we called the "lightsaber", both because it looked like a lightsaber handle, and because it shot a green laser beam you could clearly see from at least 10km away at night. Anyhow, sparkles are generally IR laser markers, and would only be visible through NODs. You CAN sparkle with a visible laser, but again, only at night. Yes, you CAN use it to mark for guided missiles or bombs. The pilot is merely using the sparkle as a point of reference to orient on; it does NOT provide guidance like a proper coded laser designator. However, since it only provides a reference point, the pilot will still have to slew the weapon onto the target visually. What I'm really waiting for is friendly troops to mark THEMSELVES for aerial identification. VS-17 flourescent panels, chem lights, or "buzzsaws" at night would be awesome.

It does? I haven't had ANY issues with short bombs in DCS:WH. Wind has way too much effect on bombs in DCS:WH, and anything above about 2 knots will blow your bombs 50 meters or more off target (super unrealistic, IMHO. Bombs have a lot of mass, and therefore a lot of inertia; it'd take a lot more than a couple knots of wind). If I set it to no wind, I can drop bombs into the side of a truck (especially with BSU49s. I loves them things). However, CLUSTER bombs regularly drop short. I think it's because the pipper is calculated on the ballistic path of the dispenser unit (the bomb) and the submunitions have a MUCH higher drag value. Since the CBU burst altitude is currently all messed up, they usually burst too high, have too much drag too long, and therefore hit short. I've found 3500-4500 ft releases to shack CBU87 and CBU97, but attempts at high releases with CBU103 and CBU105 end up hundreds of meters short of the target.

Holy crap, guys, you're going to confuse him. He's asking a question about the A-10A as depicted in FC2, and you're answering him with procedure for A-10C as depicted in DCS:WH. As to the question: it's been a while since I've played LOMAC/ FC2, but yes, the bomb releases are in milliseconds. Which doesn't translate too well into feet-on-ground. It would require some math. But, assuming you come in at 250 knots at a relatively flat angle (call it 20-30 degrees, I am SO not going to work out the relative horizontal distance in a steep dive!), then: You are travelling 250 knots x 1.1 knots per mph = 275mph. 275mph x 5280 feet per mile = 1,452,000 feet per hour. This equals 1,452,000 feet per hour/ 60 minutes per hour, or 24,200 feet per minute. In turn, that's 24,200 feet per minute / 60 seconds per minute = 403 feet per second. 403 feet per second / 1,000 milliseconds per second = 0.403 feet per milliseconds. 0.403 feet per millisecond x 5 milliseconds = about 2.017 feet per 5ms interval. Which sounds REALLY close to me, but the math checks out. It makes me wonder if "05" milliseconds on the ACP is really in TENS of milliseconds, which means "05" would really be 050 milliseconds, and thus about a 20 foot interval-per-click adjustment instead of 2. As to why you might be dropping short of the target: as others have mentioned, you have to hold down the button until your whole string of bombs has released. I cannot remember if it was on FC2 or one of the Falcon 4 variants, but I do remember some to-do about CCIP behaviour being modified: "old" versions of the software STARTED the first impacts of the bomb string on the pipper; the correct behaviour is for the string to be CENTERED on the pipper. So, if the correct CCIP behaviour is implemented, and you have a 2-bomb string selected, with 20 foot spacing, then the first bomb should hit 10 short, and the second one should hit 10 long. If you release the button before the second one drops, you'll only get the first bomb, 10 feet short. Other than that... try steeper angles. Generally, GP bombs are delivered from about a 30 degree dive. This will also make your pipper easier to acquire.

Hmmm... what I'd like to see... well, that's a long list. However, from what is logical from a business model standpoint? Well, I see two primary methods ED can go about this: 1) they can add aircraft with gradually increasing air-to-air capabilities, to ensure that online BS and WH players in the DCS battlefield don't get completely dominated by the new aircraft. This would support a high-speed, high-performance attack or light bomber with limited air-to-air capability. Something along the line of MiG-27, Su-24, Jaguar, or Harrier. The next step after those would be light fighters with strike capability (F-16, MiG-29, F/A-18), multirole fighters (F-15E, Su-30, Tornado), then finally dedicated interceptors. As a variation of this plan, they take the time to add "equivalent" units for both eastern and western forces before moving on to newer "classes" of aircraft. Logically this means adding the AH-64 to match the Ka-50, and adding the Su-25 to match the A-10 before anything else. (On a total aside, why the Ka-50? Seriously? The flagship airframe of a simulation series is modelled after a series with only 15 airframes in service? There's probably multiplayer missions with more Ka-50s flying around at once than have ever existed in reality!) 2) They can add new aircraft based off adding new mission profiles. IE, add something completely different from the last addition, to make things new and interesting. In this case, I would argue something like F-15E or Tornado is the logical next step- light multirole fighters like the F-16, F/A-18, MiG-29, and the MiG-27 or Harrier style attack aircraft are still primarily tactical bombers; they would end up doing similar missions to what BS and WH already cover- perhaps not the CAS side, but certainly BAI and similar missions. F-15E or Tornado would enable deep strike, OCA, and missions of that type, as well as limited air-to-air missions. Personally, I'd love to see the F-15E or Tornado. They open up all kinds of fun new mission profiles. As to those that argue they can't be done because they are multi-seaters... c'mon, your wingmen are AI, why not your backseater? Or allow players to jump from one seat to the other? Not to mention online play with live backseaters. Other companies have done very successful implementations of multi-seaters before. By your logic, tank simulations shouldn't exist, either! Speaking of which, why are we limiting ourself to aircraft? Seems to me tanks would be an excellent choice; they have an active, well-defined role on the battlefield, are very capable of being decisive in battle, and have enough defensive options (between active and passive) against aircraft to prevent being "just targets". Beyond that, tactical ADA are a logical addition for players. The only issue is that they have limited mobility, so players would have to wait for aircraft to come to them, which could get tedious. Easily enough solved; let the ADA player control a small network of ADA; something covering about a 30km radius; a couple mech BNs worth of tactical systems and at least one search radar.

Personally, I'm having a hard time reconciling the relative high performance of the Igla compared with Stinger. Both were designed around the same time, and have had roughly the same development cycle. And as far as flare rejection goes, that is largely a software issue, and no offense to any Russians on the board, but US software, sensors and avionics have always been a bit ahead of the Russian equivalents. On top of that, the Igla has a directed (forward-oriented) warhead that fires a "shotgun blast", while Stinger has (IIRC) a continuously expanding rod annular blast warhear. This means Stinger should be more lethal in "near miss" detonations. Given the similar layout of control surfaces and missile mass, maneuverability should be comparable, so your ability to outmaneuver either should be equal. It should also be noted that FIM-92 has recorded 270 kills, while Igla has a confirmed... two, that I know of. Not that that means anything; many more Stinger have been fired in combat, I'm sure. Anyhow, the only way I can really understand the poor performance of Stinger in DCS is if they're modelling the now-archaic FIM-92A series, circa 1985 or so. In which case, SA-14 would be a more fair comparison, I think. Perhaps ED just doesn't have access to the specs for the more modern missiles, or was provided conservative estimates ...which leads to Stinger use in Afghanistan circa 2001-2010. Seriously, guys? You honestly think the batteries and coolant canisters lasted this long without expiring? That the missiles themselves survived 20 years of crude storage without degradation? That crews stayed current on their use for a couple generations without refresher training? And even if they had, the old FIM-92As provided to the Afghans were pretty susceptible to countermeasures compared to today's models- kind of how SA-7 and SA-14 are trivially easy to spoof these days (I have this on good authority from helo pilots; SA-7 is DUMB).

A (partial) aside regarding UTM vs MGRS, as it was mentioned earlier: UTM and MGRS are, in fact, both the same geographical representation model. Both use (typically) the WGS84 geodetic data, and MGRS utilizes the UTM projection data. UTM is a map projection. IE, the coordinate method used to represent a spherical earth on a flat map. MGRS is a nomenclature system- a way of "saying" UTM data over radios in a way that is less likely to be miss-read; if there is static in your transmission, you're much less likely to get confused and think the "37T AB" grid zone designator is part of the 10-digit grid than you would be if you just got a string of 13 digits badly garbled! Recalling back to my Fire Support Officer days, the only difference between them is how the preface is written: in MGRS, you have, for example "12A BC 12345 67890", which in UTM is written (if I recall correctly) "1 12345 23 67890". In short, MGRS uses an alphanumeric grid zone designator (in this case 12A BC) where UTM uses a purely numerical grid zone designator (in this case 1 23). Both are used in the military; the SCU fire-control computer on my FIST vehicle (circa 2007) output it's coordinates in the 13-digit UTM format, and communicated to the AFATDS artillery fire direction computers in UTM format. Now that everyone is thoroughly confused by my terrible explanation, I now return you to your regularly scheduled programming

I agree, it would be very nice to configure your countermeasure settings in the mission prep page (loadout screen, maybe?) and upload them on the data cartridge. Also, when in semi-auto mode, remember that the CMS back button will terminate a running program. Most of the programs seem to run 8-10 seconds, so if you only want to dump 2-6 chaff and/or flares, hit CMS forward, give it to the count of 'two potato', then hit CMS back to end the program early.

Aha. If they are all accessible via the default.lua, that should get the job done for me. I know JUST enough programming to get the job done (also, to get myself in trouble by totally fscking it up!) :thumbup: Yes, I plan to do a full physical cockpit with all the controls supported by the sim on the panels. Yes, I realize this is a lot of work. It'll be an interesting experience, one way or another.

I am left wondering: will ALL commands be available for re-configuration onto keyboards/ joystick button/ axis (as applicable)? Having the ability to do so would be EXTREMELY helpful for persons trying to build simulated cockpits, particularly newbies like myself, as it seems to me that the easiest solution is to use a keyboard emulation card to make your switches input to the computer as keystrokes- but if the game does not support assigning ALL commands (IE, everything including each and every switch, individual radio frequency setting dials, etc), building a simulated cockpit becomes much, much more difficult, as commands would be based on mouseclicks on the screen, which I frankly have no idea how to emulate. I gather the .LUA has something to do with command inputs and possibly gauge outputs; would it be possible to get official support for this as well? I think the ideal solution would be for every position of every switch in the cockpit to be assignable to a custom keystroke or joystick button, and to enable a four-monitor setting that uses one monitor for the main display (IE, shows the panning cockpit view), two monitors assigned to the MFDs (which can then be inset into your simulated cockpit), and one monitor to display the engine gauges (as the majority of gauges are clustered there). Even better, allow a fifth monitor to display CDU output. At the very least, will the CDU and Up-Front Control Panel inputs be keyboard programmable?