Tippis

…and if you were to slam a Viggen into the deck of a carrier at a 5m/s sink rate, it would also not break.

It's wholly irrelevant whether it was intended to or not. There is no reason for the landing gear to crack just because it comes in contact with a carrier deck. If it does, it means something in the carrier code or the viggen code is broken and needs to be fixed. Any argument along the lines of “don't” or “it shouldn't be there” is just a lazy excuse for not fixing bugs. Doubly so with a plane with such a ridiculously sturdy landing gear…

Right, and in combination with the somewhat opaque and occasionally broken ways to adjust your cockpit camera position, you have a good recipe for a never-ending stream of “this cockpit feels wrong”, even in cases where it's really very accurate, but you're just viewing it from the wrong position or angle or (in some cases with suitably wrong settings) the wrong FoV. So you adjust things to make it feel right again, without actually fixing the correct underlying problem, and suddenly the whole world around the plane is wrong instead.

Nah, that's just Sharpe in general. When reality goes against his assumptions (and reality always goes against his assumptions), he always either goes for the ad hominem, or insists that his assumptions about reality are true and everything else — especially real-world data and science — is unrealistic. Just keep slapping him around with irrefutable facts and show the contradictions in his increasingly convoluted logic and you'll end up on his block list because he has no other way of combatting the unrelenting nature of reality. It's not fixed, as such — you can adjust the in-game distance. But it's also not adaptive in the sense that it could conceivably read the settings off of the headset and adjust itself accordingly. And you might not even find the correct setting so it might as well have been. If anything, there is an on-going debate as to whether it should be more fixed so that a single setting will apply accurately to all aircraft, since there is a perception that the scaling is different from one module to the next. But as pointed out, that scaling isn't something the game does… at leat not in DCS — it's how the brain interprets any deviation between in-game camera distance and real-world IPD (on top of a couple of other “familiarity cues”). It's also something the brain flat out assumes is equal in all directions (and it's actually right, since no scaling happens: everything does indeed stay at the same relative positions in all three dimensions simply because nothing changes). So a 10% error along that single axis between the eyes translates into heights and distances feeling 10% off as well. When you adjust “world scale” in many VR games, what you're actually doing is adjusting that in-game distance, and possibly the camera height as well, to match what your brain expects.

