Blackeye

To elaborate further your SPI (sensor point of interest) is -among other things- the place where the computer assumes you want drop your bombs on and the CCRP is given for that point. The place where your (current) sensor is pointing to might be different and it usually is if you start moving your TGP around. So after you have found a target you need to tell the computer that the point your SOI (sensor of interest) is currently looking at should be your new SPI. Once you've done that all calculations will be updated to reference the new SPI. Here's what the TAD looked like when you released the GBU (left) and what it should look like (right) In the left picture the green diamond (TGP) is pointing to your target, however the SPI (white wedding cake) is still at its default position, i.e. the current steer point. Pressing TMS up long (LCtrl up?) will set the SPI to your SOIs target and the cake is on top of the green diamond(right).

The Default_DTS_CDU_DB.lua file even contains a comment that seems to indicate the DB file would be loaded in custom missions when placed near? the mission file. -- Если в папке Missions рядом с файлом миссии лежит файл [ИМЯ_МИССИИ]_DTS_CDU_Database.lua, то база будет грузиться с него. Couldn't get it to work either though.

As I said just a quick cockpit check because your topic piqued my interest - skipped most dials actually. That wrap around has bothered me from day one though :joystick:

After a quick check the following 3-way switches seem to be reversed: Transponder/IFF Audio/Light Autopilot Mode Select Seat up/down HUD Video Selector Landing Lights Master Arm Gun Arm Laser Arm Altimeter Source IFFCC ON Canopy open close Oxygen Flow Position Flash HARS Mag Var The RWR system switches jump to their top position on a single right click - not sure if that is intended. The RWR jettison switch only works on left click. Additional question: would it be possible to prevent switches and dials from "rolling over", i.e. if they are already at their top position and you click "up" they would stay there instead of flipping to their downmost position. The intercom selector and autopilot mode switch do this already - would be nice to have for all switches (3- and 2-way) and dials imho.

The easiest solution is probably setting up key bindings for these (or get the Warthog HOTAS that comes with hardware switches) Alternatively you can use the mouse to click "through" the throttle at the right spot (to find it move the cursor over the throttle and wait for the correct tool tip to appear). You can also move your cockpit view backwards (RShift+RCrtl+Numpad / or TrackIR) to bring them into view. As for landing: don't come in too fast (watch AoA indexer left of your HUD), flare, throttle back to idle, after touchdown apply full (air) speed brakes (LCtrl+B) and apply wheel brakes (W) as needed - preferably at lower speeds. You can engage NWS below 80(?) knots - although I usually wait until I'm below 50 knots.

A shuttlecock is aerodynamically stable, a rocket might not necessarily be, given its design (e.g. front fins) and the fact that unstable usually means better maneuverability if you can keep control.

Only above a certain speed threshold IIRC - apparently it's assumed that when going slow in weapons mode you'll be maneuvering by checking your surroundings rather than the instruments.

Well there's other options: Dropbox, GoogleDrive, etc. A track is really the best option to check what was going on or to reproduce the bug.

Are you sure you had LWS turned on? Track? A short test vs a T72B produced a range finding warning for me (no guidance warning though).

Well the trim button does the same thing in that case and it's not awkwardly placed so you'd have to let go of the controls first to press it (in the real thing that is). Trimming does however overwrite the desired AP state, so if you want to return to exactly the same AP flight state as before then FD is helpful. If you need to re-trim after maneuvering anyway FD is sort of superfluous IMHO.

Well according to the documentation of SAM Simulator (afaik the best public simulator for those devices) this is how the radar of a ZSU-23-4V1 works: "During target acquisition, the 2° wide pencil beam of the antenna mechanically scans a 15° sector, vertically" And "During target tracking, the pencil beam of the antenna is conically scanned around the tracked target, mechanically" So I take it while acquiring you'd have to adjust the azimuth manually while the radar scans 15° of elevation automatically and provides ranging information for anything it detects. When tracking the radar will automatically follow a single target while circling the radar beam around it. So the ZSU does not have an automatic 360° scan but relies on a 9S482 Mobile Air Defense Command Post to provide an overview over the target situation. For more details download the SAMSim documentation (theres a version of the zsu docs on scribd) or even the game and see if you have it in you to operate an almost real ZSU-23-4.

I'm sure the bullets will travel even further than that, that's why I asked where he got those numbers from. In any case I think DCS is just modeling the effective range to keep things simple, thus the exploding bullets at 3km.

Where did you get those numbers from? Most sources seem to talk about an approximate range of 3km.

The Automatic Ejection System BIT Panel is located at the top of the Rear (right) Aux Panel - see section 6-91 of the flight manual.

I don't know. Those 30mm rounds are pretty powerful - I don't think there's any aircraft that can shrug off a barrage of these. The cockpit of the Ka-50 is designed to offer protection against 20mm rounds and may prevent a 30mm round from doing too much damage to vital systems (like the pilot). But even then a single 30mm hit is likely a mission kill - take multiple hits and you're lucky to live and tell. Not sure about the UH-1 damage model though.

