scoobie

I have no idea (@Machalot) Thank you for all the clarifications! The "smudging effect" must be... I think... caused by the "persistence CRT" (I don't know how they were called in English) used in the Viggy to cater for the memory mode. So, without memory mode there should be no smudging and with the mode turned on... apparently there was some smudging (I've never used such scope, so I don't know exactly, I saw a few of them, but I must have been a teenager back then and such scopes were expensive - nobody would let me touch such "serious" gear). I think the smudging may be really hard to model in detail - I doubt there's a knight-errant in HB to go down such rabbit hole, the only gain would be... smudging in memory mode. That doesn't sound like worth the effort And that shows! Has anybody else noticed that near the "pivot point" of the beam sweeping the screen there's a small "missing" arc, like "cut out"? It looks the same in DCS:Viggy! Such a tiny detail. How crazy is that! Hm... since we're talking about these things... The radar screen could easily look more real if there was only one hue of green on it - they were all monochrome. There must be a graphics file where this attitude indicator "pattern" (those lines) is drawn - the lines should be the same hue of green as the radar return picture. In the current representation it looks fake from 5 feet away, or at least it looks fake to all the folks who were lucky to sit in front of CRT scopes in their lives... and a lot of them are still alive I attached pictures for comparison. I don't know if "rich green" in the second picture is a proper phrase, but it clearly is a different green from the radar picture - so impossible to obtain IRL. (To make it clear: of course it's no big deal, nothing to write home about, just a tiny idea for a cheap (if subtle) improvement.)

Whoa, wait... what's going on at 12:21-12:22 in the video? That "rotation" on the radar screen? I've never seen anything like this in DCS:Viggy or... maybe I've never paid enough attention to the radar screen. I don't have sound here, but I guess they're talking Swedish so it wouldn't help me anyway. It looks like the pilot turned on memory mode to sort out those ships, then the two lines at the sides started extending from the bottom of the screen (starting at around 12:13), which I think mean he started pulling up (?). Then the lines started "curving", which probably means he banked right as shortly afterwards you can see the compass ring started rotating. But he was still in memory mode. It just occurred to me I've never really used memory mode (other than a quick test maybe), so I don't know... Do we have such fancy feature in DCS? I have no complaints about the Viggy, I'm just curious.

I played Argo Campaign long ago (for my memory), but IIRC: 1. Argo was OHP (Oliver Hazard Perry). 2. The method for lowering the rails was definitely given somewhere here on the forums, but I couldn't find it now. I think it involved setting a frequency in ME, somewhere, somehow. Then you fly and tell them you're inbound via - I think - ATC comms menu. They should lower the rails then. 3. Argo Campaign may not have this feature pre-set or I was just too absent-minded to spot/use it. If the former is true, you'd have to modify each mission in advance for it to work (if that's possible). If the latter is true - see in the ATC menu if you have Argo anywhere there.

By the way, one thing here is worth noting IMHO. There might exist people who could learn from the A-4 team - on the screenshot above you can see it's "full service" binding set, namely (I'll take A/P ALT HOLD as an example): * ALT/OFF - to be assigned to a joystick button or a keyboard key (toggle action: tap - it's ALT, tap - it's OFF, tap - it's ALT etc.), * ALT else OFF - to be assigned to a toggle switch with a single contact (contact is closed only in one position of the switch), * ALT and a separate OFF - to be assigned to a toggle switch with two contacts (either position of the switch has their separate contact) or any contraption of this sort (e.g. two separate keyboard keys if someone likes it this way). Chapeau bas, A-4 team! These bindings in some other modules are erratic mess (to a varying extent) - you get some of them, but others are missing, depending on a particular dev's mood, habits and/or hardware HE is using <sigh> Which only proves a general point that if ED built for themselves (or themselves and 3rd party folks) a tool for automated generation of those Lua files for keyboard/joystick bindings (not a 100% automation, but maybe like 90%), they'd have less tedious work to do with each module, less tedious work with gathering info from users on mistakes in these files and then with fixing the mistakes, and we'd get a full set of bindings for a vast majority or all controls in each aircraft's cockpit. Less work for devs, more functionality for users. Not gonna happen, I know, but... just saying

What great tips! Thanks! I wish I had known them before I started tinkering with the Scooter. Speaking of which... I only have a "microLua" with 20-30 "variables" in it. Probably not what you want, but that's all I have (see the attached file). I started making the file when A-4 2.0 was in beta and never finished. I typically start with armament panel, so it's there already, but not entirely - I use my button/pot box for a few things (e.g. I have ripple interval turned with a real potentiometer, so I don't have "buttons" for it in my profile). I put device IDs and button IDs into the Lua to facilitate creating a profile with it (like I said - I didn't know your trick at the time). Oh, and since I didn't know your second trick, either, in the file it reads "ExportScript.Version.AV8BNA = "1.2.1" (how "smart" of me, I know ) Perhaps someone else if further down the road with the Lua for A-4? EDIT: I'm too slow with the forums A few hours after your post above, you published this auto-generated file: https://github.com/asherao/DCS-ExportScripts/blob/master/Scripts/DCS-ExportScript/ExportsModules/A-4E-C.lua BIG THANKS! A-4E-C.lua

I don't know how I managed to overlook your post. Late thank you for the insight and that other picture! I guess you're right - no one seems to care about this bombing altimeter contraption, let alone ED about remodelling it true to life. Whatever. I just wonder if the white and black pointers can actually be cleverly "geared together" instead of just being one piece of metal. On one hand your explanations make sense, but on the other - this assembly is such a thin steel "sandwich" right above the glass that there seems to be extremely little space for any mechanical marvels there. Maybe the design attitude was "more or less is good enough". I don't know, just speculations. Well, anyway, it is what it is, we're not getting it, thanks for taking time to dig into it!

Sling loading cows is just lame - if used in asymmetric warfare, a dozen of very slim locals will cling onto the cow and EAT IT! Not only will the attack be ineffective, it's gonna be counterproductive. Useless, lame, no! The proper way for cow combat employment was established long ago by the French, in England (a century before the Norman Conquest, it's a complicated story)... apparently together with film making, so we have a video footage from around AD 962. Young folks may not know it, so I provided the link below. Hence a reasonable poll should ask: "Can we have a catapult unit in Combined Arms?". Someone has to come up with some "pipper depression" tables for cows, though.

