Tippis

Good that it worked out. It would be nice to have a more explicit borderless setting rather than hoping it sets itself right with the resolution relative to the desktop, but there you go.

It truly should just be a matter of not checking the full screen box. Is DCS set to the full resolution of your primary monitor? This seems to be the determining factor as to whether it runs in borderless mode or not — if the display and game resolutions don't match, then it's either “real” full-screen or, obviously, in a window with all its decorations.

Wait what?! Ugh. There goes my next idea… That one doesn't even make sense since it's a world event that actually does damage to anything in the zone rather than just make something happen to the player.

I mean, it varies. On the one hand, sure, pure tutorials are probably best left as SP since they player will want to active / hard pause to review processes and procedures and reference images to see which switch does what. MP isn't all that suitable for that from the get-go although the option to hard pause is still there to some degree. Multi-crew aircraft definitely throw a spanner into that neat separation though, and there's also the extension of tutorials where you might want to be able to play along with a student and still have them see all the things and get affected by the triggers that those SP-only actions provide. Stuff like helper gates and in-cockpit highlights and overlays could be just as useful in an MP teaching scenario as in an SP tutorial. But even beyond that, there are some information points that are immediately available with the X conditions that require a bunch of maths to figure out, or which can't be gotten at at all through other means, and some system failures that simply don't exist in MP (at least not as controllable events — you might still get lucky when you're shot at). As it is, it really feels like a lot of that functionality has been slowly extended to deal with new tutorial requests and surfacing data directly from the active simulation, whereas a feature set that actually matched how the game has evolved and how it's used now would probably require a complete rework of almost all the APIs to be more of a (local and remote) query-and-response kind of setup.

Isn't a lot of the horribleness and with the X actions (and potential scripting tied to that) due to how it reads “my plane”, but in MP, the script is run on the server and that server doesn't have a plane to read any of the interactions from? And even if it did, you're not necessarily interested in its aircraft, but everyone else's. So to make those work, it would have to be a much more complex “request data from client” call and response setup, or possibly even having some way of running client scripts separate from what's going on on the server, and having the two scripts communicate. It can get very ugly very quickly.

Seems eminently sensible Commenting out code is made trivial in any kind of scripting and programming for a reason, and the same logic applies to trying to pick apart and test complex triggers. Since all the triggers are just UI for underlying scripts anyway, it might not even be difficult to do in the mission file code.

There is actually no conflict between the two if you read the sentence after that. And note that there is a difference between those mod and what they enable (and disable) compared to general asset mods.

It's no more a deliberate provocation than when you said it. I'm simply asking you to be a bit more careful with the accusations you throw out. They can very easily be reflected right back at you. Beyond that, I have plenty of positive things to add to the poll, namely the reasons why you're not seeing the results you were hoping for and what could be done to the game to improve those results. You asked, so I spent some effort on providing a good answer. That answer also not being the one you hoped for still doesn't make it negative — just that the issue may actually be different than what you first assumed. Hence why I'm asking what the intended purpose was: because the dissonance between where you hoped this discussion would go and what answers you're getting may simply come down to a difference between that intent and how the poll and its subsequent follow-up questions are interpreted. Thus, a clearer statement of intent may help in getting more constructive answers. Either way, accusations and recriminations will not helps you. And no-one is arguing that games don't have mods. What you're describing is simply sampling bias. If you look at where modders gather, of course you will find lots of people who mod their games. You need to look elsewhere to figure out whether that's representative of the playerbase as a whole or not. DCS is not an outlier. You're just getting a perspective you're not used to because the question you were asking meant you touched on a segment of the game that isn't part of that clique. It's part of a very different one. The bias I'm talking about is how you try to assign various faults to the players — too young, too irrational, too resistant, too biased ironically enough — rather than accept that the evidence from how things work in DCS is reality, not something people have imagined. And that's the part you need to understand: others have evidence too. Don't dismiss it because it doesn't match yours. The two can actually both be accurate at the same time. The point is, you can bring up your curated zero-fault mod list as much as you like — it doesn't change the fact that mods do indeed cause issues. Eliminating the mod as a cause isn't careless of lazy. It's a necessity. Otherwise the devs would be chasing ghosts that aren't even theirs to deal with. It's not “low-hanging fruit and be done”; it's narrowing down the search. It's only done if it turns out the mod was causing the error. At any rate, this then ties back to one of the common reasons why mods aren't used: because DCS has enough issues as it is before we throw mods into the mix. Less so for with pure content mods, but they have also on occasion proven to cause problems. But then, there's quite likely a bit of a bias there as well: content mods are a lot more common so even if they have less opportunity to cause issues, they will still generate a large percentage of the instances where a mod is at fault. Dismissing this as a factor as to why some choose not to use mods, and just because your particular mod pack doesn't do that, is to deliberately turn a blind eye to something pretty obvious. That is never helpful. If you want to talk about outliers, this is probably a better place to look: the fact that until recently, within a decent segment of the game, the “beta” client supposedly meant for bug hunting was the standard way of running the game. Here's that differing clique I mentioned earlier. A similar clique that intersects this one is the MP context, where content creators have to contend with the fact that they're already dealing with a niche audience (I've seen the number 10% being bandied about as how common MP is in DCS). Catering to this small audience quickly becomes a matter of going for the lowest common denominator and staying away from blockers to joining — unfortunately, the way DCS works, mods tend to be that type of blocker and to fall way outside “common denominator” territory. Off the top of my head, I can think of one mod that has managed to overcome that: SRS. And that's because of the obvious combo of how common out-of-game comms are in MP in general (especially since it started in an era where DCS itself didn't offer any) and how comms manipulation is a key part of the sim itself, and it's neat when this ties into the comms app being used. But that's a sim function mod, not assets, and it ties into an external third-party app, so it's already a fair bit different form what you're asking about. Tacview and LotATC are similar mods-and-also-add-on tools that see a fair bit of use. But I'd almost question to what extent those are even seen as mods at all, and how much they're just looked at as the third-party tool. And to confuse matters even more, it's worth noting that public 24/7 MP is probably the most universally modded part of DCS you'll find, not just because of those three but because of SLmod and how it's used to remote-manage the servers. But again, that's functionality that doesn't affect the clients in any way — not assets that go into the mission creation side of the equation. The issues I rased are based in reality. Your curated collection not being a guilty party in that doesn't change that fact. The problems are real. People reacting to those real problems is not illogical or irrational. It's not lazy or false. It's simply a perspective and experience that you may not come across as a heavy mod user. Please insult my intelligence. I asked you to clarify because I felt the reason got lost a bit in the shuffle. The OP and the expanding second post simply asks the question of how many use mods to enhance out missions, and if we don't, why that is. There is some mention in the OP of there being obvious gaps in the unit list, but that could be interpreted in a number of ways. If you want to use the numbers to prove that there is great want for more units to fill those gaps, then that's one argument to be made. If you want to use the numbers to prove that there is great need for better modding support because that will also fill the gaps, then that's a different argument. If you feel that the numbers aren't giving you the supporting evidence you hoped for so you could make those arguments, then I feel with you, but that could just be due to how you asked your question or how you intended to construct your argument. I actually feel that you can still make those arguments even if almost half the answers are “I don't use mods” because that also says something about what ED needs to do. What it doesn't tell you is that the reasons why the numbers are like that are somehow spurious or false. I take it from this that it's not so much a matter of directing your own efforts to what is most popular, but rather to give direction to ED. This is good. Also… …very much this. I understand your frustration but you shouldn't interpret any of this as an argument against what you want. Only as a set of explanations for why you are getting those frustrating results. There are very real and very rational reasons for them. But take heart, your basic underlying argument can still be made — its logic just needs a bit of tweaking, or the results need to be cast in a slightly different light. Take the explanations on board and this will actually help your ultimate argument for what ED needs to do to get deal with the lack of assets. Trying to cast blame on the end users will not.

