Binary

If this does not help, you could also check the Logs/DCS.log and Logs/Scratchpad.log files for errors. The content of Logs/Scratchpad.log should contain content similar to: [16:02:00] Loading config file... [16:02:00] Configuration exists... [16:02:00] Creating Scratchpad window hidden... [16:02:00] Scratchpad Window created

I have added the option to change the font size (and slightly increased the default one). The updated version can be found here: https://github.com/rkusa/dcs-scratchpad/releases/tag/0.2.0 The option is called fontSize and can be changed in Config/ScratchpadConfig.lua (if the file does not exist, start DCS once after mod installation). ... and btw, thanks for the kind words, I wouldn't have expected that the mod would be that well received! I've received the suggestion to add pagination to the Scratchpad. What do you guys think about this suggestion? Should switching between pages (or tabs) work through hotkeys or buttons?

Have you moved the window all the way to the right in 2D and are using a higher resolution on 2D than in VR? If so, it might be possible that the window is shown outside of your current window bounds and the fix would be to move it back to the left in 2D (since the position is persisted).

Maybe nice to know: according to NATOPS, flared landings have a weight limitation of 39k pounds while unrestricted “normal” (aka. Controlled crash) landings have a weight limitation of 33k pounds.

Das ist ein Feature - Im Thread des Mods wird beschrieben welche Datei was macht, auch welche dafür verantwortlich ist, dass es nicht mehr S/W ist. Diesen Teil eventuell einfach nicht mit installieren.

HALLi (WM) und ich (L; Pilot Name: Binary) würden sehr gern teilnehmen! Kudos schon mal für das Organisieren des Events - ich habe das Public Helicopter Event noch in sehr guter Erinnerung!

Ich hatte mal ein ähnliches Verhalten, Grund war ein aktivierter Windows Gamemode für DCS. Eventuell sicherstellen, dass dieser deaktiviert ist.

Just tested it again to make sure. With the Specials Option "AFTERBURNER DETENT" enabled (enabled by default for the current patch). Start on an airfield (so launchbar retracted and hook up). I cannot engage the AB. However, if I press a button mapped to the keybinding option "Cycle Afterburner Detent - ON/OFF", I am now able to engange the AB. The same applies when airborne. With this keybinding, I can toggle between AB possible / not possible. However, you are right in that it is also possible to engange the AB with the finger-lifts instead of the Detent-keybinding. But I guess the intention with the "AFTERBURNER DETENT" option is to use the "Cycle Afterburner Detent - ON/OFF" keybinding and not the finger-lifts. With the Specials Option "AFTERBURNER DETENT" disabled, neither finger-lifts nor the detent-keybinding are necessary to engage the AB - both on the ground as well as in-flight. What I would suggest as an improvement is to disable the "AFTERBURNER DETENT" option by default (since there is no default keybinding for "Cycle Afterburner Detent - ON/OFF").

I could be wrong, but I think you are reading the NATOPS slightly wrong On an airfield you have weight on the wheels, but the launch bar is retracted and the arresting hook is UP. That is, in this situation, even with WOW, you do not need the finger lifts for engaging AB. What you still have, is the detent - but more on that later. Again WOW, but now if you have either the launch bar extended or the arresting hook down, the finger lifts are required to get into afterburner. As far as I see, they have added a "virtual" AB detent, which is not the same as the finger-lifts. This virtual detent helps you staying out of the AB, if you don't have a hardware detent in your throttle. The option is enabled by default and can be disabled in the SPECIAL options (uncheck "AFTERBURNER DETENT"). If this option is enabled, you do not have to use the finger-lifts - use the new keybinding "Cycle Afterburner Detent - ON/OFF" instead. That being said, IMHO, I think the current implementation is correct - just keep the difference between the finger-lifts and the AB detent in mind.

I can confirm that this is still the case. DCS logs do not contain anything that seems to relate to this issue. Once the desync happens, DCS on the server is not responding (we get the windows message: DCS is not responding). Also no error in windows logs, only an information entry: Fault bucket , type 0 Event Name: AppHangTransient Response: Not available Cab Id: 0 Problem signature: P1: DCS.exe P2: 2.5.1.16978 P3: 5af29ebc P4: unknown P5: unknown P6: unknown P7: unknown P8: P9: P10: Attached files: These files may be available here: Analysis symbol: Rechecking for solution: 0 Report Id: 01e88d27-5a0b-11e8-8431-525400123456 Report Status: 2049 Hashed bucket: This does not happen if an owner of the AV8 module opens the server. So, when trying to reproduce, maybe try to use a server that does not own the AV8 module.

