scoobie

Yes, F-14A-135-GR.lua works just fine. First of all, big thanks to @nosaMtrevoC for taking the time & pain to prepare the file! Very much appreciated! Now, down to the business... Have anybody cracked airspeed in Tomcat yet? Couldn't find it in F-14B.lua. If not, I THINK I kind of did it, but not very "cheaply", so proceed at your own discretion. I tried the least squares approximation, but didn't like the results (square and cubic polynomials, didn't look higher than that). So I stayed with my crude polygonal chain approximation (I think that's how you call it in English, but I'm not sure). I used var. number 2504, it seems to be free to take (I hope!). Single KIAS (ones) are "trembling" a bit, so you may want to filter them out, or you can leave them, as you wish. Seems to work fine, I've just done it and I'm still testing. I you want, put the pieces of code at the 3 places (hints below). Ellipsis "(...)" means "some stuff of yours is probably here". ExportScript.ConfigEveryFrameArguments = { -- (...) [2129] = "%.4f", -- scoobie, what's this? KIAS needle maybe? YES! -- (...) } function ExportScript.ProcessIkarusDCSConfigHighImportance(mainPanelDevice) -- (...) local x = {0, 0.057, 0.1, 0.141, 0.212, 0.328, 0.427, 0.518, 0.588, 0.646, 0.731, 0.801, 0.867, 0.915, 1.000} local y = {0, 80, 100, 120, 150, 200, 250, 300, 350, 400, 500, 600, 700, 800, 1000} -- 1000 KIAS is fake just to fill the range ExportScript.Tools.SendData(2504, string.format("%d", ExportScript.Linearize(mainPanelDevice:get_argument_value(2129), x, y))) -- (...) -- somewhere at the bottom of the file: function ExportScript.Linearize(current_value, raw_tab, final_tab) -- (c) scoobie if current_value <= raw_tab[1] then return final_tab[1] end for index, value in pairs(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

Beauty! Thanks, draconus. The weekend is coming, I'll try and report back. EDIT: Changed to channels from the white area in the chart above: carrier 41X, Texaco 43X, Arco 45X. I still got "Y" in the kneeboard for tankers (picture attached). Of course all the stations do actually work on channels prescribed in the mission. Well, I heard somewhere that flying TACANs are "usually" Y, but I thought it was a kind of a rule, "social agreement" let's say, not a technical requirement. Anyway... I've now changed my airborne TACANs to "Y" and I'll leave it like this. Y work (show as "Y").

Hi, folks! Just bought the Kitten Similar issue on my end, i.e. I know the kneeboard must somehow "suck" TACAN channels ouf of the mission, trouble is - there may be something wrong with it. I admit I have absolutely no idea how one assigns channels to tankers and carriers IRL, so in my mission I just set 11X for a carrier, 13X for KC-130, and 15X for KC-135 (it is a "big mess for doing everything" type of mission - you can AAR, do this/that etc.). Now, the kneeboard in my Tomcat showed this: 11Y - carrier (instead of 11X) 13X - KC-130 (correct) 15Y - KC-135 (instead of 15X) That's off the top of my head, but for sure in two cases the kneeboard claimed it was "Y", while it was "X", and for one of the three the channel was all correct. The numbers alone (11, 13, 15) were correct for all three of them. Maybe that's not a big deal, but I like a lot how Heatblur folks explore the kneeboard functionality in their modules (especially in the Viggy, where it's super important), so it would be cool if everything worked correctly there. Or maybe the code for the kneeboard went haywire because one cannot assign "X" channels for moving TACAN stations? Or something of this sort? I really don't know.

Solved for me! Thank you very much, @admiki! I'd never figure it out myself. Tried a couple of times w/o touching pedals - worked each time. Does it mean it's permanent? - dunno yet, but so far so good.

Hi, I'm super new to Hind, I've only had a few rides, so I don't if this is a side effect of some RL system operation ("correct as is") or it's a bug. However... watch the pedals in the cockpit and you'll see what's going on! At some point during start-up from cold & dark, the right pedal (I think it's the right one) starts moving forward on its own, in such funny jerky steps tick-tick-tick-tick... it moves all the way forward and so she starts spinning around. In order to prevent it you simply need to tap any of your pedals, this automa-tick-tick-tick will stop and pedals (in the cockpit) will miracously recenter. I suspect that when this phenomen is NOT occurring (sometimes), it is when you (or I) have already tapped or moved the pedals before the tick-tick. (It never happened to me after landing, though, so I don't know.) EDIT: Wait... "rudder input does nothing"... it does cure my Hind. Maybe they are two different cases - yours and mine. Also... since trim reset helps (I never tried that), maybe it has something to do with "rudder trim" option turned on in "Special" menu? I have it on. I'll see if turning it off changes anything.

FWIW... a simple take on drawing arrows. @Flamin_Squirrel - I think you've drawn too few arrows on this nice drawing you attached above. I've added arrows at the wingtips to your drawing (sorry for cr*ppy quality). Now blend the two pictures into one. The fuselage wants to go up as much as go down, so it stays where it is, but what about the wingtips? The arrows add up, right? I suspect this contraption wants to roll.

Hmm... OK, next time I'll try to "escort" such a zombie (after shooting at him) and see how he's doing in the long run. Formation flying with a bandit... interesting idea! So far, for such quick dogfight fun/practice missions, I've been using "unlimited weapons" and kept shooting at a damaged AI warbird for as long as it takes to finally turn it into a fireball, kill a pilot or persuade him to bail out. Maybe I just need to be more patient. Still, it feels pretty straightforward to shoot down a B-17 (with their gunners' ammo set to 0%) - as compared to AI fighters. You just spray bullets on it and when 2 or 3 engines are on fire, they decide to bail out. And it's easy to set their engines on fire. No zombie mode (IIRC there used to be zombie mode in B-17, but it was fixed). OK, I'll gladly do more testing, it's just... it's just I want the AI bastard to go down NOW, it's annoying when they don't want to And when I'm flying against a German bird, I imagine the pilot in the zombie plane is singing: "Heeeeidi heeido heida!", despite all my efforts to shoot him down, which is even more infuriating As for the missiles, I thought that "missle resistance" just proves the point that there's something wrong with AI warbirds damage model in general, i.e. they're too tough.

Yeah, AI warbirds are like this. They LOOK damaged (cool!), but they oftentimes fly just fine regardless of that. I call it "invincible zombie mode". No, it's not about the Spit, really, other warbirds can do this trick as well (at least most of them, I can't remember all). Maybe it's a side effect of their simplified UFO-FM? IDK. I hope it's on the "TO DO" list somewhere in ED. P.S. Regarding your AMRAAM experiment... P-51, for example, is also relatively likely to swallow AIM-9 (I tried these) and survive, at least much more likely than a jet.

