FalcoGer

Which manual are we talking about? I saw some checklists in the TM 1-1520-251-10 operator's manual. In particular I couldn't find the abbreviated checklists. Starting from section 8.11, it seems you have missed a few items. Though I don't know how DCS will handle them so it might or might not be valid to skip them for DCS purposes. Either way I am looking forward to your kneeboards. Also I concur, a clean version would be nice.

I, too, would like to have rotor blades while on the ground. And in the air. Actually in the air especially.

There is no axis command for wheel brakes, at least I didn't find it. Using my rudder pedals I can not brake the aircraft without going to the keyboard. Please add an axis binding for left/right/both wheels.

How does the thing know when to fuze? Is it timed? If so is it variable? Is it set by the WP when launching the missile and getting the info for the range to target? If so can you alter it to fuze sooner? From the video it seems like the spread is about 10° with a large margin for error. If you can open earlier it would provide higher coverage with less density.

Great opportunity to introduce fragmentation/shrapnel damage to soft and lightly armored units. Must be terrifying and painful to be perforated. The best kind of weapon to commit (virtual) warcrimes with.

But you can't unhook the launch bar...

From the point of boom raycast with however many fragments you wish to simulate. Then calculate damage based on range from source. Raycasting can be done fairly fast with GPU, range between two points is simple addition and a root calculation and shouldn't be too taxing. There is no need to overcomplicate things by creating objects and flinging them all over and calculating gravity and drag on them and doing collision detection on each and then calculate damage based on the impact velocity. It's fine to approximate things. For vehicles with components you can just ignore fragments that hit the armor. If it hits say a truck, you could raycast again from the point of impact ans see if it perhaps hits the engine. While an engine block seems fairly impervious to shrapnel, all the little bits that make an engine work is not. And it's not like it's armor grade steel either.

I'd also like a category for custom loadouts. Whenever you join a server you just can't find your loadout because it's buried in a hundred of other, pre-defined loadouts. Well that works 80% of the time. Sometimes it just asks us if we want to keep the 2 missiles in the 6 missile rack that we had left when coming back for rearm. Because why not.

I don't think it's necessary or smart to expose the guts of the message system to the player. It makes a complicated setup even worse. There needs to be no change other than the extra key binding option. To use your example if the player binds key release to pitch down (which would be possible but stupid to do), then releasing the key would from then on continuously pitch the aircraft down and when pressed it would then send the stop pitch down message. Or the other example when the key is released, the aircraft would trim roll with a value of -0.1. In that way nothing else has to change, no key bindings have to be looked over or redone as a dependency of this, and you get all the extra functionality that is required. If you were to introduce the underlying message system, it would basically ask the players to program their own input system, potentially with cryptic message names, which is a bit much. It would also require this single change to have a knock on effect on all modules, so every developer needs to go over all their modules and redo inputs. All the players will have to rebind all their buttons. It's a huge mess and a big no-no. Sometimes such changes are necessary, but this is not one of those times. All I want is that if I put a button on my control into the off position (i.e. the button press vanishes from DCS's point of view) then the switch in the cockpit is toggled. And I want that option for all available switch positions. And to do that the simplest option is to have an on release settings for each key bind. The switches should have a "switch on", "switch off" and, "switch toggle" by default. Everything else should be up to the player.

Even more annoying when you spawn on the catapult, hooked up, with engines cold on the landing strip and with the wheel chocks on. And then after you start up for 5 minutes and have the INS aligned, the ground crew refuses to take the chocks off and then you have to respawn anyway. Who thought that was a good idea?.

The Apache is not rated for IMC. Thus this is pointless.

Could you explain what you mean by that? Does that fix the issue?

Happened to me, too. Twice in a row now playing this mission as tactical commander. Works fine for a while. Then as I zoomed out on the map suddenly the symbology disappeared. liberation_nextturn.mizdcs.log

I believe the player should be able to choose any option and have the other's filtered for that. For example I might decide I want to fly F16, and then pick an airfield from which to start. Or I decide I want to fly from Anapa and don't particularly care which aircraft. Or I want to fly multicrew with a specific other player. Generally I agree though. Pick what you want, not a slot. You place 16 F16 on anapa then you can just say "F16 on anapa". Although there are a number of issues with that, most of which would be solved with the DTC being implemented. In the ME players may place multiple flights, affecting data link settings, way points and default loadouts. I think a more reasonable way would be to add multiple filters to the slot list instead of just being able to sort by unit types, names or airfields.