Black humour, I like it! I can make coffee instead, I don't get that Lua contraption, maybe like 10% of it, at best. I'd love to read one day how this strange language works Sorry for off-topic!

Oh, wait... so the text wasn't yours, you only quoted what you had found in a file written by someone else? Sorry then Never mind, I didn't mean anything wrong - it's no big deal, the code will work either way, it just struck me that someone is/was putting more work into that Lua than neccessary. Here: https://forums.eagle.ru/topic/283178-dcs-exportscripts-for-stream-deck-community-github-library/?do=findComment&comment=4805362

Hi, @bones1014! Just a tiny tip (and optional to use) that can make life easier a bit. You don't need "string.format()" where inside it you have a ready to use string. So, for example, instead of: ExportScript.Tools.SendData(60001, string.format("CH " .. UHF_ARC159_readoutBase:sub(4,6))) You can simply write: ExportScript.Tools.SendData(60001, "CH " .. UHF_ARC159_readoutBase:sub(4,6)) It's the same. Well actually the latter is faster to run for two reasons (but this shouldn't matter much), but it's also healthier for the eyes (less reading)!

No worries! And thanks for looking! Yes, I'm "sucking" the strings out of the list_indications, but for some reason in the "CAL" position of this knob on the right console, the PCN_UR_DIGITS gives me "CAL", while at the same time the in-cockpit display shows something else AND... this phenomenon popped out of the blue only after the "radar overhaul" update to the Mirage, previously it all had worked fine. I don't know if I can do anything about it, I wish I could. I suspect only Razbam can.

AFAIK, currently it's not possible and that's why people are asking ED to cater for "user cartridge(s)". I'd welcome such feature, too. However, I think such user cartridges solve one problem (the one you mention), but create a few more. Let's say you are just about to fly a campaign mission - up till now the cartridge auto-generated from the mission file has been loaded into your plane. If you get the means to override this with your own "favourite" cartridge, you may also override settings important for the mission. The easiest example would be the flight plan. Now what? Should ED seriously elaborate on it and create a new window shown on mission start where you pick particular settings: take these settings from my cartridge and those from the mission cartridge (etc.)? A kind of "cartridge blender" machine - 25 "categories" to choose from? Sounds a bit complex, so then ppl will ask for the option to "remember my choices", because they won't like to choose all 25 categories each time they want to fly a mission (even if there were 5 such categories - they still won't like it). Thus you get another layer of complexity. Now, what if you mess up your choices? You'll then come to the campaign forum and file a bug report "the mission doesn't work" and the author will have a nice puzzle, maybe he'll fly the mission 3 times to try and spot the error you reported (unsuccessfully)? See? The thing seems easy to wrap your head around ("just add user cartridge to the game"), but becomes a bit problematic if you dig into it. I'm not claiming it's an impossible feature to have, but it needs a little bit of consideration to sort out all such intricacies.

