scoobie

Thanks a lot, very much appreciated! Yeah, I can see how you did it. Your files are very tidy, pleasure to read, but your linearization is hand written code. My idea was slightly different - to have a generic function that works on data copy-pasted from mainpanel_init.lua. Now, my problems I mentioned above... the function seems to work, by and large at least, it does linearize. I've just been testing a bit and it seems the reason for my "freezes" is that the script "chokes", as if it didn't have enough time to run the code. I've written a few "patents" for my P-51... maybe too many? I'll try to figure it out, I'm a noob in all this. I'll quote the function here - if anybody likes it or wants to build on top of it, or can come up with something better. Or perhaps points mistakes/bugs? The loooong prologue tries to explain (in broken English) how to use the function - see "Example use". (Sorry for strange naming convention - I come from a different world.) -- Linearize() by scoobie (disclaimer: I don't undestarnd Lua!) -- Recalculate steam gauge's needle position into a final value, e.g. gallons of fuel, indicated airspeed etc. -- (Don't call this function if the gauge's scale is linear - in such case just recalculate the value on the fly, single linear formula.) -- Parameters: -- current_value - a variable, typically from 0.0 to 1.0, which indicates "angular position" of the gauge's needle. -- You should find this variable in mainpanel_init.lua in your module's directory (in Cockpit\Scripts subfolder). -- raw_tab, final_tab - these should be taken from mainpanel_init.lua. -- Typically the whole part of mainpanel_init.lua with these values looks something like this (example only): -- [QUOTE] -- -- Fuel contents gauge -- FuelReserveMain = CreateGauge() -- FuelReserveMain.arg_number = 109 <- THIS IS YOUR current_value, retrieve it this way: mainPanelDevice:get_argument_value(109) -- FuelReserveMain.input = { 0.0, 40.0, 100.0, 150.0, 175.0, 200.0, 225.0, 250.0, 264.0, 270.0} <- THIS IS YOUR final_tab -- FuelReserveMain.output = {0.000, 0.144, 0.347, 0.506, 0.599, 0.666, 0.753, 0.828, 0.877, 1.000} <- THIS IS YOUR raw_tab -- FuelReserveMain.controller = controllers.FuelReserveMain -- [/QUOTE] -- Note that in mainpanel_init.lua the logic is reverse - input is for us "final", output is our "raw". This is because the module does -- the opposite job. The guts of the module operate on pretty mathematical formulas and don't care about gauges in the cockpit. -- Then, the result of their work must be "projected" onto gauge's faceplate, which may be non-linear. -- As a side effect, we are forced to do the exactly opposite job here - recalculate the non-linear gauge into a pretty linear value. -- -- Rewrite these tables to your export script. -- -- Return value: number, the final value (e.g. US gallons of fuel, miles per hour of IAS etc.) representing current needle position. -- -- Example use (according to the above quote): -- final_main_tank_table = {0.0, 40.0, 100.0, 150.0, 175.0, 200.0, 225.0, 250.0, 264.0, 270.0} -- respective US gallons -- raw_main_tank_table = {0.000, 0.144, 0.347, 0.506, 0.599, 0.666, 0.753, 0.828, 0.877, 1.000} -- variable value -- ExportScript.Tools.SendData(2155, string.format("%d", ExportScript.Linearize(mainPanelDevice:get_argument_value(109), raw_main_tank_table, final_main_tank_table))) -- function ExportScript.Linearize(current_value, raw_tab, final_tab) if current_value <= 0 then return 0 end for index, value in ipairs(raw_tab) do if current_value <= value then local ft = final_tab[index] local rt = raw_tab[index] return (current_value - rt) * (ft - final_tab[index - 1]) / (rt - raw_tab[index - 1]) + ft end end -- we shouldn't be here, so something went wrong - return arbitrary max. final value, maybe the user will notice the problem: return final_tab[#final_tab] end The one with the very very light grey panel and on Stream Deck with green text. It reads "Alt (AGL)" and 73 meters - which seems a spot-on value, while the radalt is heavily non-linear. As for the F-16, I wish I could help, but I don't have the Viper (yet).

Nice job! Yeah, you could come up with some unified ID's for such values (buttons) and then adapt all neccessary export scripts to that (so you can then just copy-paste a button in Stream Deck from one plane to another, if I understood you correctly) - good idea, actually, I think I may steal it from you! BTW, are you from an "imperial" country, by any chance? I'm asking because... uhm... no offence, but recalculating meters into kilometers is slightly superfluous Metric system has some advantages - that's one of them. But yeah - whatever floats one's boat, none of my business, I know, no problem. How did you "re-linearize" radalt on this plane? I'm asking because I wrote a dirty function for such things, but I'm a Lua Idiot 2nd Class (certified!) and for some reason the data displayed on the button sometimes "freeze", for a minute or two, and then "defreeze" and start working again without my intervention. I have no idea what bug it may be, I need to investigate. It must be an issue of type: "Lua doesn't work the way you think it does". I haven't even read Lua specification and I've never been a software dude (firmware, low-level stuff - yes, software - no) so for me Lua feels a bit exotic. So, perhaps you have something that works? Turning a non-linear value back into a linear one? These values are like "angular position" of the gauge's needle, while the problem is the scale is non-linear, so if you read such value, you can't simply recalculate it into final units (you'll get rubbish), you must first make it linear.

Thanks, grafspee! Naah, how can it (the take-off) be impossible if other people can actually do it nicely? OK, I'll try other methods then. 109 was my first warbird, then I bought them all (except for the Ishak) and have now many more hours in them (counting collectively, that is), so perhaps I no longer need my procedure aimed at beginners? No, I'm not the one to complain that this or that plane feels difficult to deal with - I have already noticed that it's just a matter of time you devote for the aircraft, learn/discover what she demands from you and adapt to that. It's actually great fun!

Do you know if the tail wheel friction was reduced since... around Q4 2020? I'm asking because now I'm having problems with my own "procedure" for take-off I gave a few posts above in this thread. It used to work for me, but now when I give her 0.8 ata to peacefully get up to the speed where rudder becomes effective without veering off the RWY centerline too much (and without tapping the right toe brake)... 109 can now drift to the left quite a lot, often too much. So my procedure is now broken, doesn't work so nicely anymore.

Unbelievable! How can anybody forget the module after a few months of not flying it!? Well, I can Anyway, sorry for the drama and thanks for additional insight!

Thank you, Weegie... but you are being too generous for my clumsy buttons, really @LeCuvier Weegie explained it all, but I may add one thing extra: with a little bit of Lua programming (modifying the so-called "export scripts") you may squeeze even more "juice" from this plugin than it allows out of the box. You don't have to, but you may. It's actually quite easy. @nosaMtrevoC showed what can be done with it in his profile for the Tomcat Yeah, CB's on Anton... AFAIK Kurt Tank was an electrical engineer, that may explain the obscene number of CB'S on Anton and the fact that lots of things that were hydraulic on US planes (or pneumatic on the British ones) were electric on Focke-Wulfs. EDIT: Oops... it's the Jug's forum. Sorry! In that case a screen from my P-47D-30 profile. There's only one CB here, but an important one - the one that likes to pop if you turn on too much cockpit illumination (as a result your oil pressuretemperature gauge dies, too). In the picture in the pushed-in state. When it pops, it goes red.

To continue this little off-topic... Can't see the contents Weegie linked, but - same here! Stream Deck is just perfect for bindings such that you don't want to squander "good" controls for them (joystic buttons etc.), but you still want to control them and (maybe) see their state. For, say, "second class" bindings. A few dirty screens from my Stream Deck - for Kurfurst, Anton and Dora. As ugly as my icons are - all these buttons work (in the pictures all are in the "off" state)

As far as the version is concerned, I may be well wrong. Recently I've been flying the English beauty and the Jug, so the 109 was gathering dust for quite a while. It might have been some previous update where this change was introduced, I can't be sure, I admit. Confirm! Both things. As for the other phenomena you mentioned - I wasn't careful enough to notice. I'll give it a go again. EDIT: Couldn't check the airspeed, because... I killed the engine sooner. Twice Just to make sure - the "scenario 1" is MW50 off (at least for me), where strange things happen. I have no complaints about "scenario 2" with MW50 on - it seems to work as it always used to. MW50 OFF is where things are now different. (I hope we're talking the same thing.) I know 109 was "revisited" some time ago - for example the pump control lever was changed to axis and bodged in the process (@pmiceli provided a workaround in another thread), maybe there have been some more "collateral damage" to the module? I don't know, but it's definitely DIFFERENT, so if there was no plan to update/upgrade 109, apparently it is some unintended change. Just my $0.02 of guesswork.

Hi, I might have broken down my Bf 109 or the newest update introduced some changes. IIRC, previously in 109 you could enable/disable MW50 with the switch and when it was OFF and you moved throttle full forward, ata was... can't remember, 1.5 or something. If you then switched MW50 on, you could hear that sudden roar and ata jumped to 1.8 or so. Simply put, there was obvious, clear difference between MW50 working and not working. As of today, my Bf 109 works differently, like this: 1. MW50 switch OFF + move throttle slightly forward from nearly full forward to exactly full forward: The roar kicks in (why?), ata abruptly jumps from 1.45 to 1.8 (why?). MW50 pressure gauge shows 0. 2. MW50 switch ON + move throttle as above: The roar kicks in, ata abruptly jumps from 1.45 to 1.8. MW50 pressure jumps to 0.6 kg/cm^2. Point 2 above works as previously. Point 1 - does not, is now different. I have noticed only one difference - if you keep throttle full forward and turn MW50 on/off/on/off/etc. - there is slight slight difference in sound and Kommandogerat changes prop pitch (makes it coarser). Probably it changes pitch not to overrev the engine because of the increased boost, but there is no increased boost - ata is identical in both cases (close to 1.8). Do you have an idea what might be going on here?

Oh, OK... so it's high flow that does the trick. The temp. difference argument makes a lot of sense (thanks!). It just felt so, you know... super quick, hence my question.

I was looking for a similar thread, but couldn't find anything. While I have learnt to deal with cowl flaps in Dora, there's one thing that makes me scratch my head. I'm not claiming it's a bug or something, I just don't understand the thing. On the ground, you may close/open cowl flaps and have to wait a while until you see influence on coolant temperature. That makes sense to me. Now, in the air, when you "tune" cowl flaps to set coolant temperature at around 100°C, it takes literally 2 seconds for the temperature (as read from the temp. gauge) to jump up or down by a few dozen degrees Celcius. YES, I'm aware that lots of air is now flowing through the radiator (unlike when on the ground), but still... the response is so crazy fast. How's that possible? Only part of the water is in the radiator at a time, the rest is in the engine, hoses etc. Water can't flow through the circuit with at a "waterfall rate" (I think) because the radiator is made of tiny tubes etc. Even the very thermometer (coolant temp. sensor) - its response must be very fast to indicate such abrupt changes in temperature, so what did they use? I don't know what sensors they were using back in the day, but it IS very fast. I know thremocouples can be this fast, but they're rather difficult to use without "proper" electronics. Nowadays not a problem, but in 1940's? I don't know. My head's spinning. I know it may be all rubbish, what I'm saying, but where am I wrong? Can the the cooling system be this quick?

I know it's not much of your personal opinion, more like thinking loud, so please don't take it personally. I'm arguing arguments (not exactly yours, I guess). It it NOT equally valid, because it is clearly inferior. Fortunately ED are well aware that DCS is mainly being written (not only, but mainly) for rivet counters, otherwise other software products would look better: low (or lower) price, lots of planes included, planes are balanced for "rewarding multiplayer experience", this that and what not. I'm not laughing at that - if that's what someone likes, great - go get it. Many do and they're happy campers... even to the point where a specific "fly game" is merely a Super Mario in aeroplane's disguise. Pesonally I find such games revolting and I'd rather spend my time picking my nose than "flying" Super Mario, but while some people hate spinach, others like it. No problem... No problem... until another messiah who "genetically knows better" comes and tells you to like (and shut up) someting you hate. (I'm talking about denigrating rivet counting.) This place here feels like an oasis for a minority of forever grumpy "nitpicky bastards" a.k.a. "rivet counters", freaks, nerds and other highly suspicious types. Actually, at least part of ED people belong to that bunch, too And you can actually enjoy DCS and scream about the wrong number of rivets at the same time, that's normal. Now, the argument that since you can barrel roll and loop (and do other "stupid sh*t"), it's equally good if we can "just fly it and navigate it" is wrong, too. Flying outside of envelope, going ballistic etc. has been a very general problem in sims since I can remember. I'm not saying it's cool that you can do loops, no (although there are serious technical problems on the way if you want to overcome such limitations), but if flying WITHIN the envelope is borked, it's worse by a 100 miles. Simply put the argument is this: "Since we don't get FM's 100% accurate, than 30% is as good as 60%". It's not. 0.6 is bigger than 0.3. Twice bigger. What's the point in arguing about it? Here folks agree to 60% correct, hardly, just because they can't get any more elsewhere (but they keep ranting that 70% would be, barely, acceptable minimum - which is normal, too), but if someone wants them to agree to spinach (30%) because it flies nice, you can navigate and so on - it's disgusting. There are great spinach games elsewhere. And ED must be perfectly aware of that, and besides... they don't seem to like spinach, either. I mean personally, even if we put business matters aside. So, the point is: if you like 30%, NO PROBLEM. But if you tell those who "outright demand" 60% to shut up, it is a problem. Disclaimer: I took 30, 60 and 100 out of thin air.

All these are exactly my thoughts! Yeah, if you read through these forums you get a skewed picture, because people here focus on problems, not praise. In part it's the very purpose for the forums (bug/problem reporting etc.). As Hiob pointed out above, people sometimes go very emotional about the problems EXACTLY because they care. You don't get emotional about dog poo on the lawn (maybe unless it's your lawn and it wasn't your dog, haha). You just shrug and go on with your life. Folks care because the sim is really good, so they want it even better. And better. (And - yes - then better some more... ad infinitum). I think the fair "test" for DCS is to check it once a year, perhaps on New Year's Eve (preferably before you have your surplus of drinks ). For example, watch youtube videos with DCS 1.5, then 2.0, then 2.5.6, now 2.7. Not enough? - see LOMAC, Flanker 2 or Su-27 (the game) - I could point a few differences You can easily notice what amount of work is put into DCS every year. Now, if you think it takes a little long (or just "too long") to have all these new features implemented, take into kind consideration that ED is not the former MS Aces Studio (5000+ people). They really must be working very hard to achieve all this. To all hard working people I invariably salute! So, big "thank you" to ED from me, too!

It is, both in Jug and Pony. My short slogan for this (otherwise I keep forgetting): "PULL, TAP, RELEASE", i.e. pull the handle, tap the toe brakes (fully), realease the handle.

Sorry for a little OT, but... what exactly are the proper names/phrases for Vx/Vy? Back in FS2000/FS9 times I was told/tought they were "best angle of climb" and "best rate of climb". Did pilots in WW2 use different phrases for these? I would just like to use correct terms, not fruit of my own imagination.

I think I might know what @peirof has in mind... One may call it "a problem", but I don't. Trouble is that PC keybords have too few keys for DCS, piano keyboards would be better, but some people have too small rooms to fit a piano for DCS. That is the true problem - more people should have pianos! The snap views become persistent only after you rCtrl-Num_0 first (and another rCtrl-Num_0 turns this "persistent mode" off). Personally I deal with it by means of macros in Joystick Gremlin. When I press a button on my HOTAS (typically I use "radio hat" on my TM Hawg throttle), it presses the following keys: Press rCtrl Press Num_0 Release Num_0 Release rCtrl Press Num_X (where X the number of my snap view) Release Num_X The snap view persists until I press the button again (this exact button or another "persistent snap view" button - for some planes I have 2 or 3 of them). Yes, it's a little bit of work to have it all arranged like this and yes - you do need external software for that (I use Joystick Gremlin + vJoy, though I'm sure one can use any similar software, there are quite a few out there). Also... please note that you DON'T need such views in all cases. You may want such a view to interact with a specific control (knob/switch) with a mouse. In such cases, I guess, you need this "persistent mode". But if a specific view is only meant for you to have a glimpse at some instrument (to read its indication) etc. - these can be momentary, so no such macros are required for them. PS. In reality I don't have such complex macros as above - I assign bare Num_0 to have the same funtcion as rCtrl-Num_0, so it's a bit quicker for me to set up these macros - but it's not mandatory, it's just my way of doing it. EDIT: Sorry, just in case - I know piano keyboards have fewer keys than PC keyboards. It was just a groaner joke

PROCEED AT YOUR OWN RISK! (I've just discovered it, I don't know if there may be any negative side effects, dependencies etc.) It seems that the annoying sound the OP mentions comes from this file and is played in "slow motion": <DSC install dir>\CoreMods\aircraft\I-16\Sounds\Effects\Aircrafts\I-16\PlaneWingTurbulence.wav I have renamed it to "PlaneWingTurbulence.wav_ORIGINAL_BAD_HUM" and the annoying sound is gone. Of course expect these: 1. With every DCS update you'll get a new copy of the original file, so you need to have a solution for that - some people use mod managers or version control systems etc. 2. This file will NEVER play, neither when it shouldn't, nor when it should.

Beautiful! Thanks for letting me know. Mod installed & works.

I'm sorry if this was asked before, but maybe someone knows: 1. Would pilots IRL replace maps (on the "moving map" device) during the flight? Seems bothersome a bit (though doable, I guess). 2. How come the plotter aligns automatically when you change scale? You can check this even if one of the maps is all black, doesn't matter. Fly away from the plotter's center position, switch scale back and forth and the plotter jumps. It just... how can such a device work like this? It looks like a simple (smart but simple) plotter driven by DISS, nothing else.

We may be talking about the same, but I'm not sure, so... While up/down Lua commands do normally react to a "slope", i.e. off/on and on/off transitions, when you have "sync. controls" option on, at the mission start DCS reads your latching switches, but only those in the physical "on" position. It seems to be ignoring switches in the "off" position - instead they are (in the cockpit) set to their "default" state for a specific aircraft configuration ("on" or "off"), for example, in a cold & dark state. A kind of assymetry, that's how it looks to me - "ON" will be sync'ed, "OFF" won't. Is that what you're talking about? (I feel I may be mistaken). With axes it seems to be the same thing - axes aren't "read" on mission load, but set to the "default" state proper for a specific configuration of the aircraft (different for cold & dark and for "start in the air" missions), so you need to move them up or down to make DCS read their physical position and only then the plane gets synchronized to your throttle etc. For joystick (stick), I believe we don't see this effect only because the "default" aircraft's state at the mission load is stick centered - and yours is centered too. So at the mission load it's good (but incidentally!), and when you only touch it, its value (X or Y) is immediately read and it's still good. The question is... is this effect more bad or more good? It does, in a way, ensure your mission starts properly, i.e. even if your controls are in bad positions, nothing bad is going to happen immediately upon the mission load. Maybe this way of thinking stands behind this feature? What troubles me more, however... maybe it's just something messed up on my end, I don't know... It seems that this effect happens also when you switch to external view (F2) and then jump back to F1, the latching switches kind of forget where they were, you need to "wake them up" as LeCuvier calls it. I'm not sure if it's always the case, but I'm seeing this at least often. I like F2 (and F3) to watch my shiny pretty plane Anybody else having this, by any chance? I'm hoping that I have just messed up my options or something and it's repairable.

+1 Oh, I'd love that, too! I enjoy Russian a lot in my Mi-8. I enjoy English a lot in Amercian birds. But when I'm sitting in my badass/cut-throat Bf 109, my name is, say, Johann Schweinsteiger and I hear over the radio: "Spingfield-1-1, taxi to runway 10" (etc.) it's a little bit of a turn-off (SimiliarilySimilarly... I find absolutely fantastic the "theme tune" for... I think it's Anton (?) - that proper German march. Or at least it sounds German enough to me. Great stuff!)

Utterly great idea! With one change, pretty please: for speeds it's not "metric vs. imperial". There are three units: km/h, mph (statue miles per hour) and knots (nautical miles per hour). EDIT: (Yeah, with "plane-automatic" system of units it becomes irrelevant, I just wanted to point out just in case that there are 3 units, not 2).

As for seeing the very flaps (in automatic or not), you can actually see them, provided you're flexible as a snake (and have TrackIR with quite a bit of "amplification" in "lean left-righ" axis; I think VR could do the trick as well). If canopy is open, you may stick your head outside the cockpit left or right and see them. If canopy is closed, you can kind of bend yourself over the gun sight and see the flaps from above. However, I find it not so much neccessary as during flight you simply set flaps looking at the coolant temperature gauge (it seems to "snap" into automatic at about 100 °C, as grafspee explained). I also found TM Warthog throttle to be helpful helpful here. I assigned autopilot mode toggle switch to cowl flaps. It's a latching switch - that's the trick (double latching: ON-OFF-ON). During start-up & warm-up, cowl flaps are to be closed so I flip the switch and leave it there, so I'm guaranteed flaps remain fully closed and I don't have to think about it. After the warm-up - flaps must be open, so I flip the switch into the opposite position and - again - I leave it there. Then, after the take-off, you need to play with the switch a little bit until the tempertarute settles at about 100 °C (automatic mode kicks in, so it seems) and leave the switch in the off position (the middle one).

(I've rewritten this post.) Sure, no problem! This Orbweaver thing looks really handy. There are, however, two differences between Stream Deck and a keyboard: 1. You can have labels/icons under each button appropriate for the aircraft you're currently flying (say - different UFC's for A-10C and Hornet). So you always know what the button you're pressing does. 2. WITH the plugin I mentioned, Stream Deck becomes a bidirectional device. It can both send your button presses to DCS and read data from your aircraft in DCS - which you can display. A sample of what it can do is in the thread linked below.

I know it's not what you're asking about, but if one day you have a few bucks to spare - check the Stream Deck XL. This gear + the DCS plugin from @ctytler and you'll be in heaven. It's such a versatile bit of kit. Doesn't replace your throttle/joystick/etc., but complements them beautifully. For example - it's great for UFC's. The advantage over a "tap-screen" is that it's got physical buttons, so you don't have to "aim" your finger. Fingers are somehow better with physical buttons than tap-screens. At least mine are. (Of course tap-screens have the advantage of no boundaries for specific controls, you may define various "tap areas" freely, while the Stream Deck XL has a fixed set of 32 buttons, each of the same size, with LCD screen below them.) EDIT: and it's got a proper enclosure! It firmly sits on the table, no need for "holders" or any contraptions of this sort. Moreover, Stream Deck is often a rescue when a specific DCS module lacks appropriate key/button bindigs (lacks in such a way that you can't even add them yourself in the Lua files). For example, currently in the Viggen you can't have "bomb interval increase/decrease" - you can only have 10 (or 12 or so) buttons/keys for each position of this rotary selector. Enter ctytler's plugin for Stream Deck and it becomes possible! You spare one Stream Deck's button for "bomb interval rotate CW", another for "CCW" and on one on these buttons you may (if you like) "print" the current selected position of this dial. And it's all easy to set up. You can also (for more advanced users) do a little bit of easy Lua programming in the "export scripts" to achive things not possible to achive in a specific module out of the box. It's a gorgeous supplement for your flight simming kit. PS. No, I don't work for Elgato, I really like this thing PS. Fun fact. It's actually my invention! Pay me huge royalties! I came up with the idea of Stream Deck in the early 80's... but the technology wasn't quite there at the time. Damn. So great it's become possible nowadays. All you need to do is just buy it. Easy!