I don't see the point of having the filter off by default. If I don't own a particular map or don't have it installed, there is no reason to show me servers for that map, unless I specifically ask for such a thing. Please make that filter option enabled by default. Or even better, make the filter remember the setting so that when you open the list again, persisting through restarts of course, it remembers the last state.

We need the $40 music module! Adds MP3 player to all planes I'm confused why this is on the wishlist.

I don't understand that english. What do you want? You want to be damaged but you can't be killed even with your pilot's head spread out on the canopy glass and the wings missing, but you want performance degraded? Like you know... 0 lift and 0 flight controls?

Should be moved to bug reports. Happened to me too. You disappear from the F10 map, DCS thinks you are dead. enemies don't shoot you. One time I broke off the wing top on my F16 and still had some bombs. I could fly happily to iran, blow up an SA 10 with some bombs I still had under my wings, then gunned down a few sa15s and 2S6. As ever I don't have a track because MP.

I don't know what you mean. What key bindings do you want? I didn't check if it didn't exist (would be a bug IMO) because I always just click the thing, but the only key bindings that had to be added was the power switch on the right console.

I don't understand why DCS is locking their API for the public and allowing only select module developers access to it. Things like a targeting pod are impossible to be added by mods at the moment. Why is that? I understand that ED wants to keep things high quality and realistic, but at the same time people can still make aircraft and make them as ridiculous as they want. Sure things like the C130 mod aren't visually as high quality as a professionally developed model, and they may not be 100% accurate, but they're still good fun and reasonably good. And at the end of the day people know that they download mods and bugs and inaccuracies are expected. If the community A4-E is any indication it also proves that the community can produce amazing results. So why then are they held back? Why not release all the tools? It can only make DCS better. And if something like the A4 is of a really good standard, ED can adopt it into the core, perhaps either free or at the developers choosing priced. Yes the bomb drop tables aren't a perfect match to the real world, but in the end it's a great model with great textures and the procedures seem realistic. Not that I could say, because I never flew the thing, but I'm sure a lot of effort went into it. And yet development of such aircraft are held back by not providing the tools needed to perfect them.

