FalcoGer

When joining a multiplayer game and going to the F10 map, the map tools on top such as: Show detection rings Show engagement rings Show Labels etc Are selected or not selected seemingly at random. I need to select my preferences every time whenever I join a server. Sometimes they are on, sometimes they are off. It would be great if the last setting would be remembered or if a default could be set in the options somewhere.

When inserting an image from the clipboard into the textbox of a forum post, a little blank square is inserted instead and the image uploaded as an attachment. When you do not delete that little square thing from the text and post, then the text "(null)" is inserted in it's place. This happens with Firefox 110.0 (64 bit) on Windows and earlier versions as well.

When navigating to https://www.digitalcombatsimulator.com/ it always goes to German for me, probably based on my IP Address. I need to select English every time manually. It would be great if the selected language would be stored in the profile after logging in, or in a cookie when not logged in.

Also the tail rotor hub is not blurred at all while the main rotor hub is blurred. It looks strange.

That's not how the apache datalink works. You won't get an updating position marker on the map. datalink is mostly for target sharing. You can get a position report by requesting it or getting it sent actively, but it will only update when you do that process manually and you don't get any fancy overlays on your helmet. You can also share fuel and ammo data. I'm not quite sure why they don't just update the positions automatically every 5 seconds like with most other DL implementations, but that's how it is. FCR would be great of course, but I had been hoping for something that seems quick and easy, such as the LWR. Would help a lot with those ATGM threats. I was surprised that this has been put on delay in favor of more complex things, like FCR and IDM. Also I don't mind features being delayed if that means bugs are being fixed. The issue is that every patch a new massive bug is being introduced or reintroduced while the old bugs don't get fixed nearly fast enough or are even acknowledged. The big ones being the tail being shot off and you can still fly around (but not repair) or the engines not starting in sync, or the engines not spooling down completely after receiving damage (and thus not repairable). That along with a myriad of sync issues in multicrew and a lot of less major but still annoying bugs, like the laser not behaving correctly (still), being able to use IAT as a live unit detector behind bushes and trees, etc.

A work around is to ask your CPG if the engine is running or not. If either pilot gets a bad start then shut down and communicate that Ng is 0%, then try another start. Repeat until both pilots report a good start. It's fiddly, but at least you can get in the air. Although officially not allowed, dual starting seems to also make a good start more likely, although again, sample size is somewhat small. Can't draw any conclusive data from a couple dozen start attempts. Would really like a hotfix though, it is rather annoying and happens very frequently. Not being able to start your aircraft is kind of a big deal. Just my opinion though.

Someone already moved it. Bug reports are for bugs, not for asking questions about systems. I'm not sure you can actually move the topic yourself, so it wasn't aimed at you.

No problem. Thanks for answering at least, even if there is no info.

@BIGNEWY I don't know why this was moved to wishlist. I just inquired about the effect of water on the radar.

Could probably make one yourself simply by shooting a hellfire and watching the tacview track, taking times for different ranges from ownship. Or if you have the advanced version you can get the speed over time graph for the missile and integrate and there is your distance over time.

I was wondering if weather would significantly affect the effectiveness of millimeter wavelength radars. Given their short wavelength they provide good resolution, but those wavelengths are also easily absorbed by moisture. How would weather affect the radar picture? Will this be simulated? https://en.wikipedia.org/wiki/Electromagnetic_absorption_by_water

Certainly feels like that's better chances than asking ED for anything on these forums.

Are there perhaps multiple laser spots with the same code? Such could confuse the missile. I have not yet had such issues before.

Is it being considered? Is it being done? Is it not being done? If not, why not, because I think i raised some good points on why it should be done. Has someone even read this? Sometimes, or rather most often, it feels like writing in this forum is completely pointless and a waste of time. Why have a wish list forum if nobody cares to read the wishes. It's like talking to a wall. I mean this was asked for a year ago and not a single official reply or even a tag. And so are 95% of the other wish list items on here. The reason this was asked early is because we could see where this was going with the FCR option in the ME as a checkbox. It would be a really big middle finger to us if the next thing we see is the gun ammo option in the same place with no explanation on why that is the right decision after it has been requested specifically to not be there a year earlier for some good reasons. Or at least that what it would feel like to me anyhow.

