virgo47

In the A2A MSL training (the first training for A2A and radar) the voiceover says there is unlimited ammo, but there is not. The next two missions are fine and set correctly. I checked in the ME and it really should be a quick fix. As a minor confusing point, the voiceover also says "When radar range setting is 40 nm or less, the radar acquisition symbol is visible." - but it should be 20 nm or less. With 40 nm range the symbol is not visible and TDC can't control it. This is how it works as of now, and also matches the steps from the manual, p 213. But I guess the voiceover fix is unlikely. After all, have you ever gone to a school where the teacher was always right?

On Caucasus, most of the aerodromes have a preferred direction when there is no wind (or matching upwind). To "reverse" the ATC instruction from their defaults just make the wind go against the default and set it to 5 m/s or more. There are a few exceptions, some mentioned above: Batumi is always 31 for TO and 13 for landing. Gelendzhik 19/01 for TO/L, respectively Nalchik 06/24 TO/L Novorossiysk 22/04 TO/L Sochi 24/06 TO/L And then there's Soganlug with ATC providing the wrong instructions - it sends you to the right approach starting point but reports the other RWY (reported here). I didn't do such detailed tests on other maps. So shortly: In general, aerodrome prefers some direction and if there is strong enough opposite wind, TAC reverses the instructions - including beacons, as available (e.g. only approach NDBs are on). Some aerodromes have one direction for TO whatever you do, typically with a reverse direction for landing. As for the prefered RWY for TO/L, those are the bold ones in the following table:

I'd love to recheck it - but the first thing I encountered is this when I wanted to drag the NS430 more to the center of the screen before resizing it: In words: the header/title bar moves, but the window does not - the window snaps after I hide and reshow it again (Close Look to NS430 On Off). My first reaction was "REALLY?!" Am I the only one encountering this? Following this... I was not able to resize the window. There was no change in the mouse cursor and no way to resize the window. I barely stop myself from being sarcastic (like "it's really not a problem anymore"). Again - am I the only one with this problem? EDIT: I'm actually glad there is a change at all. It gives me hope we're heading into the right direction. This is probably just the effect of "NS430 inoperable. Not in 2D neither 3D" in Known issues for Multithreading. But the post above mentioned that it works now in MT. I have to disagree.

Generally yes, I totally agree, and I never thought about it for other planes. In my original post, I forgot to mention that "Trim neutral" is a checklist item for landing this plane. Unless "neutral" means "to trim it" - but that doesn't sound right. I don't know whether there is any reason or danger when landing this plane trimmed for the current situation, but I'll probably ignore the "neutral trim" item for now and see whether it makes landing easier or not. Thanks.

Hello guys, it's pretty quiet on this part of the forum, but I'll try again. At first, it puzzled me why I needed to push the stick so much in landing instant actions, while in most other situations I needed to pull it in most cases. I thought "perhaps it's the Nevada thin air" (silly me), but in the end, I'd bet it's the fuel level! When I start the plane and take off, I have more fuel - which is in the front. When I land in some of these instant actions, it says I have 10-15m of fuel, hence a comparatively lighter front, hence rising nose and the need to push the stick. But I need to push the stick (or, conversely, pull with a full airplane) quite a lot - with any fine curve I'll easily get to the less comfortable steeper part of the curve. Do you really never trim the plane before the landing? Is it reasonable to land without any trim when using two quite a "different planes"? Or do you not use any curve on this plane? What are your best practices? Any tips are dearly welcome.

Radio seems also dead for me... but I found both displays eventually - just not where I expected them. They move around in a funny way when I look around, but they are never in front of me really.

I'm confused about the Fuel display - it did not come alive in the cold start, neither does it work in the free flight instant action. Is it bugged somehow or do I need to do something to make it work? I checked the manual, but from the cursory check I can't find any explicit action mentioned around it. Also, the "Fuel indicator mode" buttons are not bindable at all.

Actually, I wanted to bind the flashlight (pilot torch) to the mouse as well (as for any other aircraft) and now I see that nothing can be really bound to the mouse buttons! Also, I cannot bind the eject action (and many other button-suitable actions) to my throttle or joystick either. It can be pressed on the keyboard, but not on the buttons. I'm surprised by these things, this is the first plane where I have had such problems.

For most planes, I use mouse button 3 to switch between the clickable cockpit and mouse view. It's super handy, the hand is already on the mouse... but Christen Eagle II has a dark/disabled field in the mouse column for this action. Why? Is it just some simple omission? It seems like an inconsistency (read "a bug") to me.

Hello guys, I can't find the answer to the purpose of this general input profile. What is it, when and how does it work? I'd assume it is some kind of default to which diff.lua for a particular airplane is added - but this seems NOT to be the case, because I have some camera/snap views redefined in General profile but it doesn't work at all for a new plane I get in DCS. Instead, some kind of "mysterious" default (which probably can be found somewhere in the installation directory) is applied and the diff.lua starts from there. That diff.lua is also a bit fishy - you can't simply save it and then edit it - because the things not modified are simply not there. Some option to save non-diff (complete) profile would be great, but in the end I can work around diff.lua mechanics as well. But when does the General profile apply - this is still puzzling me.

