Xupicor

But the only warbird and the only taildragger prop with multicrew is the Mosquito. Not quite the same thing as a Mustang. We have the second seat in TF-51D behind us, just not usable, sadly.

Stop it, I can salivate only this much!

TF-51D has this and the Hornet doesn't?

Strange, I didn't get the 2% lightoff at all when doing it by the book. I've got the game slow repaired and metashader/fxo purged after every update. Any mods on? But yes, the startup procedure is not running as it was on the old flight model and there's a need to look into it. For example, I don't need to hold the start switch till 40% as the book prescribes. It used to be that the engine would spool down if I released below 40% -- now you can just hold it for a bit and off it goes even if you release it way early.

We played around with the Huey yesterday and today, on the newest OB, and it was still there. The co-pilot can't see the rotors running, low RPM starts blasting for them. When they leave and rejoin multicrew once the cold start procedure is finished it works OK.

Any updates on this? I'm asking, because I mucked about with TF-51D and got the battery to die on me without even trying -- had to connect ground power to get the engine running. Is TF-51D so much different from P-51D when it comes to the engine simulation programming guts that it would work in one but not in the other?

On G2 the dots were huge, blobby and didn't really fade off with the distance in my experience. It was either nothing, big square black blob or again almost nothing as the blob disappeared when the unit got close enough. On Pimax Crystal (so a higher resolution, higher PPD) the dots seem to look way, way more reasonable. It's actually hard to spot targets again - as it should be. The only thing is the blobs seem to sometimes flicker back up for a fraction of a second, so I might be scanning the sky and not really see much and all of a sudden a black blob (way smaller than on G2, though) pops up and disappears. If I focus on that point I usually see a unit there. So I guess for 4K thereabouts on flat screen or pretty high resolution VR headsets like Crystal this new spotting isn't too bad (excluding other issues with it that are surely pending to be fixed in about two weeks). For G2 it was pretty nightmarish with big black blobs flying around. The most offending thing, though, was that the depth perception made me think the black blobs were way closer to myself than they really were. That doesn't seem to be the case on Crystal, curiously. Probably something to do with the relative size of them. @James DeSouza can you put a little circle around the dots you see? Because I'm squinting my eyes and I can't see a single airplane on that picture. Ah, I zoomed in and found them. Geez! If it looked like that on G2 I'd be actually happy, haha.

Think this was reported soon after the changes were made. Right, @Flappie?

@P3CFE - well, both the DCS Huey manual and UH-1 H/V Operator's Manual dated 1988 say the throttle should be just below idle, not at idle. You can get there, like I mentioned above (or planned to), by pressing the Idle Stop Button (low thumb-side on the collective) to unlock the lower ("below idle") range on the throttle and then PgDn to get it just below the Idle Stop. Indeed, like @admiki mentions, can't get there by using an axis, but using a button/key binding or a mouse is possible. Kind of a bummer that the axis doesn't work in that range, because my Virpil collective actually has a throttle with an Idle Stop mechanically working like it should (locking part of it out like the Huey does) that I could use for it. @admiki Hm, the order of it would indeed suggest it's 40% N1... I've been pushing it to idle way too soon all this time then. But I never got a hung start below 40% N1 -- I had hung starts (I know) when I waited. Reading through the procedure now, that seems clear just from the order. I don't know why it couldn't click in my head. Thanks for you comment!

Not to revive an old thread (but I will) -- I had this happen just now. The thing is - I WANT to have the FFB trim implementation since I'm flying an FFB base. At the cold start the neutral point was well to the front, leaving small amount of movement range (kind of similar to F5) -- but after the engines were running at some point it switched places, as in, the neutral point moved well to aft, leaving barely any movement range to aft. I could, however, trim it out and she flew well afterwards. My question would be - is this normal? Did I just forget to trim it to zero? Is the trim randomly set or something? I'm not flying the 14 much, so I just don't know.

Of course I get that. The mission editor just loads the game using that mission. That's clear. It goes with the letter of the law, but kind of against the spirit of it, as it makes the player to jump through hoops just to not get the stats demolished. Again, I don't care personally -- most of the time I don't even remember this thing is even there. But I imagine there's a lot of single player people out there that might take a degree of pride in the stats gathered over a period of time. Imagine getting those stats wiped because you wanted to try making your own mission and spawned too close to a friendly, or the friendly just rams you. Anyway, regurgitating the same point isn't useful, so I'll stop. Just stinks like something that shouldn't happen whether a lot of people care about it or not. It isn't a sign of polish, you know. If you asked me, missions ran through ME shouldn't have any effect on your pilot's profile stats.