I think generally the controls setup could use some work in DCS as a whole. I will be using the following terminology: An action or key binding is what is being bound to, for example pressing a virtual button or setting a switch to a certain position in the cockpit. A button or switch is the user's hardware, attached to their computer. A button or switch can either be on (pressed or switched) or off (not pressed or switched in the default state). An axis is a variable, analog, physical input device that a user has attached to their computer. The following would, in my opinion, greatly enhance the experience and allow more flexibility for binding actions. They can all be implemented incrementally and have no effect on one another. An action for button release There are multiple key bindings for "special" cases. For example in the Ka-50 Black shark 3 there is a special key binding for the laser arm switch, but for the Black shark 2 there is not. Those special key bindings act upon both pressing and releasing a button. This approach works, but only if the module developer adds those kinds of key bindings to their module and then they only work for those specific bindings. It would be more flexible to allow users to do that with any action they choose. Add a binding for each switch position that can be selected. When binding that action to a button, the user may specify that the action happens "On Release" using a checkbox in the key assignment UI. This then allows the user to bind a hardware switch to laser arm on and use the same hardware switch to laser arm off in the Ka-50 Black Shark 2 as an example. There are several benefits: Nothing needs to be changed, just the new feature added, Special key bindings can remain without breaking with no change and slowly be phased out Users can use this feature with any key binding they desire, allowing creative setups without the need for module developers to introduce special bindings for any and all switches Future aircraft will not require the implementation of special key bindings Special key bindings may be phased out, reducing the clutter and confusion during the key binding process Assigning axis trigger points Assigning axis values to actions would be nice. This would take the form of "If axis value is above/below (selectable) x% (also selectable), then do this action". Multiple such settings could be applied to one axis input. A good use case for this would be assigning trigger axis on game controllers to actions. For instance if right trigger axis passes 10% then action first trigger detent, if above 95% then action second trigger detent, if it falls below 90% then release second trigger detent, if it falls below 5% then release first trigger detent. This allows the use of spare axis as buttons or even multiple buttons. Multiple assignments Press one button and have it do multiple things at once. As long as those things do not conflict (for example setting the same virtual switch into two different positions), this should be fine. Assign axis values on button presses I'd like if I could press a button, and a virtual axis is assigned some value. For example I press a button and the formation light brightness knob is set to 0%, or any other arbitrary value I want. Staged Actions It would be handy if one was able to assign multiple a single button to multiple actions in such a way that each press triggers the next or previous stage in some internal state counter. And when that state switches it acts like a normal button press for key bindings. This would allow a user to assign a button and step through different actions on each press. For instance in the Apache one could configure a stage to press the different zoom buttons and then configure two buttons to go to the next and previous stage respectively. Suddenly you only need 2 hardware buttons to zoom in and out instead of 4. Or one to toggle between FLIR and TV, and suddenly you only need one button instead of 2. While not particularly realistic, it allows for users with limited or mismatching hardware to fly effectively. The way I envision this is that there is a new, intermediary layer between the user's hardware and the key bindings. The interface could look similar to the trigger interface in the ME. The user configures this layer to have a name, a certain number of stages. The user then configures which binding is triggered for each stage when that stage turns on or off. An option might be needed for how long the stage keep each action engaged. Then new, virtual key bindings appear in the key binding list for each stage to be set explicitly as well as forward/backwards bindings and forwards/backwards bindings with cycling on the last/first element. In the TADS FOV example above this would look something like this: User enters key bindings screen for Apache CPG User clicks a button, "Manage Staged Actions" A list of such custom actions is displayed along with some buttons to add, edit or remove them. The user clicks the add button User enters a name for the staged actions, "TADS FOV" A list of stages is presented along with an add and remove button. The user adds 4 Stages User defines names for each of the 4 stages ("Wide", "Med", "Narrow", "Zoom") User defines the actions to be taken on each of the 4 stages (the respective button presses, and no actions on release) User finalizes their decisions with an "OK" button. A new category "TADS FOV" appears in the category list. New key bindings appear "TADS FOV - 1 - Wide", "TADS FOV - 2 - Med", etc., as well as "TADS FOV - Next Stage", "TADS FOV - Next Stage (Cyclic)", "TADS FOV - Previous Stage" and "TADS FOV - Previous Stage (Cyclic)" User configures key binding "TADS FOV - Next Stage" and "TADS FOV - Previous Stage" and leaves the others unconfigured.

It's an old bug. You can push the fire switches, pull throttle to off and defuel the aircraft to 0% and the engines will still be running after they have taken damage.

That's it. Is there some way to disable that behavior?

it's a recreation of someone wanting to clean their gear using tree branches. I just scraped my nose on the ground for this one.

When you sheer off the gun you can still fire it, despite it not being present. To reproduce: Fly like a crazy man/woman Watch gun fall off Shoot non existing gun at things Track attached. shoot_gun_nogun.trk

Also: The left arrow indicator always indicates your station's selected radio. So the front seat left arrow is the front seat selected radio and the back seat left arrow is the back seat selected radio.

I added a Farp in the ME and put some blue support units on it to make it work. The farp is set to USA (Blue) in the ME. I have added two aircraft to the FARP (AH64), take off from ramp and take off from ramp hot. The FARP shows blue in ME, but when I join the game it suddenly becomes neutral. When joining the hot aircraft it calls Anapa for takeoff. I changed the helicopters from takeoff from ramp to takeoff from ground/ground hot. The FARP is still neutral. The very same mission was working fine before the latest patch, but I might have changed stuff around. Ah64Issues.miz In Mission: In the editor:

I'm not sure if this is the same issue, but I have had some issues in multicrew only (2 humans). In the CPG seat I had man range set to 800m. Switching to gun either with HMD or TADS as selected sight, man range wouldn't be set but instead the last laser range would stick. I was under the impression that selecting gun would instantly select man range. Switching to the other sight would set man range at either 1200m or 2400m and I don't know where those numbers are coming from. When flying alone and switching to the front seat it behaves differently. I'll try to get a track.

I must agree. I didn't know everything at first either, but I did watch at least wags video to get the basic idea behind how the avionics work before asking specifics on the forum. (Also I did read the manual first)

The only issue I could find is that if you are very high and you go above radar altitude then george will actually descend to the barometric altitude (which is lower than the radar altitude). For example if the ground level is at 1500ft and you tell george to go to 2000ft baro, he will go to 500ft radar, which is below 1420ft radar physically, but "above" 1420ft radar when you scroll through the altitude you want him to fly. I believe a better approach would be to start the barometric altitude to hold not at 1430, but at current ground level MSL + 1420, so setting anything above the radar altimeter range will actually be above the radar altimeter range.

It's very sporadic. I do mainly lengthy multiplayer session. Often enough it doesn't happen at all. Maybe once every 10 hours or so. I never really tried to reproduce the issue though.