Tippis

The immediate question becomes, do any of the parties and planes represented actually use that?

Ideally, and in the long run, yes. The point of my standard copypasta is that it can be done now, universally (or at least based on very broad categories), with pretty minimal effort. The only tricky bit lies in moving the death state to much earlier in the process, since odds are that, once dead, units stop being processed and thus the whole burning and exploding bit might cease to function. All the components are there already; all the limits and effects are there (albeit in the wrong order); and it gets us at least 50% there, which is a pretty massive gain for so little work. Something needs to happen, and I'm not sure a full rework of the everythings will come within any reasonable amount of time. A quick and ugly fix would, for once, be a pretty good thing.

Copypasta time! Fundamentally, the problem is that the damage application is completely backwards. Even a simple hit point system can be made to work while they chip away at more intricate systems modelling in all vehicles, but only if that hitpoint pile is treated properly. Right now, it isn't. At the moment, ground vehicle damage application basically consists of three different components: • A hitpoint pile — the bigger the vehicle, the more hitpoints it has, and the tougher it is. • A damage mitigation stat — an abstraction of armour to simply deflect some smaller amounts of damage application, including an aspect calculation whereby, depending on the vehicle and the angle of attack, the damage mitigation is scaled up or down. • A four-(and-a-half)-tiered damage state: fine(ish), system-crippled, movement-crippled, (burning, soon to be) dead. It's that last one that is set up horribly. In particular, the thresholds are nonsensical in relation to the full hitpoint pile, although the order is also questionable. Essentially, it's a case of, at 50% HP, the unit stops working; at 25% (or thereabouts), it starts moving slowly; at 10% it starts burning and will slowly lose its remaining hitpoints; and at 0% it dies and explodes. Not a single one of those are where they should be. By all means, units should probably explode at 0% HP, but they should start burning a lot sooner (and and stay burning a long time after), and in particular they should be dead long before that. The reason this matters is that the only event you can reliably automate without scripting up every single unit in a mission (say goodbye to your CPU) is death. It's what scores point in the kill screen; it's what most mass triggers (“group dead”, “group alive” and the “…less than” versions of the same triggers) use to do their thing. To make that happen, and to make the attack actually count from a game-mechanical perspective, you end up having to hit individual trucks with 500lbs bombs, where a 0.5lbs bomblet should really be able do the same job: in this case, to reduce the hitpoint pile to 0 to trigger the “death” state. Similarly, somewhat depending on exactly what kind of unit we're talking about, movement should probably be lost long before the system as a whole is gone, unless we're talking about something flimsy (eg. radar antennas and the like on anti-air), in which case the systems should be gone the moment something sneezes in their general direction. Ideally, the whole thing would be set up something like: • The hitpoint pile is still there because it's too much effort to get rid of it. • The damage states are set by unit type, and all happen a lot sooner. Eg. for a tank, it's mobility loss at 80%, system loss at 70%, death at 50%; for a mobile SAM, it might instead be system loss at 95%, mobility loss at 80%, death at 50%. The only unit where death should happen at 0% HP is infantry, and they should still lose their ability to fight long before that. • For added bonus funtime: have system loss also affect mobility so that units that lose their offensive capabilities run away really fast, until mobility damage sets in and they instead have to run away really slow… (or just have two stages of reduced mobility if you're boring). • Tie triggers into not just the revised death limit, but also to the “non-operational” and “immobile” thresholds so those can be used as mass triggers to score points and achieve objectives with ease. ED have already indicated that they're working on a ground vehicle damage model update Later™, so this kind of stopgap isn't likely to happen and thus not worth a full wishlist thread, but at least that last point will still need to happen.

Look, if you're not getting a check in the mail for shilling on behalf of the nebulous backwards tech council, how else are you supposed to pay for your module and increasingly bloated HOTAS setups? Think of the children!

…arbitrary code execution on the client, data loss, lawsuits, all the good stuff. The use of scripting languages for the purpose of scripting content is limited by design, and any inefficiencies are marginal given how small a portion it represents of the overall processing, while at the same time vastly increasing the accessibility to the end users. The expansions you're envisioning are not covered by the scripting engine; are already all done in C++; and can already be changed by replacing the associated DLLs. That's modding, though, not scripting, and there are very good reasons not to open that up to the users.

In other other words, if Vulcan was coming within [fairly long period], they'd be showing it off every second of the day and shouting it from the rooftops.