I have no idea how DCS handles input internally. Generally in game design you have a game loop where you do mostly 3 things. Handle Events Update Draw You run this loop indefinitely until the event handling says it should not anymore. Naturally it gets more involved with exceptions and special cases and multi threading as software gets more complex. Typically, at least I do so, event handling consists of either listening to windows events, which will be things like "mouse move, key down, key up." In some engines there are two methods of getting keys. A text mode and a key press and release mode. Text mode is used, who would've thought, to read text from the input device, such like when you press and hold a button it will fire the event in accordance with the repetition frequency set in your operating system, or automatically use capitalized letters in the event message when holding shift, etc. The other is used for raw key events. A key event could include modifiers or not. A release key event could be it's own object type or it could be just a generic key event with the type member being release (which would be ideal here, but the other option wouldn't be infinitely harder if the class structure is sane, just dynamic type checking is slightly more complex and resource intensive than to check an enumerated value) Typically in game design, whenever an event is fired you check if you want to handle it in a large select statement or list of if statements and if you wish to handle it, you then alter some data that is then evaluated in the update statement. Typically you don't poll the device for it's current state. You assume it didn't change since the last time you got an event message. If this is indeed how DCS works then handling key up events would require marginal reworking. Some key up events are already handled though, such as the special options for 3 position switches like the A10C warthog throttle pinkie switch, which reverts to OFF when either key or button is released. I envisioned it in such a way that the change for the user only means that it acts as another modifier, along with shift, alt or ctrl. This is distinguishing it from a normal press and allowing a normal binding and a release binding to exist at the same time (as with the other modifiers), and allowing the existing logic for assigning buttons to persist as it is, needing no further adjustments. In that way none of the existing bindings should be affected in any way. The special options existing so far could be marked deprecated or somehow automatically converted, but would remain unaffected directly. This would create a unified interface, module makers don't need to worry anymore about if they should make any or all buttons have such a special options, needlessly bloating up the controls list or making people disgruntled about not having the laser arm switch in the ka50 be turned off if you flick the radar altimeter arm switch, to which you bound it, on the warthog hotas, but at the same time have the master arm switch do exactly that with the EAC arm switch.

planned in 2013. I have given up all hope of seeing this my lifetime.

You should also so that you suffocate and die if you fly through the chemtrails. Or that your pilot model starts to grow green blisters (depending on if you are flying through russian or nato chemtrails). Also we need to model the chemtrail release valve on the left side of the seat in all fighter jets.

I guess I was wrong. Please feed me molten lead as punishment.

I think they should just take a year off making something new and just focus on bug fixes, like the beam spill of the mig 29 STT being 180° wide apparently and reaching approximately 50 astronomical units. Or the AWACS having a lovely talk to us with 0% downtime telling us all about every enemy aircraft 500 miles away nonstop and in FC3 you can't even tune the radio to stop the blasted thing from spamming the airwaves with the useless rant instead of giving relevant information about nearby air threats ONCE and when we ASK for it. Again we are stuck with 3rd party overlord bot, made by fans for free in just a months at most. There are numerous bugs that make no sense or at least in relation to each other such as damage for anti ship missiles having huge discrepancies despite them being approximately equal in warhead size and tech. Such issues require literally 60 seconds of work to fix by opening some lua file and editing a number and yet they persist through the years and years and years. Secondly we pay ED for developing this software for us, yet we are given the tiniest bit of information about what is actually being done. My opinion is that they need to re consolidate, restructure, sharpen their tools and get the kinks out and then work on the stuff that binds everything together. For example: Why are weapons that the AI use different from the weapons that players use. Why is the GBU-12 on the A10 different from the one on the F18 in code? It shouldn't be. It's literally the same piece of kit. It multiplies workloads. Copy & paste is not a valid design pattern. Whenever there is a bug fix, do ED implement a unit test to prevent regression? I don't know, I doubt it. Do they use version control? I don't know. I hope so. Sharpen the tools, then work on the quick to fix things that have been around for years. Go through the bug repots, create tasks for each, organize and consolidate and fix. Leave the stuff that works alone until the stuff that doesn't work is working. I agree. A better Aim 120 logic is nice. But they work in principle. Other things do not work or don't make sense yet. Those are priorities. Because those things don't require months and years of research and asking subject matter experts and having bureaucratic legal discussions. It's plain logic, UX, tweaking values to be logical and engine work. Once you made them logical using common sense (ie. no mig 29 spikes from 500 miles away through a concrete bunker), you can then work on making them accurate to the real word. After the quick stuff is done, work on the big things that apply to all modules. ATC, DTC + Mission planner (outside ME), IFF, COMMS. We were promised ATC for multiple years. Whenever we ask it's like "we work on it, it's complicated, there are 2 time periods and lots of countries". NO. Screw that. You can do it incrementally. If the russians in WW2 use modern, english ATC until the russian WW2 ATC is done then that's 50000% better than what we have now which is basically "I wanna land" - "ok". We get no updates, we get no information and when we do get something it's "coming later", where later is always 1 year ahead. What are you? Developing a fusion reactor, because that meme was reserved for that? We were teased DTC a year ago. Not a single word since. We were promised comms and are still stuck with 3rd party software to do it for you and even when eventually put in, it was just basically voice chat for the side, not filtered through the radios using frequencies, ranges, line of sight and effects. When a 3rd party program by fans can do it so well, including terrain masking and range effects, why can't we have that in game where the data is available instead of accessed through an API? Because it isn't perfect? I don't know the reasoning. It doesn't matter it's not perfect or 100% realistic. It's something. It's working. If fans can do it, then why can't you? Yes, all those things take time, but not centuries. I would understand it if we were given a reason why our money is not put into those things. Instead we get shiny new things, and I understand that. Shiny new things make lots of money, and I love shiny new things as much as the next guy. So yes. Please just stop with the shiny new things, work on API, work on values, work on UI, work on the engine. I would've taken ATC over volumetric clouds. I would've taken IFF over high poly Caucasus. And yes I would've taken systems damage and countermeasures on ships over the apache. But those things aren't shiny new things that make people buy lots of modules. So I guess they don't matter. Of course all of that is just the opinion of some guy who is really impressed with how DCS can look so good, simulate in such detail but then horribly fail at seemingly the simplest things that have been proven to be doable in a reasonable time frame by people who don't even have access to all the tools, and for free at that and/or that have been around in similar software for for decades. I only want things to be better.