It's an ancient case, and I think it was fixed at some point since then but… Are any of the servers that don't show up correctly in the MP server list on the same network behind a NAT? And if so, is one of them running on the default port? Back in the early cretaceous era, I noticed how running multiple servers on the same network as my client would get the client very confused about which server was which, and it would fill in the (observable) server information with just about any data it could find. It looked like my servers weren't there, but in fact they were — I just couldn't make out which one it was because they all showed up as duplicates of other servers. If it looks right in the public server list (or in your “my servers” list), and it's only your local MP listing that is screwed up, it may be that something similar to that old bug is rearing its head again.

…and you have polled this extensively, I take it? Because otherwise, your anecdotal evidence has no more value than my not having met a single person who plays those games with mods. Neither really proves anything (or even disprove each other). Also, note that if it weren't true, then those games would have evolved modding support by now rather than still being stuck in the position you describe. Lack of mod support begets lack of mod support, and you're describing games that have no mod support. Which was kind of the point all along. Cripes. No. Look, you really need to dial your prejudice back. Way back. You tried to dismiss people's actual experiences as bias. You're calling the community “mod resistant” without really wanting to listen to the reasons why this may be the case. Now you're leaning on some… interesting ageism that makes assumptions about people's opinion based on their equally assumed age. Same with your implying that people are illogical and irrational further down the post. This is not doing you any favours. That's called a clique, and you're over-generalising from your own position. You like mods. So you find them for your games and you discuss mods with players who also use and like mods. Just because there are mods does not make them the standard way of playing the games, nor does it mean that these games don't follow the same pattern of higher or lower mod usage. DCS is not an outlier other than actively trying to change to become more mod-friendly. You're just coming into this assuming that its half-decent selection of mods means that it falls into that category already, when the reality of the situation is that it's still struggling to get there. You're judging the game community based on this erroneous assumption of where the game is positioned, rather than looking at what the game actually is, and figuring out why the modding numbers look the way they do from there. That doesn't actually do anything to his argument. The simple fact of the matter is that step #1 in trying to resolve issues in DCS is to disable mods, and that a lot of that time, this does indeed solve the problem. Go through any of the bug reporting threads on this board, and you'll find “disable mods” as pretty much the go-to answer alongside “post a track” for identifying what's going on. You have found a curated set of mods that work, and that's fine, but that doesn't mean that mods introducing more bugs into a game that is already notorious for having all kinds of odd behaviours is a good reason why people stay away from anything but the official ones. If anything, it just further highlights why more stuff is needed as core content since mods won't solve the problem given the state of the modding support at the moment. Alternatively, it can be used as an argument why improving the modding support is more than worth the effort that would be put into it: because then they could rely on the community rather than having to do all that content work themselves. Logic and reasons have been offered as to why modding in DCS may not have the traction you wish it did. You should probably look at how you've responded to those so far and revisit this statement. Don't get me wrong. Your ultimate conclusion here is not bad: there are lots of assets that we could use as part of the core game, but your can get that point across without leaning on mod usage as the foundation of your argument. Or, if the goal is to make mod usage more wide-spread to compensate for that lack, address the systemic reasons why we're not there yet rather than throwing random accusations at the players who simply respond to those reasons. I suppose, to be a bit more constructive about it, I'll say that I'm a bit confused about the purpose of the poll. If you could clarify it, that would help. Basically, what are you looking to glean from the numbers? What kind of content everyone feel they're missing, if any, since that should be focus of ED's development? What kind of content everyone prefers, since that gives you guidance to what you should focus on in building your own mods? To show that modding as a phenomenon is underserved and that ED should focus on that as a development priority? To get to the logic why some content is used or not, since that may show where more supporting features need to exist? …or some other reason that I've missed?

