isotaan

I cannot reproduce this working with an axis even when I change the mapping to a slider- I max out at 2700RPM regardless of the binding. I am able to reproduce it with only the mouse. I see a straight line even when not configured into a slider (see the attached image). You are talking about the Prop Governor Handle binding, correct? null Can you share screenshots of how you have it tuned and configured? What is your axis (HOTAS? throttle quadrant? manufacturer?)

These already exists as triggers in the Mission Editor: Picture to Unit Picture to All Picture to Coalition Picture to Country Picture to Group Picture Clear But there are no functions that allow us to perform the same task. Analogous functions already exist for Sound files: trigger.action.outSound trigger.action.outSoundForCoalition trigger.action.outSoundForCountry trigger.action.outSoundForGroup trigger.action.outSoundForUnit I propose that trigger functions be created for the Picture triggers: trigger.action.outPicture --Displays for all clients trigger.action.outPictureForCoalition --Limited to coalition trigger.action.outPictureForCountry --Limited to country trigger.action.outPictureForGroup --Limited to group trigger.action.outPictureForUnit --Limited to unit trigger.action.clearPicture --Removes pictures. Would need to have arguments to decide if that applies to all clients, coalition, country, group, or unit

The function "addStaticObject" does not accept the "hidden" attribute as a possible argument. Can we get this added? Currently you can hide static objects in the mission editor, but since the function does not accept the parameter once the mission runs all new statics are visible (assuming F10 views are set correctly). The function addGroup already does this, so why not the statics function? The result is that dynamically spawned statics cannot be hidden under the F10 map short of hiding an entire side/all sides from the map, which is not ideal.

I'm experiencing the same. First time in ages that I've tried using the NS430 and it gives me CTDs on Afghanistan: # -------------- 20241201-023410 -------------- DCS/2.9.9.2474 (x86_64; MT; Windows NT 10.0.22631) G:\DCS World OpenBeta\bin-mt\edCore.dll # 80000003 BREAKPOINT at 00007ff9bb67535b 00:00000000 SymInit: Symbol-SearchPath: 'G:\DCS World OpenBeta\bin-mt;', symOptions: 532, UserName: 'not_applicable' OS-Version: 10.0.22631 () 0x100-0x1 0x000000000002535b (edCore): ed::fatal_out_of_memory + 0x3B 0x000000000001e0a0 (edCore): TFrameMemoryHeap<0>::create_pool + 0x50 0x000000000001e96f (edCore): TFrameMemoryHeap<0>::reset_memory + 0x2F 0x00000000000338e9 (jsAvionics): ed_on_mission_pre_start + 0x3769 0x00000000000315ba (jsAvionics): ed_on_mission_pre_start + 0x143A 0x00000000000bf814 (jsAvionics): simSdk_UpdateServer + 0x71504 0x00000000000b6535 (jsAvionics): simSdk_UpdateServer + 0x68225 0x00000000000b76b1 (jsAvionics): simSdk_UpdateServer + 0x693A1 0x00000000000717e0 (jsAvionics): simSdk_UpdateServer + 0x234D0 0x000000000007182a (jsAvionics): simSdk_UpdateServer + 0x2351A 0x000000000007182a (jsAvionics): simSdk_UpdateServer + 0x2351A 0x000000000007182a (jsAvionics): simSdk_UpdateServer + 0x2351A 0x0000000000074f79 (jsAvionics): simSdk_UpdateServer + 0x26C69 0x0000000000014ea2 (NS430): cockpit::G430::avGNS430::release + 0x862 0x000000000021f70e (CockpitBase): (function-name not available) + 0x0 0x00000000000045eb (World): (function-name not available) + 0x0 0x0000000000004c12 (World): (function-name not available) + 0x0 0x0000000000910b7a (DCS): (function-name not available) + 0x0 0x0000000000910851 (DCS): (function-name not available) + 0x0 0x00000000009361a2 (DCS): (function-name not available) + 0x0 0x00000000008f0514 (DCS): (function-name not available) + 0x0 0x00000000008f1c43 (DCS): (function-name not available) + 0x0 0x000000000227b498 (DCS): (function-name not available) + 0x0 0x0000000000cd2a82 (DCS): (function-name not available) + 0x0 0x000000000001259d (KERNEL32): (function-name not available) + 0x0

I'm experiencing this issue as well!