Small appendix: I can't pinpoint it now - no matter what I'm doing, my new bindings always land only in the "SpitfireLFMxIX" folder (not "CW"). However... a small piece of evidence that SOMETIMES DCS chooses the "CW" folder instead: I bought the Spit on 10/31/2020 and files in the SpitfireLFMkIXCW (this time "CW") have identical modif. date: 07/25/2021 20:21:44 (waay after the purchase). One of the files contains, for example, a very specific binding for my homemade button/pot box: ["a3039cd1"] = { ["added"] = { [1] = { ["key"] = "JOY_RX", }, }, ["name"] = "Altimeter Pressure Set (analog)", }, so it's clearly NOT a default binding. I remember doing it as an experiment, this binding can only be found in the "CW" folder, so... DCS picked "CW" folder on that specific day, while it seems to normally "prefer" non-clipped Spit folder... or at least it consistently chooses this one today. Anyways, it only proves the folder selection mechanism is somewhat erratic and this is, I guess, when people experience problems - one day DCS selected folder "X", the player makes bindings. Then, on other occassion, DCS selected folder "Y" where these bindings don't exist and the user says "WT... my bindigns are gone!". Must be something of this sort. Anyway, it doesn't matter much - the main problem is that there should be two categories in "Controls" window - one for non-clipped, one for clipped. Then all problems should go away.