Nah. You see it in every game that suffers from rudimentary mod support. Specifically, you'll come across the same downwards or upwards pressure no matter where you look: • So-so mod support -> resistance to use mods (for any number of reasons) -> lower returns on creating mod-heavy content -> less need for mods -> less need to improve mod support -> repeat. or • Good mod support -> using mods becomes almost automatic -> no loss of audience for mod-heavy content -> higher demand for new mods -> more need to improve the mod support -> repeat. DCS is living in a bit of a grey zone between the two, where mods are possible and they're working to get proper good support, but have been through many iterations of exactly how they need to be done, so there's a lot of historical (and current) confusion about what works, when, and how. And as the support is slowly improving, some limitations still linger to muddy the waters and to keep that confusion and its accompanying resistance active, which means that the devs are not just struggling with creating the mod support itself, but with managing the technical transition and the historical image of that support. They say it takes a generation to change the public perception of something. Hopefully, it's going to be a bit faster than that in this case, but we're almost half-way there already…

It's factor. Otherwise you wouldn't need OvGME to begin with. It's whole purpose for existing is that, for some things, you need to mod the core install. For others, you can use the user profile mod category. And in making this separation between what can go where, you are now asking the user (and mod creator) to keep track of where the mod needs to go and what it alters and, ultimately, risks breaking. Ideally, you'd only ever need the latter and wouldn't need OvGME or similar tools to begin with. Hell, ideally, you wouldn't even need to create much of a file structure at all, and DCS could just load directly from the mod zip files much like it can from the mission (also zip) files. It can already transparently treat zips as file systems — if it could do it for entire mods, another hassle would go away. It's not about what the solutions can do. It's about the problem that they're there to solve to begin with — problems that ideally shouldn't even exist.

