virgo47

If any time modification is available in F-14 (I don't have the module, so I don't know), let's try to ignore it and use the one in the UI layer instead: In UI layer, you can find the "time" actions: These should work in all the modules.

Man, thanks, I didn't expect this answer. As a programmer, I understood the first and second paragraphs, although googling for DCS acceptDecimalPoint didn't provide any handy pointers (yet) and grep showed the option is used in various places (dll/dlg file, nothing in Config though) but from the look at it not related to this dialog. So my simple question - where exactly should I adjust this option? In/Out using a function that many other things rely on... pitty, but I can understand it will not be changed, although currently the output is very coarse (and I suspect it is floored, but not sure about it). The info about AB is a bit over my head (yet). I'm fine with current options, just not with the lack of precision. And the info about curvature supporting more "rows" - that's cool. But that asks even more for more precision for the values as well. But as "more keys" are available in the config only, I can enter the precise values there. User curves are not my main concern (but it may be for others). But curvature with more precision would be cool. Thanks for all the info... I'm going to further process it now.

Currently, we can only enter whole numbers (0-100) for the Deadzone, Saturation X/Y and Curvature - and also, only whole numbers are shown in In/Out fields. This is sometimes too coarse, for instance when matching the AB detent with Curvature (Deadzone/Saturation is probably OK, but there is no reason to not allow it there as well). The internal values are decimals in 0-1.0 range, the precision can be much higher, it is probably not necessary to allow any/max number of decimals, but two - or even the single one - would add tons of precision to this kind of setup. The same would be also great for user curves, of course: Here the difference of 1 is often very coarse on some ends of the curve. Currently we have to go to Lua files for any more precision. As you already work with decimals in the config info anyway (x100), it would be great if UI allows for decimals as well. Thanks.

FAQs are that long for a few reasons - this one being one of them. A note about the different Trial version should be also clearly visible on the shopping page. Trialable non-sellable module (as it appears on the shop now) would be probably more understandable. Otherwise, it will always be confusing when Normandy 1944 is the name of the module we download for a trial. I'm not sure this is good for Ugra Media either, I hope you'll manage to come to a less confusing setup. Best luck and thanks for your patience.

When I wrote "lies", I meant it technically, I know there is no bad intention. Perhaps it's all part of the confusion - there are three versions: The old Normandy 1944 The new Normandy 2.0 (which is not trialable at this moment) And then the updated version - how is this one called? "Free Normandy 2.0 update"? I always assumed that the modernized Normandy 1944 is still called Normandy 1944, it's just the upgraded/updated version of it. I looked at the FAQs and the map shown there, and it is very hard to assume that Normandy 2.0 can mean "modernized Normandy 1944". I eventually learned (on this thread) what version of the map I trialled - but is that the map you want to (also) call Normandy 2.0? Perhaps I'm not clear, but what should I write under the screenshot of low-res Paris? "Normandy 2.0 trial"? We can be descriptive here, but that version should have a clear and distinctive name. Also, isn't it a bad precedent that the trial and full product may be different? If the updated version of Normandy 1944 (which is what I see in the game) is used for trial, let only that one be trialable. Disable trial from Normandy 2.0 in the shop. Compare the following scenarios: I trial Normandy 2.0. Shop says it's Normandy 2.0 on trial. DCS downloads Normandy 1944 anyway (which I consider just a naming problem). And I see the upgraded Normandy 1944. Confusion. I can't trial Normandy 2.0. I trial Normandy 1944. The shop clearly says it's Normandy 1944 on trial, Normandy 2.0 doesn't offer the button and doesn't show confusing Trial info. I download Normandy 1944. Yes, it is the upgraded version, but not the "true" 2.0. No confusion. Sorry, if it seems like pushing it, but I didn't start this thread, many people had the problem. The name must be totally clear. It would be best to stop using Normandy 2.0 with whatever adjective for the upgraded Normandy 1944. Of course, we appreciate the upgrade, but isn't it still Normandy 1944? Didn't all the users of Normandy 1944 get it? If yes, then it's just the most recent of Normandy 1944 - or not? EDIT: When it comes to Normandy 1944 "upgraded" and "updated" conflate, as it is a free upgrade, it acts as any other update of a module. Correct me if I'm wrong.