Hi. Either I'm missing something or there's one obvious bug. On one hand, you (or I at least) only have one Spit in the drop-down list in Controls window - see the picture. On the other hand, I have two folders for the Spit in Saved Games\Config\Input - another picture below. How can DCS know which Spit I have in mind when I'm assigning new bindings, if I have a common "category" for both of them in the Controls menu, while there are separate destination folders for each? This very thing must be a bug. There should be TWO categories: "Spitfire LF Mk IX Sim" and "Spitfire LF Mk IX CW Sim" (or something like this). I have never modified files in these folders manually, but... the contents in each are different. Files differ and have different modification dates (different between the two folders, but identical for all files in each). In both folders file contents are credible (no garbage) and it looks like I was tweaking axes sensitivities, adding new joystick bindings etc. I DID have problems when my settings from the clipped version didn't work in the non-clipped version and/or vice versa. I had these problems only sometimes, not every time. My blind guess: the destination folder for clipped/non-clipped version is selected appropriately when I am or was flying a specific version, but when I haven't flown any since DCS start, it falls back to some "default" folder (one or another, depending on how the code is written). Or something of this sort. P.S. I think there should be two Spit versions (clipped/non-clipped) in the Controls window and not one common folder in \Config\Input instead, because people may want to have different sensitivity for example for roll axis.... e.g. more sensitive for non-clipped (the "lazy" Spit), less sensitive for clipped (the "impetuous" Spit).

This is splendid, thank you! I'll plough through it right away. No, no - no need for Notepad++. If anybody can touch type, I can recommend Vim - a modal editor (today a forgotten term). I've been using it for years and now couldn't live without it. Gee... I must learn to read. For file comparison/merge I normally use Kdiff3. Thanks again Now... it's not that I'm trying to "convert" Cpt. Orso, but I thought I could just emphasize that in practice one doesn't have to really operate that "external software for joysticks", on a daily basis. I don't need to launch it, configure it, select profile or whatever - not at all. Here's how it's possible... For hardware-related reasons (actually it's bugs in Win10 USB support, not hardware), I launch DCS from a batch file. I just have to. Since I do it either way, I can add Joystick Gremlin to it, so it launches together with DCS. Now, for all warbirds I have a common "profile" (smartly named "warbirds.xml" ) in Joystick Gremlin. It's easy as warbirds aren't "controls intensive", they're not flying computers. The batch file launches the Gremlin, the Gremlin hops into Windows SysTray and enables the last used profile (warbirds.xml). I don't have to do anything, it's all automatic. I quote this batch file if anyone's interested. It looks a bit over the top, but this is because I'm doing more things there. So... the point is IT'S NOT AS BAD AS PEOPLE MAY THINK, really @echo off echo Restarting Leo Bodnar... pnputil /disable-device "USB\VID_16C0&PID_05B7\A01232" pnputil /enable-device "USB\VID_16C0&PID_05B7\A01232" echo Starting Stream Deck... start "" "D:\Elgato\StreamDeck\StreamDeck.exe" tasklist /FI "IMAGENAME eq joystick_gremlin.exe" 2>NUL | find /I /N "joystick_gremlin.exe">NUL if "%ERRORLEVEL%"=="0" ( echo Joystick Gremlin is already running. ) else ( echo Starting Joystick Gremlin... start "" /D D:\Gremlin joystick_gremlin.exe ) tasklist /FI "IMAGENAME eq TrackIR5.exe" 2>NUL | find /I /N "TrackIR5.exe">NUL if "%ERRORLEVEL%"=="0" ( echo TrackIR is already running. ) else ( echo Starting TrackIR... start "" "C:\Program Files (x86)\NaturalPoint\TrackIR5\TrackIR5.exe" ) echo Starting DCS... start "" "D:\gry\DCS World\bin\DCS_updater.exe" timeout /T 7 rem pause

Haha... out of dispair I added "released" command in the hope that it would work as a pair to "pressed" But no, of course - DCS is oblivious of the word "released". "pressed" is meant to be alone. I never do auto-start/stop and have never looked at how it works in Lua files, so if you ask me - YES, PLEASE, share the method (if only you can find time to do it)! Your tips really help people. I don't know if Capt. Orso is insterested too, but I for one am. Alternatively, you have this (relatively) new thread in "Guides & Tutorials", the one with the guide in PDF and your Lua commands for various planes. Great stuff, BTW! I guess that place could be better for this, people could find all the knowledge at one specific place.