What is your throttle position when holding the Engine Start button? Both the DCS Huey and the Bell UH-1H/V manual I have here say it should be just a below the IDLE STOP position, but neither one says exactly at which point to start turning it towards IDLE STOP. I gather a 10% N1 is an alright value since we need to confirm rotors start turning at 15%? If I set it at IDLE STOP (so, PgUp fully and PgDn to get to the locked position) - indeed immediately when I press the Engine Start button Exhaust gauge skyrockets immediately. However, if I set it at just a touch below IDLE STOP position (by pressing Idle Stop Switch -- then I get the Exhaust gauge only positively react after I move the throttle to the IDLE STOP position. Now, if the rate at which it shoots up is correct - I have no idea. Obviously I haven't flown the Huey or anything else in real life. If you have, can you expand on my observations?

Looks like to move 50mil according to the 50mil diameter circle you need to move the knob by about 94mil as indicated on the knob itself. Awfully close to x2 factor, so maybe it's my measurement error... Maybe it's some kind of conversion error somewhere or the two 50mil radius and diameter reticles were confused at some point and one was used for modeling the reticle while the other was used in modeling the elevation mechanism? On the side, IRL, seems a bit strange to have two reticles exactly identical but scaled x2 -- was one older and another a replacement for it? Or were they used side by side? Any history behind that?

So I just tested something unrelated in ME - had a Huey take off in front of AI C17. I took off and started hover taxing on the runway - when I was picking up a bit of speed the C17 started rolling and rammed me from behind. Huey got the skids obliterated, but was otherwise okay-ish. The C17 started burning, decelerated, I was about to restart the test to avoid this situation so just crashed the Huey. At the mission end screen I got a pop up that I committed fratricide and that my combat scores are wiped out. I don't care about that at all, but some people might. Is the only way to avoid someone ruining their SP pilot profile is only switching it on when flying actual missions? Why would testing stuff in ME trigger permament things like this? Seems kind of unfair to have tinkering around in ME have any consequences on the pilot profile. I guess you could use it to prop up stats as well as get your legit stats wiped out unfairly. Or is the pop up spurious? Again, I don't care at all for my case, but it looks more like a bug than a feature to me.

In VR (G2 / 4080 / MSAAx4 or DLSS) the dots are too blocky for me. They look like quite blurry squares. In terms of stereo vision - they look as if they are much closer to me than they are. They do in fact look like they're closer than other airplanes that are actually closer and are no longer rendered as that blurry square. When I see them I always think: "Oh, is that a Huey in the distance?" -- but no. As the airplane gets closer, at some point the blocky, blurry square fades out suddenly and leaves a barely visible, pretty small airplane in the distance. That transition doesn't look good at all. It's a step in the right direction, I guess, but needs more time in the oven. I much preferred the units going down to the size of a pixel.

Is there any strangeness though? I mean, yeah, need to be a bit delicate on the breaking side, wait till you slow down more, but otherwise I (using no curves at all) had no problems landing this thing. I'd be wary of depressing breaks a lot in any tail-dragger.

Just out of curiosity - leaving the matter of unlocking this on the sides, obviously it should be done - as a temporary solution for you guys, can't you copy it over to the correct lua file and thus enable it in the controls screen?

Just checked it out of curiosity - it works just fine. It feels a little different, but nothing radical at all. No curves (on any module, actually) and I'm fine. Using Virpil collective as well. Hopefully by this point your problem is solved? Was it just the change that threw you off or was it an actual hardware problem?

Surely the company can scrounge up 2k euros to buy two Rhinos FFB bases from Walmis and some extensions and use that for testing with whatever compatible grips (Virpil, Warthog, etc) you already have? I think Walmis customers would agree to being shifted 2 units into the future if it was for the betterment of DCS FFB implementation down the road.

This might be a problem on my side, but I can't install liveries through DCSLM anymore. It downloads the livery packed in a .rar archive and then tries to unpack it with 7z (from Lua 5.1 directory, I guess it's before 7zip's own in PATH) which returns "non-zero exit status 2" - after which DCSLM removes the archive and spits out a failed livery install error. :< I've got 14 GB of free space on C, the livery can be installed just fine by hand. Maybe switching PATH around to use 7zip's original 7z.exe would be something to try?

Why do you need to restart the mission, though, couldn't they just reslot and start back up in the air again, immediately?

Beauty, thank you for letting me know.

With the dawn of more advanced controlling devices like Virpil collective base with an actual twist throttle and a physical idle-stop cutoff (that is also a bindable push button as well) - it would be very nice if we could actually use them properly. At the moment, the physical device is more advanced than what DCS is giving us, which is really not something that occurred often to me... At the moment when we bind an axis to the throttle, we can't move it at all during a cold start. We have to either move it with the mouse or Page Up a bit to get it up across the cut-off. Then, the only portion of the throttle movement that is bound to the entirety of the axis is the portion that is above the cut-off point. That shouldn't be the case, or let me rephrase it, there should be accommodations made for more advanced devices that reflect real controlling device better. Additional axis that worked over the whole range of the throttle movement would be great. If we could also define where on that throttle the idle cut off point is, so it was where our physical cut off is, that would be even better. More and more people are going for those more advanced controllers. Usually it is the case that DCS has to make options for devices that do not have this or that option. But in case of afterburner detents and this here helicopter throttle cut-off, it's the other way around - DCS is behind the actual devices on the market and is in this respect less realistic than them. You don't see that every day, huh? Please, do not let this just lie over here for 10 years. I know this was already voiced before, years ago... But with the recent Huey activity on EDs side - can we throw this into some TODO list, please?

They still didn't map the throttle axis to in-cockpit throttle 1:1, though.

Is anyone here fluent in 'Lua Console' / 'Hub Scripts'? I wanted to write a proof of concept "coordinates to cockpit inputs" where I would read in coordinates and translate them to button inputs needed to automatically punch them in, something "DCS: The Way" is doing already. However, the code - as unoptimized and primitive as it is - seems to work fine in all respects but the crucial one. Only the first and last input seems to get sent and actually recognized by DCS. Is there a caveat to using `hub.sendSimCommand()`? I'm sending the button names taken from the docs (Control Reference), yet only the AMPCD ones get acted upon properly. UFC_OC1 doesn't get activated for some reason - but if I play with the delay and punch the button in-cockpit myself, the numbers show up in the end (so UFC_0 through UFC_9 work? Kinda?), though, not the last one, for some reason, and UFC_ENT doesn't seem to do anything either. if not hub then -- for testing in cli hub = { sendSimCommand = function(c, v) end } end function sleep(n) -- seconds local t0 = os.clock() while os.clock() - t0 <= n do -- just a busy loop - I couldn't find a way to do it smarter in hub environment end end function press(command) hub.sendSimCommand(command, "1") sleep(1) -- I want to see it done slowly hub.sendSimCommand(command, "0") sleep(1) -- I want to see it done slowly end local command_to_buttons = { ["N"] = "UFC_2", ["S"] = "UFC_8", ["E"] = "UFC_6", ["W"] = "UFC_4", ["0"] = "UFC_0", ["1"] = "UFC_1", ["2"] = "UFC_2", ["3"] = "UFC_3", ["4"] = "UFC_4", ["5"] = "UFC_5", ["6"] = "UFC_6", ["7"] = "UFC_7", ["8"] = "UFC_8", ["9"] = "UFC_9", [","] = "UFC_ENT", ["'"] = "UFC_ENT", ["."] = "UFC_ENT", ["U"] = "AMPCD_PB_05", [">"] = "AMPCD_PB_12", [":"] = "UFC_OS1", ["f"] = "UFC_OS3", ["t"] = "UFC_OS1", } function punch_in_single_coord(sanitized_coord) for c in string.gmatch(sanitized_coord, ".") do press(command_to_buttons[c]) --print(command_to_buttons[c]) end end function punch_it_in() local matches = { "U:N4134.>", --"U:N4134.0411'E4136.9865'ft155.>", -- "U:N4134.0411'E4136.9865'ft155.>", -- "U:N4330.8198'E4338.3728'ft1411.>", -- "U:N4244.4262'E4404.3242'ft11001.>", -- "U:N4314.8299'E4426.1757'ft1370.>", } for _,m in pairs(matches) do punch_in_single_coord(m) end end punch_it_in() The docs don't even include any wait/sleep function between an example of those calls, so I'm unsure if I would need them in the end or not. I'd think so, since otherwise it would be a barrage of inputs... They also say: But I have no idea what it's supposed to mean. Buffer size of 10... what? 10 commands? Or do they phrase a time delay between the calls as "buffer" and it's miliseconds or something? No clue. That's basically all there is about it in the docs -- that I found... I'd appreciate any input. I'm new to Lua, so maybe there's something obvious in there. (Not as new to programming to see that there are probably faster ways to loop just using normal indexing, but that's not the showstopper here. I just wanted to use the fancy Lua stuff. ) The way you'd test this is just copy paste this to 'Lua Console' in DCS BIOS Dashboard and execute. This is for the Hornet and you have to be in HSI 'DATA' screen with PRECISE boxed in, that's on your AMPCD.