Tippis

Have you tried reading the OP? That's not how DLC actually works. Or business. Or DCS. Or modding. A work-around for the obstacle plane mods (and indeed any mod) creates is needed regardless of how little you want to understand anything and irrespective of you dislike for the game getting better.

So this is basically you admitting that you're simply trolling these threads. You're being useless because it amuses you, and no amount of not having a clue about how DCS works or anything related to the topic, and no amount of the mods telling you to stop will actually stop you. Groovy.

I don't know. It falls within that general area of “fallback is unexplored and unknown”. From a basic programming perspective, it makes sense if it would: the defaults are (possibly) loaded first, and any custom files are loaded later — ones in the mission file are obviously not handled until at mission launch, but that's the one one we can know for sure. But if it works like that, then it should be a case of all definitions existing, and the custom ones simply overwrite any ones that were there before. Something like, default defines “none”, “dot” (including neutral dot), “abbreviated” and “full”; if you only define “full” in your custom labels file, only the full one is overwritten and the others remain as they were. But note the caveats here: “makes sense”, “if”, and “should”. If it actually works that way requires experimentation that I haven't seen anywhere. Or… well… I haven't really looked, so it's no surprise that I haven't seen any of it, and I haven't bothered to investigate it myself either. There is one quirk to this, though. The way many things in that default label file are defined — things like colours, fading palettes, fading distances, and even the dot symbol — are used in all label types. It's just easier to do it that way: create a bunch of templates and then let each label type use (or not) whatever parts are needed so you don't have to re-define and repeat the same colour scheme four times over. This means that any custom lua that alters those template definitions directly would also spill over to affect even the label types that aren't explicitly defined in that custom file.

