s32191234

While using the Apache I ran into a different issue which seems related and would like to provide the additional information. When using the keybind (a on keyboard) I can visually see the A-key on the KU move in sync with both the press and the release. My conclusion is then that the problem is not particularly there. What I ran into is the following: If any other KU-key is pressed, after releasing the A-key, within approximately 0.5 seconds, the second letter will end up in the KU first. This only happens to the letter A when attempted to enter before any other letter and i have found no other letter to have this. To me this becomes a problem if I type AG to mark a CM as an Airfield, which results in GM ending up in the KU. This of course solely being a problem because I enter the data via my keyboard on PC, instead of using the mouse. I have tested this today on the Beta MT version 2.9.3.51704 in the CPG seat. However my experience has been that this was the case in both seats and having been a discrepancy since the start of EA. My hope with this reply, is to both bring new information to help, but also ask for an update as this post is now nearing 2 years. Kind regards, s32191234

TL:DR Add a special drop-down on the Apache unit: 'Populate points within' -> choices: 0nm, 10nm, 50nm, 150nm Quite simple to implement and quite effective in combination with other tools like DTC. Full: I fly in a battalion with a few fixed-wing groups that want "all known SAMs" on their MFD. My squadron doesn't need those as TGT or CM. Currently we can only compromise in the middle with neither really happy. While I have read about intentions to work on this, I am hoping to suggest a shorter term "quick fix". Any of the proposed solutions seem significantly more complex. I do think those are very welcomed by the community but I still want to float this idea, due to its simplicity in both usage and implementation. With the 0nm range the import is simply off for that group or ship. Tools like the DTC are able to provide data from an external source which make this already helpful, without DTC having to delete all points first. With the 3 semi-arbitrary values, the option arises to choose a scale, where 150nm should reach the end of operational limits. An option, if desired, could be add an "all" option to the list. Kind regards, s32191234

As draconus said, no worries, its not the "wrong" place, its just that there is a better place. There's quite a few pointers I have for you here which would not be great to list here. Instead, I would ask you to consider sending me a DM on this form with your Discord ID so we can have a chat there at some point. I've never tried such mechanics but I've got a few idea's on what could go wrong causing the "Your flight is delayed" message. Again, Discord seems more the place for this because I'll need some additional info.

So, I (obviously) have no idea how you are trying to do what you do. However, based on the information you do provide, the following comes to mind: Probability in programming is more often done in the range of 0 to 1, instead of the 0 to 100 (percent) you (have) use(d). This means that 1 is "always" and 0 is "never" and 0.5 is 50%. What you could test is to see if dividing your percental value by 100 gives the desired result. Note: I do not know whether this behaviour change is intended or a bug, so bear in mind that, if my suggested fix works, changing the value's may "break" again in the future. Best of luck

So this can be done with 7-zip as well. A .miz file is literally a zip file (in the technical sense) which is why 7-zip, winzip and winrar can handle it. So here are the steps: Extract the .miz you have to a spot Edit the mission file Select all within the folder (not the folder itself) and right click 7-zip -> add to "folder name".zip Rename the resulting zip in the folder to .miz The biggest thing that tends to go wrong (and break DCS) is when the archiving software creates a top level folder within the archive. When opening the .miz you made, make sure you see the default files (mission, theatre, etc.) P.s. to alter the extension, these need to be shown. If they are not, look here: https://support.winzip.com/hc/en-us/articles/115011457948-How-to-configure-Windows-to-show-file-extensions-and-hidden-files

So first off, the question isn't exactly in the right place. For the editor we have this section: https://forums.eagle.ru/forumdisplay.php?f=210 Second, sadly what you want can't be done through the editor. There is, however, a way to do this through a script. This does mean it might get a little more complicated than you'd want: So first, you will have to change your trigger to the action: "DO SCRIPT". As an example you can paste the code below into the "TEXT" box to see it in action. local subgroup = missionCommands.addSubMenu("Top level group") local action = missionCommands.addCommand("Sub item", subgroup, trigger.action.setUserFlag, 1, 10) I don't know your background, but I'll try to walk you through what the script says: At the line "local subgroup", the subgroup is created with the displayed text. At the next line an action is made. After its text, it references the subgroup it wants to be part of, which on the previous line was defined (with the local keyword) with the name "subgroup". Next, the function to call when the item is triggered is listed. I've chosen to use the flag function to keep the behaviour you know from the editor in tact. Last are the 2 arguments that the setUserFlag function needs, which is flag id and flag value respectively. From here you can do two things: Add another submenu layer or add a second action: Extra submenu local subgroup = missionCommands.addSubMenu("Top level group") local midlevelgroup = missionCommands.addSubMenu("Mid level group", subgroup) local action = missionCommands.addCommand("Sub item", midlevelgroup, trigger.action.setUserFlag, 1, 10) Note that in the second line, the "midlevelgroup" variable is made which is then referenced in the third line. Second action: local subgroup = missionCommands.addSubMenu("Top level group") local actionOne = missionCommands.addCommand("Sub item 1", subgroup, trigger.action.setUserFlag, 1, 10) local actionTwo = missionCommands.addCommand("Sub item 2", subgroup, trigger.action.setUserFlag, 2, 10) I hope this is a workable solution for you. Best of luck with your mission!