It's not that the mods need to be made part of the game — it's that the game only half-way supports mods to begin with so we have to have all these work-arounds and extra tools to make it behave even slightly nicely with them. You almost see this with the official modules and how they work: every time a new official module is made, all client installs have to have additions to their CoreMods and Bazaar collections of assets: you still get large portions of the module, just not the bits that let you fly it. A good case study is the Supercarrier vs WWII asset pack, where the former can be deployed and accessed (but not used) anywhere because so much of it is just the assets and those are all part of the CoreModes. The latter is strictly limited and will even break in various fun ways if you try to bypass the requirement, because of how little is in the CoreMods and how much is in the full module. And it's an asset pack — it's pretty much all… well… assets. Again, the problem is one of fallbacks: the official modules work because the client has a bunch of stuff in their CoreMods that it uses to represent the module content. If you were to remove any of that, things start going haywire. Many airplane mods survive on the fact that they also have a fallback in form of The One True Air Unit — the Su-27 (for historical Flanker reasons). At least as far as assets go. Nothing like that really exists for any of the other things you'd like to add, at least not in a way that doesn't look very very silly. Eg. if all your bespoke fortification-mod sand bag statics defaulted back to wind socks for anyone who didn't have the mod installed. So that's one thing that needs to be resolved: how should the game handle fallbacks? If it encounters something that it has no record of, what does it do? What assets does it use? If it's a live unit, what driving/flying/fighting logic is employed? Another issue is with the core install vs. user profile separation. They've actually done a lot of work here and made it more and more possible to alter the game via your user profile rather than mucking around with the core install files. The more that can be done there, possibly even to the point of overwriting more central files in the game and its various modules, the better — this would remove the need for a mod manager, especially if this could be made subject to the “clean clients” server flag in a more dynamic and interactive way. I.e. letting you put in replacement files for pretty much everything in the DCS install file structure and have those user-specific file take precedence over the base files unless the “clean client” flag was set, in which case the game strictly reads from the base install directory, and those files can be protected by IC checks to hell and back. A lot of the annoyance we have with IC right now is that the only way to alter some files is to directly replace them in the core install; there is no user-profile override for them. The third problem is, as was mentioned earlier, mod discovery, installation and updating. There are a few ways to go about that. The most convenient for the user would obviously be if everything existed in the same repository — most immediately the DCS User Files — rather than there, on github, on personal cloud storages, on various self-hosted websites etc etc etc. So if you come across a mod that is blocking you, you can immediately find it. The evolution of this solution is to expand the notion of the “required” field in the mission file, where mods not only mark themselves as required, but also provide the client with its source location. This would then enable auto-downloading of modules from any source if the user accepts it. This would still require quite a bit of structure and organisation on the mod creators' end — always strictly following an archive structure that exactly replicates how it should go into the user's mod directory; always maintaining a “latest” archive to be fetched (including some kind of hashing to tell the client whether they need to auto-update or not); and of course, being subject to moderation and outright blacklisting because their mods are just too horrid for whatever technical reason. One might think that having that in place would solve the issue of fallbacks, but at the end of the day, the player needs to be able to choose, and what happens if they say “no”? Does the mission still load, but rely on fallbacks, or is access denied? Basically, winning them over is all about one by one removing the obstacles that sit in the way of the player wanting to run a mission or joining a server, and only ever clicking “load” or “connect” to do just that. The rest is handled automagically. The issue is that a lot of that magic falls on ED to conjure up, and that this deeper support will inevitably end up (rightly or wrongly) being interpreted as their support for xXx420WeedLord69Hitler1488xXx's genocide mod, with all the legal funtime this will entail. Oh, and security issues… we haven't even touched those. …on reflection, all of this sounded a lot more negative than I actually feel about it. I'm not saying it's all dead in the water and we have to live an ascetic and mod-free DCS life. Only that we're not sitting on the most solid foundation for building out good and hassle-free mod support. The game has a ton of very good mods — it was just never really built with them in mind so it's even more of a miracle that they can exist to begin with. The more that can be done with that ecosystem, the better everything will be, but it's a long climb.