+1 This happened to me in L-39 Albatros as well (with mirrors) on Friday but I couldn't find any thread for it and wasn't sure if it's not just some GPU driver thing (or something in the shady area between GPU and the game). But I've seen it in Growling Sidewinder's video today, so it seems like something with the new patch. And I found this thread. Good to know it's not just me because such bugs bug me the most. Definitely not Sinai-specific though, I don't have that map. I experienced it with the Persian Gulf map.

I disagree - I started the game first with the very same version(MT does not auto-update) and it forgot my authorization as well, not more than 24 hours since the last time I'd played. I actually started the update after I encountered the problem. So it doesn't quite work the way you suggested, at least not on my end. Luckily, I planned to play Su-25T today anyway (for real, no sarcasm). But it didn't make me feel better in general, as just a few days ago I was trialling the wrong version of Normandy (actually, on the shop it still says my trial "Ends in 175 days" for Normandy 1944, at the same time my trial for Normandy 2.0, which I'd never really seen, is over), so I'm not sure how consistent some things are between various customers. Not a big deal after all, but with so many modules and such complexity, it sometimes seems like QA is a bit behind.

For the sake of completeness - I first got unauthorized with 502 BEFORE the update (MT version does not auto-update), so it doesn't seem to be related to the update. Yesterday, I played, today, because of a single 502, I couldn't. Some kind of offline mode/authorization cache would be appreciated. A few days would be more than enough. BUT: I'm back in business at this moment, seems the problem is fixed on their side. EDIT after less than 2h: Back to 504 again... I should have kept the game going in the background just to stay authorized so it seems. This really sucks, I put the head tracking on, getting ready, knowing it's up again... and it isn't.

@YoungBuckThanks for the info, I haven't seen it. I am actually patient, I see there is a new update as well with tons of new stuff, great. I'm just suggesting a more graceful way how to at least let us play the game in the meantime for the future. Things happen, I know. BTW, my code was neither 503 nor 500, it was 502 (Bad Gateway, the same currently often visible on their page).

I failed authorization today (after the release of Sinai trailer, when DCS web seems to be very slow as well). The silly thing is that it said it would use "saved authorization" - yet it unauthorized all my modules. Requiring online for even starting the game is something I never liked, but at least think about some robustness into it all. And cache some token or whatever for at least a few days. Rather fail in favour of the users. Please.

I've started trialing Normandy 2.0 2023-05-17 and saw low-res Paris and London as well as "Green cliffs of Dover". Product detail page says my trial is ending in one day, so I thought everything is all right. I blamed the low-res Paris/London to my setup, but now I wanted to see it one last time in high-res - and it really seems like I have some kind of upgraded hybrid, but not full 2.0. My textures are high, I tried to mess with the detail sliders - but still the buildings are low-res. So obviously, it happens.

Yeah, sorry for not being clear. Next waypoint works fine, as always, it even wraps around. Previous waypoint works, but without proper wrapping - as you pointed out before. The strange thing is that with this 0 WPY it cycles 0-1-0-1 when trying to wrap. But in missions where 1 is the lowest WPY number Previous waypoint just stays on it (sans the short blink when trying to wrap around). Either way, Previous waypoint does not wrap correctly - just doing it differently when 0 WPY is present. I got used to it already and take it as it is.

@IronhandI'm not sure how it works for you, but I tried the mission "F-15C Training - 13 - Intercept (Practice Mission)" and it actually starts unpaused for me and 0-1-0-1-... cycle works all the time for me. Also, going up the waypoint cycle, I wrap up to 0 in these missions. So, "0" waypoint is reachable for me in these missions anytime, even when unpaused, using either Next or Previous waypoint shortcuts.

