virgo47

You're very kind, @cfrag. I'll try on my own and if I get stuck, I'll write here. I don't mind scripting per se, the problem is I'm totally lost in all those options. I'll try to use the pointers you gave me (e.g. the birth event) and we'll see how it goes. One would assume that player/client birth (or re-birth) would be some elementary event available from the editor, but many stuff I considered "basic" (e.g. setting up the plane instruments after the mission start) are quite complicated and virtually unavailable for casual editors. But I'll try to have a stab at it first and report on the result, hopefully soon.

Yeah, I made it to a trigger parameter. Another adjustment is to make a specific message per plane, not per zone. I have to check whether a zone per plane would help or if I need another solution. In my case, I want to print plane specific landing checklist. But these are all minor things. Your mission example pushed me 99% of the way I guess.

Thanks a lot, this looks very usable! I'll try to modify it to add clearview option, shouldn't be a problem for a programmer. Although not what I meant by "simple" originally, this is self-contained, working well, etc. Thanks a lot. I've noticed DML before, but I thought it is overkill for my needs. But if it helps make simple things really simple.

Hello mission creators. I have a simplistic mission with a couple of planes set as Client on the approach for the landing. I'd like to display a different message for each just after I take control of the plane. I tried a few combinations of triggers and conditions, I can send a message to a unit, but it's far from my ideal, as I can either send it just once (not working for another spawn to the same unit) or repeatedly (annoying), etc. The message should be shown each time I choose the slot, as it is another attempt for the landing (or whatever I'm trying to do). The message is set for a long time and stays there through the change to another slot, but Clearview checkbox is fine for that. I can easily do it Once per plane, using Unit Alive as a condition - but not repeatedly. Switched condition/Mission start does not work at all with this condition and Repetitive action repeats the message each second... which is bearable with Clearview, but still annoying as it blinks. And it would be even more annoying if I also wanted to play a short beep before the message (which I'd like). Is there any simple solution or do I need to use some flags for this?

I use Kneeboard Builder mostly for repositioning my kneeboard - which I previously did by adjusting the ViewportHandling file in the installation directory (is there a better way?). But this reportedly fails the integrity check (no prob for me yet, but I don't like it). So I tried Kneeboard Builder - but the kneeboard placement seems to work only until the game is restarted. Is this right? Is there a way how to make my kneeboard position permanent without breaking the integrity check?

Hi guys! It was bothering me for some time that I had my default view set, but my zoom axis cradle/paddles always centered on different FOV. So I decided to explore the topic and make it into a video: It discusses zooming, setting the default view, tweaking the zoom axis, going over both SnapViews.lua and input config files to finally get the result I wanted. TL;DR version would be: zoom axis to slider, enable custom user curve (and probably also invert) find the right value for the middle point depending on your FOV (there is an equation in the video) fix the rest of the values to make the curve nice check the cradle middle position and FOV there, and now resave your default view with this FOV for zero deviance and total satisfaction. I hope you will find it informative and useful.

TL;DR: Does not relate to SnapViews.lua saving. Annoying FOV after mission load, but not serious. Now the details: I guess I got lost in my experiments with default view and editing SnapViews.lua manually while doing so. This actually does not have anything with saving the file. Every time I set my preferred view and its FOV, it is saved nicely into the file, but without HOTAS sync the initial FOV is always higher. E.g., default view FOV 20 will give you 28.2 after the mission loads, 89 will show 108.8, etc. It's not even linear! With HOTAS sync, this can be mitigated, if you have a zoom axis and it is centered perfectly on your preferred FOV - which is possible with some tweaking. Strangely though, some planes (e.g. TF-51D) do not read the zoom axis after the mission start. So you still need to tap Zoom normal or touch the axis. No problem. It would be nice if the FOV after mission start was the default view FOV. There clearly is some relation - can't it be 1:1 for a change?

Hello guys! This has been the first time I'd ever flown F/A-18C Hornet - and I used the first training mission for that. After the talk, I started to fly through the gates. I don't mind gates as a training prop, I know them from Su-25T, there are some issues with them (especially when you miss one ;-)), but in overall they are OK. However, after a few gates here, you can't see the next gates in the bright sky - unless you know the mission by heart I guess, which is not the point. You still can't see them. Strangely, the next gate does NOT scale up as it does in Su-25T or L-39 training missions. I guess this smallness is the biggest problem. It would really be great if the color of the gates could be adjustable - be it a player, or just by the mission author. E.g. red would be better here. Please, consider these things, because the mission would be quite fun and instructive - but when you see the gate too late you have to fly a circle to get to it again and it really sucks. The Hornet seems great, BTW, love it.

Exactly, this is for explicitly saved profiles which can be done from the dropdown menu accessed with the little triangle next to the device name in the Controls setup. This way your files (e.g. for backup reasons) are nicely separated.

EDITED: Default view is fine, just initial FOV changes for whatever reasons. I've just encountered a problem with default initial FOV. If I set the FOV for in-game and save the default view, it shows the right view under [13] FOV. But if I edit it in the file and change it, the plane has a different initial FOV after the mission starts (somehow higher, there seems to be some shift). Strangely, when I change the FOV now and save it again, the right default FOV is used as an initial FOV after the mission start, again. Even if I change anything else in the file, the default initial FOVs are broken - for other planes as well (probably for all the planes)! This means that any backup/restore of this file always breaks all the default starting FOVs. After the first fright (and first version of the report) I tried Zoom normal and the expected value of FOV is set (relief). Initial FOV can be worked around by zoom axis curve to tune the center position FOV, with the HOTAS sync at the mission start enabled.