Hi @BIGNEWY, thanks for looking into it. I thought the question of whether Normandy 2.0 should be trialable was resolved a long time ago, that's how I also read your answers in this thread from May 2023. Of course, I have no problem with whatever decision. Not-trialable Normandy 2.0 is fine with me too, but this should have been decided at the release time. However, the communication around it should be clear to avoid confusion, no Trial for the map should be offered in the shop. The current state of affairs is very unfortunate. Now I know what I know, but when I first saw Paris in "Normandy 2" I was underwhelmed and thought the problem is on my end (graphics settings, etc.). Also the info in the shop must be clear, currently, the two versions of Normandy are somehow connected (when I trial one, I also trial the other one). I guess the duality is because you want users with 1944 version to upgrade to 2.0 version, not to have them as separate products. But the result is that the shop "lies" to me when it clearly states I'm trialling 2.0. When you introduced Black Shark 3, it was clear that BS2 was trialable and BS3 was not, there were no problems. I hope when you figure out the Normandy problem you will avoid it in future product upgrades and their trials. Trials are a great thing, thanks for those, not sure what data you have, but in my personal experience they often lead to purchases.

Hi @BIGNEWY... still no answer from the team?

I tried both pulses and button behavior in VKB software, no difference, but also tried with the keyboard keys. The issue is either solvable on DCS end or not at all. As I described, even if the extreme position button is held (and SW indicates so), it will not register anymore if it was pressed during the "animation" (or whatever causes this behavior) to the middle position. In other words - even if the button for extreme position is press and held (not "pulse" behavior), it doesn't matter. DCS will ignore it if it came too soon.

One can also mess with <dcs-install>/Mods/terrains/<terrain>/beacons.lua files and "mod" those, that makes more sense as it adds stuff into the world, but it's not clean and I'm not sure whether it passes an integrity check. I've seen some threads asking for mobile RSBN or NDBs for concrete missions, I'm not sure what of it is currently possible, but this is a different topic. I understand how this happened to the MiG-21bis module, I believe it should have been fixed and aligned with the "real" world, but I doubt that will happen. From the look at the MiG nav data file, I believe there are more RSBNs, but way less NDBs on the Caucasus map. So for navigation, you win some and lose some. At least I understand it now. God knows how much I don't understand yet. DCS ecosystem keeps surprising me.

Aha, so this is not by DCS/ED design, which is good to hear. Considering the MiG-21 module history I can understand how this happened. Thanks for the explanation.

When I was researching RSBN for MiG-21, I've found that there is no such thing like RSBN for the map - or perhaps there is a default but the module can have its own info, even totally incompatible with the map. In case of MiG-21, this seems to be in <dcs-install>/Mods/aircraft/MiG-21bis/Cockpit/Systems/R_NAV_data_<mapname>.lua files. I don't know whether this is a mod thing, and I understand why this may be mod-specific, but it makes the navigation system unrealistic because one plane has different signals than another one (in my experience L-39 vs MiG-21). But now I belive, this is not a bug, but... well, a feature, encoded in the file R_NAV_data_Caucasus.lua: { country = 'GEO - Abkhazia', --1 / absolute 41 freq = 395, lat = 43.09889, long = 40.57861, location = 'FH27 Gudauta RWY', code = '..-. .... ..--- --... ' --/N/ FH27_ }, It is very confusing that modules can see different things on the same map - although it is flexible. I can understand modifications on the mission level, but when a module sees a different RSBN than another module, or NDBs transmit different signals for the same NDB with the same frequency (this one probably still SHOULD be considered a bug and the codes should be fixed), this sounds more like a modeling problem on a DCS/ED level than a module problem. It definitely makes the matter much more complicated. World objects suddenly are module-specific objects. I don't even know what to make of it at this moment and will have to give it some time and look at other materials with this info taken into account.

