virgo47

You're right! I connected GPU, flipped the switch up (stuck now), continued on the starter panel, lights came back when I pressed the start switch (this also flips the QRA back down) and the engine normally starts if everything is done correctly. Funny I can flip the switch up again, plane goes dark, but the engine works fine. To flip it back down I need to press the starter button again. Even better, just ask the ground crew to turn off the ground power, the QRA switch flips back then. Of course, this is already fooling around. So it seems to work somehow, although the manual p71 says "NOT FUNCTIONAL" in the table, 3rd row: Whether it's production ready, I don't know. But next time if I accidentally press this, I'll not panic or restart the mission. Thanks.

I don't see any more current QRA-specific topic, so I'll revive this. During the cold start, I clicked this switch, it went up, all the cockpit stuff went off like there is no battery - and the switch is stuck there and I can't click it back to down. Is it normal?

This is very individual. I've seen SW release delays over and over again... unless you have a very safe project it is often bound to happen. You either have to descope or delay, or often both. Alternative is to just tease without a date. Then another group will complain there is no date. I've seen interesting releases this year. Sure, there is the ongoing situation with RAZBAM, but that's PR nightmare one way or the other and will take time (good there are no dates there ;-)). If I don't read forums for a day or two I feel no anxiety about the release, there are tons of modules to play with already, why are we so focused on the ones that are not in DCS yet? Sure, we want them, sure, we're looking forward to them, but most of the bad and hard feelings about it all seem to be generated and reinforced by the vocal part of the community. I don't feel significantly worse about ED or DCS than in 2022 for instance.

As a SW developer myself, I don't necessarily agree with ED's priorities in some areas (longstanding bugs in older modules), but delaying a release...? No problem, I'll wait. Sure, I don't plan vacations according to their announced dates, maybe that's it. I understand people eagerly anticipating new things, e.g. the Hook or AF map but I don't understand the traffic (and the style of the traffic) that happens on this forum every time something is delayed or postponed. I'm looking forward to the next patch, whenever it comes. Better late than sorry, indeed.

For a newcomer trying the first tutorial this thread was useful. Of course I got stuck on the INS alignment right away as the tutorial does not mention using another BUT.

Hello Viggen savvies! I noticed that sometimes there is a pair of flickering short lines above or below the horizon: I am in the NAV mode and the flickering lines seem to depend on my pitch change somehow... but I couldn't find anything about this on Google nor in the manual (which doesn't mean it's not there). What do these indicate?

The first message in this training mission is perhaps some unlucky copy/paste from some on-the-ground mission: Now I obediently did that... and eventually figured out that this is probably not the right instruction. There is no impact on the voiceover, only the message needs to be fixed... or removed completely, as it does not appear in ARAK or RB-05A training and it's not missed there at all.

See, it's wasn't obvious to me and, believe it or not, I couldn't google it - perhaps wrong words, but simple this vs that didn't help me. Thank you for the explanation.

It's possible, but it's difficult to come up with an exact number unless you do absolutely everything the same way as the pilot who came up with the number. If I'm a bit slow, I need higher RPM to get to the desired speed - doubly so in turn. Then suddenly it's too much, etc. So the numbers are not universally true. I started to make my own extended notes for the campaign, but they are only relevant up to mission 4. I'm offering it as-is, no guarantee. L-39 Kursant Campaign Notes.pdf It still is a shame this campaign has NO docs at all... I wish I knew what the difference is between the manoeuvres and when to use which kind of bombing, etc. Maybe I'll learn later, but PDF would still help. Many/most campaigns have some kind of docs. This one - nada. I still like the campaign, it is perhaps old-school from today's perspective, but I like the effort they put into it.

I haven't ironed out my experience yet, but... Yes, you can drive the vehicle, that's the easy part. You can look around with a mouse - or TrackIR (which messes up with aiming and I'd avoid it for CA). You can even bind turret-turning to the joystick! But in the outside view (called Isometric view) the mouse and arrow keys (turret elevation/rotate key actions) work fine - but the joystick (turret axes) doesn't for whatever reason. Yes, you can use binocular view to add some smoke and laze/IR mark stuff - this is the cool part - and probably much more. But the inconsistency in basic controls and view switching is rather staggering.

I'm already using Toggle in opentrack, works fine for some cases, today I also bound Toggle track - this also recenters the tracking. Thanks for the tip to review these options again. However: Toggling tracking in DCS would have a great benefit, as it would also re-enable view moving actions, which are stuck with TrackIR enabled in DCS. And yes, there are good use cases for that. It is just a workaround - clearly a necessary one. CA with TrackIR is still essentially broken when aiming reticle for a TOW rocket visually moves, but rocket goes somewhere else. I'll first spend some more time with CA before I start reporting any bugs (if not reported already). I found a few suspects within minutes, mostly related to controls.

Admittedly, it's my first minutes in CA, but - similar to door gunners in UH-1H - TrackIR doesn't make any sense at all. Actually, UH-1H offers a few options what trackIR does, here it only makes things worse. It moves the circle which is supposed to be used for aiming - but the rockets go for the "centered" position. So far I didn't figure out what is the binding (if any) to toggle aiming mode with/without TrackIR. It's puzzling that they create a product that works absolutely counter-intuitively. TrackIR messing things up, various views being toggles (I have to toggle from one to be able to use another)... Everything is different from planes, like made on purpouse super hard. Of course, I'll give it another read of the manual (which isn't that long, luckily), but I definitely didn't get it the first time. But the TrackIR on top of it... it's unusable mess with it. It doesn't aim, it only makes your aim harder. It does move some reticles, but not the actual aim... very, very frustrating experience. And of course, one has to go to the Controls to disable the TrackIR, as there is still no simple UI Layer global bind for it.

