Tippis
-
Posts
2620 -
Joined
-
Last visited
-
Days Won
9
Content Type
Profiles
Forums
Events
Posts posted by Tippis
-
-
For the “new device/new GUID/new computer” part, at least, you can ameliorate the hassle somewhat with a decent file manager that lets you search-and-replace across an entire file system. But that's a tricky part to automate no matter what. Even this kind of work-around rests on the supposition that the new device is exactly the same as the old one, and there's really no guaranteeing that. The (luxury) problem we have these days is that there are so many things we could attach, and a significant portion of them can be fully customised in their button and axis setups, so matching anything against anything is an inherent nightmare. And of course, this ties into the whole notion that DCS probably shouldn't try to auto-assign binds because they will invariably, unfailingly, be completely wrong except for in a very very tiny number of cases.
Still, omg yes, as someone who just had to re-do almost all my binds for almost everything… the ability to mass-import old profiles would be a huge time-saver. Getting around that GUID issue by being able to point to a directory or an archive and basically say, “import these (old) GUID files for new device wherever applicable”.
That would also get around the problem that occurs every now and then already where devices squabble over which ID they should be using today. A common example is the TM MFDs, where each MFD keeps track of whether it's a “right” or a “left” model… but if you have two (or more) lefts or rights, they can occasionally swap their assignments for obscure and opaque USB reasons. If you could just go “ugh… import all X, import all Y” rather than having to do the whole rename-and-replace song and dance, that would remove almost all the hassle.
-
2
-
-
54 minutes ago, Lixma 06 said:
Are there any plans to have the 'dots' gradually fade in?
They should already fade in. If they suddenly appear, you should probably submit a bug report, maybe with a video showing it happening along with a view on F10 map to see the crossover point. Also, check that you're not seeing (possibly customised) labels as they can be set to a much more aggressive behaviour in terms of how they show up.
-
You sort of can set it up already, by triggering immortality on and off if some suitable weapon is employed within the target zone, but it quickly gets very messy to keep track of all the states and options, and as you hint at, even then, they will run out of ammo sooner or later anyway.
So yes, both of those would be helpful.
But at the same time, I wonder: what are you actually trying to achieve? If it's just the look of ground fire – of tracers and smoke puffs from hits and all — so that there is a visual cue that ground fighting is going on, maybe flipping the thing on its head could be a better way to go? As in, rather than making the groups immortal and take no damage, you turn them into stormtroopers and they deal no damage. A “simulated fire” option, of sort, where they go through all the motions and all the effects trigger, but no-one ever actually deals any damage to anything. That way, you'd probably get the same effect, but it wouldn't be as restricted to “only A2G fire”, or having to mess around with detecting the weapon type to figure out if it should do damage or not. Instead, it would be a matter of “these two groups make noise, but anyone else can come along and kill them”, including players driving ground vehicles in CA and AI groups being called in from support locations, or — as you're envisioning it — players coming along in their aircraft and dropping ordnance on them.
It might even be possible to extend that further so that the same “simulated fire” could be used by air units, eg. to create a furball of gunfire on the horizon, but no-one will die until you get there. Or lots of SAM launches, and bomb drops, but only when the player gets involved will things start to die. It's a different implementation of the same idea, but it could probably be made (and used) more flexibly.
-
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.
-
1
-
-
53 minutes ago, Pikey said:
- Which functions work only in Single Player (shelling in zone, cockpit parameters, green gates, set failure, etc)
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.
-
1
-
31 minutes ago, virgo47 said:
The question is if the common API is even possible for both SP and MP environment. Perhaps tutorials are not suitable for MP, although if one wanted to teach two-seat planes with two real people there... suddenly it gets interesting.
Or there may be scripts just sent to the client to do the stuff with the local state. But here I am on thin ice... I have zero MP mission experience and no idea how that should work and interact.
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.
-
1
-
-
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.
-
2
-
-
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.
-
2 minutes ago, Elphaba said:
You echo it and then in the next sentence say how you require mods for your players... /facepalm.
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.
-
3 hours ago, Elphaba said:
I'm trying not to bite at the deliberate provocation in your comments so I'll just say this and let's just go our separate ways as you have nothing positive to add to the poll or the topic and I thank you for most of the conversation.
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.
3 hours ago, Elphaba said:So it's not *my bias* because I have EVIDENCE. TONS of evidence that modding almost any game, is far more common place than you think and the gaming community and players are benefiting from it daily.
The outlier here is DCS.
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.
3 hours ago, Elphaba said:Now, there is an argument that the first time you have an issue people say 'disable all mods' and most of the time that doesn't fix the issue - sometimes it does, but the times is does is outweighed by the times it doesn't - go look at the modding section on this site to confirm that. But it's a lazy argument and from a tech support point of view it's the same as 'did you turn it off and on again'. It shows that they don't care to know the cause, just smash the low hanging fruit and be done.
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.
3 hours ago, Elphaba said:So the issues you raise are not based, at least with the mods I've curated, in reality, only imaginary problems.
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.
3 hours ago, Elphaba said:And as to why I'm doing this poll, that's patently obvious from the post itself. I won't insult your intelligence by repeating it.
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.
3 hours ago, Elphaba said:Mods fix that. And if people want access to my curated mod so we can make those kind of missions, I'll gladly provide it, maybe that will spur ED to do something about it.
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…
39 minutes ago, cfrag said:Two things can be true at the same time: people could know that using mods would offer them a much better experience, and they still can be unwilling to install them.
And you are preaching the choir, dear Elphaba. All of is here know phenomenal mods that are available and how much better our missions could be if we used them. And we all know the hard truth: using any mod in our mission reduces the number of people who play them. It's heartbreaking, but undeniable fact. We, as mission designers want our missions to be played, so we cater to our audience and do not include them.
Your frustration is palpable, my friend. Your arguments are well received, mostly agreed, and we all dream of the day we could use mods. Today, unfortunately, is not that day. In my experience, trying to force other people to see the light seldom brings the desired results. So my recommendation for you is to perhaps relent a little in this regard, lest it breaks your enjoyment of DCS. Because that is why we are here.
…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.
-
1
-
-
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.
-
1 hour ago, Elphaba said:
Not true, at least universally. Games like the Silent Hunter series and Dangerous Waters etc. all use mods that require JSGME or OvGME etc to use and some of the mod installations require manual hacking of files and editing of settings etc. And virtually no-one plays those games without mods.
…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.
1 hour ago, Elphaba said:I wonder if this is an age thing; kids and people under 25 using DCS who have never edited an .ini file or messed with mods, just expect games to have built-in mod support and managers etc... but those of us who've been around since the Vic20 etc are used to getting our hands dirty - although OvGME and moderated/curated mod packs, like my own, are as close to 'built-in' mod support as you can get. And cause zero problems.
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.
1 hour ago, Elphaba said:This reluctance is a terrible waste and a shame. And most certainly NOT universal. Virtually every game in my steam library does not have built-in mod support, but there are modders out there and with the trivially easy OvGME, most of the players, I've talked to online, are playing the modded games.
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.
1 hour ago, Elphaba said:Perhaps as @cfrag said, it's because DCS is so buggy and problematic vanilla, but that argument falls apart in the face of the mods I listed that cause zero problems and add a HUGE amount to the variety of missions and interactions possible with the sim.
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.
1 hour ago, Elphaba said:Still, I know logic and reason don't convince most people to change their minds
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? -
15 minutes ago, Elphaba said:
Only in DCS is seems...
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…
-
1 minute ago, Elphaba said:
This isn't a factor.
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.
-
40 minutes ago, Elphaba said:
Okay, if that's true, and I have no reason to disbelieve you, then it reinforces my opinion that players of DCS and people in this community are massive outliers when it comes to mods - even perfectly seasoned and benign mods like CAW/CVM/MAM... this 'resistance' is unreasonable and on top of that just reinforces that ED need to bring those mods into the game themselves.
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.-
1
-
-
8 minutes ago, Elphaba said:
No offence but that seems like a cognitive bias rather than evidence. It sounds like you're imagining issues without them actually ever having been raised by others.
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.
-
Based on other experiences, that whole ”pathing to the runway” is the key issue. If the plane can't figure out where the runway is — or, hell, what the runway is if we're talking about road bases — or how to get there, its being able to spawn doesn't help. The reason large parking spots are a rare commodity has to do with how the map validates, where a bounding box of a given size must be able to move along that path without colliding with anything (including other bounding boxes) on the way. It's why you can sometimes see heavies land on smaller airports, realise that they can't taxi anywhere because there are no valid routes for it, and just *pop* out of existence.
The idea is good and even much needed, but it would also have to come with a toolset to semi-dynamically add pathing and runway information to the map as well to guide the AI to where it needs to go. Doubly so if you want it to be able to land and park in the same place. It might not even be something that is currently separable from the terrain — i.e. it's baked into the map, and simply can't be added afterwards. In that case, the whole map format would need a rework. Someone who's gone elbow-deep into the map format would have to explain if the whole bounding box check is done once, of if it's something that actually happens “live”. In the former case, it would obviously be on the mission designer if a plane clipped the environment and exploded; if it's the latter, then some placement might not even be possible for reasons that are opaque to the designer.
Definitely a +1 for the idea, but it could be shockingly complex to make it work right even on existing airfields.
-
20 hours ago, cfrag said:
Lots of words.
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?
-
1
-
-
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.
-
25 minutes ago, Exorcet said:
DCS does have a pretty cool warehouse system, but it doesn't really tie into gameplay very much or at least I haven't found ways to make it very meaningful outside of removing specific weapons from a mission. I guess it's more of an online feature.
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.
-
2
-
-
16 minutes ago, PhantomHans said:
However let me just add this:
I like the suggestion and I wonder if, over the course of a long campaign, this could be used to simulate wear and tear to a squadrons aircraft?
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.
-
1
-
-
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.
Operating in cockpit with pilot body (masked areas)
in DCS Core Wish List
Posted
Oh yes, please!
That and/or some kind of “interactable highlight” to indicate that you're mousing over some kind of control that might be hidden from the camera but which is actually fully accessible. That one would also help with some of the warbirds where you have controls hidden behind panels that should be easy to find… by touch. Which we don't have. The mouse cursor changing is a bit of a help, but that could be expanded so that the camera isn't the deciding factor in what can and can't be reached.