Tippis

If you keep clinging to the misapprehension that it's about $15, then you don't understand what the problem is and why $15 doesn't solve anything. So, again: it has nothing to do with the price. It has to do with pointlessly and needlessly creating hurdles that must be catered for by not erecting them in the first place. That way, and only that way, all those who want to play can play. And you want them all to play. What you're describing is not “those who want to play” because you're wantonly skipping over the most important qualifier: “those who want and have already fully committed to playing”. That is a very different category. In other words, not all who want to play can play. That's a catastrophically bad position to put yourself in if you want people to play. It does. The thing about this sim is that it's free. Its $0 entry point is actually one of its major strengths, especially now when we also have $0 module trial periods. You don't even need much in the way of extra gear beyond what you probably already have as a gamer. It can certainly become costly, sure, but that leads right back to that missing qualifier: those who have already fully committed. That $0 level is the lowest common denominator that you need to consider if you want to achieve any real coherence and critical mass in your community-building. The way to make them commit, and even just a little bit, is to not arbitrarily and for no good reason lock them out the way pay-or-gtfo content does. And that's the other thing about this sim that makes it far less… antagonistic, for the lack of a better term, than its complexity and niche-ness would intuitively suggest: there is precious little such content. It's just the terrains and that very poorly handled asset pack. Again, it's telling that the second time they tried to use the same lock-out system, they ended up deciding not to because of how thoroughly the point and the consequences of that false economy and the detrimental consequences of that lock-out was hammered home. That's unfortunately a useless example because it has exactly zero impact on your ability to join missions where the Apache is present. This is a good thing and you're very happy that the game works that way. So if anything, it is an example of the exact opposite of the point you're trying to make.

It's a big deal, not because of the price of inclusion (and there will be an endless discussion about whether it's too high or low enough or annoying in aggregate or something), but because of exactly the splitting problem. As the guy managing a 24/7 server for a smallish community, I must decide: should I run mission X if that means that suddenly, the new guys we're trying to get involved to expand that community can no longer play? The answer is just immediately and obviously “no.” The terrain situation is already problematic, but we have enough resources and support within the community that the most common alternative can often be gifted to newbies who really want to stick around, and we use that most-common extra terrain on rare occasions or on a second server instance while the main server is available to and accepting of all and sundry no matter how hooked on DCS they are. If I were to start running missions that has some asset pack requirement, I suddenly put a burden on the community to also shower those newbies with the asset pack, and for something with vastly more dubious utility than the terrain. I could conceivably run it on a third server instance, but it becomes so pointlessly niche that it's just not worth it for how little that third instance will be used. The next chain reinforces the bigness of the deal: since I can't sensibly run missions that have extra requirements, other than maybe as a very one-time special-event request, there will quite naturally be no content made within the community that has those requirements — why would anyone do that when it will never see the light of day? Instead, the creators put their time and effort into something that can reasonably be run 24/7; that can be used to attract and retain new and old players alike; and maybe something that can convince the odd player here and there that that extra terrain is actually worth it if no-one is able to gift it to them at this point. Both I as the server manager and the content creator have to go for the lowest common denominator. That means nothing more restrictive than at most one of the for-pay terrain modules. Enough planes will be added that just about anyone has something to fly, or maybe they can run LotATC (on a server license) or use a commander slot to direct the action. Unless the cost is so low as to be effectively free anyway, where we can just shower anyone who accidentally peeks into the Discord with module gifts, that asset pack will never be part of the lowest common denominator we must serve. Even free community mods can be problematic to include, but that depends on how they're integrated and how much tech support will be needed if everyone is asked to install it. The WWII asset pack is already an extra cost upon an extra cost upon an extra cost to access a niche within a niche within a niche; Korea would if anything manage to make that niche-cube be even narrower. So even at a low cost, its value everyone in that content chain would be close to nil and the price:value ratio would be completely out of whack, because that niche is simply inherently contradictory to the common denominator. That's just it: the SC doesn't exclude anyone. It is freely included even if you don't buy it. But with a twist. You can play that mission freely but you can't interact with the carrier assets in any way (or well… in one way: they can shoot you down ). It's far more reasonable than not to have it work that way than to lock people out, which coincidentally is why it works that way and… you know… doesn't lock people out. The same actually goes for the F-18: just because you didn't buy the module doesn't mean you're excluded — it just means that you can't fly specifically the F-18. Anything else that might be included is all yours, which in the extreme case might just be a spectator or commander slot for yelling-over-SRS duty (but in that case, the mission maker failed, gets rightfully ridiculed, and the mission will be rejected for being worthless and stupid). So yes, the SC and the “hundreds of thousands of” man hours that has gone into its development should be free and included. And it is. It's free and included (but not interactive) for the very good reason that splitting the community — especially the on-line community that speaks to a lot of people and give them recommendations on what to buy and what not — is a horrendously bad idea, and because it being “included for free” this way means ED makes more money off of it than if it isn't.

