Dangerzone

Rotten! I thought I missed a release of Half-Life 3 there for a second when I read your post! Joke all you want, but don't include Half Life 3 - it's too soon (still)!

Not to mention reduce the sun's reflections from other aircraft in the sky - which is kind of handy to see as a pilot.

While it maybe realistic, so is rearming in a matter of a minute, isn't it? How long does it actually take to refuel the F-15E? If you're sitting around for 15 minutes waiting for each refuel, then I can see how this request could be justified. If it's just another minute or so than what the Hornet takes, then maybe not though?

On the contrary - eaves dropping in on the radio call I had myself laughing out loud! (Won't say more here as I don't want to spoiler for anyone who hasn't played the campaign or read the book)

Just one for the next time the forum dev's decide to tinker with the forum a little more, but as someone who glances through the 'Latest activity', it would be nice to have the ability to choose to ignore individual topics/threads so they don't keep reshowing if that's not too difficult to add please.

I thought it just uses UDP to reduce TCP usage Or is that RAM to reduce ROM usage?

From the latest newsletter: I'm on the edge of my seat with this one wondering... Will this allow us to dynamically spawn FARPS in game and have new slots automatically available at the new FARPs? The dream of mine has been for players to be able to cart crates (like they do with CTLD), but build a FARP which gives them a new spawn point dynamically in a perpetual campaign. Will this new feature using warehousing allow us to achieve this?

Are you replaying the track file from your own DCS choosing 'Save Track' after flying, or are you obtaining the saved track file from the dedicated server's save directory? (Are you self-hosting the dedicated server)?

Sweet and thanks.. Can't blame a bloke for trying. I realise for decades now (ever since I was no longer a kid), Christmas has lost it's edge when it comes to "what's coming'. I haven't really had that sort of excitement until I started getting involved with DCS. You guys have brought back my childhood experiences. (And yes, I was one of those kids that would go and lift and shake his present to try and figure out what it was).

Thanks for the clarification. But can't you let something slip, just something little as to what we might expect? 2.9 seems like a significant version increment.

Here's my stab in the dark: Vulcan - Unlikely - I would have thought Vulcan would be a significant version such as 3.0. DLSS - Hopeful. I say this because I recall the 2023 & Beyond video mentioned "Made with DLSS". So I'm really hoping that this (and some other GPU enhancements) will be here, even if not Vulkan. But then I'm reminded that some other & Beyond video's had some units that we didn't see at all that following year, so don't know. I know it's been a focus. Supercarrier - Likely. I think in a recent thread there were requests and concerns about the supercarrier and upcoming features of more deck personelle. IIRC - BigNewy said to wait and see what was released in 2.9, so my guess is that it's very likely we're going to see something new hear. Briefing room and elevators maybe, or maybe something else? CH-47 Chinook - Likely. Oh, this would be amazing, but I'm joking. I think this is Unlikely, but my ever-ending hope goes "Maybe ED don't want to give discounts for this one and will bypass the pre-order sale and release it directly". My pragmatic logic then hits me around the head until I'm nearly knocked out and says "Don't be stupid". Plus, Wags hasn't released any video's, and that would go against their SOP. C130 Herc . Same wishful hoping as the CH-47 Chinook that there would be a surprise announcement, but all things tell me the F4 is probably coming first. But, unlike the CH-47 which is ED's pet project, we have nothing to go by on how the C130 company operates. Maybe they do things differently to others and it will just be a sudden "Here it is - Christmas in September". F4 - Not Yet - but I think it might be close to release. Maybe 2.9 has things that the F4 requires before release and as soon as 2.9 goes out we'll see pre-orders available? That's my guess. There's possibly a push to have it released for Christmas, so I could hazard a guess that maybe 2.9 may have something to do with it's features. Dynamic Campaign Engine / Mission Enhancements - Maybe? This would be sweet. There was a video of Wag's back quite some time ago that appeared to leak an additional 'menu option' in it that may have been related to the Dynamic Campaign Engine. However it's gone very quiet since. Being more realistic - I'm really hoping if we don't get the DCE, that we at least get some features that would be working it's way towards the DCE that we can use now. My desire to spawn FARPS in dynamically wherever the players may build them, and have dynamic spawn points being able to be created through script on the fly has been a dream. However there's been no chatter of this, nor DCE, so I think this might go back to my pragmatic consciousness taking another batman-slap at my hopeful face. Weather - Hopeful. There's been no hints here like DLSS or SC, but it's been a while since I think we've seen any updates with the weather system. Thunderstorms would be fantastic to have - as would different weather over different parts of the map, such as a weather front coming through, or similar. Return to more regular Stable Release cycles - Unlikely. What I'm suspicious of regarding our observations with fewer SR and OB releases is maybe ED throwing their hands up in the air, and going "if our customers don't understand the difference between BETA vs a Stable release, and treat Beta expectations as Stable with Stable expectations - then if we can't beat them, we'll join them. And... they've just changed their logic so that OPEN BETA's release cycle is held back until more bugs have been fixed frist. They then maybe release a handful of stable releases for the "Very Stable". Thus Open Beta has become the equivalent of what Stable used to be, and Stable has become less of a release with the hope for it to be more stable than before. Full Globe / Earth - Unlikely. I see this is as been a 3.0 major release, or if not, a 4.0 release. However - there may be more pressure on with this. In the past there was a handful of terrains available and I think the majority of multiplayer users probably owned most if not all. (After all, it was only NTTP and Persia). With the significant increase in more MAPS, sales could be waning due to too many selections, and groups going "Well, less than half is willing to buy <xxx> map, so there's no point creating a mission for it". Having full earth would mean that us server mission creators could create these, and go "everyone can play". Those with the map get nice pretties, and those without can fly it with bland scenery. The simple fact that those missions would be up may encourage more people to fork out $'s for those new terrains. Hidden Easter Egg for Christmas. -Possibly. (Or maybe it's already been there and I missed it last Christmas)? What else could there be to make it significant enough to call it a more major 2.9 release?

While I imagine that this is a lot more work than other requests, it would be nice to do hand signals to other pilots in multiplayer. I just fear that it is probably a very complex and time consuming thing to achieve. It's not just the animation (such as a salute), but it would also need to take into account: The direction the pilot is facing. (Is he looking left, right, forward, or up (everyone is thinking topgun here )), and animations would need to be done for the different directions. The different kind of hand signals. Don't get me wrong - I would love to see this. As someone who flies VR with mates in close formation, I love seeing just the head movements to know where people are looking. Adding hand gestures to this would be great, but let's consider maybe something basic: Hand gestures that allow for left and right only (x2) Hand gestures that include Thumbs Up (yes) Thumbs Now (no) Closed Fist (Tight formation) Open Hand Wave (Spread Out) Hand Chop (Separate) Finger Circle (Turn around) Palm Down (descend) Palm Up (ascend) Fist Bump (agreement, excitement, splash) Pointing to self (Follow me / take lead) We're talking 10 signals x 2 directions = 20 different animations that would need to be done (compare this to how long it took to get the one currently done for salute). And then we have this replicated in each aircraft. As much as I'd love to see these (and more), I think that it would take way too much work to implement, for the few people that would appreciate it. Plus, the can of worms would open up as I'm sure there's other hand signals that have been missed that others would say "We need this too"... As a result, while I +1 this request, I also can accept that this may be something that would be very low on ED's radar.

Great news BigNewy. Glad to hear that they've managed to find something.

That's probably because you've launched a second instance of the same installation/program. I'm talking about launching a dedicated server install (will be a separate directory, and separate configuration) to the game copy that you're talking about. It doesn't launch the GUI interface. It's not something that I've done (or done in a while), but I do recall seeing it discussed in the past. Just keep in mind, I'm talking about a dedicated server install, and not using another normal DCS install for the second instance.

Wonderful. Thanks for putting that in incorrect hypothesis to bed so quickly.

I wouldn't class myself as being an expert either (although I have designed numerous TCP and UDP functions within my career, but normally not 'web' service related...) My understanding is that a 400 error means that the server is responding with a 400 error. (So that the request is reaching the server, but the server is erroring out with an 'unknown' error). I would expect a timeout error or similar if routing was broken. However, I also note that the 400 above may not be coming back from the server. It may be an internal error code within dcs.exe that is raised if it runs into problems itself. So, the above message doesn't definitively specify whether Error code 400 is being received by the server, or whether DCS just has an internal error they've called error code "400". The 'No saved authorization found' is also vague. Does that mean 'locally saved' authorization cache, or is it at the server's end where it is unable to find any locally cached authentication on it's end, and has been unable to send the request further upstream? Either way - I notice when I get this error, it errors out first time, maybe even second, but will go through on the 3rd, without me flushing DNS servers, etc - which has me thinking it may not be a routing issue (as I would expect the same route to be taken each time to the end IP address, which the DNS entry would be cached on my PC or router after the first attempt) but something else might be going on, either with the actual client/server protocols, or something at the server end. The other question I have is that (and it might be - and most probably is) coincidence, but I turned on 2FA on my account with DCS over the weekend and now have started to see this error. My understanding of 2FA says that it shouldn't be a factor for the above, but my limited understanding of the full extend on how ED authenticates accounts tells me that I need to not assume quickly. Thus, my question is - is there anyone here that is getting the above errors that is NOT running 2FA? If so, we can rule that out. If not, and everyone getting the error is running 2FA, maybe it's worth disabling that just to see if it's a factor.

My guess is not much. When you're recording client track files while on a multiplayer server, it's doing this for all the other players/aircraft on the server as it is. So, recording additional data for your own would be the same as recording additional data for another player that's on there. Obviously I can't say that with 100% certainty, I'm not saavy to the source code of DCS, but I'm taking an educated guess. There is a workaround for this at the moment. It's a bit clumsy, but it should work: If you start a dedicated server (even on your own computer) and use it to host the mission, and then launch a second instance of DCS to play the mission, you can use the track file that's recorded from the dedicated server to the get recording your looking for. While it's not an ideal solution - it can be used as a workaround in a pinch. (This won't work though if you're wanting to record and replay stuff back from other public servers online - it only works if you are able to host the mission yourself).

This isn't a bad idea, and you may be onto something. From my understanding, the single player track records all users inputs and 'replays' those inputs when you play the track back. The dedicated server can't do this (as it doesn't have this particular data from all the users) so it instead is recording positions, direction, velocity, etc of all units. As a result, the server method isn't relying on replicating exactly the user inputs but a more robust option of x/y/z/speed/direction/etc of the aircraft. However, in saying this, I believe ED would still need single player track to still record the way it does for diagnostic purposes (the original intent of the track if I'm not mistaken). One possible solution is to have both recorded in the track file, along with the option to choose how to replay the track (either 'diagnostic' which replicates the inputs, or 'replay' which uses the "server" recording data would allow us to have cake and eat it too).

Another one here that was experiencing those issues. Sometimes works, sometimes doesn't. Sometimes I just need to restart DCS and it works. When it does work the 'logging in...' seems to take a while sometimes too, not quick like usual. Will send PM with tracert.

Oh, that's what people were/are doing or how ED are trying to use this for trials? Ummm.. OK. I won't say anything further on this re 2FA because I don't want to cause problems by exposing the holes with this approach. Good point though on the hardware based checksum. Hopefully that's already being used, as that would definitely be a way of tracking abusers with the multi-account approach, and thanks for clarifying or giving a reason why people are linking 2FA with 'trial abuse' security. I appreciate the explanation.

Hi Tom, So how it works is like this. The QR code (or the manual seed code) you get is all that's needed for the devices to calculate the authentication. I give an analogy in here how it works. No devices need to know about other devices. If you enter the same manual code, all devices will give you the same number because all it is is combining the initial seed/code with the current date/time to come up with a specific number. (Which number and combinations will be different depending on the starting seed/code) You are correct. If you note the initial secret key/code/seed - you can put it in as many WinAuths (or as many different authenticators as you want). You can have WinAuth running on your PC, Microsoft Authenticator running on your phone, etc. They will all just combine your initial secret key with the current date/time and give you a calculated figure that should match. This is the best 2FA (in my opinion) for this kind of setup, because: 1) It's an open formula that can be used (and is used) by many different programs, and 2) There's no syncing between devices, so you can have multiple independent devices as backups, or convenience, and 3) Unlike SMS messaging, there is no costs involved in it's use, and 4) It's completely separate/independent. There's no network needed. No tracking. No having to give ED any personal information. It's effectively 'free extra security'.

Thanks for clarification Rob. My apologies for misunderstanding where you were coming from and I appreciate the clarification. TBH, it's been a week of headbutting walls, and I misunderstood where you were coming from, so the clarification is greatly appreciated! I also haven't read every post, I got through a few and thought "oh dear - this is a mess that needs clarification" and jumped in.

Thanks for getting back and confirming your experience. Glad I could be of help.

Hey there, I'm really not looking for an argument, but I'd ask that you please refrain from put words into my mouth about what I'm thinking. I never said I think ED is lying to their customers. I have no idea what ED have stated. All I am simply doing is clearing the air as to what 2FA is, what it does, and what it doesn't do, and correct the false assumptions people have, while trying to help people understand it's purpose, potential reasons for it's use, and alternatives besides google or smartphone apps that people have expressed desires for due to understandable, but not relative privacy concerns. The limits of it's use are basic facts and simple. I've worked with the source code myself, but no one needs to trust me. It's freely available on the net for anyone who wants to check and see how simple and basic it really is. It doesn't take much to see how basic it is and confirm if what I'm saying is true or not for anyone who is interested. I'm confused with the resistance to my trying to clear the very smoky air from the misunderstandings about 2FA, and what seems like determination to continue to keep ignorant of it's purpose, capabilities and limitations and be upset about issues that don't need to be issues. But I've spent about as much time on this as I'm willing to and I really don't want to keep going on with people about it if they don't want my knowledge and input, so I'll respectfully bow out of this discussion as it's now past the point of productivity and into diminishing returns.

I think there's a false assumption that 2FA is about stopping abuse of multiple accounts for trials. It's not. It can't be. It doesn't work like that. 2FA has nothing to do with ED not trusting you. It has nothing to do with ED tracking you, or locking your account down to one mobile phone number, or device. It has nothing to do with (nor can it) stop you from making multiple copies of accounts for consistent trials if that is their goal. (Which by your above post, it appears to be your understanding). 2FA can't prove any of this. All 2FA does is add an extra layer of security to your account that means someone requires more than a username and password to get into your account. That is it. That way, if someone manages to get your username and password (such off a hack list) - they still can't get in. Even if they were watching over your shoulder and knew your username and password, and watched you type in your 2FA, once they get home, (or even 30 seconds later) they couldn't log into your account knowing all that - because your 2FA has now changed to another number. All it is is an extra layer that a would be thief would have to get through in order to log into your ED account. That is it. It does not, and can not stop people from abusing the trial licensing. That is not it's purpose. As such, having purchases in your account does nothing to increase or reduce the risk compared to 2FA. Having purchases can't reduce the risk of hacking into your account. From my perspective, the more purchases you have, the better off you are with 2FA. It's the accounts with little to no purchases that are the least risk because what's a thief going to get? Next to nothing. On the contrary, an account with all the terrains and 3/4 of the modules is another matter. We would want extra protection on those. Now, looking at the flip side - if all this is as people are assuming - about ED trying to stop people from using multiple accounts for trials, then yes - your idea would be good. But 2FA isn't for this, and can't do this, so I really think people's assumptions about it's use here are extremely flawed. As to the question why ED has decided to enforce 2FA for accounts that want trials I do not know, nor understand, but I can take an educated guess: That would be that they might be having an increase of issues with people's accounts being hacked that is causing a higher work load, and they want to reduce this. If so, 2FA is one of the simplest solutions for this. But not many people haven't been using it. How can they encourage more to get on it? Well, as people try out new modules, require people to turn it on. These people may not be aware of 2FA until then, or just be apathetic and not care. This gets them over the line. Making it compulsory on trial purchases will have a lot of people switch over to 2FA, securing their accounts better. Doing trial purchases may be the best option, because making it compulsory on existing purchases may be received poorly at forcing people to do this for something they've already paid for. (And given the reactions to the misunderstandings here, if this was their reason, they'd probably be right). If, on the other hand ED are doing this to try and stop multiple-account trial license abuse, then they'd be barking up the wrong tree. 2FA can not make any difference with this except for those who misunderstand it and are scared off by it thinking that it's doing something that it's not.