Thank you very much @plusnine, beautifully explained! Have a great day

My turn! Flew the Scooter before this release and it was fantastic, now it's "fantastic+" - is it really a free comunity mod? You gotta be kidding! She sounds great (many a paid module sounds way worse, especially some 3rd-party modules), the cockpit looks just lovely and I love the illumination inside. EDIT: Oh, and the yellow vacuum cleaner, where else one gets this?! All I can say is just... thank you! It's a great, high quality module and fun to fly for multiple reasons. Stellar work, gents! Hats off! Is this a good place to ask a few questions? 1. I still experience an error in the altimeter indication due to pressure setting. Yesterday, on a mission start in Kutaisi, the altimeter showed around 0 ft (or perhaps 10 ft - more or less the correct altitude), but the Kollsman window was showing 29.92 (I didn't touch anything), while in reality in this mission the pressure is 30.16. Am I doing something wrong, need to select a better static source or something, or is it still this mysterious issue with how DCS reports bar alt? 2. This may be a feature in the Scooter itself, I just don't know. Gunsight brightness knob. It goes from dimmest to brightest within half of the knob's rotation and when you keep rotating, it suddenly drops to 0 brightness, then keeps getting brighter again. Like "two cycles" of dimmest->brightest along the full rotation (instead of one cycle). Is it a bug in the module, or some fancy gizmo in the Scooter? Or maybe it is something messed up on my end, though I'm having this regardless of whether I'm using an axis or the mouse. 3. Roll rate. AFAICR, I set the roll axis saturation to something like 15-25%, otherwise A-4 rolls like a spinning top. Is it something on the to do list? Basically I'm fine with my settings, but the point is - I don't know what settings are realistic, should she roll a bit more or a bit less? I'd just prefer to fly like the real thing, give or take, not a fantasy airplane arbitrarily created by myself with the saturation slider. 4. I concur with @Andrew8604's opinion. There's something (quote) "unsettling" about NWS, differential braking that is. See, at this point I haven't a faintest idea how this should feel. All planes with this kind of steering feel very different in DCS: A-4, MiG-15, MiG-19, MiG-21, L-39. All so different in this respect. Is there really some objective truth out there? If you asked me (a layman), L-39 feels most credible, but frankly - how can I tell? As for the Scooter, I don't want to repeat everything what Andrew wrote, but I also sometimes feel something like "fading", it's hard to explain. Yeah, I've experienced "nice" emotional fading in a car, trying to slow down from like 100 to 30 mph before that other car which suddenly materialised just in front of me, but here, on a taxiway - she's going slow and sometimes the brake (left or right) seems to "catch" better and sometimes she hardly does anything. Maybe it's just my brain failure of sorts, wrong perception, don't know, but "unsettling" is a great description to this. All these things, of course, don't change the general view that A-4 is a gorgeous module!

You, folks, are impossible! I went to bed, got up in the morning, hardly had a second to scratch my butt and suddently I see this: "Hey, Lua's ready!" Amazing! Thanks a lot Thank you, Bailey, for info on the ghost outlines - I thought I was doing something wrong, but apparently it is some kind of "contrast enhancement" (for text) that Stream Deck is using. In normal circumstances I guess it's a good feature. My outlines aren't as bad, it was my camera which amplified the contrast and brought out those outlines (damned digital signal processing! ). And I got one thing wrong - the outlines are also visible in Stream Deck software (contrary to what I said), they're just hard to spot on 1080p (plus my eyes are cr*p). Never mind. Great job, again

Beautiful! Yeah, that's the "cover icon with characters" or "multiple annunciators in one button" thing. However... aren't you, by any chance, getting artifacts such that I get as shown in the attached picture - those greyish outlines? They are actually 100% black "full rectangle" and "empty rectangle" (top row) characters on 100% black bitmap (icon). I only get such "ghost" outlines on the real (hardware) Stream Deck, they're invisible in Stream Deck software (in Windows). I have no idea where they come from. (This is Dora gear/flaps - in the picture all are up, hence all 3 red lamps are uncovered.)

+1 Until it gets fixed... not really a solution, but just a poorman's workaround: the breaker doesn't pop when you turn the cockpit light rheostat only "some", somewhere between 1/2 and 3/4 of full travel, can't remember exactly off the top of my head. The light's a bit dimmer then, but maybe bright enough for anybody? Disclaimer: Haven't tested it in recent months, but it used to work like that around the turn of 2021.

Thank you, @ctytler, for the explanation. I was worried that Lua somehow expands on the classic printf format string syntax as specified in C. If not - great! Hi, @Bailey! Yes, all these ideas I sometimes utilize in my ugly profiles for SD, with little modifications. Instead of || I sometimes use brackets [] (which doesn't matter, of course). For example I have a "gauge" on SD which shows how much fuel I have in tanks in P-51 and which tank is currently selected (otherwise I routinely forget to switch them in flight). I don't have my DCS computer here, so I'll try to mimick it with text. The SD button looks like this: 89 [82] 0 LD RD Whichever tank is selected - gets "bracketed" (non-bracketed numbers are instead surrounded by a single space from left and right). In the example above the right wing tank is selected - top right number. Numbers are gallons of fuel, except for left/right droptanks (LD/RD), where there are no probes. Well, I still sometimes forget to switch tanks, but not so often EDIT: I'm an idiot, I swear! It just popped into my mind... In the script you can "measure" the discrepancy in fuel remaining in the left vs. right tank. When it's too big, you may set some other (new) export variable and drive the "Icon State Change" for the button in the SD. For example: no or little fuel imbalance - black icon, big imbalance - yellow icon! Maybe this will prevent me from forgetting to switch tanks. Instead of a degree symbol, there are circles in unicode - full and empty circles, so I sometimes use them where textual descriptions for switch positions are very short, like this (Mirage 2000, bomb arming switch - inert/retarded/instantaneous): And another idea, though very far from perfect, is to have a uniform black/grey icon with coloured rectangles painted on it in very particular places (it requires painstaking "tuning"). Each coloured rectangle is a specific annunciator, then you COVER some of them with unicode characters which look like full rectangles. Text colour and the underlying icon color must be the same, e.g. the same hue of grey. I have this kind of contraption for Dora's gear/flaps lamps (green, yellow, red). Don't have a screenshot to show it now. The imperfection is that Stream Deck software uses some kind of "contrast enhancement" for text, so if you put text of colour X onto an icon of the same colour X, the borders of characters are somehow changed in colour to become visible. I don't know how to explain that better. So... in case of my Dora gear/flaps lamps, you can still see faint silhouettes of those rectangular unicode charactes. Looks rather bad The last "patent" is the one I explained somewhere above here. If the backlight in the button is characters, you can simply "print" (as text) those of them which are currently illuminated in the button, and replace with space(s) those that aren't. Say, the button has separate "ABCD" letters, but B and D are currently out, only A and C are illuminated (backlit), so in this case you print "A C " (the spaces substitue the missing B and D). That works too, except for the problems with alignment - spaces aren't always a good replacement for a missing "B" (for example), one space may be - say - 0.65 of a B's width, while two spaces will be 1.30 of it - and the whole string starts jumping left or right. That looks very poor. Oh, and yes - everything in one colour only @bones1014 There's something strange about Lua, or my Google skills aren't good enough - I haven't found a "proper" languge specification for Lua and the only source I'm using (with limited success) is the "manual" here: http://www.lua.org/manual/5.4/ In certain places this manual tries to look like a specification, but not everywhere. For example it explains what some string function does, but... doesn't say what the function does when the passed arguments are wrong, for example the number of something physical is passed as a negative number etc. I feel a bit lost when I'm reading it. Now, if you don't know absolutely anything about the language (much like myself, really), the best approach, at least in the hobbyist/amateur realm (as it is the case with DCS for us), is what I call the "monkey approach", i.e. go see how other people wrote something and start tinkering with that, replicate it and modify, like "touch it and see what happens", while at the same time helping yourself with the aforementioned manual. Slowly, step by step, you'll start having those "Eureka!" moments and things will start to click into their proper places. There's nothing to be afraid of, it's not a job, no one's gonna fire you for writing cr*ppy code, no one will yell at you, nor will anybody die because of the bugs you make. The other piece of good news is that you won't "break" your DCS with bad export script, the only thing that will (silently) crash will be your script. And another good news - if your script crashes, you don't have to re-launch the whole DCS, but only the mission! Quit mission (stay in the debriefing window), Alt-Tab, fix the script, Alt-Tab, "Fly again" and you can test your fixed scipt Oh, and more good news - as long as your script doesn't crash, you don't have to leave a mission in order to test new changes in your script. The script is loaded fresh every time you "change aircraft" in the mission (note: it must be a different module! changing from, say, A-10C to A-10C doesn't count as the "change"). So, for working on my export script I'm using a mission with more than one "spawn" aircraft, where one of them is the one I'm working on, and the other (or others) is any other module, preferably a lightweight (simple) one, so it doesn't take too long to load. So now... if you want to modify your script, you change aircraft and go change the script, then go back to DCS and change aircraft again - to the one the script is for. You need to reload the mission only when your script crashes. You know it when your SD profile stops responding, not even a simplest toggle switch works. It means your script had some syntactic error (or some other error) and Lua interpreter bailed out. Fix the script, reload mission. As for your question regarding A-4E-C... blind guess, but it may be the case that Charlie's plugin looks for clickabledata.lua files in theDCS folder, while the Scooter sits in the "Saved Games" (Sorry, I don't think I understand what you did). Regardless of that, the lack of those ready to use commands in the plugin's window (the one you pasted above) is only a small nuisance - you can still put proper ID's, device numbers etc. manually, digging them out of the clickabledata.lua, devices.lua and mainpanel_init.lua. It's not the greatest fun in life, but it's totally doable and... you only do it once, a few hours of toil and the profile is more or less ready

Regardless of all technical errors (vs. performance cost), these reflections and "canopy filth" is IMHO wrong for the reason @MAXsenna pointed out above. In a car you may have some dust on the windscreen and it doesn't make you blind, because when your eyes accomodate into infinity, the dust becomes merely a layer of greyish tint to the picture, it only darkens the picture in your brain a bit (until you get too much of dust/filth and you instinctively reach out for the sprinklers handle). In a computer game, your eyes are accomodated on the monitor, so you can only have a single, common plane for both reflections/filth and outside-of-cockpit view. Even if you "painted" perfectly true to life reflections, Super-Duper-Raycasting-Technology (TM), it would still be unrealistic because of the way eyes work. You can't have both, neither in 2D, nor in VR (the machine doesn't know what your eye lens is doing) - perfect reflections when you look at them, and at the same time perfect when you look THROUGH them. I think the reason why some folks in ED are so keen on filthy canopies (and "severe" reflections) is just this - they have pictures of filthy canopies (what was your camera's focus when you were taking the picture? of course - on the canopy glass itself), then they recreate it as closely as they can and are proud of their work. Rightfully proud, I guess, but the whole premise is kind of wrong. So, if you can't have both, what can be done? Maybe a more pragmatic approach - pilots (and drivers alike) usually stare THROUGH the canopy/windscreen, not ON them, otherwise most of us would be dead already, run over by cars or killed in cars, a bloody apocalypse. So, if that's the case, why not tone down all the graphics "projected" on canopies so that they look more like when IRL you look into infinity through them? It's a lesser evil, I think. Or maybe an experiment - make a picture of a slightly worn out canopy in such a way that your camera is forced to focus in infinity? Then bake it into the canopy in DCS and let's see how it works? Yes, it will be only blurry "something", but maybe the final effect will be nicer in practice, when flying? Well, I don't know, but I know one thing - the current "philosophy" for reflections and filth in DCS are - granted - good when you want to jump into the cockpit and just sit there, watching how pretty it is, but NOT for flying, when you stare outside, through the canopy, far away where the damned bad guys are. That's especially important when you're looking for targets on the ground, less so when you're at the Bf 109's six (he's close, looks big).

Hi folks! Sorry for a strange question, but... am I missing something? I've seen it dozens of times in export scripts and I don't understand it. What's the puprose of writing "%1d" as a format string? To the best of my knowledge (admittedly fragmented!), "1" does nothing there, i.e. "%d" is exactly the same as "%1d". Is there a secret you know and I don't or... or is it really a superfluous "1"? ============== Yeah, all you can do is take these "variables" (S, T, F, A) (a.k.a. "IDs" - I call them "variables" for the lack of a better term) and "compose" a string of text out of them, two-line string in this case (with some vertical spacing probably, like "\n\n" or so), then make the string a new exported variable. I'm not nagging Viper currently and don't have a profile for it (except for basic UFC), but the general idea is the same as I put into the Mirage profile. It's not a very nice task, because you have to take care of text alignment for a particular font size and shape, SD has only (IIRC) Courier and Courier New monospaced fonts, which look different from what you see in the cockpit (ugly, uncacceptable if you ask me). Other fonts which are similar to fonts used in the cockpit are unfortunately "variable width" (don't know how you call them properly), so you are forced to put strange amount of spaces in between the letters (in your case those S, A, F, T) depending on whether - say - "S" is illuminated or not, so that the letters don't move around too much when S is on or off etc. And if you're not lucky, they WILL move regardless of how hard you try (the space character in a particular font also has some fixed length, which may or may not be the aliquant aliquot of width of the character currently missing in the string). Oh, and all such annunciations will have to be of the same color, sadly Maybe Bailey will (or has already?) put his hands on the Viper? See, I've swallowed almost all modules in... 19 months, it's crazy (don't tell my wife, please!), I can't keep up with the pace ========== I'll be damned if I know the answer and I'll buy a crate of beer for anyone who can tell how to fight the lag. It may be due to the fact that virtually each script exports hundreds of variables, Lua treats the "tables" probably as a kind of "dictionary", so looking up for a specific entry is not as simple as in a "proper" array (of fixed-size elements identified by incremental indices). Then, your variable may be exported in "Every frame arguments" or "Config arguments" (the latter is only 2-3 times per second). And there may be a dozen different reasons for the lag I'm not aware of.

By using this "Model Viewer" app that sits in the DCS's "bin" folder, but it wasn't overly funny. There's another variable somewhere which controls the common light intensity for groups of buttons, and at first I must have had this turned off so nothing worked (no green lights in the buttons) Then I somehow figured it out and from that point on it was very "straightforward" - you just need to move around a 1,000 sliders to find those 4 that control the green lamps in question. Great fun Interestingly, these 4 variables which now control the lamps, used to do something with the V/UHF radio (old comments in German in the export script suggest so)... so, yeah, good idea and good luck looking for PCN button backlight in the radio department. Anyway, I got a bit green of anger and finally found those IDs. I just wanted my quick and dirty profile to be ready for the French beauty again (even though I'm not flying Mirage at the moment, I'm tormenting my Christmas gift - the Chechoslovak pretty girl ).

Rudimentary SD XL profile for M-2000C, more or less as depicted HERE Changes: * Update export script and SD profile to current version of M-2000C (as of 12/29/2021). * Add countermeasure program selector (a pair of buttons) also showing DEFAULT (!) program settings, e.g. "C6 x 3" means 6 chaffs in 3 series, "C1 F1" means one chaff and one flare etc. - it is fixed text, so if you change your CM settings, the text on the SD buttons will be false and deceitful! I added it to help me memorise which of the 10 (or so) programs is for what purpose. If you don't like the profile like this, modify as desired or remove this information from these 2 buttons. * Copy SIL/EM radar control to the main screen (nice to have for a quick glance + there was still some free space on main screen). Known issues: * (minor) Setting the INS knob to "CAL" displays "CAL" on top right "LCD display" on Stream Deck, instead of what the display shows in the cockpit (there's nothing I can do about it). Put both files attached below where necessary. If something still doesn't work, please let me know, I'm sorta tired already, might have overlooked this or that. M-2000C.lua M-2000C.streamDeckProfile

Oh, great! I'll look into this, but need to find some free time to sit down and investigate. I hope it's repairable.

It isn't. Someone forgot to add this pinkish/orangish (whatever colour that is) "Requires DCS World version 2.7.9 or above!". Same goes for the Paradise Lost campaign.

Alright! I get it now! Damn, when you look at the screenshot you're thinking "What can be more obvious than that? There's the thing and the other thing - just look!", but when doing it I miss the basket suspiciously often. OK, Chistmas is coming, there will be some free time to try "put 30 on the hose", thanks @draconus!