No. Unlike, say, the F-18, the WWII asset pack splits the community because if it is included even slightly and at all, it immediately makes it impossible for anyone that doesn't have that pack to play the mission. This is not the case with any other module. A mission that has an F-18 in it does not require you to own the F-18 module, so no split occurs. The split is not between “flying X” and “not flying X” — it's between “playing” and “not being allowed to play at all”. You can join any number of multiplayer servers and they will all have all kinds of modules active — as long as none of those are the WWII asset pack, anyone can join in. They may not be able to fly every plane featured, but they can join nonetheless. Hell, even if you own none of the planes, you can still be on the server, play the game, and participate in the mission in an ABM (or similar) role. It never splits the community, and this is how it should be. There are exactly two exceptions to this rule: terrains and the asset pack. ED thought about adding SC to the list but it was thoroughly explained to them why this was a very very bad idea — why splitting the community down this line would largely kill the module — so they chose not to go down that route. And let's not kid ourselves: it is only ED that creates those splits because it is only ED that decides whether something must or must not be required for all participants by mere inclusion.

It's a bit of a stretch, but it could hypothetically sort of happen if there's a tipping point where no content is made without the asset pack, so you'd have a split of sorts between people who like the era or region or whatever, and those who don't, where the former now have to pay a “sorry but your interest costs extra” tax to get any content at all. But given how it makes more sense for content creators to aim for a broader audience, it's not just unlikely but also requires a pretty specific interpretation of both “splitting” and “the community”.

Heh, ok, next thing to try: can you rebind the map view or at least add an alternate hot key to get to the map, and does that bring it up ok? Maybe you've managed to prohibit the F10 view for yourself somehow so it doesn't matter what keys you use.

An immediate thought would be more or less the opposite of what you checked: whether something else is also bound to F10 that manages to take precedence. This should normally show up with a warning flag next to the bind, but every now and then — depending on how the bind was created (and especially if accidentally) — they don't. Have you installed any mods that have their own in-game binds, like SRS and the like? Or do you have some external input modifying software (anything that responds to or sends hotkeys) that could be intercepting the key?

…and as the SC debacle showed, their business dictates that when a module comes out that splits the community into haves and have-nots, they must by necessity go for the lowest common denominator — i.e. the have-nots — to maintain critical mass and keep a useful population going on those servers. Consequently, they will not suddenly host any missions that use a community-splitting module. They will also not recommend the purchase of those modules since they will never be used on the servers. This then spreads throughout the server's large community to become a general word-of-mouth (non)recommendation: the people who aren't being provided with any content for the module in question use this as an argument to tell others also not to get it. Yes, by making a module that makes it impossible for some players not to use content where that module's assets are present ED is inherently and by very definition splitting the community. ED — no-one else — choose to create a situation where the haves and have-nots cannot play together. Everyone else can only choose whether they want to be part of one group or another, but the split community doesn't go away. Indeed, the very fact that they must choose is a consequence of the community being split. The whole “no-one is forcing you” line doesn't make the split go away either — it just further proves that the split exists and that ED has created a situation where that choice matters and determines whether you can play a specific mission or not. With the Supercarrier, ED decided against splitting the community and instead actively chose to create a module that could be included in missions and still let the have-nots play that mission. Again, ED made this choice, no-one else. The reason they did this was because the above logic was explained to them in painful detail: how just about all of the most active community groups saw the initial restriction, declared it pointless for them to own, and not worth recommending. If restricted, it would not be featured on their servers; if not featured, content creators had no incentive to create content with it; with no content created for it, regular users had far less incentive to buy it. Thus, what private servers required — or more accurately refused to require — became very much ED's (literal) business. Yes it is. They were the ones who decided to create that very restriction. No-one else can do anything about it without breaking the EULA and digging out the DRM and restriction code from the game. Being able to spend money on the package just means you're on the other side of that restriction, but the restriction still exists and is still entirely something ED decided on. They could also have decided not to do it that way, as proven by SC. Or are you suggesting that when ED decided to change SC so that even the have-nots could participate in missions where SC was included, was not actually something ED decided on and changed in the code? We know that it's ED's “fault,” not just because they've proven that this restriction doesn't need to exist, but also because third-party mod makers have proven the same thing. Their way of maintaining non-required compatibility is a bit uglier and more kludgey than when ED does it by making certain bits part of the core game, but the fact that it can be done (and the fact that there are a fair amount of mods where it can't or wasn't done) further highlights that it's up to the dev to make that choice. No-one else.