Make sure Force Feedback is disabled in Misc Options unless you're using a FFB joystick. To elaborate: With this option checked DCS will adjust the forces to keep an FFB joystick at the position when the trimmer was released and NOT offset the joystick input - similar to the real world trimmer. However if you don't have an FFB device the joystick will of course happily return to its mechanical center and the trimmer only sends the new flight parameters to the autopilot. This won't do much though as the cyclic is usually way off the intended center position overriding the AP. When Force Feedback is disabled, DCS will instead offset the raw positional data from the joystick with the values from when the trimmer was released, keeping the in game cyclic at that position even though the actual joystick returned to its mechanical center

I'd say its an AoA sensor so you know the angle at which the air is flowing around the helicopter - might even be used to turn a tube directly into the air stream to get the correct air speed.

Tell me and I’ll forget; Show me and I may remember; Involve me and I’ll understand. :)

There are however excellent interactive tutorials for BS2 made by BigfootMSR http://forums.eagle.ru/showthread.php?t=84612

Wrong. There are no "50% of the energy directed in the opposite direction" - Newton talks about FORCES - those laws say nothing about energy. If you want to know the energy distribution you'll have to look at the laws and formulas dealing with (kinetic) energy (and impulse in this case). Wrong. If you're talking about how the energy is generated in the first place (chemical reaction) then that has nothing to do Newton and the loss might amount to any value - 50% would be a huge coincidence. The deformation energy of the bodies is pretty negligible as long as the push takes place over an extended period of time (i.e. no explosion) You could also replace the pushing muscles with a loaded spring and the heat up of that spring expanding and pushing does definitely not amount to 50% of the kinetic energy of the two bodies afterwards. Does not matter for the Law of Impulse. It applies regardless of how the bodies are composed before and after or how they interact - sum of V*m has to remain the same (V as vector) no matter how many parts make up that sum or what happens in between. Not at all. That's exactly what's happening when you push a body and you both are freely moving. Not arguing with Newton here - he's right and dead anyway. But your interpretation of those laws is wrong or more specifically they do not apply in the way (and where) you seem to think they do. Feel free to do so or message me - in German if you want.

An that is not quite correct. Let's take your trolley example and assume that the trolley is the thing you want to actually move. And also let the masses be 10kg for the trolley and 100kg for the one pushing. The overall impulse (m*v) has to stay constant. So if we assume a final velocity of 10m/s for the trolley its impulse is 100 kg*m/s which results in a speed of 1m/s for the person (100kg) The energy of the trolley is then 0.5*10kg*(10m/2)^2 = 500 kg*m2/s2 and for the person it's 0.5*100kg*(1m/2)^2 = 50 kg*m2/s2. In this scenario 91% of the energy went into the trolley while 9% went into the person, so where the energy ends up is highly dependent on the masses involved. Of course in this scenario we're not talking about the process of generating movement out of heat (like in a turbine or piston engine) but simply about energy distribution when you start to push freely moving things around. The efficiency of heat engines i.e. converting heat into motion has nothing to do with this. Edit: Going back to the Ka-50 we have 1) a turbine burning fuel and generating power on its shaft This is a heat engine whose efficiency is limited by the carnot process and the accompanying theorem. Of course there are better formulas to calculate/estimate the efficiency of a real world turbine - still the temperature pools define the possible maximum. No Newton involved. 2) a rotor converting the motion of the drive shaft into thrust into motion of the helicopter That's a pretty complex process and it's also not obvious how you would define efficiency. Newton is probably helpful here.

Sure Newton is helpful whenever you want to calculate forces and motion of bodies. So if you want to know the forces a piston encounters during its movement you need Newton; when flying to the moon you definitely need Newton. However Newton won't help you when dealing with the efficiency of a heat engine - like a piston engine. However Carnots theorem tells you the lacking efficiency is not a problem with the actual implementation of your piston engine (it may add on on top of this though) but regardless of how your engine is designed, you fundamentally cannot get better than the value defined by the two working temperatures. And you cannot calculate or explain this with the Laws of Newton. Since you mention Perpetum Mobiles - there's nothing in the Three Laws of Motion that would disallow those - they do however violate the laws of Thermodynamics.

Thank you. The 11.9 and 10.8 ton graphs seem to indicate that the in-game MTOW of 11.9 is correct while the widely quoted 10.8 is not - so much for the Internet ;) Also in 2500m at 11.4t you're pretty much stuck at 0m/s while hovering, so the in-game observation appears to match the real world performance. :D

Yeah, that's a bit weird. Wikipedia also lists 10 800kg and cites kamov.ru as source (only available via internet archive now) There it says "takeoff weight: 10800kg" - possibly meaning typical tow? Or perhaps it was adjusted later? Maybe someone with better connections (or better google skills) can shed some light on this.