https://imgur.com/a/u8sbaLC

Thanks for the reply. I don't have a screenshot yet, once I do I ll put it in. The messages are from the server about the mission, on whats happening. This is useful information in most cases, but once read, I would like to be able to dismiss them via keybinding. I couldn't find such option. I'll check the font size to try and make it less prominent.

So I've recently gotten myself a Valve Index and using it is all nice n stuff. But there is one specific problem. Sometimes servers have a tendency to spew messages in the top right about things happening. When these sentences become long and start forming whole paragraphs, this message box is covering half my screen including the HUD. Now my hope is that someone can help me manage that. Is there a way to "mark as read" so it clears? Or can I reduce its size? Or maybe someone knows another clever way to solve this? Thanks in advance!

Great to hear you found the cause that quickly!

Hello, Being a programmer my self, I know how important it is to get all info for a bug so this may look intimidating but I did my best to put all info I have found in here. General summary: So I've found a scenario in which DCS crashes to desktop which I can reproduce. This occurred first in multiplayer and afterwards I did all testing directly from the editor. From what I've gathered it's a quite unlikely edge-case with a few key factors. Because my friend can reproduce it as well, I've chosen not to add full because they seem irrelevant. We both run Windows 7 64-bit though. The only possibly related forum post I could find in the Viggen section is: https://forums.eagle.ru/showthread.php?t=181571&highlight=crash I'll do my best to reply asap to any questions. Key factors for the crash: These are the factors I have found to be essential based on my own findings (all described in the section "Personal tests and findings"): The Viggen is playable and in the same coalition as the ships A ship group that at least contains both the CV 1143.5 Admiral Kuznetsov and FSG 1241.1MP Molniya Attachments: In attached zip, are 5 files in total: crashtest.miz: My resulting mission from following the steps in section "Full clean slate reproduction steps" crash reports of my mate/.*\.crash crash reports of my mate/.*\.dmp (empty) crash reports of myself/.*\.crash crash reports of myself/.*\.dmp (not empty (found that strange but didn't look into it)) Quick reproduction steps: Using the .miz file in the attachments Place the crashtest.miz file contained in the attached zip so it is available in the Mission Editor in DCS Start DCS on an installation with the Viggen module enabled Go to Mission Editor Open the mission Click on Fly Mission Select the only Viggen Click on start Click on fly Direct crash to desktop Personal tests and findings: If done multiple tests to try to narrow down the essential factors. With the steps in the "Full clean slate reproduction steps" section I've created my bare minimum for the crash to occur. Using this as my starting point the following changes will cause DCS to not crash: Changing the Viggen to USA (Blue) Putting the 2 ships in different groups Swapping the carrier out for another Molniya Swapping the Molniya out for another carrier Using that same scenario the following changes did not prevent DCS from crashing Changing location of the Viggen (both bearing and range to group are irrelevant) Cold-start the Viggen from Kobuleti Changing the positions of the ships in any manner, even with one north of the Viggen and one south of the Viggen Changing the country of the Viggen to Abkhazia (Red) Adding other Blue or Red units in any group, new or existing Adding extra Viggens hoping a second one would not have the same issue Changing the Viggens skin to "Bare Metal" Adding waypoint(s) for the Viggens Changing the load-out of the Viggen Full clean slate reproduction steps: No pre-existing files Start DCS on an installation with the Viggen module enabled In the main menu, select Mission Editor Click on Create new mission Create at least coalition Red with Russia Place 1 aircraft over Kobuleti (location irrelevant) Change country to Russian, type to Viggen and skill to Client Place a ship (for example: GG14 (2 blocks east from Kobuleti airport)) Change country to Russia, Type to CV 1143.5 Admiral Kuznetsov Set the unit size to 2 Change the type of the second ship to FSG 1241.1MP Molniya Save mission Try to fly the only Viggen (see list under "Quick reproduction steps" on how I do it) I hope the information is usable in fixing the crash. Kind regards, Emiel Hermsen bugreport.zip