It really isn't. The evidence is in the interactions with the players in question; with the amount of “don't worry — you can join with whatever you have and nothing more” we have to go through; with the very clear drop in numbers we see any time anything extra is required, no matter how available it is. Don't ascribe other people's experiences to your biases.

I'm in a similar position. I did the annoying thing of answering the poll in two opposite directions: I use a very select number of military aircraft mods and also I don't use mods. The problem is, anything that puts even more of a barrier between the player and the (multiplayer, which is what I build for) game is a no-go. I will happily try to add in the most out-of-place aircraft for some very tortured-logic reason just to enable a player's ability to join — if that's that's the only plane they have, that's the one they get to fly. At the opposite end, I will refuse to add even the most sensible addition if it disables players' ability to join — if they have to install a lot of extras on top of the hassle DCS is by default, then I've already lost them before we even get into the process of finding a fork of a tool based on a previous tool so you can (hopefully) find a version of a mod that is suitably compatible with the tool and/or the game. The reason military aircraft mods work in all this is that they are usually not just self-contained, but more importantly provide a fallback: anyone who doesn't have the mod install sees an oddly-behaving Flanker. It's ugly, but still: they do see an airplane, and they can shoot it or avoid it or do whatever they want with it. It just looks wrong. Other mods rarely have the same kind of fall-back, even if you manually bypass the “required” field. Other players may then be able to join, but best-case scenario is that they see nothing and nothing happens, so the creator's time is wasted; worst-case is they see nothing and then explode, so their time is ruined. The inconvenience on both player, creator, and server end just isn't worth it unless there is a graceful fallback built into DCS itself. In most cases, there isn't, and this is an ED-level issue rather than something the mod can really resolve. On top of that, there's the IC to contend with. Admittedly, this is less of an issue nowadays, but all the other mods — the ones that could offer gameplay improvements and convenience as opposed to just being decorative — tend to fall straight into this category and as a rule have to go as well. SP could be a different matter. There, I just build for myself so any mods I have I… well… obviously have and wouldn't be restricted by, but due to the above, I don't have many to begin with. It's such a small niche for my own creation that there's no reason for me to install anything that doesn't work in MP without the mod installed.

Are you talking about the LandingReFuArm AI task, where it occasionally gets stuck if it can't do one or the other because of lacking stores? Or are you talking about separating in the rearming interface (two different buttons maybe?) and/or the F10 menu (so you explicitly ask for one but not the other), since most modules love to interpret any rearming or refuelling as a refresh of your stores, which means you lose out on any existing weapon programming even though you just wanted to top up on fuel? Or both?

Not without resorting to infinite weapons and fuel, and depending on the module and whether you want the player to be able to run out during an individual wave, this will of course potentially create problems of their own.