Yeah, you're right - works fine on the latest version. I'm sorry about it, I need to get used to manual updating before reporting anything. I'm looking forward to auto-updater for MT or MT becoming the mainstream version.

I'm curious about the Y-axis range and how is it modelled. For Su-25T in particular, but the question is probably related to other planes too. I have my stick with some curves, but both X and Y axis are set in the same way. If I pull the stick completely, I see this in the controls indicator: If I push, the stick in the cockpit stops moving, when the indicator shows: But even beyond this point, I can see not only indicator change, but also see/feel the action, all the way up to this indicator status: Looking at the outside view, the elevators clearly move in the whole range. Why does the indicator look asymmetric and should I care? Is the action realistic? Why does the stick stop mid-way while pushing? Is this in any way related to Special options like this one in F-5? Thanks for any insight into the topic. And yes, I know that 99+% of the time I don't push that much and planes probably don't like it either.

Revisiting this after many months with 2.8 and the contrast seems better. Pictures are not aligned, this one is more up close, but it is also overcast, like before. But the brightness and contrast are both much better and I'm actually seeing what I'm shooting at. So I guess it's somehow resolved.

I've tried Su-25T after some time and I've noticed that there is one too many г - one of them obviously instead of K.

Ah, now I understand what you meant... on the fly in the editor and map, got it.

Yeah, I report it as a bug, because the tooltip clearly lies to us. It's not critical and it's true I don't need to restart the game after the change. But I'd be careful calling it "on the fly" in case of flight simulator. Gameplay options are not available inside the mission - for obvious reasons, as it would be difficult to magically change the instrument/cockpit. Still, for players switching between eastern and western planes it would be nice to have this as a plane setting, not a global one.

I know that Kursant campaign warns about Imperial vs Metric, but I believe it's a bug that the cockpit air speed gauge totally changes when switching this option: Notice what the tooltip says - "NOT change indication in the cockpits". I believe that switching the gauge from metric to imperial for a single plain should be in its Special section. Doesn't the Units option also change things in the editor, etc.? Why can't I have Imperial selected for other purposes and stick to metric for L-39 (and similar aircrafts) only for immersion?

It does work properly now in openbeta! Yeah! https://www.digitalcombatsimulator.com/en/news/changelog/openbeta/2.8.3.37854.1/

Thanks for the clarification. I don't know why I haven't checked the manual as I mostly do. P-51D manual says it clearly - they are spring loaded indeed. That means the bug is not affecting me as a keyboard user, only the mouse user, I see. It's not a biggie then. But of course, the things like this are confusing.

Hi, I noticed people mentioned this in other threads, but I don't see the one for it, so I'm writing it. Both switches for Radiator Air Controls have 4 positions when used with mouse - and can stay in any of them. But with bindings (e.g. LAlt/LCtrl+A/S) these seem to be spring loaded - plus there is no binding for the central position either. EDIT: The binding behavior is correct, the mouse is wrong.

Flaps are fixed, I can confirm that, which is great. But I can hardly hide my disappointment about radiator switches and canopy open not working via keyboard/buttons. But at least something was fixed. Thanks.

Hi, Flappie, thanks for your time! I replayed your track and it has cut transmission on my computer - see 1:15 in this video: Now, to correct the description - changing channels to wrong and back doesn't seem to affect it (my mistake), but I can reproduce it super simple even with empty mission, Kutaisi hot start, I can communicate with tower (\ or radio thumb button which I use predominantly in L-39, doesn't seem to matter) - everything works. Then I flip RDO switch off, try a single communication... dramatic silence, as expected... then I turn the RDO back on, try the communication again - and the result is cut transmission, as demonstrated in the video. I attach the logs from the time I replayed your TRK. I can create my TRK as well, if needed. I don't think I have crazy custom modules - just Tacview and DCS-BIOS for external controllers. And A-4. dcs.log.zip

If I start a plane (L-39C/ZA in my case) on the Caucasus, I try to communicate with the ATC (R-832M menu, F5, F1, F3 to request startup)... nothing is heard because I didn't turn on the radio or have a wrong channel. As expected... OK, I set it all right, try again and this time I see the response message, but I only hear the first word (if at all) from the actual voice message. All the subsequent messages have sound cut off after they hardly start or I can't hear anything at all. The text messages are fine. No other sound issues on my end, this clearly is somehow broken after a failed previous ATC comm attempt. Anyone else with similar problems?

Perfect, thank you very much - that is the name I was missing. Now I can easily find the explanation and it all makes sense.

Hi Flappie, thanks for response! My problem is GPU, not CPU related. It's not a big deal, just surprising. A few numbers for illustration. Standing on the RWY in a hot L39 doing nothing, totally empty mission - my CPU/GPU % is ~16/80. When I turn on the NS430 popup with its default (CDI) screen: CPU/GPU is ~17/97 (CPU is clearly a bit higher, but not much, but GPU jumped by 17%) With NS430 on a map screen: ~17/95, no change in CPU, but for whatever reason, this screen is less GPU intensive(?) The terrain screen - more or less as the map. That means various menu or other screens are easily more GPU intensive than map/terrain. But the popup itself takes anywhere around 15% of my humble 3060 GPU. I'm attaching day and night mission tracks, but while these reflect the actions, they don't show the resizing of the popup which creates many more brightness "effects". BTW: As for the cyan border mentioned - I'm not implying it should be everywhere. The wrap-over of the pixels is the problem (seems like some +/-1 error to a humble programmer like me). Even in original GNS430 the map upper edge does not have the cyan border - it's OK. That's why I've created the following video demonstration as well: Hope that helps and shows it clearly enough. ns430-night-brightness-problems.trk ns430-brightness-strobing-problems.trk