Lascaille

OK this seems not to work. The DCS editor shows the buttons as bound but only one function is activated.

Teej, I had a thought. I've found multiple controls mapped to the same button within the DCS editor after upgrades - i.e. the DCS 'edit controls' window shows the same joy button bound to multiple actions. You can't create that scenario in the DCS editor but it does display it, therefore it's not erroring out immediately. Is it possible/easier just to edit the saved input configuration files directly, adding the same button to multiple actions? That would also avoid integrity check issues.

This is honestly one of the best threads I've ever seen. No attitude, just incredible advice. Need to set up some multiple actions myself (I want the wheelbrakes and weapon drop combined on the warthog paddle switch for some aircraft) and will get into it. Huge thanks.

All, please consider: Radar modelling within DCS, from what I have read, is not based on radar theory. The radar system works on the position, aspect, size and speed of the objects - basically it's like a passive system, it relies on being able to 'see' the object, presumably there is a master 'object array (array as in programming terms)' which defines the position, speed, aspect, type etc of all objects in the game and the relevant countermeasure/radar code for each module consults this array when deciding what to display to the user. I am not sure how much of this is abstracted by DCS or if DCS just exposes a list of objects and the developer can do their own work. With that in mind there are no 'radar waves' in DCS being generated by the aggressor to be received by the SPO-10 code. So the SPO-10 code has access to the same 'object array' as any other radar/countermeasure code object, so it can see which objects are at which distance, and whether they are emitting, whether they are facing towards/away, etc. LN do not control modules aside from their own, so I guess they have to give their SPO-10 a list of modules (aircraft, SAMs, etc) and an effectiveness (range) value depending on the modernity, etc of each unit. The SPO-10 code then does a calculation: how distant is the object, is it facing me, what is the altitude, is it emitting, is it behind terrain and decides whether to alert. This is my conjecture but from all the reading I have been doing this is fairly accurate as to how radar within DCS works. It is not a simulation of radar, it is a system designed to allow radars to be functional in game. So, you are not going to find in any manual anywhere details about the real world effectiveness of the SPO-10. 'Detects radar emissions up to 20km' or something maybe, but versus specific radars, including more modern ones designed long after the SPO-10 was last in production? No chance. So I believe you have to accept that any modelling of the performance of the SPO-10 - beyond the behaviours exposed in the manual, i.e. the manner in which the lights flash, the beep patterns - will be original research / original fiction. Of course if anyone has more details about how things _actually_ work in game - if I am wrong - I would be interested. Maybe we can come up with some potential ideas to improve, in that case? Not just 'make it better' but a different way to model the system.

Track attached for anyone who's interested. Note there's no actual kill, the Magic II didn't lock in time. I had the target well within the seeker window though with the airframe under control. Can you use the radar to guide the seeker head? Rearward Missile.trk

Thanks B

The first person to die to this is going to be SO butthurt they'll probably develop haemorrhoids. [ame] [/ame]