It's always been semi-possible to use it to create a very limited economy in a real-time campaign, where you want to protect incoming transports or replacement planes because they refill the warehouses. With the new scripting tools we got a while back that opened up the option to directly manipulate warehouse stores, it's now possible to do a lot more and a lot easier. But most of that is a list in an equipment table, and you have to jump through a ton of hoops and poke hole in the scripting security sandbox to make it persistent. But at least you can make it persistent now since you can write exported/saved data back into the warehouse state. And even then, it's still just numbers available. It can be used to represent a long-term logistics state on the map, and fiddling with specific aircraft states would be a huge step forward. Oh right… maybe if I actually finish my thought. The point is, I could see something similar being done on an airplane level but I'm contemplating whether it's best to let DCS do it itself, or if maybe a different way of going about what the OP is asking for would be to be able to extract damage states and cockpit arguments, but that would in turn require all the arguments to be available for client aircraft. That would be a huge win on its own.

That would definitely be a neat bonus effect if the damage and system modelling gradually started to allow it. Really, the only thing that stops much of this from happening (almost) tomorrow is the unevenness of the modules and that, on its own, it's perhaps more of a “must do the checklist” novelty. If long-term wear were to be a factor, it would suddenly matter even more and have an additional purpose in terms of slotting into and driving other mechanics. If it gets enough traction, it might even provide a bit of development feedback push where more players want to see more effort spent on the systems modelling because of how that improves this feature.

Shouldn't be too difficult in principle, but it depends heavily on how well systems degradation (and accompanying effects) is modelled in the specific module. If it's just done on the level of “works / broken” then obviously, there's no shades of gray between that you could randomly dip into. But things like the pre-set engine wear in some of the helo modules shows that part of is can be, and indeed already is, implemented. There's also the issue of how “client” aircraft differ from “player” aircraft, now how some faults and degradations aren't and wouldn't be available in MP. For actual uneven axes, that should be utterly trivial but easily also quite infuriating — just add ±small% to each parameter in the axis binds every time you enter a new cockpit. By default, I don't think this would necessarily yield uneven axes other than possibly for custom curves, since you can't shift the centre point to any significant degree. But again, in concept it's there.

Procedure. Getting more practice in while doing it live rather than just in a strict training environment. But again, the only one who has suggested that is you. If you don't like your suggestion, you can just change your mind and it will go away. No. By very definition, having unlimited fuel is in every way nothing like having to manage fuel. The whole point of unlimited fuel is that, not only do you not have to manage fuel — you can't manage it. It removes it as a thing that happens. Assisted AAR means you have to manage your fuel, same as everyone else. Then they need to remove tankers altogether, since their entire purpose is to make access to fuel easier. Or they could learn to police their servers better. The good news is that there are assists available for that. You can't eat your cake without having it.

You have to make up your mind. Either practice has a value or it doesn't. If you can practice and also get fuel at the same time, then that has more value than practising without getting fuel. No, it's the exact opposite of giving everyone unlimited fuel. It means everyone gets to manage their fuel the same way. That would be a function of having a tanker in the mission — the presence of refuel assist would not be a factor. If it were true for those who had an assist turned on, it would be equally true for those who had it turned off. Of course, in actuality, it's blatantly false for both. Good.

Good thing that no-one has asked for that, then. Well, other than you, just now. Strawmen are a fallacy for a reason. People would also certainly want it enabled online. Just because some would want it off doesn't mean there's no point in having it. After all, if they have it off, then its existence does not affect them so for all intents and purposes, for them, it doesn't exist even though for others it does. Options are kind of neat that way. Oh, and remember what you said earlier: multiplayer is a tiny tiny utterly minute minority so their opinion is wholly irrelevant anyway. Right?

No. I'd allow the refuel assist because I'd want the players in our community who struggle to struggle less, and it wouldn't affect those who don't struggle since they wouldn't have the assist turned on anyway. And when we run dogfight scenarios, there has never been any request for assists. Well… other than “could I at least get to shoot you once before exploding [grumble grumble]?!” and the other guy would let them because we're nice to our community members that way.

Because the refuelling assist would not have any appreciable impact on fairness in the scenario where I'd leave it on. And that has no relation to whether a dog fight assist would be active or not. They're two different and separate things that aren't connected in any way. Each would individually be allowed or not on its own merits and according to different needs. There is no “if one, then also by absolute necessity the other (or not)” equivalence between the two.