In most cases, it's not even “a few lines” but rather 2 or 3 numbers that need to be adjust. The seeker type is a single enum, and that sets up so many defaults that often aren't even touched as far as the logic goes. For IR seekers, it really only comes down to two more numbers: countermeasure die roll modifier and a sensitivity (target size multiplier) parameter. For optical seekers, it's not even that. The most “work” would be in defining targeting arc/search zones andmaximum detection ranges — all of which are almost universally the same. The rest is in the missile kinematic parameters and just the regular things any unit needs to have in its definition (hitpoints, movement speed, ammo capacity, rearm time — again, things that are pretty much universally the same for all infantry units). So yeah, it's really just a 3D model and possibly a missile tweak (but the differences here are questionable for the outside observer anyway). Everything else is a hard day's work of copy-paste.

If you read what he actually wrote, then yes.

What makes you think they have to create separate functionality? Or that Heatblur would be the ones to put in an MP slot limitation (which, coincidentally, already exists)? Do you even have any experience at all with the F-14, because you certainly seem almost entirely unfamiliar with how it operates and with how MP works. Or are you, as always, just making up uninformed complaints about imaginary problems based on nothing but wilful ignorance and an absolute refusal to actually research anything that you opine on?

This sounds like it's all about the icons and map spam. That's not really all that much of an issue because DCS doesn't quite support enough active units to really warrant any of the larger unit groupings, especially not if you want both sides to have them. No, the thing that would massively improve the game (and coincidentally also get rid of the icon spam) is if this was an AI change. If en entire company could be treated as a single AI actor, and when (and only when) suitably decimated, it would split into individual platoon actors. Individual ground units acting as their own AI agent would be the very last step after a whole lot of shooting.

More seriously though, this actually got me thinking. Skip the whole arming and repair business — that's a sideshow. What would be handy would be something that has proven more and more needed, often requested, and which would get around a whole lot of headaches that the module developers are facing: the ground crew in total, including armaments. The IC debacle once again raised the awareness of the long-needed DTC functionality in a whole bunch of aircraft. Various modules use the most inane and silly methods to handle things like weapon release settings, laser codes, burst and ripple amounts etc. A unified DTC API and UI is needed for 7 player-flyable modern aircraft — and probably more in the near future. Another 5 have some kind of programmable weapons or release systems. By the sound of it, this number will increase pretty soon as well That's 12 out of 21, more than half, and that proportion will only increase over time. A DTC system like in [game that must not be mentioned] would in other words be sensible for half those modules, but less so for the other half which rely more on manual settings or even mechanical modifications. Even for the computerised ones, many of them still require some manual ground adjustments to get the weapons to work as intended, and then there's the ever-popular violent row about what systems can be wired into where, and who's doing the wiring for whom. At the moment, that's all done via an incongruous mess of faked on-board systems, half a dozen implementations of kneeboard and keyboard shortcut manipulations, mission editor settings, “Special”-page settings, and module developer whim and preference. So what if all of that just died in a fire, was buried in the desert, nuked, and sent into space, and then replaced by a visually interesting — maybe even gameplay-reliant — system of adjusting onboard systems, stores, and even entire aircraft, including storing data to DTC for the planes that used those. Want to wire in those much hated/loved hardpoints for extra HARMs on the Viper? Do so in the ground crew interface. Want a different laser code on your GBUs and APKWS? Dial it in ni the ground crew interface. What new tyres and a slightly less perforated wing? Pick some in the ground crew interface. Want to get unstuck from the grass because ehm… “your brakes didn't work (yes, that'll work — they'll believe that)”? Drag the plane out in the ground crew interface. Want to define multiple flight plans and nav points and mark air defences and draw lines on your SA/TAD/whatever page? Draw it in the ground crew interface on the map, and load it onto a DTC from the ground crew interface. Pre-program your radios? Same. Etc etc etc. Or just load everything from presets (which can be defined and save with the mission, similar to the largely abandoned “prepare mission” function). If it's unified enough, and built on common APIs that all the third-party developers will hate, it wouldn't even have to be done on a per-aircraft level — the same preparation presets would work for them all… …and then I woke up.

Also, being online or offline makes no difference.

Being able to troll the AI right back would be the best thing ever. Release now, ED!

No, this is just another case of your not being all that familiar with how the game works and imagining things to fill up the gap. Charitably, you might be confused by the restocking time of airports, which will obviously limit how much munition you can load up an aircraft with, but the rearming process is the same as has always been. An that's still not a server setting.