Ok, that makes a bit more sense. Context helps. But at the end of the day, you're going to have the “missed traffic” issue almost no matter what and to some extent, that might even be a desirable outcome. It's quite realistic, after all, that if you try to talk to someone on the wrong frequency, you'll get nothing. And that if the wrong guy is listening, he'll do odd things that ruin all your plans. Annoying, yes, and I can already foresee a bunch of funny bugs where players still manage to trigger outcomes without know how and why, but in a horrible way, that's also kind of realistic. Frequency restrictions will to some extent be the work-around that you'll have to work with, I feel, and the fact that this can be overheard by unintended recipients or missed by intended ones is… well, just life. Hence work-around. You can probably ameliorate it by using hideously complex randomised code words or the like, combined with doing as much as you can to reduce how many people can even give those responses — e.g. targeting groups as the smallest level. Also, having means to request repetition of previous messages (something that the game normally doesn't provide anyway so that alone is something you need to fix on your own no matter what). But then, I suppose that comes back to the other question and other way of approaching the problem: what is it about the “group”… ehm… grouping of units that makes it necessary to use them? What game mechanics would you be missing out by splitting them apart into single units, or maybe player-unit + AI wingman? Off the top of my head, I can only think of some of the fudged or faked datalink grouping that happens automatically in some airframes, but is there anything more you feel wouldn't work properly any more? Maybe it's easier to try to find the work-around there instead, if some of that functionality can be replicated between a whole bunch of single-unit “groups”.

That's user error. Their problem. You can tell that they're listening if they subsequently do the right thing and you try to trigger on that behaviour. If they're not listening when the transmission happen, then they'll obviously do something else, and same thing there: you try to figure out if you can detect and capture that (mis)behaviour. If you want to be fancy about it, you can create randomisation in some kind of sign-countersign exchange to make sure the players have received the information (and responded within an appropriate time frame) rather than just gotten lucky by mashing their keyboards. If you radio “flash” and they don't respond with “thunder” within 10 seconds, spawn 4,000 SA-10 installations or something to teach them the error of their ways. You can use the radio transmission command both for looping and single transmissions, so that's not a problem. And if they're already assigned a frequency to receive the messages on, then the aforementioned user error shouldn't happen anyway. Those are the only two messages that exist. And in fact, text is just an abstraction of information that would be sent over radio, only it's easier to produce and offers some accessibility options. At least until they open up some fancy API so you can script-send data link messages. Rather, your entire problem hinges on the self-imposed restriction that only one specific unit must be allowed to answer to the messages being sent. Yes, there is a limitation to how you can assign comms menu commands, but again, you were asking for work-arounds and the work-around for that is trivial: ask the players to behave. Ask them to play according to your self-imposed restrictions. If they can't, kick them or just don't invite them to begin with. Or, better yet, make full use of the MP situation that is at the heart of the problem, and have players be in full control of the communication on both ends with a GM playing the part of controlling the flow of the mission. No need for any “message” scripting, be it via radio or text representations of radio, because you'll be actually talking to each other. If you remove the only two types of messages that can exist to being with, you almost make it sound like you're not talking about messages at all, but about sending controller commands ("tasks"). And those are for AI units (and can indeed be sent on a per-unit level, at least for aircraft, even if it gets quite messy, scripting-wise to do so). I am more and more leaning towards knowing. Not being able to detect cockpit settings isn't necessarily an oversight — it's a consequence of their being “client” and “player” kinds of units to differentiate who should be simulating what, and to what level of detail. But as it is, from what you're describing, you're not really presenting something that would work markedly different in MP and SP, other than that in SP, there would only be the one player who even could respond to begin with… and we're back to the work-around in MP to enforce a bit of discipline on your players in the situation where there are multiple ones that could do so.

There's also the classic question of from what, where and when the random seed is picked. A good experiment to run is to see if you get different results depending on where in the setup process you do your randomisation. Arguably, it shouldn't matter, but it can and when it does, it helps to know so you can work around it. If you put the flag randomisation on a TIME IS MORE trigger so it fires a few seconds in — meaning a bunch of other stuff has happened before that may have affected the seed or (if the randomisation algorithm is truly antiquated) “eaten” early results — and see a different outcome, then that's one way of dealing with the matter. Also, note that you have a couple of different occasions to set your randomisation and that this will actually cause different behaviours in other pares of the game. One notable example is the “initialisation script” section, which fires off before the mission is constructed in the game. That timing can be compared against ON MISSION START triggers which, well… fire on mission start. I.e. after the mission is fully constructed. This is important if you want to use the “State” conditions for spawning AI groups, for instance, since that check happens very early on. Similar timing issues can happen depending on loading order of triggers and scripts. So if your setup is at all timing dependent, make sure the timing actually works so the check definitely happens after the flag setting. Delaying both the randomisation and the check will obviously have an impact here in making sure things happen in the right order. Similarly, with all the chaos going on at the setup phase, it's also depressingly easy to overlook when a trigger (or some loaded script) overwrites a flag that you thought you set up properly earlier in the sequence. On top of that, there's an oddball behaviour that as come and gone over the years, where DCS does… things… if you set and check flags immediately following each other. Or if you want to use triggers such as TIME SINCE FLAG, where the exact condition for when the game considers a flag “set” or “changed” seems to almost be astrological in nature. Just to clarify: I've had similar issues to yours in the past when trying to introduce random elements in missions, and those have all been factors when I've forgotten to do it properly. Timing, sequencing, knowing when varying checks fire, and just making sure you don't accidentally reuse and overwrite a flag.

Hence “tell them to play nice and keep their grubby hands off the controls”. Problem solved. The radio transmission command works just fine in MP. You don't need to capture anything. You just rely on the players having their radios tuned correctly to hear the message when it plays. If they don't they miss the information. If you want the information to be restricted to specific players, only tell them the the frequency to tune to, but — quite realistically — obviously anyone who has that frequency can listen in. Simples. Maybe check your attitude and understand what the command does before facepalming, hmm…? You're asking for work-arounds. Don't get mad when presented with work-arounds. If you want more, maybe go into the wishlist section and post there.

The solution to that is easy and has already been mentioned: tell them to play nice and keep their grubby hands off the controls. And/or just start analysing why on earth they need to be grouped together to begin with from a game-mechanical standpoint. The rest can be done via outText and outSound, both of which exist on a unit level, but since this is presumably happening over radio, they wouldn't go just a single aircraft because the radios wouldn't (and indeed couldn't) be set up that way. They would hear each other's communication. If you want to do it properly, you use the radio transmission command so the individual aircraft have to actually have their radios set up correctly.

So… how about actually giving some? So we have something to work with in the discussion. Player interactions that have a branching effect on the mission isn't particularly hard to create either. You don't even have to dip into scripting (or, for that matter, menu choices) to create any of that. Dynamism and immersiveness are already built into some of the more complex online experiences players have built while waiting for ED to deliver. But… that is quite literally what you were asking for.

They can't go to specific units, no, but you don't really have to. If you just want one player to have access to commands, you can make a group of one plane and feed it add[X]ForGroup, and the main limitations is that you probably want to give those to some kind of GM unit (or role) that isn't necessarily in an aircraft. So then the question becomes, can you give an example of a scenario where you'd want to give it to one specific unit, where it wouldn't work to give it to the group as a whole? If you're playing with friends in the same group, you can always just tell them to play nice and keep their grubby fingers off of the mission controls.

If you open the .miz in any kind of zip explorer, you will find two files in it: one called “theatre”, which simply lists the theatre (this is how DCS mission listing knows what map the mission is on without having to interpret anything complex) and one called “mission”, which is the file that… drumroll… defines the mission. The “mission” file is a lua file, even though it lacks the extension, and can be opened up and edited in any competent text (or lua-specific) editor. Early on in the structure, you will find a data key that is called ”theatre” that likewise defines what map the mission is on. I don't know how standardised it is, but it seems to appear between the “weather” and “trigger” blocks in all the examples I looked at. It will look something like }, -- end of ["weather"] ["theatre"] = "Normandy", ["triggers"] = or }, -- end of ["weather"] ["theatre"] = "Syria", ["triggers"] = or }, -- end of ["weather"] ["theatre"] = "Falklans", ["triggers"] = …or any of the other internal names of the maps. To completely change over a mission from one terrain to another, just swap out the name in those two places. The one caveat is that each map has different coordinate systems, or at least different coordinate limits, so if you've place any units right in the middle of one map, they may end up at the very border of (or even beyond the border) another terrain, and you'll have to drag them back into place. This is why it's best to do this before you've placed any units at all, if you're building a template. Otherwise, you're looking at an awful lot of dragging-and-dropping, or even manual coordinate copy-and-pasting if stuff ends up outside of the visible editing area.

It's not the only solution, but it's the most immediately available. Depending on what other restrictions you have to adhere to, it might also be the one that saves you the most time. If it's mostly scripts you want to load, you can look up “dynamic script loading” as a topic all in and of itself, and what kind of setup is required to make that happen. Scripting in general can let you work around many of the annoyances in the mission editor, but the complexity will soon require you to set up a full on script debugging environment to make all of that work without turning your hear grey. Part of that should probably be to figure out what you actually need those triggers for, and if they are such a necessity that you need them in every mission you create. Some organisation and optimisation might cull a few from the list. And if it's only the triggers and their attached assets we're talking about, it's utterly trivial to transfer those from one terrain to the other — you just have to change the definition in the mission file of what terrain it is supposed to use. So you only have to do it once, and then change two lines of code for every other terrain you want to use.

My immediate suggestion would be to try to make a template mission — any files that you reuse can just be reused directly; some that you don't can perhaps be used as generic placeholders where you can update their specific content to match the unique mission. E.g. if you use custom beacons with their own morse (or radio) signals, and want to use different identifiers in each mission, then re-use those units and setups, but give them names that let you easily identify which becaon is which file so all you have to do is mass-update the sound files because everything else is already set up properly. As for third-party stuff, there are a few frameworks that let you generate missions in various ways and which work within the data structures the .miz use. You can look for them in other parts of the Mission Editor subforum. There are also some scripting frameworks that let you include stuff at runtime, but this entails some level of breaking the security sandbox and/or might only work in SP with appropriately set up clients. This may be a bit of a blocker depending on how squeamish you about those things.

The problem isn't so much the adding and removing files via a zip tool or the filesystem data of the file itself, but that the mission only really recognises assets that are either auto-indexed (eg embedded kneeboard pages and certain config files like labels.lua) or that are part of its “dictionary” file. When you add them through the ME trigger editor, they also get added to the dictionary. And perhaps more to the point, they're attached to a dictionary index that is recognised and blocked by the editor so there's no conflict with other dictionary items. You can do all of that manually, but it's a huge faff to keep it all straight. The mission editor will invariably end up being the simplest option, although there are some other third-party .miz tools that also keep the adding and indexing straight. That said, you can still benefit a bit from doing some things manually, like updating files that have already been added in an approved way, but you now have a new version that you want to include instead. Or the aforementioned auto-indexed files, where you can play around freely without involving the mission editor (indeed, often you have the exact opposite problem there: the mission editor doesn't have any way of adding or editing those files so you must do it manually).

Right. I was semi-purposefully vague there: it's not that the rendering is scaled but more that the instant you have a translation from one linear distance to another, all other dimensions have forcibly have to have the same translation applied to them or the world would go wonky in new and interesting ways. Exactly what parameters go into that translation can then vary depending on the game (and headset).

Because the in-game IPD is fixed. Your virtual pilot's eyes sit a specific distance apart. When you alter the player's IPD — because different players have differently shaped heads — you create a scaling factor between that in-game and out-of-game eye distance. To not make the world 3D-anamorphic, which would look very odd, that scaling factor needs to be applied equally to all axes. Thus, the whole world scales up or down to make sure it conforms to how it is supposed to look through that pilot's eyes. It has nothing to do with depth perception. It has to do with linear scale and how it needs to be applied equally in every direction to not make the world go squish. This may create an effect where the world looks too large or small to you, because you are larger or smaller than the in-game pilot and aren't used to seeing the world around you through their… physique. If the game is fancy, you can also alter the in-game IPD, to reset the world to your expectations, but that just moves that one-dimensional scaling factor up or down, and it still needs to be applied equally to all axes. edit #678: oh, and of course, there's also the issue of camera position over ground compared to where you expect your eye line to be, and how proportional the in-game character-height-to-character-IPD is in relation to your own proportions. If you've ever played around in Google Earth VR and flipped the switch between “always stand on the ground” vs. “always stay actual size” options, this is the relationship you're fiddling with.

Of course, one of the most extreme sensations of speed come from when that speed makes your four dimensions expand at different rates…

Wrong way around. With the option to turn the dot off, players can currently use the 2.8 rendering method to see objects at egregious ranges. The new system reduces the range at which they are rendered. Now, arguably, you'd still want a mission setting option to remove that use case. And let's be clear here: that is all it ever will be: a use case — it cannot possibly be an exploit since it does exactly what it intends to. But that option would be to force the new dots on, not to remove them. If you truly wanted the effect you claim, you'd advocate the exact opposite of what you're arguing for.

Just wait until someone manages to Lua-hack in igla troops instead of regular pilots!

Again, you realise that the only one who has ever tried to convince anyone that they should be easy to see is you, right? You're were the one who once upon a time offered a screenshot of a plane being visible at 50nm as proof that DCS spotting was fine under the old system. It wasn't until you realised that it gave people advantages over you that counter-balanced the advantage you had over them that you wanted to see it changed. Now we're getting a new system that is scaling back where that upper limit is; where it starts out being faded completely into the background rather than popping in quite harshly; where it is at least attempting to be hardware-agnostic; and where we know that the upper limits could stand to be scaled back a bit more (although, tbh, it's probably the near limit that is the bigger problem in how the fading happens), even if they are sort-of-reasonable for larger airframes given the right display settings. And with that, you have come full circle to arguing that we should actually go back to that old rendering system. A system that you, for a while at least, decried as being horribly broken. You have even posted new images showing the improvement, only to then immediately argue that it should be made worse, and that somehow, for no clearly explained reason or rationale, this reversal to ridiculous visibility is supposed to be more realistic. These new images show planes clearly visible at 30nm using the old rendering, and now you're trying to say that that's “close enough” to the realistic limits. Only roughly an order of magnitude off. The realistic limits are well understood, yes. That's why actual numbers have been thrown at you for quite some time now: to demonstrate how your intuitive, yet ever-changing sense of what's supposedly right is actually objectively wrong. Especially on the topic of anything to do with display technology and how it relates to properly and realistically simulating perception, which is the ultimate goal here. And let's not forget, just about every time any kind of research or numbers have been offered you to demonstrate why your intuition is wrong, you have decried it as “silly” or, like now, questioned its relevance…

…and that's why DCS is getting rid of that system and we're getting this much improved one instead. Everyone wins. Except those who get too used to being able to see planes at insane distances and who want it to stay that way. You're making a good argument why we also can't really rely on pure perspective rendering since that doesn't actually match how perception works.

Oh god yes. There are so many “eh, let's just wing it” systems in DCS that either weren't originally interesting or that only received some token attention or work-around, but which have now become expected features that all modules have to do in one way or another without any unifying structure behind it. DTC and all the settings that go into that, dynamic mission programming, laser-guided weapons, cockpit environment controls, and (in the past) such obvious things like ground radar. So much is now standard that it should be part of the core, but we're looking down the barrel of an increasingly disparate and often mutually incompatible bunch of implementations. Sure, core systems don't sell planes, but I am kind of wondering how much effort is wasted on remaking these systems that should be universal by now.

Quite, and that's where we get into the black box. But as mentioned, you don't really need to open that box as long as the input and outcome matches what's expected — i.e. right code = thumbs up; wrong code = thumbs down. It's the failures that get tricky because you'd have to know how robust both ends are to weak or noisy signals. But then again, that also mostly comes down to a matter of ambition: much like how half the planes completely and deliberately do laser-guided weapons wrong because [reasons], there's nothing to say that that kind of detail in the error simulation must exist. Just doing IFF a little more — say by making range and aspect a factor — goes a long way since the starting point is zero in most cases.

A lot of it will come down to what you mean by “in depth”. IFF is one of those “if you open the black box, you will be put into one yourself” topics, so that depth will obviously never happen. At the other end of the spectrum, the most shallow level of where you have to input and match codes — provide input, and get the expected outcome and what happens in the black box in-between is ignored — exist in a handful of aircraft already. But the lesson there is that it can cause incompatibilities with aircraft that don't have the same detail, so it falls back on magic knowledge anyway. Having it be capable of failure would increase the depth ever so slightly, but then you'd need good info on why it can fail, but without going into details, and the game would probably have to be expanded in other areas to make room for that. For instance, the issue of the signal not getting through is actually already in the game — you can see it happen with TACAN, for instance. But that failure is a simple matter of line-of-sight and range attenuation, and the way those are handled wouldn't really come into effect if we're looking at aircraft querying each other. It could be faked with randomisation, of course, but those tend to end up over-modelled, or people won't notice. The AI issues discussed above fall into a similar “there, but would have to be expanded” category. It also depends on what systems you want to include. If it's just giving the IFF code panel a purpose, then that's a separate thing from stuff like Hornet's NCTR mode, but maybe that's unique enough that it's better handled on a per-module basis.