In ideal world there would be some queueing for events on the same device (flaps here), but as we reopened the topic in the other linked discussion, I came up with some neat solution. Instead of just one pulse, I send two with some not so long space between: Set Generator Type to GTR2, 60 is for 600ms which should cover most animations. The only downside is, if the switch acts as a toggle (e.g. toggling between UP/NEUTRAL or DOWN/NEUTRAL), which I hope guys made right for F-4E - or offered all alternatives. I was so happy with this solution only to find, that in MiG-15bis someone was too clever and made the actions toggle, without proper naming. Luckily I could fix it with Quaggle's command injector and some Lua. So now I'm instructing the plane to lower (or retract) the gear twice. And it listens. Not tested on F-4E, but I hope it's applicable. Technically, this is still just a workaround for a general DCS issue affecting only us - poor flip switchers.

Nice one! I use K-switch (3 buttons) for flaps. And for the flip switch I mapped the middle position with the boolean function, so it actually acts like the physical button. That's why I didn't need this so far, but it may still be handy - thanks for sharing the tips!

Ah, I see what you mean now. I'll think about it, right now I'm not sure how it would help me, but perhaps I'll find some usages.

I don't quite understand, can you elaborate?

I'm not sure if you meant me, but this is not STECS-specific as demonstrated by using keys instead. So this event processing thing should be fixed on DCS end. My STECS setup is actually very similar to yours, boolean "creates" the middle button and I had pulse on all of them. With no pulse on the middle, the behavior is the same. GT does not work, because I tested with the keyboard - even if you press and hold the key for outer position. It stays stuck in the middle, probably because the "up" transition for the button was already missed. However, with all the talk about pulses, I came up with some idea. VKB offers GTR2 generator which generates two pulses with some space. I went for 600 ms (value 60 in the input) and this "repeats" the input again, if the first one was missed. This works great for Yak-52 and L-39 back seat: Alas, nothing comes free - in MiG-15bis the Gear Up and Down commands, believe it or not, work as toggles! I have to check whether there are some alternatives with Queggle's command injector, but this sucks. All in all, with STECS/VBK config software, there are some possibilities how to repeat the pulse twice (or repeat the pulses all the time, but that's not what I want for other reasons). This is just a workaround for what I believe is DCS input processing problem. And any plane can surprise you with a silly unexpected toggle binding instead of a normal one.

Ah, then it definitely is N1. In L-39 the RPM % is N1 needle. Of course, it is still just rough number depending on the current situation as the same power does different things in level flight or climb, etc.

Recently also complained about here:

Also reported for the gear - but the input is the same - STECS 3-way flip lever: It's very annoying - and actually NOT specific to STECS. Also, it can happen with a lot of modules with 3-way levers/switches. You can simulate this on keyboard as well. It's clearly DCS input processing related, not input device related. And no, it is not affected by the "generator" on or off - as proven by the keyboard reproduction.

I have to admit I'm hardly in the middle of the campaign (very slow, I know), so I'm not sure in which mission is N2 mentioned. In most cases, for L-39 power, N1 (HPC needle) is referenced instead, so isn't that just some kind of typo?

I'm new to Viggen, but I believe this must be some kind of binding/action definition bug: I've checked the first action in the installation directory and this popped up: I guess the different value_up in the mousebindings.lua is messing things up.

This exactly... no problem with the launcher, seems nice, but I hope it will not take away existing capabilities. I so hated when config was launched only. As for FC2004, I'm in. I have all those modules in ff, but I fully support FC idea, so I'm upgrading for sure.

Server.lua (under Saved Games) is kind of override and has higher priority, Views.lua under DCS installation are the defaults. I use Views.lua as a template when needed and put the ViewSettings = {...} block to Server.lua - but here it needs to be put under the right key - DO NOT override the whole ViewSettings table in Server.lua: ViewSettings["TF-51D"] = { ... the same content as ViewSettings in installation dir ... } The keys used are internal type names, not the map editor type names (although sometimes they are the same, not always). Find that in entry.lua in the installed mod, there will be some type = assignment. I have my incomplete list here, probably there are similar tables online for complete list, but it's not difficult to find in that entry.lua. These changes in Server.lua do not affect Integrity Check - everything is green, don't worry.

Mostly, the list loads OK for me as well. But when it doesn't, I can't easily access the favourites, it simply doesn't show until it goes over its problems with loading the list. What I suggest is, besides somehow not getting stuck on the list itself (but that can get complicated as any network stuff can), offer the favourites either separately, or in the current list, if checked, simply prioritize and check those first. They must be somehow remembered on my end anyway, why not use that for more than filtering the final list? Why not just load those? (Or perhaps load first and then the rest on the background, so we can toggle it later.)