Only idea needed: • Get rid of asset packs as separate purchases. Make all modules contribute an “asset tax” towards the development of decorative and environment-enhancing units and statics that all become part of the core package. The game lives and dies by its content. By dividing the community in have and have-nots, you inherently reduce the audience for content creators that use those assets packs, thereby reducing the content being created with those assets, thereby reducing the value of the asset packs, thereby reducing the audience for and the income from the asset packs themselves. They had to learn this lesson the hard way with the SC — now it's only a matter of taking that lesson to heart and bring it to its logical conclusion. Asset packs as something you need to purchase can only ever be self-defeating false economy that reduces the ability for ED to create the assets needed for content creators to create the content that keeps ED's customer base alive, attached to the game, and inclined to spend more money on the game. At most, there could be some “usage packs” to replace them, where functionality is added to integrate with CA and the like, thereby — much like what Northstar suggests — disentangling the existence of the assets and their active use by players in a given scenario.

You can set up refuelling loops with the LandingReArFu action. It even works. If set up and timed very carefully. For small groups. And specific aircraft. Sometimes.

Also, there is the notable difference that the Su-25 is a mass-produced aircraft that has seen action in just about every conflict in the last 40 years, whereas the 25T was a moribund and ultimately abandoned attempt at creating an upgrade path for the -25 but which was deemed far too complex and expensive to be worth rolling out properly. The T saw some very limited combat testing before the whole thing was shelved, and even the second attempt at a similar concept (the -25TM) was abandoned because it just wasn't worth it. Ultimately, not even 1% of the airframes were updated before the whole thing was abandoned and they tried to create something more sensible. So really, the reason why you'd buy FC3 (you should never buy any of the individual planes included in the pack) is because they want to play more realistic scenario with planes that actually existed in any relevant way rather than some experimental fantasy plane that for all intents and purposes didn't.

Yes. You simply include the labels.lua in the miz file. It's really just a zip so any tool you have to open up and manipulate those will work for you. In the .miz, create a directory called Config\View and put your modified Labels.lua there. Then set the appropriate label type in the ME options the way you normally would — the labels settings will then apply to all clients (and due to how mission options work in MP, there is no way to not enforce the label setting).

A bit of both. You probably want to save the entire Saved Games\DCS directory somewhere safe and run DCS once on the new computer to let it rebuild its required basics (shader cache, config, some module-specific user directories). But after that first run, you'll want to copy back in things like your liveries and missions, and possibly also the MissionEditor directory (to get your logbook back). Some user mods will also work just fine if you copy over the stuff in the Mods and Scripts directory, but that's not as guaranteed. You could copy the input directory as well, but chances are that all the USB device IDs will have changed so the old binds won't be picked up automatically. Your keyboard and mouse binds will probably work, but anything related to sticks and throttlres and the like will not. You can either use that backup you made as a source that you import your binds from or, if you have good bulk renaming tools, you can copy the entire directory back with names that match your new device IDs (this requires a bit of understanding of how the naming scheme works, though). So in theory, it's mostly copy-paste, but in practice, some thing will have changed on your new install that you have to accommodate anyway — including some hidden config choices that can cause significant issues, performance loss, and and even crashes in extreme cases. The input situation is particularly annoying, and if you have special export mods like Tacview or LotATC or SRS, you'll want to reinstall them fresh anyway to make sure the hooks between DCS and the external software is set up right. As such, my recommendation is to re-do just about everything in the Settings screen from scratch, and using the import function to get your binds back in place without having to do everything manually. That really only leaves the aforementioned liveries, missions, maybe some mods (but this will vary depending on how self-contained they are), and maybe the mission editor directory.

No.

Because multiplayer in DCS is… odd. In particular, the way missions are translated from their assumed SP environment to MP is odd in how it applies a lot of implicit and explicit settings in the mission editor. This is just another case of the ME storing local data from the mission-creator in the mission file and then applying them to clients because it doesn't quite know what else to do. There's a very similar bug quirk where you can't not (yes, double negative) enforce settings in MP, but the mission editor makes it look like you can. In actuality, you're choosing between enforcing the difficulty and sim settings as set up in the mission options screen, or enforcing the difficulty and sim settings as set up on the mission creator's local system (because those systems are included in the .miz file along with various user data for no sane or sensible reason). The map issue is most likely yet another case of the game assuming that the mission will be run in SP and that some settings will therefore be overwritten by the player's setup… but there is no such setup so it instead defaults back to something rather nonsensical that probably shouldn't be stored in the mission at all.

Ask the server manager to re-save the mission with a more sensible zoom.

Given how little of the module functionality is actually in and working, it's not worth getting unless under the most niche circumstances. Any pre-existing on-board navigation system, including all the classic forms of radio navigation, removes the need for this module since it won't provide anything that isn't already in the plane. Best-case scenario is that you don't need to press F10 as often.