Sort of, but in a very backwards and unintuitive way. The most likely culprit is actually elsewhere, but it could also be a hidden override that makes your setting meaningless. There are three separate means and ultimately three-and-a-half layers of overriding what you say in the gameplay menu, in rough order of precedence: A user-defined custom labels.lua… a. …placed in your %USERPROFILE%\Saved Games\DCS\Config\Views directory. b. …placed in an included Config\Views directory in the .miz file you're running — this overrides option 1a. The gameplay preference setting (which picks the label style as defined in the default or custom labels.lua file) in… a. …the mission-creator's local settings. b. …your local settings — this is the default if nothing else happens. The mission editor setting, which can be… a. …set to not enforce anything in SP — this reverts back to option 2b b. …set to enforce a specific setting in SP and MP c. …the surprise option: set “not to enforce” anything in MP, which actually enforces 2a(!) Starting with the labels.lua file, you can come across roughly three different variants of the file: version 1a — the really old-school variant using a set of Lua arrays to define how each label style should be drawn; version 1b — an updated version that also supports dot labels and abbreviated labels; version 2 — the one we have now, which uses entire Lua functions to define each label style and supports two levels of dot labels (normal and ”neutral”). So the first thing that can happen is that your labels.lua is simply outdated: you're picking a label style that doesn't exist or just isn't defined in the lua file so it reverts to… something. The fallback mechanism here is largely unexplored and unknown. The second thing that can happen is that your labels.lua defines the labels differently from what you'd expect. For instance, the mission maker might have wanted to cover all cases and work-arounds and just defined everything to look like dot labels, no matter what option is picked in the ME or in the settings. Or, like we do in our group, we have a standardised labels file that go into all our missions where everything is redefined so the mission maker can pick between (effectively) two styles of abbreviated and two styles of dot labels (both of which show something else than simple dots) — none of them show “full” labels and none of them show nothing. Thus, the third thing that can happen (or maybe the second-and-a-half:th) is that there is a custom labels file sneaking in somewhere that you're not aware of. For instance, if you use a mission template of some sort that you always build your missions from, that template might have a labels file included that screw up your expectations, and that you're not even aware of. This can be identified and remedied by opening up the .miz file (it's just a zip) and looking for a Config\Views\Labels.lua file. The fourth thing that can happen is that your setting just doesn't stick — a file error of some sort, or that DCS has gotten confused about where to look so it watches the wrong directory for a file (or a setting) that tells it to do something else that what you think you've set it to. This is a four-letter-word to try to identify and trouble-shoot, and is luckily very rare, but it can happen… The fifth thing is the SP vs MP thing. In SP, the mission may enforce a label setting, and if it does, this should obviously invoke whatever Labels.lua file is the most appropriate (custom in the .miz ranks higher than custom in the user directory, which ranks higher than default). In MP, however, it gets completely bugged. If you enforce labels in an MP mission, you get the usual result: the label style is picked by the setting chosen in the ME; the same sorting order for the Labels.lua files is used to pick the appearance. If you don't enforce labels in an MP mission… well, then you actually enforce labels anyway — just from the most bizarre, unintuitive, and obscure source imaginable: you get whatever label style the mission maker had set in their local settings when they saved that mission file. This mission-maker setting is included in the mission definition for some odd reason, and if you try to remove it, the mission breaks. Thus, if you run in MP, even if it's just a local server for yourself, you can come across a situation where your local settings aren't used because the mission enforces something else, but your local settings are also not used because the mission doesn't (supposedly) enforce anything, and rather than looking at your local settings, it picks the label style from that included mission-maker info and uses that instead. In the ME, it will look like you've set the mission to not use any style at all, and in your gameplay settings, it looks like you've picked something very specific, but you'll get something completely different because that's what someone completely unrelated used at some point somewhere… The more you try not to enforce things, the more things are enforced, but outside of your control. But again, this is only in MP (and if you mess with the mission, it should then include your local settings as its fall-back data and use that anyway). As for solving the whole thing, the immediate standard suggestion is that you (temporarily) move your Saved Games\DCS\Config directory somewhere safe and run a test to see if still misbehaves. This should set everything back to defaults and use the latest label.lua from the DCS install directory, at least if you create a new dummy mission from scratch so you know for sure it doesn't contain any custom definitions. If it still doesn't work, the DCS install has a broken labels file in it. If going for defaults works, you can then start adding files back in and see at what point the labels break again.

And how is what you think in any way, shape, or form relevant to the topic at hand? Third-party devs have already proven your belief wrong so we're once again at that stage of your wishlist trolling where you're starting to contradict known reality just to get the last word in. Good thing you're not a dev then since that would have deprived us of some of the more fun aircraft this game has to offer.

Because it would improve the game, widen the appeal ever so slightly, and add things they are not personally interested in. These are clearly heinous crimes that must be trolled stopped at all costs. Arguments from incredulity are fallacies for a reason. What you believe is so amazingly irrelvant and off topic that it beggars belief. Oh, and do you remember what the mods have told you every time you get into this "gotta have the last word" mood of yours in wishlist threads...?

So? If that's the argument against it, then all modules should be pulled from the store and development should cease on all future modules because none of them will reach such a moronic standard. ...and can then easily make even more money by also selling the module to the one giant combat sim. Everyone wins. Anyway, we've discussed this before. You always come back to this wrong-headed notion that "no"-votes mean something, They don't. That's why your trollish whinging in wishlist threads is also meaningless: because it provides no valuable or useful information for anyone. The only thing that matters is how large a proportion of yes votes you get -- if it's large enough (and that doesn't have to be a very high absolute number), there's value to be had. The only time "no" votes matter is if the amount to 100%. All other times, they're worthless noise.

We do. Mostly. That's what all the conditionals are about after all. The problem is rather the highly obtuse and inflexible way we can combine them with just “OR” statements. What we could use to make those “IF”s a lot more clear, and the execution logic of them more clear, is the ability to add explicit parentheses / brackets and equally explicit “AND” statements to (optionally) replace the current implicit ANDs and unclear OR groupings. For bonus funpoints, complete the set with NOT, XOR, NAND… But as mentioned earlier, a huge problem in all this is the implicit and nature of the logic operators that are there, and the equally implicit and obscured grouping of those operators. It's an old thread and an old problem with an even older UI that was in dire need to upgrades and refinements half a decade ago.

Also, both the CE2 and the -52 were testbeds for new engine sims, since they differ quite a bit from the bajillion-hp barely-contained-explosions you see in the WWII fighters. If there was ever a small chance of them wanting to build other kind of prop planes than classic dogfighters (and there has always been every indication that such planes are planned In The Future™), getting the coding basics for a few more engine types would be a good and sensible foundation to build on.

So in other words, you are making suggestions for workarounds for something you have never encountered with no idea of or second thought about what the causes could be and how that would affect your guesswork.