BTW: I've noticed that at least training missions #5 and #6 (radar ops and AA missiles) have the FARP in a better position:

Exactly. Many modules offer both separate ON + OFF bindings and additional toggle binding for switches. Does this require a separate "device_command" that is not implemented for MiG-21bis or is there a way to somehow "compose" such a functionality from existing ON + OFF bindings? I tried value_down -1 (inspired by how L-39 does it), but that didn't work.

For my respect to Rudel, who helped me a few times before already, and because my first post really was a bit harsher than I wanted, I'll just cover one issue here: Yes, it does, if you use Quaggle, preferably with OVGME, as I described here: However, there are still many outstanding issues. I like flying with MiG-21Bis, but the bindings are lacking a lot. Many switches are either toggle or separate on/off, but mostly not both. Some axis bindings lack inc/dec bindings (pipper brightness for instance, and yes, I actually use this in all other modules). This applies also to the commands you can dig out from the module's LUA files. There are missing commands, or I just can't find them with my skill, but I suspect the first. Even example files for Quaggle injector show only commands setting some values to concrete values, but no toggle or inc/dec actions for those. And then there are some lazy controls like RSBN channels that are easier/faster to mouse click than to bother with any bindings (again, I use this happily on L-39). I believe these are usability bugs. We can call them missing features, but that doesn't change the result. I still understand that module needs some minimal maintenance even if nothing changes, just because DCS itself changes, and we don't see that kind of work, but then we also don't know how much of work that really is. I like that Magnitude 3 LLC have a public bug tracker now, but we will see how that helps.