Just got the Mirage which is behaving very nicely, congrats to RAZBAM on a great release. I'm sure I'm not the only person to notice how different the viewpoint/angle is from other DCS mods. I made changes in the views.lua (mods\aircraft\m-2000c\views.lua) and provide it here as a starting point for anyone who has a similar feeling. This gives a similar cockpit feel to the A10C - which I think is itself a bit more zoomed in and 'up front' than the FC3 mods - and reduces (to zero) the eyepoint/pivotpoint differential thus reducing viewpoint position shift with trackir pitch/roll (so when you look down, you will no longer feel like your head is moving down also). ViewSettings = { Cockpit = { [1] = {-- player slot 1 CockpitLocalPoint = {0.00,0.000,0.000}, CameraViewAngleLimits = {20.0000,140.0000}, CameraAngleRestriction = {false,90.000000,0.500000}, CameraAngleLimits = {200,-90.000000,90.000000}, EyePoint = {0.000000,0.000000,0.000000}, ShoulderSize = 0.25, Allow360rotation = false, limits_6DOF = {x = {-0.050000,0.450000},y ={-0.100000,0.100000},z = {-0.30000,0.30000},roll = 90.000000}, }, }, -- Cockpit Chase = { LocalPoint = {-10.0,1.0,3.0}, AnglesDefault = {0.000000, 0.000000}, }, -- Chase Arcade = { LocalPoint = {-21.500000,6.618000,0.000000}, AnglesDefault = {0.000000,-8.000000}, }, -- Arcade } SnapViews = { [1] = {-- player slot 1 [1] = {--LWin + Num0 : Snap View 0 viewAngle = 48.000000,--FOV hAngle = 0.000000, vAngle = -45.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [2] = {--LWin + Num1 : Snap View 1 viewAngle = 48.000000,--FOV hAngle = 45.000000, vAngle = -45.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [3] = {--LWin + Num2 : Snap View 2 viewAngle = 48.000000,--FOV hAngle = 0.000000, vAngle = -75.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [4] = {--LWin + Num3 : Snap View 3 viewAngle = 48.000000,--FOV hAngle = -45.000000, vAngle = -45.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [5] = {--LWin + Num4 : Snap View 4 viewAngle = 91.040001,--FOV hAngle = 157.332764, vAngle = -28.359503, x_trans = 0.063872, y_trans = 0.082888, z_trans = -0.116148, rollAngle = 0.000000, }, [6] = {--LWin + Num5 : Snap View 5 viewAngle = 50.000000,--FOV hAngle = 0.000000, vAngle = -8.722581, x_trans = 0.212078, y_trans = 0.057813, z_trans = 0.000000, rollAngle = 0.000000, }, [7] = {--LWin + Num6 : Snap View 6 viewAngle = 80.000000,--FOV hAngle = -143.000000, vAngle = 0.000000, x_trans = 0.350000, y_trans = 0.020000, z_trans = 0.100000, rollAngle = 0.000000, }, [8] = {--LWin + Num7 : Snap View 7 viewAngle = 80.000000,--FOV hAngle = 45.000000, vAngle = -5.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [9] = {--LWin + Num8 : Snap View 8 viewAngle = 80.000000,--FOV hAngle = 0.000000, vAngle = 10.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [10] = {--LWin + Num9 : Snap View 9 viewAngle = 80.000000,--FOV hAngle = -45.000000, vAngle = -5.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [11] = {--look at left mirror viewAngle = 80.000000,--FOV hAngle = 0.000000, vAngle = 10.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [12] = {--look at right mirror viewAngle = 80.000000,--FOV hAngle = -20.000000, vAngle = 8.000000, x_trans = 0.120000, y_trans = 0.020000, z_trans = 0.000000, rollAngle = 0.000000, }, [13] = {--default view viewAngle = 71.000000,--FOV hAngle = 0.000000, vAngle = -19.000000, x_trans = 0.000000, y_trans = 0.010000, z_trans = 0.000000, rollAngle = 0.000000, }, }, } Changes: Line 8: EyePoint = {0.000000,0.000000,0.000000}, Line 134: viewAngle = 71.000000,--FOV Line 136: vAngle = -19.000000, Line 138: y_trans = 0.010000, No whining please! I am not complaining about the module, I am just making viewpoint changes for my own familiarity. Don't forget to backup your views.lua!

The Mig-21 has neither trim tabs or a fully moveable tailplane. Therefore trim is effected by changing the neutral position of the elevators themselves. Yes in real life this reduces control authority (adding back trim has the same effect on the control surfaces as pulling the stick back. As the position of the stick directly reflects the position of the control surfaces the stick will move as you trim.

The actual situation seems to be both - if you have the crosswind directly on your right wing (88-92 degrees) wing the aircraft will yaw right _into_ it, but will stabilize at some angle to it. If you have the crosswind barely off the nose (i.e. 2 degrees) the aircraft will yaw right _away_ from it and also end up stable.

So to host 50 players you would need 40Mbit? As in nearly half a 100mbit ethernet connection? I am not doubting you just astonished, I used to do some managed hosting stuff and that would be well over $2k per month for B/W alone. I am going to be selfish asshole here but ask, I am in Asia and see ~225ms to your server. I would like to get back to it once the beta calms down a bit. I understand pings have to be for the benefit of all people but warping that I could see was caused much more by packet loss than simple high ping. If the limit could be set 'considerately' that would be appreciated. No matter what connection I pay for I won't get that ping below 225 due to physics. Also: have you seen any reduction in b/w due to the beta? Or just due to fewer clients?

30m/s is the crosswind limit? What is the headwind limit? I would guess small and light aircraft have limits due to ground handling. If you were to land C172 for example in 50kts headwind (I think you would land at full throttle to achieve positive ground speed) I don't see how you would get it off the runway. Either the wind would blow it straight whenever you tried to turn (that weathercocking effect) or it would turn upside down once the wind to the downwind wing was blocked.

A clarification would be nice. As I said, I measured the bandwidth of my client with WMI and on the 104th I was not seeing more than approx 17.5KBps / 140Kbps / 0.13Mbps down, and less than half of that up. If people do see benefits on their clients from setting huge bitrates - when these observed bitrates are about a 1/10th of the standard limit - then... why?

Crosswind speed limits are because the aircraft has to be brought level and oriented to the runway heading centerline (decrab) before it contacts the runway, or the gear will shear off. With crosswinds greater than a certain amount the aircraft cannot safely decrab without running out of runway width or a wing strike. Headwind: I read what you say but B777 has NO headwind limit for manually flown takeoff and landing! (FYI crosswind limit 37kts, autoland headwind limit 25kts) Tailwind limits are due to various technical limitations, runway length and gear speed limitations. B777 10kts.

There is a need to clarify turbulence vs wind. Turbulence is 'wind within wind' i.e. the air as a whole has a speed of 50kmh at 0 degrees, a small 1m^2 sector of that air might be moving downwards at 20kmh but another sector next to that might be moving upwards at 20kmh. Turbulence ofc will rock the aircraft and can cause it to roll - e.g. if one wing is in an updraft and the other in a downdraft. We are not discussing turbulence, but wind. Wind with zero turbulence (both inside and outside of DCS) involves the entire air mass moving stably as one. In that wind there is NO effect upon the airborne aircraft (yawing, rolling, pitching, no effect at all) because it is impossible, there is no reaction point or pivot point for the aircraft. The wind does not 'blow' on the aircraft, the wind just moves the air and the aircraft just moves inside the air. If there is delta (moving from a region of 50kmh wind to 150kmh wind) there will be inertia forces but that is not the case for this scenario, this involves a static constant global wind.

From a quick look the MiG-21 has 2x 15-SCS-45 batteries, each of 24v and 45Ah. If we assume the GSR-ST-12000WT starter is 12KW then at 24V you would draw 428A from the battery. Based on what you said about the T-33 needing 400A and also operating at 24V that seems reasonable. With the batteries being 45Ah each you could in theory run the starter for 12 minutes straight completely flattening the batteries in the process. If you were to try this I think either the starter, batteries or wiring would catch fire.

I get your point but 'a PC on a bedroom with a decent connection' isn't something I have - my residential connection is DSL, 512k/15m. That is plenty of downstream for any reasonable usage but only enough upstream for 4 or 5 clients. Each client needs about 0.1-0.15Mbps of bandwidth to be available at the server, with some margin on top. Can you host or produce a 5-10Mbps connection somewhere? I would rather pay outright for hardware than $200 monthly. A cheapo server is cheap, you are right, it doesn't need a Xeon but if you want dedicated servers these days they don't seem to offer much less than a Xeon, I guess virtual machines have taken over the low end.

Am thinking to make a public dedi once 1.5 comes out of beta and we have a decent idea of memory and CPU requirements. There's a shortage of decent servers in Asia and most USA servers yield a ping of 175+. I'd want to host mostly freeflight maps - good ones with target rich environments, something in a similar vein to OpenConflict Sochi - but with proper missions starting GMT+8 8pm weekdays a few days a week, and Saturdays or Sundays. Of course the costs for a proper dedicated server (a Xeon 8/16gb rack server in a datacenter, not a box under some guy's stairs) are not insignificant and it would be nice to share costs using kickstarter or gofundme etc. Nothing is on the table yet but it would be nice to know if there was any interest. Also, to have the official opinion as to whether one could publicise such a kickstarter/gofundme here.

Right I just had a poke about and am seeing the following: These are rates measured at the client using WMI. As a client, joining a MP server with two other clients both actively flying: Down: Approx 10KBps / 80Kbps / 0.08Mbps Up: Approx 2.5KBps / 20Kbps/ 0.02Mbps Using a MP server with 15 active clients: Down: Approx 17.5KBps / 140Kbps / 0.13Mbps Up: Approx 7KBps / 56Kbps/ 0.06Mbps Extrapolating a bit, a server needs about 1.5Mbps of bandwidth for each 10 clients. Perhaps a bit more. Any single client should be able to play on - realistically - any bandwidth connection aside from a 56k modem. I don't know that changing these autoexec.cfg settings should have effects for clients as even the smallest limits are real high compared to the required rates... Of course it won't do any harm given how little b/w the client uses :)

The upstream rates being discussed here are orders of magnitude higher than a lot of DSL connections that players are using. DSL generally has a terrible upstream, I have 512k/15m for example. I am doing fine with net.download_speed = 655360 (5mbps) net.upload_speed = 49152 (75% of line limit, 384kbit) The client should not need anywhere as much upstream bandwidth as the server, and logically the downstream bandwidth of all the clients combined should be equal to the total upstream bandwidth of the server... If you set limit values to greater than your line capacity - and DCS tries to use that nonexistent bandwidth - then I suspect you will have major issues.

A combined starter & backup-generator (which this unit is) is not uncommon for smaller engines which can be started electrically without needing a huge starter and battery. A similar starter/generator is in the huey, there is a switch on the top panel to change the function of the device from starter to standby generator.

The g-lurch associated with the cutoff (not drop) of the SPRD boosters sometimes causes engine failure. I am using the SPRD boosters in the usual manner and rotating positively at ~250kmh to 10 degrees nose up with the SPRD cutoff occurring at about ~350kmh.

Create a mission with a loaded Mig-21 (80% fuel and a symmetrical load of 500kg and 250kg bombs is a good demonstrator, but other payloads also work) and set it as 'takeoff from runway'. Takeoff, clean up, and note that there is a tendency for the aircraft to roll to the right; left stick is required to keep the aircraft straight and level. With SAU Recovery engaged the aircraft will stabilise in height with a right bank and will circle slowly to the right. Drop the payload (note, even if you have dropped the payload through usage you have to JETTISON the payload using the buttons below the radar, specifically the outer pylons) and note that the roll tendency disappears. You can now either land, or reload the mission. Either way when static on the runway, use the in-game payload editor (F8/Rearm) and load the Mig-21 with the same stores. Takeoff, clean up, and note that there NO roll behaviour and that engaging SAU recovery puts the aircraft dead straight and level. In summary: The weight and balance of the stores is calculated differently when F8/Rearm is used than when the stores are on the aircraft from the outset of the mission. From the jettison behaviour - using the payload does not change the roll, only jettisoning it does - there is a 'phantom' store on the right outer pylon? This is also suggested by the fact you hear the jettison noise for the outer pylons when you hit the jettison button, even though there is nothing to jettison and nothing falls away.

May we avoid the word 'slip' - that is a word which has a meaning referring to the flight conditions deliberately created by crossed controls, where the angle of attack deviates from the perpendicular to the wing plane. While there may be slip occurring the common word for the behaviour we are seeing is 'weathercocking'. This refers to the tendency of aircraft parked on the ground to point into the wind as a result the reaction of wind forces on the vertical stabilizer vs friction forces against the tires. However weathercocking is not used to describe the behaviour of aircraft in the air as it does not occur in the air... I would still want to avoid the word 'slip' however as it describes something that is possible, this behaviour is impossible. However back to the matter at hand, having loaded the mission and experimented there is no argument from me: this is a bug.

A strange thing to say given that transport category aircraft routinely fly in the north atlantic jet streams which are considered slow when 'only' 100kts, and that the North Atlantic tracks are updated daily to either take advantage of (eastbound) or avoid (westbound) them... You can see from today's map that the eastbound jetstream varies from 100kts (two triangles) to 140kts (two triangles, 4 lines). An aircraft in flight cannot possibly want to turn into the wind - or away from the wind, or at all - as there is no difference to the aircraft between travelling at 500kmh IAS in a 250kmh wind, and travelling at 750kmh IAS in a 10kmh wind. The high wind speeds are exposing a bug that is masked under slower conditions. Please do check further.