If it's any consolation, I wouldn't quite say that it has worked properly for ages — AA TACAN has consistently been a contradictory and confusing mess with ever-changing answers as to how to make it work, how it does work, and how it should work in relation to various other aircraft. TACAN has been reasonably stable overall; AA TACAN has been apparently broken, explained away, suddenly fixed supposedly without being broken, (re)broken(?) and possibly fixed (or just explained away again) on a number of occasions. This is just a new(?) chapter in that back-and-forth story.

Because the A-10 is an ancient module and it wasn't necessary to build a complicated system (beyond what mission planning allows) for it when it would just affect this one plane. Now, on the other hand, when a third of the planes they have use some kind of mission data transfer functionality, they've come around to the idea but last they made any mention of it (many moons ago), they were talking about going for the catastrophically expensive false-economy option of doing it module by module rather than by creating a common interface and API that all modules could hook into. With a bit of “luck”, it's one of those things tied to the creation of a dynamic campaign engine (because such an engine would require this kind of functionality to be even remotely sensible), but then that just means that it's even farther off in the future.

DCS-level, sure. Polychopchopchop-level, no. One UFO is already more than is necessary.

It depends heavily on the size of the weapon — with a reflection limit of 0.18, it is just barely incapable of detecting AGM-84 and -86 (a reflection stat of <0.17), and equally just barely able to detect and defeat Kh-29 and -58s (reflection 0.18–0.2). So most anti-armour and anti-radiation weaponry that will be aimed at it will get through. Some of the larger cruise missiles and gliding bombs will get shot at though. Another problem it has is its relatively low detection range combined with a fairly long lock-on time — most missiles would just fly right by it while it's trying to get a lock, even if and when they get detected to begin with. Again, gliding bombs and some of the more massive cruise missiles are viable targets because they aren't fast enough. A second aspect of that is the way the system works, with its different levels of search and tracking radars, including the ones on the TELARs themselves — if given enough warning from search radars and the like, it can be very nasty; if it only relies on the inherent capabilities of the TELAR, their detection capabilities are drastically reduced and you can literally fly circles around them in a Hercules without ever getting locked on. The SR and CC are good at spotting things at long range, but suck at seeing small targets; the TELAR is decent enough at locking even smallish targets, but is absolutely horrid at actually spotting anything to begin with. It's not a very effective combo for defence against anything other than aircraft, so supplementing them with SA-15s is usually a good idea.

DCS: Blue Lint would be a day-one preorder. Oh, wait… naval. Yeah, sure, I guess +1 on that too.

The -21 uses an alcohol coolant to keep its radar from melting its way out of the airframe. So it's important to know whether the coolant has… ehm… dual-use potential.

Not only. Even in SP, CA (and the right role) lets you issue orders to AI aircraft much the same as you can to ground units. They're even more fiddly and unreliable as far as making them do what you want than artillery and similarly reticent ground guys, but it is doable.

More to the point, what would they do in DCS? Cause mass casualties among a population that doesn't even exist in the game? Ok… “Civilian traffic: none”, done. Have the player deliver a clunky canister of something? Ok… [Select CBU-87][Copy-Paste][Replace texture], done. So… what would be the actual meaningful addition?

Even if it were used post-start as well, it would still have its uses. Realism doesn't really matter because this is something the mission creator has both all the freedom in the world, as well as the responsibility, to deal with as they like. It's one of those behind-the-curtains tricks that all missions use — a programming sleight of hand to just make the whole thing work better. A teleport would let you massively reduce the unit count in a number of situations and AI is one of those things that we have very few methods of tweaking. If the same (decorative or fully functional) group could patrol both the starting airport and the one the mission ends at, and/or the one you have to defend half-way through the mission, or whatever, that means cutting the unit count in half (or by two thirds), which is pretty significant. And the player won't notice because it'll happen when they're not looking. A lot of the same results could be done with scripting — disabling and spawning units — to much the same effect, but with a slightly higher overhead since you'd then have to deal with the scripting trigger checks. Granted, those don't account for a lot, but still… The only downside I can see is that it wouldn't be as applicable for those post-start uses in MP, simply because more eyes = more people that you have to hide the teleport from. Whereas a spawn/despawn script would just deal with it by spawning a new group for the people in front while the laggards in the back delay the despawning of the first group, a teleport would look ugly for one or the other since the units in the front would be the same as the units in the back, and one of the two would notice them suddenly appearing or disappearing. The randomised spawn point thing would just be icing on the cake — a lot of the issues with the current randomisation schemes is the ugliness of the “Condition” predicate logic is what drives the need to do it via scripting instead and this kind of thing would definitely help with creating a different means of having randomisation and unpredictability directly in the game logic without having to go the lua route.