Well... you can also use the patent invented by @LeCuvier. His patent was meant and works nice with switches protected by a cover, but for bomb dropping it comes with an undesirable side effect. When you release the button that has just dropped left and right wing bombs at the same time, the right handle will stay up (pulled)! So if you're going to then land and get another pair of bombs, you will have to have another binding for "Jettison Right Wing Hardpoint" - using it will lower the handle again. It may be a key on the keyboard or whatever. So yeah... it's better than nothing, but not quite a solution, I guess. {pressed = device_commands.Button_9, down = device_commands.Button_8, up = device_commands.Button_8, cockpit_device_id = devices.WEAPONS, value_pressed = 1.0, value_down = 1.0, value_up = 0.0, name = _('Jettison Left And Right Wing Hardpoints'), category = {_('Weapons'), _('Input.Generic.drop_ordnance_arming_panel')}}, PS. Yes, me English be rudimentary. Sometimes I get what they're saying, sometimes I don't

Naah, I'd be hard to digest If you're using the Target software, I guess you can achieve the desired result as well. The main point is that ED said they were not going to implement this feature in DCS. I think I know why, but anyway... either there exists some smart trick you can do in some Lua files for the Jug (a trick I have no idea about) or you really HAVE to use some external software. Pick the one you like most, but it seems you have to do it that way.

AFAIK no, there isn't any way within DCS. Nevertheless, you may want to try external joystick software to create a "virtual copy" of your physical joystick button on a virtual joystick. Thus you get two buttons in the game (one is real, the other fake, but DCS doesn't know that), both are always pressed/released in tandem. Then you just assign one of them to drop the left wing bomb and the other to the right one. I do such things quite a lot, both with buttons and sometimes even axes. I'm using software called Joystick Gremlin (and "vJoy" virtual joystick), but I know there are more programs of this type out there.

Wow... you're right, "TrackIR external views" is the culprit, nice catch, thank you! (FYI: in the .miz file you attached it's still borked for me.) Yeah, it's a kind of bug. Moreover, the aiming sight seems to inherit TrackIR settings from gunner/operator settings. As I showed in the picture above, I deleted the bindings for the aiming sight, but TrackIR was still active. However, if I delete them from gunner/operator, TrackIR will then "die" (for both gunner/operator AND the aiming sight). Which means there's something wrong with settings for aiming sight. They were meant, so it looks, to be separate from gunner/operator, while they're not, they're kind of hardwired to the gunner/operator settings. Anyways, thanks for catching the culprit, I have disabled it for now. @TaygaMongun You're right, but just as you say - it's annoying and especially so if you have to use the keyboard to disable TrackIR (I consider my joystick buttons too "precious" for such low priority bindings).