Hi, this is basically the same as already written in https://forums.eagle.ru/showthread.php?t=200408 but the bug sections seems to be a better fit. I also updated the example mission to use DCS 2.5 I have the following setup. A Bandit-Group with the task "Attack Group" (with the task's group option being set to the Player's group). The expected behavior is that the bandits intercept the player and this works so far. However, if I activate "Late Activation" and activate the group through LUA, the task "Attack Group" is lost/removed (group:getController():hasTask() is false). Strangely, if I setup a trigger in the editor with the action "GROUP ACTIVATE" it works perfectly fine and the task is not lost. So why is the task removed when activating the group with LUA (using the code below)? local group = Group.getByName('Bandit') group:activate() -- same issue with: trigger.action.activateGroup(group) I've attached an example mission. In this mission there are two F10 Radio options. One for activating the bandit group with the trigger action "GROUP ACTIVATE" and another one with "DO SCRIPT" (which executes the code above). When using the one with the trigger action, it works - the bandit group will fly to the player upon activation. However, with the LUA action, it does not work - the bandit group will RTB immediately after activation. Thanks Late Activation Task Issue Test.miz

Hi, I have the following setup. A Bandit-Group with the task "Attack Group" (with the task's group option being set to the Player's group). This works so far. However, if I activate "Late Activation" and activate the group through LUA, the task "Attack Group" got lost (group:getController():hasTask() is false). Strangely, if I setup a trigger in the editor with the action "GROUP ACTIVATE" it works perfectly fine and the task is not lost. So why is the task removed when doing the following? local group = Group.getByName('Bandit') group:activate() -- same issue with: trigger.action.activateGroup(group) I've attached an example mission. In this mission there are two F10 Radio options. One for activating the bandit group with the trigger action "GROUP ACTIVATE" and another one with "DO SCRIPT" (which executes the code above). When using the one with the trigger action, it works - the bandit group will fly to the player upon activation. However, with the LUA action, it does not work - the bandit group will RTB immediately after activation. Is this a bug or am I missing something? Thanks EDIT: Example mission is on Normandy. I could also create an example on a non-payed map. Late Activation Task Issue Test.miz

Cool, thanks for the Update!

Yes F10 -> CTLD -> Transport

Hi Apache600, thanks a lot for the mission! We already had some fun on it. We found one bug yesterday. We had two Hueys. The first Huey had no issues loading and unloading troops. However, all Transport actions the second Huey called, where executed on the first Huey. E.g. Second tried to load troops, troops were loaded into the first Huey.

Das Event ist eine super Idee, danke dass ihr sowas organisiert! Ich würde auch gern teilnehmen. Huey (Slick oder Gunship), Gazelle (einzeln oder Multicrew) und Ka50 wären möglich. Ich würde also einfach eine fehlende Rolle auffüllen. Am Dienstag kann ich jedoch erst verspätet dazukommen.

Master Arm Key binding You could create the binding yourself. If you want to have the Master Arm on a Switch, have a look here https://forums.eagle.ru/showthread.php?t=179527

I achieved it by adding the following -- Alternate Switch Abstractions {down = 3234, up = 3234, cockpit_device_id = 6, value_up = -1, value_down = 1, name = _('Master UNARMED, else ARMED'), category = _('Alternate Switch Abstractions')}, {down = 3463, up = 3463, cockpit_device_id = 6, value_up = -1, value_down = 1, name = _('Gun UNARMED, else ARMED'), category = _('Alternate Switch Abstractions')}, to DCS World\Mods\aircraft\M-2000C\Input\M-2000C\joystick\default.lua The beginning of this file should then look like: local res = external_profile("Config/Input/Aircrafts/common_joystick_binding.lua") local cockpit = folder.."../../../Cockpit/" dofile(cockpit.."devices.lua") dofile(cockpit.."command_defs.lua") join(res.keyCommands,{ -- Alternate Switch Abstractions {down = 3234, up = 3234, cockpit_device_id = 6, value_up = -1, value_down = 1, name = _('Master UNARMED, else ARMED'), category = _('Alternate Switch Abstractions')}, {down = 3463, up = 3463, cockpit_device_id = 6, value_up = -1, value_down = 1, name = _('Gun UNARMED, else ARMED'), category = _('Alternate Switch Abstractions')}, -- 3-Pos. Switch Abstractions ... Doing this will give you a new category in the controller settings ("Alternate Switch Abstractions") where you can setup your Hotas. This change has to be applied after every update.

This is great! I was able to use JTAC coordinates as the IP and the JTAC successfully guided the GBU-12 to the intended destination. However, I am wondering why this approach requires an offset waypoint? Because having to setup an offset (even though it is just a value of about 0,001 degree) to get it to work, fells kinda wrong? Don't get me wrong, I don't want to complain, I am just interested into the "why". Thanks

I was able to put the gun arm onto my hotas using the following snippet: {down = 3463, up = 3463, cockpit_device_id = 6, value_up= -1, value_down = 1, name = _('Gun UNARMED, else ARMED'), category = _('Alternate Switch Abstractions')}, I had to use 3463 instead of iCommandPlaneAHCPGUNArm, which is used for the default keybinding. So maybe the issue with the default provided keybinding could also be fixed by using 3463 instead of iCommandPlaneAHCPGUNArm.

The Gun Arm toggle key binding does not seem to work. I've tried different key mappings (besides the default LCTRL+6) and also tried buttons on my hotas, neither work. Other key bindings (like Master arm toggle) are working.