That will obviously not solve the OP's problem. Have you tried reading, thinking a bit, and/or understanding how DCS works before you post? Anything that overwrites an edit (eg. clearing a default keybind) will also overwrite a remap because it's the same thing. If the OP is seeing his bind clears being cancelled out by something, remapping will do nothing to stop that. Anything that can't be cleared also can't be rebound. So if the OP is having issue with something that isn't exposed in the binds menu, remapping that is obviously not an option. What do you have against user choice and improvements to the game, by the way?

But he's not. He's referring the Christen Eagle, which is not a military trainer and which ruins your complete lack of anything remotely resembling an intelligent, coherent, or rational argument just as well. So what you're referring to is is not really relevant, now is it? Same as always when you go after a wishlist thread (in spite of the mods repeatedly telling you to stop trolling them) with your pointless whinging. As for the poll results, they show a significant portion of responders being interested. You have yet to understand how polling and statistics work, huh? Given how fond you are of quoting them, it's gut-bustingly funny how completely incapable you are of actually deriving any kind of understanding from them.

If they were anywhere near that close to even rolling out the tiniest sliver of a feature, they'd be shouting it from the rooftops and doing 24/7 hype video segments. So no. That's not really “speculation” so much as “wishful thinking in direct opposition to everything known and every trend and pattern ever.”

…also if zones in general were not infinite-height tubes, but rather existed as some kind of [whatever]-radius spheres. e: I remember there was some talk a while back, before they started nibbling away at the problem with the quad zones, about adding arbitrary-shaped zones with height restrictions, which would obviously also be good, but it seems like slow going.

...and plane repairs is a hugely critical part of that. So you fully approve of this idea, presumably. There's a reason why a basic framework for what the OP is asking for is already in the game, after all, but we can equally presumably add that to the list of DCS-related things you are wilfully ignorant of.

Because you refuse to read and because you refuse to do what the mods say and stay out of threads where your non-input is not necessary. You have already demonstrated, stated, and fully explained that you do not understand the topic. That very refusal to understand is exactly what has caused those extra pages. Your continued telling everyone that you do not understand is unnecessary spam. Go troll somewhere else.

You have long since proven that you don't even understand the problem. The fact that you now claim that you don't “pay much attention” to something that affects the entire input system of the game just further highlights how uselessly uninformed and irrelevant your input is. This is a wishlist thread. Your desperate desire to keep the game from ever being improved has been noted and is as useless as ever. Go troll somewhere else.

It's a good idea at the basic level, but it has some pretty significant complexity to it. On top of being something that other units can interact with without exploding, it will need to be able to affect AI pathing, which is a fairly significant departure from how everything else works, and bridge pathing in particular has a long history of... being less than satisfactory, let's say. They have come and gone (and come again and gone again), but you'll find numerous examples of ground units ignoring bridges, going under bridges, literally travelling on the underside of bridges, and complex pathing (again, especially over bridges) just outright causing massive CPU usage and even server crashes. So yeah, good idea on the face of it, but probably hugely complex to actually make it work reliably in a satisfactory way.

It would help the discussion if you had any idea what you were talking about. You have already amply proved that you have no experience with competitive multiplayer games, and in numerous other threads, you have amply demonstrated that you understanding of how DCS works (to say nothing of the ecosystem surrounding it) is nil. It would also help the discussion if anyone could present an actual argument why such a basic MP feature is absolutely not needed in DCS MP. You, in particular, need to actually present something to show that this isn't your usual "no, I refuse to accept anything that improves DCS' functionality" and "nothing that could potentially affect my advantages must ever be allowed to exist" whinging. Remember what the mods have told you repeatedly: this is a wishlist thread. If you don't support it, do so by not posting. Your dislike for the idea has been noted and is discarded as pointless and irrelevant. Appeal to ignorance and appeal to incredulity are fallacies for a reason. You are also confusing cause and effect. If something doesn't exist in DCS, maybe it's because the tools aren't there to make it happen... hmm? At any rate, there are plenty of dogfight or gunfight servers where this kind of thing would be helpful. I'm running one myself. Is not really relevant because that's the mission-maker's problem, not something the balancing tool has to care about. You can certainly make an argument that this is something that the balancing mechanism should be able to handle, and that's a good suggestion: it falls right in line with the notion of the mission-maker being able to tweak the ratios and/or the margin of error between the two (or three) teams. No, that's not how multiplayer players actually behave. In fact, its their tendency to the exact opposite that has made it so that team balancing features are a staple in just about every (team-based) MP game since, oh, the 1990s (possibly earlier but I wasn't in a position to observe that).