Hi. As for the TrackIR in the aiming station - same here! Track included. I disabled and re-enabled TrackIR a few times (it's easy to spot when) so that I could illustrate the problem - the view follows TrackIR, but it's NOT where the station is really "looking" or where it would guide a missle. Only when you disable TrackIR, the view, after a second or two, snaps back to where it's really looking. Disabling TrackIR bindings in the aiming sight control setup didn't help, either (picture attached). hind_aiming_sight_w_trackir.trk

(I'm saying this off the top of my head, so please check this out in DCS for yourself.) If you insist on using an axis, then what @swatstar98 means for this case is, I think, that you need to LOWER the X saturation below 100% (Y at 100%, X at less than 100%), which is not something you normally want to do. The aim is to guarantee that when you push/move your hardware lever (or whatever you've got there) to the limit, the in-game axis is guaranteed to stay firmly at exactly 100%. Depending on your hardware, its age etc. it may actually never reach exactly 100% (only close to it) - which should be possible to fix by a re-calibration, or you may have a "noisy" potentiometer and your so-called "100%" may be actually "trembling" between, say, 99% and 100%, or worse. So, X saturation below 100% should prevent it. The tip or tips of the curve in "Axis Tune" window should be flat, horizontal.

Wy...w...wut?.... Why didn't anybody called me earlier? I had no idea such thing existed at all! THANKS! Ooo... this thing is cool... EDIT: THE FORUM'S GONE NUTS! Strange things are happening here since... 2-3 day ago. In my previous post my "EDIT" disappeard (the one asking about modelViewer)... but I haven't edited the post and deleted the text, the forum itself would show when I did it.

Just an update to close open questions. I did test it, it works, but actually I needn't have tested it If one looks around in mainpanel_init.lua for P-47 you can quickly find other gauges that have linear scale in the file, for example: -- Variometer gauge Variometer = CreateGauge() Variometer.arg_number = 29 Variometer.input = {-6000.0, 6000.0} Variometer.output = {-0.6, 0.6} Variometer.controller = controllers.Variometer while this gauge as seen in the cockpit is clearly non-linear (not a surprise in a VVI), so apparently the variable 29 is non-linear itself. As simple as that. Hence, everything works, I needn't have worried. Now, if anyone prefers lazy approach, modify the first "if" - to my (VERY SHALLOW!) knowledge of Lua it should be this: if current_value <= raw_tab[1] then return final_tab[1] end instead of this: if current_value <= 0 then return 0 end in this way the function should be good both for "unidirectional" gauges (going from 0.0 to 1.0) such as some airspeed indicators, fuel reserve gauges etc. and "bidirectional" (going, for example, from -1.0 through 0.0 to 1.0) such as VVI's etc. Without this modification it's good for the former type only. As for the Mi-24, it seems your numbers in the script are doing just fine, see comparison: columns A and B are from mainpanel_init.lua, while column C is what gets out of your code. Very good match until above 400 km/h - is this what you call "huge error"? If so, than nothing to worry about, technically there should be another "elbow" there, but since it doesn't matter as the pilot is just about to die (as you noticed above yourself), than yeah - it's all good

Absolutely! If all programmers used this rule, we'd live in a happy world. Doh! I completely forgot about this kind of gauges! Yeah, this absolutely prevents VVI from working with this function... oh, boy It can be repaired easily, I think. All it takes is probably just replace it with "if it's <= first_raw_value_in_the_table then return first_final_value_from_the_other_table". My code is basically doing what you are doing outside of the code. You look for "elbows" (vertices) in Excel and define these elbows as "if/else" (or if/elseif/else etc.), while I look for them in the code, running through the table (the "raw" table) stolen from mainpanel_init.lua. The other difference is that I calculate "a" and "b" for y = ax + b in the specific "range" - in between two adjacent vertices - in the code (equation of the line going through two points), while you feed "a" and "b" calculated outside of code. It's basically the same thing, though my "lazy" approach costs processor time, while you feed ready to use values directly in the code, so it's as fast as it gets. Good idea, the more I think about it the more I like it. I wanted to be lazy, but perhaps it's a bad strategy. Oh, and it may be bad for one other reason, as I can see now... I put those example tables from my code into Excel (picture attached). And look what happens... it's a freaking straight line for the most part! Except for the very top, where there's a single elbow/corner (I call them "corners", you call them "elbows", whatever). So I could simplify it to "one elbow" only. Damn... And it's not the end of the problems, I've just noticed. Something seems seriously wrong with those tables. I assumed that ED use polygonal chain (I think that's how it's called in English) to make non-linearity, which may or may not be the case. I can't check it now (I'll do that at home), but my example tables above I THINK come from P-47's fuel gauge - 270 gallons look like the Jug. If that's actually the case, it's all wrong. For example, the table says that for value = 0.666 (66% of the needle travel range, as I understand it) it should read 200 gallons. It doesn't. 200 gal is more or less in the middle (as if it was for value... about... 0.550 or so, 55% of the needle travel). Picture attached. Another problem... since this table defines, for the most part, a more or less straight line and - if you look at the gauge, 100 gal is at about 25% of the needle travel, then 200 at about 50%, 270 at 100%, so it's NOT a straight line at all. Hmm... maybe you have the correct answer to that - maybe the variable itself is non-linear, just as the arispeed in F-16 - which you have discovered. Excellent clue, thank you! I will check at home if this function works with the Jug's fuel gauge. EDIT: Wait... what is this "modelViewer"?

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.