I found this when googling "Missione editor dictionary cleanup" after noticing the same problem. Perhaps not a biggie, but definitely making a programmer in me uneasy. I experimented just a little with the information that the keys all start with DictKey_... and when I unzip the mission to an empty tmp directory, I can then run the following bash command: grep -r DictKey_ --exclude=dictionary | sed -e 's|^.*["'\'']\(DictKey_[^"'\'']*\).*$|\1|g' This ignores the directory files and assumes the DictKey_ strings are in double or single quotes (Lua strings, ME seems to use only ", but scripts can use ' as well). This is just a first step, as you still need to go through the dictionary file(s). Based on this I created the attached bash script, place it out of the extracted mission directory, but run it from there (current directory is in the extracted mission folder) - example output: $ /h/work/.../scripts/cleanup_dictionaries.sh Used keys: DictKey_descriptionBlueTask_3 DictKey_descriptionNeutralsTask_4 DictKey_descriptionRedTask_2 DictKey_descriptionText_1 DictKey_sortie_5 Processing l10n/DEFAULT/dictionary Removing: ["DictKey_ActionText_10"] = "L-39 is doing it... maybe!", Removing: ["DictKey_ActionText_6"] = "TEST #1", Removing: ["DictKey_ActionText_7"] = "TEST #2", Removing: ["DictKey_ActionText_18"] = "", Removing: ["DictKey_ActionText_13"] = "Test G2", Removing: ["DictKey_ActionText_16"] = "Alive once!", Removing: ["DictKey_ActionText_14"] = "xxx", Removing: ["DictKey_ActionText_9"] = "", Removing: ["DictKey_ActionText_11"] = "Test G1", Removing: ["DictKey_ActionText_8"] = "TEST #3 (Doesn't make sense!)", Removing: ["DictKey_ActionText_15"] = "Alive", Removing: ["DictKey_ActionText_17"] = "", DONE After this, I renamed dictionary.fixed to dictionary, overwriting the original (this also can be automated, if you feel brave). This version can be run repeatedly without changing the dictionary file. If you uncomment the two mv commands after the done < $dictfile line, it will do it for you, but then it overwrites the bak file the second time you run it. Obviously: TRY AT YOUR OWN RISK I haven't tested it on any complex missions. After the process, zip the content of the mission directory into a new file (without the directory itself), try to open it in ME, check it, resave it (DCS zips differently than my tool - although that is probably not a problem) and try to play it. If it works, good for you. cleanup_dictionaries.sh

I played the Landing training mission and followed the final "taxi practice" to my parking spot. But the mission starts in the air and the exact spot is not totally clear. I parked nicely next to the MiG-21, I was aligned with it, but I was obviously not triggering a zone I was supposed to. So I went to the ME to see what was going on. I went from behind, somewhere between "04" and "05" in the picture and stopped just before triggering the zone. The zone could be just a bit bigger, the existing heading condition should cover any false positives. Perhaps the zone was OK on an older version of the map, I don't know. Also, this mission has that FARP that should be moved if it can't be removed. As a side note, I like the tone of these other missions (2-4) in comparison to the first training mission. I was afraid all the missions would be that sarcastic and I'm glad it's not so, which is much better.

I have the latest OB and tried the Su-25T training missions for CCIP and CCRP and the pipper behaved correctly. Do you have any mods activated? The only thing I've noticed is that in the CCIP training mission, I select A2G mode as instructed, but after the ripple interval and quantity adjustments when the line starting with "Those are the basics..." ending with "Press the space bar to unpause the mission", I'm back to the navigation mode and I have the course circle instead of the pipper. But this doesn't seem to be the same issue you described (and not that serious either, just confusing). I wanted to confirm it, but it works fine on my end.

I'm going through a user's mission for the cold start on Godauta, with the NDB 395.00 and code XC. This NDB is in the map sector FH27 (or FH2873 if zoomed in all the way). I checked the morse code of the NDB of the Godauta - which should be the morse code for XC (callsign of the NDB). But I was surprised that the morse code of the sector (morse code for FH27) was heard instead. I don't think various planes should receive different Morse codes for the same NDB, so I assume this is a bug. Also, the loop of the NDB is quite fast (compared to other planes) - unless I'm misled by the longer transmission of the (longer) code itself.

I also noticed this. I use encoders for RSBN channels in other planes with the system, but this doesn't work well in MiG-21, as it requires a long press time to do the tick - this results in many clicks of the encoder to change a channel by one. I found some custom commands using bigger value_pressed value, but this results in the same lazy behavior, just with different jump (e.g. 10 channels). This makes only the mouse a viable solution for fast clicking to the channel buttons. Would it be possible to make it encoder-friendly? I don't like the lazy feeling on the buttons/keys either, so it should not make that experience worse.

This is perhaps a more general question, but I don't know where to ask it - and as I'm trying to solve MiG-21 Radio squelch on/off binding, I'll ask here. I have Squech on and off commands available for binding: {cockpit_device_id = devices.RADIO, down = device_commands.Squelch, value_down = 0, name = _('Squelch Off'), category = _('Radio Communications')}, {cockpit_device_id = devices.RADIO, down = device_commands.Squelch, value_down = 1, name = _('Squelch On'), category = _('Radio Communications')}, There is no obvious on/off toggle for binding. I tried to search for something about this topic, but the results were quite noisy, mostly related to the "toggle switch" on some joysticks and how to deal with them - but that's not related. Is there a way how to construct a binding for toggle? Is it some different value or something else? Or is it simply not provided by the module coding?

Not a fix, but a workaround without the need to modify the installation directory directly: Well, actually, there is a mod, so it touches the installation directory, but OVGME+Quaggles' Command Injector makes this all much easier now - and after that you only add to the Saved Games, so it's much cleaner (no edit of the Mod in DCS install anymore).

Great! BTW: it probably goes over multiple missions, I encountered it in the 3rd one as well (although there it is merely an aesthetic problem). Are you aware of that?

Thanks to @Rudel_chw and his gentle nudge I found a reasonable solution/workaround: Install https://github.com/iquercorb/OpenModMan (newer mod manager by the same author as OvGME). https://wiki.hoggitworld.com/view/OVGME if you don't have it (I didn't) for better management of mods that go to your DCS installation directory. I checked this video on why and how, there are probably others, but it is quite simple and useful. Good value proposition. It's not strictly necessary to use mod manager, but it's a good idea for cleaner mod installation and uninstallation (e.g. before DCS updates). Download https://github.com/Quaggles/dcs-input-command-injector mod, put it into the "mods" dir you created for OpenModMan and enable it. The rest happens in your Saved Games/<dcs> directory - which is a great thing. Create InputCommands\MiG-21bis\Input\MiG-21\mouse directory there. The first part (InputCommands) is the root of the "patches" that Quaggles input injector uses, the rest is the structure that copies the Input file structure under <dcs-installation>\Mods\aircraft. Copy the provided default.lua there. I added just a few commands I wanted, but you can copy anything from <dcs-install>\Mods\aircraft\MIG-21bis\Input\MiG-21\keyboard\default.lua - assuming the action is available for the keyboard. When copying, remove the binding (combos) part from the line, e.g. from: {combos={{key='NumEnter'}},down=iCommandViewAngleDefault,name=_('Zoom normal'),category=_('View')}, make {down=iCommandViewAngleDefault,name=_('Zoom normal'),category=_('View')}, It's OK to leave the trailing comma, don't worry. Example for clickable cockpit command: {down = iCommandCockpitClickModeOnOff, name = _('Mouse cursor cockpit mode'), category = {_('General'), _('Custom')}}, There are even projects providing some bindings, e.g. https://github.com/Munkwolf/dcs-community-keybinds/tree/main/InputCommands, but there is not much for MiG-21 mouse in this case. The provided file DOES NOT assign the actions to the mouse yet, although it can be done as well (providing the proper combos, I guess). However, now you can assign it in the DCS. The cell in the mouse column is enabled and can be assigned. Works very well and it's not such a hassle as I'd expect. On a side note, I was surprised that some modules (e.g. L-39) don't have any defaults for the mouse in the DCS installation directory, yet it works somehow. This is probably a mystery of a different implementation of those modules. default.lua

First an apology for the overly dark and not fair assessment. I play mostly a bit in the evening, mostly single player, and I like to go through the single player content. That is what affects the experience a lot. I've heard MiG-21 in the sky is a good module and I'm looking forward to get there. I understand that keeping up with the DCS updates is difficult. If the plane is done, I don't want new features or even variants of the plane. Even if I wish something, I don't feel entitled to that and don't judge based on that. I've heard some devs do it, which is great, but I'm a different kind of SW developer too, so I understand the burden and priorities, etc. What bothers me most are the bugs... and yes, also missing binding capabilities. Not implemented there is "prohibited" on my end. That said... Thanks for the tip. I'll check those lua fixes you mention, although I don't understand why I have to do it. But I will, because I want the mouse to be consistent across modules. Nice mission and you're right. Of course, I can't do missions like these for a new plane, where I struggle with buggy training missions instead. I took the wrong path. In general, I know you do a lot for the community, I'm not able to on that level, I at least report bugs. And I don't expect them to be fixed anytime soon - although sometimes I'm surprised. Recently a few of the reported bugs in a few modules I considered frozen got fixed. I appreciate when that happens. To clarify a bit - I didn't talk about MiG-21 here necessarily as I barely started with it, it was more about CE2. However, the most recent change log contained: "Added 3 customizable mouse inputs: Comm menu, Zoom in slow, Zoom out slow" for both CE2 and MiG-21, so... there is still hope. I don't want to comment on the module price, but when I buy something now, I have no idea where it will be in 10 years. I haven't been enjoying the module for 10 years yet. After 10 years I'd consider the cost amortized, I guess. As for my abandonware remark, I felt that way about NS430 or Yak-52 (very little development for an early access module, although there were at least some bug fixes lately, so again, there is hope). I admit CE2 is not there yet and I hope it will not be. I appreciate your response and thank you for the information. And again, I'm sorry about the outburst.

I tried the second training mission and followed the taxi instructions only to encounter this obstacle: Now I'm stuck in the grass, not even max power helps me.