One thing that the modules are missing are a series of additional keybinds that takes advantage of individual players' HOTAS setups. Not everyone has a button in the right place, and some of us don't have any three position switches at all. I think that this is a missed opportunity to make the F1 an easier plane to configure for HOTAS inputs. Here's an example of what I'm talking about: I was practicing aerial refueling today in the F1EE. In the real world, I'd keep my right hand on the flight stick and keep my eyes on the tanker while I feel for the refueling guard switch, and push the underlying switch forward. When I'm done, I again use my left hand to feel for the switch and guard and drop both. Since we aren't actually in F1 cockpits, you have only two options: you look down and fumble with the mouse to click the guard and the switch individually. Depending on your zoom, you might have to try multiple times. Keep in mind that you're in formation with a tanker and one or more of your wingmen, so a moment of you being heads-down could mean the difference between being alive one moment and collision the next. The alternative is to use keyboard or HOTAS bindings. HOTAS is preferred, since there are no native keyboard mappings for the refueling system and the keyboard is cluttered with bindings already. If you're going to have to use bindings, to perform the above workflow you'd have to give up FOUR bindings. One to open the guard, one to push the refueling switch forward, one to push the refueling switch back, and one to close the guard. Given differences between people's setups, that's not realistic to expect people to dedicate that many bindings, since there are many switches that can be time critical (in the sense that you need to do something very quickly but you can't take your eyes off of the HUD). Speaking for myself, I'd have to dedicate four switches to the refueling system- and my setup only has four! These switches are Up = Pressed continuously and Down = unpressed. If changes are made, we can cut down the number of binds to just two: the ability for one bind to do two actions each. There are two ways of doing this: 1. Implement a ON else OFF-style bindings. Imagine a simple switch like I have. I'd like to be able to flip my switch up and have the refueling guard go forward and up. When I flip that switch back, the guard returns to its back and closed position. Since the switch holds the input continuously, I don't need to hold down anything to keep the guard forward. 2. Implement toggle buttons. While not ideal for my setup, other players will appreciate it, too. Some players may want to map the refueling guard cover to a pushbutton. Holding down a pushbutton isn't feasible, so this should instead be a simple toggle. Press it once, the guard flips open. Press it again, it closes. Simple. I think that all switches/toggles/guards should get this treatment. However, in the interest of focusing on the ones I feel are important, I've made a list to help. By no means is this list supposed to be exhaustive. It's focused on mappings that otherwise require excessive bindings and may be used in critical stages of a flight, such as in combat or while in formation. A summary: X else Y - When pressed, is in state X. If not pressed, will give state Y A/B - When pressed, toggles from state A to state B. When pressed again, goes from state B back to state A. ***All Airframes (F1CE, F1BE, F1EE, Presumably F1M as well)*** Master Arm switchology: Armament Master Switch Guard: Open Else Closed Armament Master Switch Guard: Closed Else Open Armament Master Switch Guard: OPEN/CLOSE Armament Master Switch: On Else Off Armament Master Switch: Off Else On Armament Master Switch: ON/OFF Armament Panel: Auto/Manual Firing Selector switch - AUTO else MAN Auto/Manual Firing Selector switch - MAN else AUTO Auto/Manual Firing Selector switch - MAN/AUTO Bomb/Rocket selector - 1+2/INBD/OUTBD Bomb/Rocket selector - INBD/OUTBD Fuselage Bombs Pushbutton - ON else OFF Fuselage Bombs Pushbutton - OFF else ON Wing bombs pushbutton - ON else OFF Wing bombs pushbutton - OFF else ON Fore/Aft selector switch: AFT else FWD Fore/Aft selector switch: FWD else AFT Fore/Aft selector switch: FWD/AFT MATRA 550 or Sidewinder Missile Switch: ON else OFF MATRA 550 or Sidewinder Missile Switch: OFF else ON Stores Jettison: Selective Jettison button guard - OPEN else ClOSE Selective Jettison button guard - CLOSE else OPEN Selective Jettison button guard - OPEN/CLOSE Emergency Jettison button guard - OPEN else ClOSE Emergency Jettison button guard - CLOSE else OPEN Emergency Jettison button guard - OPEN/CLOSE ***F1EE-specific*** Refueling: Transfer/Filling switch guard - Open Else Closed Transfer/Filling switch guard - Closed Else Open Transfer/Filling switch guard - OPEN/CLOSED Transfer/Filling switch - REMP. VOL (AERIAL REFUELING) Else TRANFERT (TRANSFER) Transfer/Filling switch - TRANFERT (TRANSFER) Else REMP. VOL (AERIAL REFUELING) Transfer/Filling switch - TRANFERT (TRANSFER)/REMP. VOL (AERIAL REFUELING) ECM: BARAX state Selector - ON else OFF BARAX state Selector - OFF else On BARAX state Selector - ON/OFF/TEST BARAX state Selector - ON/OFF BARAX emission ready korry - pressed else released BARAX emission ready korry - released else pressed BARAX emission ready korry - pressed/released

I've noticed similar behavior as well. Upon mission start or group activation, the vehicles move.

I've been thinking that DCS has been needing something similar for some time now. The current MP UI is a serious turnoff, and the inability to conduct flight planning is a significant limitation.

I'm noticing this as well on two dedicated servers that I run. I installed the liveries onto the dedicated server, but none appeal.

When the Harpoon is in the LRG search pattern, we should have the option to OFFSET the Harpoon into searching for specific targets among other traffic: LEFT RIGHT NORM NEAR FAR The Viggen has similar functionality (using HB's custom code), but I'd like to see this with ED's Harpoon.

AIM-7P

This is a problem with many of the AI aircraft; they cheat by not bleeding the speed they should when they turn and their acceleration figures don't account for gravity, so they can actually accelerate faster in the vertical than a human-flown aircraft even if the human plane has a better TWR. That's why you'll often hear of AI F-5s and others as having "UFO engines." This cheating of physics is more apparent at the higher difficulty levels (since Ace AI planes will pull harder). The F-5 has it bad, but the Korean War jets have it *really* bad. They're supposed to be roughly equivalent, but try taking a F-86 out against a Mig-15 and watch as they demonstrate their superior UFO physics modeling, especially in the vertical.

The concept is simple: let mission makers redefine the strengths of airborne ECMs at the .miz level. This will allow mission makers to fine-tune the ECM for the needs of any particular mission. For example, if I'm running a campaign, we could have standard Hornet ASPJ strengths for the first few missions but then the enemy tunes their EW and the ASPJ is a lot less effective. Or the bluefor side can get ELINT updates to their EW and the SA-10 is now ineffective. Then there's multiplayer pvp to consider. Not everyone will agree with some of the decisions made, but ECM would be another way to balance airframes. Consider Mig-21s with effective ECM that makes them very difficult to lock or get ranging info beyond 10 NM? Or giving FC3 planes less/more effective ECM depending on the balance we want to achieve. The last advantage- The community won't be bothering the devs three years from now when someone finds some publicly released data that conflicts with the current in-game modeling of ECM system effectiveness.

After today's OB patch (2.7.10.19402), here are the following results of my testing: Eagle Dynamic's AIM-54C still will not engage beyond 20 NM. Kinematically, they are capable of going much, much further than 20 NM. Heatblur's AIM-54s of all stripes have corrected DLZs plus whatever guidance tweaks tjay were added. This means that the AI will now shoot targets at 65 NM.

Raven One has a mission over Basra. Baltic Dragon did his best by placing static structure, but the map there is so awfully painful to look at that it makes the mission harder than it needs to be. I'm not suggesting the addition of anything beyond Basra and its immediate vicinity. It doesn't even need to be more than high-resolution textures and stock assets. I just want that the team helps out by making a paid, quality campaign better by making just one town at a detailed level.

If it helps, it seems like it's the missile's DLZ. Kinematically it's possible to get far past that, but the missile only reports it's capable of being in range at about 30NM. This affects the HB phoenixes, and after some testing, it's appears to be an issue for the ED Phoenixes as well.

I'm experiencing this as well.

Are we going to get this? Hornet Tactical Manual Pocket Guide (2001) - AGM-88 employment under TOO mode, Page 117, step 3.

During a training flight, we had four Hornets attempt to use HPTP's to conduct an anvil attack. However, the use of the HPTP was not synchronized across all clients. This means that each client saw only its 4 Harpoons go to the HPTP and then angle in to the target. All other missiles were seen as flying directly to (and overhead the target). The target carrier was seen taking phantom damage from the unsynchonized-but-invisible missiles impacting the carrier. Edit: Unfortunately our track files are too big (>5MB) so I've attached what we can. harpoon_practice_mp-20210307-174330.trk harpoon_practice_mp-20210307-144318.trk

I haven't experienced this until the last patch, but now I'm seeing every time I fly the Hornet. Some of the folks I fly with report similar issues while others haven't noticed it at all.

Any word on the LSO / PLAT Cam feature for the supercarrier?

There's a big tree just outside the base that AI aircraft will hit on takeoff. Someone should cut it down.

Last I heard ED didn't have documentation of how it works, so they chose not to simulate it.

Additionally, the Mig-27K is also unable to use fuel tanks on stations 1 and 9. The stations show as available in the loadout editor but have no entries on them.

The SLAM came about in the pre-JDAM days. Think of it as a replacement of the Vietnam-era Walleye that complements other PGMs that the Navy was using at the time. Back then the Navy used the AGM-123 Skipper II, the Walleye, and other LGB kits. The Walleye's MITL offered the potential for a degree of standoff precision that one didn't get short of the Skipper while offering more range and without needing to maintain a laser on the target. As one previous comment noted, the SLAM is like the JSOW- you use it to hit high-value targets on the first night of the war in order to break the enemy's C4ISR infrastructure. The SLAM wouldn't be used for CAS any more than you'd call down a Tomahawk for CAS.