No.

Has this even been noticed or acknowledged @NineLine or @BIGNEWY? It literally makes remote management useless unless you add custom scripting to delete entire DOM nodes, or break out the dev tools to remove them manually. Mild case: …inevitably turns into a bad case…

He probably means ICLS since those can be used on land as well. To clarify further: ICLS is not just “ILS, but on a carrier” — it's a separate system, with separate transmitters and receivers. A mobile ICLS (and ACLS) is needed to provide precision electronic approach guidance to aircraft who have that system rather than regular ILS hardware onboard (e.g the Hornet), but still want to land on a regular air field. e: And also, yes, obviously — we need all the mobile and semi-permanent (and preferably some permanent) nav aids as placeable, scriptable, and user-defined objects: not just the ones Northstar listed, but regular VOR/DME, ARC-whatever, and even good old ILS. The funny thing is that the basic interfaces are all there, but none of the scripting is really in place and active.

That depends entirely on how and where it is recorded. It is not true that “any action” will replay differently — some may under some circumstances, and the biggest problem isn't actually with recording your actions, but the actions of various AI actors. But even there, it can be circumvented by not using SP tracks.

No. You can't on the one hand suggest that we can draw any generalised conclusions from your poll and then, when that approach doesn't work out for you, turn around and say that, oh no, it was deliberately bad, and especially not then try to turn around again and save the first claim when the second approach also doesn't work that well. You get to choose: either it was deliberately made bad, in which case we can conclude nothing from it, or it was an attempt to do something serious and should be treated as such, in which case we still can't draw any conclusion from it — or at least not the one you want — because of the huge flaws and the spectacularly large margin of error that your preferred conclusion would entail. One of the two. Clustered randomized selection; off-forum; sample size of, oh, 500+; with discrete, mutually exclusive, non-opinionated and judgmental, and preferably dichotomised options; probably 4–5 groups of 10+ branching questions each, dealing with outcomes of different scenarios (if yes -> how much; if not -> at what loss). You know, proper poll stuff.

Then don't presume to draw any conclusions from it. You can't have it both ways.

No. A typical monitor at 1:1 FoV would be like looking through a monitor. Because that's what 1:1 FoV is. For the 1:1 FoV to be like looking through a tube, you need to be looking through a tube, and if that is all the visual area your monitor covers, you need to seriously reconsider how you've arranged your furniture. Oh, and each eye has a 120–130° FoV; the two combined clock in at roughly 180°, of which less than half is binocular, and half of that is your actual focus area that you use to see rather than just notice.

That does not follow. People can already give money to ED if they want to. So there's very little opportunity to change that hypothetical loss even if it existed, and you don't know if it does. You also haven't accounted for the cost and loss of income such a move would entail. We really can't, because the poll too poorly constructed, uses too small a sample, and relies entirely on self-selection even among that sample, for it to say anything definitively. You end up with a sample market size with something along the lines of a 300% margin of error.

As a surprise replacement for some static object on an appropriate day, I'd fully approve — even if it was a bit of a low-poly rush job (probably even more then, since that would just make it sillier). The question is which one, since it's a pretty specific size and there aren't many options for what you could replace and not immediately have it break things. The crane for the carrier maybe? As something fully animated and flying and whathaveyou, it would be a bit too over-worked and serious for my taste, and wouldn't be able to appear as a surprise since it would be its own thing that you'd actively have to add to the mission. Too much effort on both sides would just defuse the joke too much.

It's a bit outdated, but something could probably be done using this as a reference: https://www.airgoons.com/w/DCS_Reference/Radio_and_Navigation_Systems

There exists exactly zero evidence to support that stance and an overwhelming amount of evidence to support that the RWR actually functions as an intelligently designed RWR. If those internal doubters have anything to say to try to bolster their case, present it, otherwise it will — entirely correctly — continue to be seen as an inaccurate and bugged implementation. There's an argument to be made that the F-5 has the wrong RWR, but that is something very different. In that case, the proper solution would be to give it the correct and properly functioning RWR, not to keep the wrong and incorrectly modelled one. In a way the same thing goes for this entire IC debacle: is there any actual evidence to support the notion that the supposed problems that this is meant to fix even exist? The simple fact of the matter is that this wholesale banning of much-needed adjustments has broken the game. I hope this was not the intent and that the breakage will be fixed in short order.