Setting aside their involvement in various semi-official competitive events, which would suggest that they enjoy going down any path that brings a bit of attention to the game, this isn't really about turning the game into anything. It's about giving mission-makers more tools to more easily create a wider range of content. And if it's any path the devs would want to go down, it's one where the game gets more content because that's what ultimately keeps the interest in it alive and gets people to keep buying modules. Your example just shows that a balancing tool needs to allow for some sort of parameter tweaking, and that's pretty much inherent in the concept anyway.

Because they want the advantage. Any experience with any kind of MP in the last decade or three will have shown this to you. Whether it makes sense to you or not is irrelevant - it just shows a fundamental inexperience to suggest that it's not what players do time and time again. Yeah, you're not really qualified to have this discussion if this universally disproven nonsense is the unfounded assumption you're basing your whinging on. As always, this is just you not wanting to see DCS evolve and get better, and as always, you are arguing from a position of complete ignorance, inexperience, and lack of understanding of the topic at hand.

“Supposedly” is not “actually.” And the point is, if you want to create a balanced scenario, you create a balanced scenario. Creating an unbalanced scenario doesn't take away from the usefulness of — much less “poke a hole in” — the idea of having a built-in team balancer that works on the slot selection screen. Again, at best it shows that such a system would be even nicer if it allowed you to defined the balance ratio and/or the margin of error. But that's really it. But coming up with improvements doesn't take away from the foundation. No it's not. It's just good old airquake. It's the way competitive MP has worked for, oh, 40ish years now. You'd have to be catastrophically out of touched to be confused by something as simple, standardised, and common-place. You haven't played many games with team balancing have you? Have you seen any? Because no, that is not something “team balancing in games” uses or necessitates.

The most immediate way of doing it is to use the thoroughly antiquated “prepare mission” function in the mission editor. It only really works with the A-10 and the Ka-50 — all modules after that put those kinds of settings in the mission editor like the OP is suggesting for the A-10. This puts you in the mission, lets you set up your aircraft, and then you can quit out and have those settings saved. What this does is that it creates a set of “device files” for the systems you set up during the prep, and those files are then included in the mission file. This only works for SP but the files that are created are things you can then use in an MP mission. I don't fully remember their names and format off the top of my head, so you'll have to experiment a bit with it — they're fairly obvious and self-explanatory though. You can extract them by opening up the .miz file using any old zip manipulation tool and dig around — they'll be in their own subdirectory in the mission file, and it's best to just extract that full directory. You can then insert them in any new mission you create by using the same zip manipulation and just put that directory back in there. They'll be named after the system, so you'll have an ARC-whatever file for each radio for instance, and in those, the presets will be a numbered (Lua) list with the frequencies exposed as simple Hz numbers. It's very easy to manually edit and get what you want. The limitations to this is that, 1) this is a pretty elaborate process as you may have noticed: create a dummy SP mission, use “prep mission” to create the necessary files, extract them, create the MP mission, re-insert the files. Once you have them extracted once, you can just edit them using any old text editor — no need to keep using the prep mission thing. 2) as mentioned, the method was originally intended for SP and it shows: the files you extract will apply to all A-10s in any mission you import them into, as opposed to the later way of doing things directly in the ME for other aircraft, and have different groups use different settings. Everyone gets the same thing with this method. This is why it has been (often) proposed to just do a revamp of the whole thing and make the A-10s work like any modern module, with all those “prep mission” settings being exposed, on a per-group basis, directly in the editor.

That doesn't really poke a hole in anything, though, other than possibly the mission-maker's self-image of being somewhat competent. Presenting an unbalanced scenario is not an argument against balance. Quite the opposite. If that's the setup for the available spawns, you wouldn't enforce 1:1 participation. Simple. That doesn't mean that there is no point in having a team balancing system — just that it would be made even better if you could define that balance in terms of other ratios or just with an acceptable margin of error.

In our modern day and age where we are bombarded by hype and lofty promises and fail to be met by the final product, it is always nice to reflect on the fact that this is a phenomenon as old as man… doubly so when we're discussing actual bombardment.