Thanks for the reference, now I see why the text search didn't help. My problem with VS BST is, that when I go to vertical mode, and then back to NAV (1), it still says VS BST in the second row until I turn off the radar. Again, I don't know whether this is intentional, luckily I found the tip on the forums previously - just turn off the radar and it immediately shows the distance to the WP. When going to BVR or BORE mode and back to NAV, there is no problem, even when the radar is on. (Adding to my confusion was the fact, that NAV/ILSN line is actually shown in most modes, I didn't expect that. When I got that "stuck VS BST" problem, I was questioning even things that were OK.) This is happening to me in the custom training missions from here: https://www.digitalcombatsimulator.com/en/files/3313014/ (e.g. BVR Intercept practice, but most missions have 0 WPY selectable) Thank you both for the answers and tips. I'm enjoying the F-15C quite a lot, I'm reading the manual too actually, but slowly. So I'm asking whenever I can't find the answer, or just don't get it even after reading. F-15C is fun, I don't mind the details or cockpit textures, but it would deserve more dev love nonetheless.

You're right! I encountered this first on a different mission with waypoints 0, 1 and 2 and that's what confused me - although it still is strange, as it cycled 1-0, not just 0 (not sure why/how 0 was the first waypoint). In the free flight, I totally forgot to try it from the higher number waypoints - and it actually DOES go down properly, but it does not cycle to the last one and ends on the first waypoint. A bit unexpected (makes returning to the last waypoint in case of wrapping up to the first one difficult), but I'm not sure whether it is a bug or not. All these things are quite a lot to get used to and not always easy to find in the manual without already knowing the solution and they compound with other strange things. E.g. sometimes you get "VS BST" in NAV mode instead of the distance - turning the radar off helps, but other times it shows distance just fine even with a radar. No idea why, and "BST" is nowhere to find in the F-15C manual. Luckily, many things are already discussed on this forum already. Just finding it is tricky sometimes. Thanks, guys.

I found this "CPU" mentioned, yet totally unexplained, in the F-15C manual - and in this thread. Can someone please explain, what is the meaning of CPU acronym and also why it's used instead of AoA in the manual?

I can see I'm not the first one having trouble with waypoints and navigation in F-15C, but I can't find the exact problem I have. I'm flying a mission where I can see 3 waypoints on the autogenerated kneeboard pages. I am in navigation mode (1). I have custom binds for Next/Previous Waypoint, but both custom and default act the same way. When I use Next Waypoint, it goes 0->1->2->0->1... just fine. I'm not sure why 3 is not there, perhaps it's only for landing, but somehow it cycles. When I use Previous Waypoint, it goes 0->1->0->1... and it never goes to 2. But it seems to flicker to something going down from 0 just for a moment, but it's so fast I can't read it. A related strange problem also is that sometimes NAV mode is "inert" and I can't change waypoints at all. I have to reselect it again. This happens after a cold start, one sees NAV mode, but it's not a working nav mode yet, and I believe I encountered this also when returning from other modes. I'm attaching a short track from standard free flight Instant Action on the Marianas. Previous waypoint there just blinks on 1 (not sure why it went 0-1-0-1... on another mission). f15-prev-waypoint-problem.trk

Thanks @Rudel_chw for mentioning this. I know about plane-specific kneeboards and use them, but I wanted it as a message. I haven't used mission(+plane)-specific kneeboards yet, perhaps I'll consider it in the future. In this case, I like that message is condensed compared to a kneeboard.

The debugging was not very fast for a newbie in Lua (I used some online Lua demo for simple stuff, but some errors appear only during the mission load)... but I got what I want with the following script (Mission start trigger, obviously): -- Let's call this "my library" of reusable stuff for the future. dunlib = {} -- duration in seconds function dunlib.messageUnit(unitId, text, duration, clearView) trigger.action.outTextForUnit(unitId, text or "Undefined message!", duration or 10, clearView or false) end -- delay and duration in seconds function dunlib.messageUnitDelayed(unitId, text, delay, duration, clearView) timer.scheduleFunction(function() dunlib.messageUnit(unitId, text, duration, clearView) end, {}, timer.getTime() + (delay or 2)) end -- cm = current mission cm = {} -- Just a small demo of messages for a few planes. cm.messageTable = {} cm.messageTable["L-39C"] = [[ Hi kursant... get it down without any damage, will you? ]] cm.messageTable["L-39ZA"] = cm.messageTable["L-39C"] cm.messageTable["F-15C"] = [[ Fly, Eagle, Fly! ... Oh, I mean land, actually...]] function cm.defaultIntroMessage(event) return "Sorry, no instructions for " .. event.initiator:getTypeName() .. ".\n" .. "Get it down somehow..." end function cm:onEvent(event) if event.id ~= 20 then -- We only want a "player enter unit" event: -- https://wiki.hoggitworld.com/view/DCS_event_player_enter_unit return end dunlib.messageUnitDelayed(event.initiator:getID(), cm.messageTable[event.initiator:getTypeName()] or cm.defaultIntroMessage(event), 3, 600, true) -- 3s delay, show for 10 mins, true for clearing previous messages end world.addEventHandler(cm) I didn't use DML for this after all, but I'd not get there this quickly without your pointers. Thank you very much for the directions.

Probably way too late to the party, but I've solved calling the function with multiple arguments with on-site function call like this: function dunlib.messageAll(msg, duration, clearView) trigger.action.outText(msg or 'Undefined message', duration or 10, clearView or false) end function dunlib.messageAllDelayed(msg, delay, duration, clearView) timer.scheduleFunction(function() dunlib.messageAll(msg, duration, clearView) end, {}, timer.getTime() + delay) end The first function just prints the message, and the second one does it with a delay and calls the first one with function() ... end construct, not using the second argument {} at all.