GhostB

Hey guys how about we directly answer the question, disable your feed from the ext wing tanks, wait for the center-line to empty, jettison it and then enable the wing tanks again. These checklist elitists might bicker about it not being procedure, because drop tanks cost money. But you know what the nice thing about the playing a flight simulator video game is, you don't have to pay the bill to replace a virtual fuel tank... Why people let the way they want to play the game get in the way of answering a technical question, I do not know. I haven't managed to find a drag index for the hornet, but someone dredged up one for the 3 bag F15 debate, and the centerline tank on the 15 had slightly less drag than the 2 wing tanks... combined... So you will definitely see a performance increase by getting rid of the centerline first, over doing it the other way around as it will likely nearly halve the added drag from the bags overall. Without even accounting for the fact it will take less time to empty it.

Nineline, care to comment on the relative back burner the radar has seemingly be put on? There has not been a single addition to it except the "IFF" since release, unless you count "We finally made it work, mostly, sometimes" as a feature. I know that's a bit hyperbolic and I don't except you'd actually admit it if it had been but things have been pretty full speed ahead on things like JHMCS which was said to be coming much much later into the cycle, seem to be jumping the queue over base-level functionality for the primary A2A system. It'd be nice to know if we were going to see some improvements and new features to it before wag's video in two weeks showing off the early targeting pod, because at this point I'm getting increasingly convinced I'm going to be dropping JDAMs or being TWS locked by a F14 before I'm TWS locking a bandit myself in the F18. The release of news on the radar apart from "We're going to fix it... this time... we swear!" has been lacking for months.

(No sorry I don't know who that is) Just to further build upon what I said earlier, as Trev mentions above, the lack of NCTR is painful, but I can live without it though... I mean the flanker doesn't have it, and the F15 essentially doesn't have it in 50% of cases these days because basically anything released after the huey doesn't actually have a NCTR profile, because apparently the F15, F5, F18, Mirage and Harrier exist in a separate timeline to the F15C, and therefore the F15 gets confused and is unable to identify any of its NATO allies aircraft or that of its own country and manufacturer... Nor did the designers ever manage to record a profile for the Mig-21, wouldn't ever be needed obviously. But I digress. So I'm flying with my buddies, they are in f15s or mirages, and they call out 4 enemies coming towards us, they declare one is a slow moving helo, theres a 2 ship up high, and a lone fighter just below them... I'm meant to go after the lone guy, they'll handle the 2 ship and we'll ignore the helo for now... Great, so now I'm trapped in a magicians act playing the fool in the classic cups and balls routine, because the I've 25% chance of picking out the correct one, I can't see their speed, altitude or even direction without locking one up, I can only lock one up at a time... But what choice do I have?... Oops, I locked the helo, well I'll just unlock him and select the next one... But wait, I've gotta wait for the radar to reset and redraw the page, and if they contacts were REMOTELY stacked, they'll all spawn in a different order from the last... So I'm basically picking in the blind again, hoping I've got the right one, the options being randomized each time I select a cup to check under. This isn't effective... friend, foe, fast, slow, high, low... its all the same little block symbol... Its hopeless. Why the hell does this seem to be the lowest priority for ED? Pushing ahead with mavericks, JHMCS... Its running before you can walk... Yes, it can technically detect an airplane... Yeah, you can select which contact to lock... I mean, yeah you'll find out speed and altitude when you lock it. Yes, it can technically identify if its a friend or a hostile, when it feels like it. Sure it'll guide an aim7 to that hostile, or if its having a bad day, that friendly. Yeah it can do all that. But god forbid you want to do some combination of those things at once. Its not combat effective, its not nearly just "Oh its a just missing a little polish, we'll come back it after we add some new toys, it'll just be a tiny bit rough for now"... Its pretty much useless outside of firing up the editor, sticking down 2 mig29s in front of you, and kill them, and then resetting the mission, the second you start mixing friendlies into it, or even just start adding different targets with different threat levels to be prioritized, your screwed. This isn't just "OH ITS EARLY ACCESS", so don't go there... Yeah, its early access if don't like it buy it, don't play it. Alright a couple things A) This isn't the progression path that was talked about in the lead up to sales of the module B) Alright I'll stop playing it (I have stopped) but would you mind convincing that other guy who is lighting up my RWR every 20 seconds because hes not sure if I'm a new contact? Like it or not, if your playing multiplayer, weather you own this early access aircraft or not, if you play it personally or not... This "Early access" product is on release branch... its setting off alarms in my cockpit, team killing me or my teammates, and just generally disrupting the comms/gameplay... and if I go back to flying something like the F15... NCTR in my non-early access product... Target type? Unk... One moment while I pull out my 20 point checklist and put on my best Sherlock impersonation, and go through the increasing long list of possibilities, of what it could be based off what RWR contacts I have... Its speed... Its altitude... Known likely targets to be in the area... With the addition of the 18 and soon to be the F14... This list is getting so long its basically getting impossible guess with too much accuracy... this wasn't so bad when answer, 90% of the time was its a bloody Mirage, but its getting stupid these days, back then the excuse was its "Its a 3rd party module, it must be razbam's fault". Both of these are ED products... Support your existing products atleast ffs. This can't problem can't be ED Forum flamed away with comments about it being EA, or it being an open beta thing... This plane is on release branch... You basically cannot avoid it on the main big MP servers... Stop declaring the radar done, patting ED on the back and then bleating HHARRM HAARAAM HAAARRRAM

I mean the radar still, in multiplayer likes to have a freak out and not decide if the target is flying at you, away from you, or is going orbital at escape velocity... Locks still frequently get stuck in these loops and fail, or don't and just spaz out until you manually drop it and try again. The obviously WIP and placeholder IFF is also still incapable of of deciding if a target is friend or foe, flicking back and forth, sometimes rapidly other times after long delays, which always nice when the aim7 that is about 2 seconds down range, is suddenly heading at a friendly which was showing a constant steady foe diamond right up until 3nm at which point I'm better off reading his tail number and checking the scoreboard... and alot of missions do have planes on the both teams for balance reasons, just doing visual profile IFF isn't always an option. Its a WIP and placeholder, that's fine ...ish, but this is a virtual world, you create the collection of pixels that we called a F18 and a SU27, why exactly are you unable to come up with a placeholder system that actually knows what its shooting at? The simple (you could call them placeholder) IFF for the FC3 aircraft don't get confused and flicker randomly within visual range... Nor does it mistaken that enemy frogfoot for UFO changing directions doing 100G spins So much for the initial roadmap and promises of filling out the aircraft as an A2A platform before turning to more advanced modern features like the JHMCS, targeting pod and harm. I don't understand why people feel this shoddy, nearly unusable until this week radar is somehow acceptable and ready to be sidelined in favor of features that were only promised later on the development roadmaps... Why is barely functional somehow praise worthy and worth stringing up a "Mission accomplished" banner on the side of the tower on the Stennis and declaring its time to move onto the harm? Theres no TWS, we can't IFF people without sending off a flurry of "BUDDYSPIKE!?!?" on comms. Every time a hornet arrives to the fight, its like the seagulls from finding nemo all of a sudden discovered some new words. "RAYGUN!?" "BUDDYSPIKE!" "BUDDYSPIKE!" "IS THAT FRIENDLY?" "RAYGUN!?" "BUDDYSPIKE?!" "FRIENDLY 18!?" "BUDDYSPIKE?" "BUDDYSPIKE?!" "DO WE HAVE FRIENDLY 18?" "BUDDYSPI--- I'm dead, it was hostile" "RAYGUN!!!" "..." "FOX 2" "DAMN IT BLOODY IFF YOU TEAMKILLED ME" "IT WAS DIAMOND I SWEAR" Its getting a tad old...

Hey, I'll give you the benefit of the doubt and assume you are not incapable of putting together an well reasoned argument, and your just are having trouble understanding and translating English. Let me try help. "The only factual data provided is the NATOPS manual, that tells you how to do proper startup and how to take off." The only dactual data provided is the NATOPS manual eh.... So.. so we know HOW your meant to do a proper take-off, but doesn't that manual say "Caution; Taking off with the poorly named AUTO-Flaps will endanger your aircraft and challenge your ability to maintain stable flight" Does it? Does it say "Taking off with the incorrect flap setting will induce X, sorry we probably should of caught that during development, and fielding the platform for a couple decades, we fixed a bunch of other FCS issues but decided we liked this one" Because I'm pretty damn sure the FCS isn't setup in such a fashion to attempt to kill NAVY pilots, they're generally pretty protective of their expensive personnel and equipment. So how about instead of quoting how its meant to be done, as if that somehow eliminates what does happen if its done 'incorrectly'. You don't have the level of detailed documentation that ED has through its partners and contacts... Do you? You have redacted, absent of most of the combat systems flight manual that tells you have to turn the lights on. The correct way of doing it, does not tell you what will happen when you do it incorrectly. It in no way, proves or disproves the accuracy of this flight characteristic... Does it? So how about instead of telling the guy hes simply doing it wrong, when hes acknowledged that its not the correct way of doing it but the behavior still seems unlikely and inaccurate... We instead get this passed along to the development team, who have the ability to consult their licensed documents and their 1st hand sources, such as F18 pilots, who have a tad more knowledge of the flight characteristics than simply jumping up and down on the spot, blue in the face going "BUT THAT ISN"T HOW ITS MEANT TO BE DONE" If you have trouble understanding any of the words I have used, or the concepts I have tried to express, please feel free to ask for further clarification I will be glad to provide further assistance.

At what point can we perhaps instead of trying to prove or disprove the behavior based off if it is or is not in a startup checklist as being procedure, and just ask a simple question. Does this seem like intended behavior from such a late model hornets FCS? Forget if its procedure, would this potentially dangerous behavior, requiring the pilot to take his hands off the hands to correct, be intended in a real plane. If this is intended realistic behavior, I could almost guarantee it'd be documented and ample cautions would be stated somewhere in your hallowed manual. Seriously, the fact it behaves different between a cold and a hot start alone, should be enough for people to drop their checklists and begin to consider that they might need something a bit more concrete to prove this one either way.

I did say effectively, what your suggesting would limit is exclusively to hard-coded static targets, that doesn't really allow for much flexibility, doesn't allow it be used to full effect.

What is the point of this poll, when half of these things depend another option on the list? You can't complete the datalink without completing the A/A Radar and the Tpod. Sure you can datalink friendly positions but your still not anywhere near complete without those being done first, so contacts from those sensors can actually be passed along, and be used to slew your own sensors to them from datalink info. Your not going to be able to effectively using guided bombs, slammers, harpoons without completing the Tpod, the datalink also not being complete isn't ideal either. The path to complete is obvious, sensors > above all, because that's the order you need them there's no point in having weapons or data-links without sensors to detect targets.

So, I don't use any of the anti-viruses Bignewy mentioned, and I had actually disabled what do I do have as part of my trouble shooting, I also temporarily disabled both my windows firewall, and my routers firewall as well. Issue persisted, some days it'd just refuse to connect or show up in the browser, I eventually worked out that the VPN workaround that has worked for me in the past, actually does work, its just really temperamental, one day one location will work, another it won't, but once I pick the right VPN server, bam, I can see and connect to my target DCS server. This issue is unlikely a routing issue however, as A) Any of the VPN locations should get around that, not one on one day but then only another on another... B) Pinging the target IP (IP, not a domain) once per second for 10 minutes, averages 0% packet loss and stable pings C) I actually have access to 2 landline internet server providers, both with completely different routes according to tracert, both get stable pings 0% packetloss to the target DCS server. Really at a loss to explain this, I've had this not occur some days, some days it happens after a crash/restart, others first login of the day it just won't work. I don't even need to restart DCS once I start swapping IPs either by swapping internet connections or connecting the VPN, and again no matter if the connection can, or cannot, connect to the DCS server, my cmd ping will be stable latency with 0% packetloss. I don't understand how this effects both Direct connecting, AND the masterlist, even if I had a bad route to the gameserver, would the master server-list still let me SEE the server? Its two different routes? Perhaps the server list filters out any that fail the local client ping request? This has got to be something do with the DCS network code, external tests/routes work just fine, there's a website running off a domain at the same network address, entering the IP or the Domain name into a will still get you the website.

I'm experiencing this issue every couple of days, where what I believe is after crashing/disconnecting, I simply cannot rejoin that server again. It does not show up in the browser, you cannot manually connect either, it just says 'server offline' This lasts for a couple days before apparently magically fixing itself for a day or so, before doing so again. This issue persists in-between my local computer restarts, mission changes on the server (Unknown how often the server provider/s are restarting their physical machine or game processes?) I've repaired DCS, ensured I am running the same update as the server, emptied out my DCS save game folder to rule out corrupted settings of some kind. I've VPN routed to several different worldwide locations to rule out routing issues (And I can command line ping the server IP externally successfully). Anyone got any other ideas? ED, do you wish to comment?

Delete your shader folders, your using shaders compiled for different hardware, which can cause performance issues and visual artifacts. Someone posted the instructions earlier.

Experienced this in the F15 in single-player yesterday.

Hey Nineline, out of interest, can you perhaps explain to us, how one is meant to take a TRACK of a multiplayer join sync issue? Like seriously, lets think about this Do you want a track from the Bombers point of view? Because he sees it, and if he leaves, well he won't see it again. But thats TWO tracks, its a track of the gameplay, not of the loading screen? What exactly does this tell you? The important bit is the bit INBETWEEN the tracks. Do you want it to from a 3rd parties point of view who joins after the event? I mean he NEVER saw it and joins AFTER so who is say the bomb ever landed? He didn't witness it to track record it, so I don't see what that tells you. Or do you want it from the servers point of view? Also interesting because nothing is synced between a server restart? So what exactly do you want a track of? Seriously. This is not a case where a track file is applicable. Here are the steps to reproduce, Host a server(Are ED aware this a supported feature?), Have Client X drop a bomb on runway, have Client Y join the server, Client X will see and experience the crater, Client Y will not. I get asking for tracks of intermittent, or otherwise hard to reproduce issues of actual gameplay, but this is a 100% occurrence issue of a SERVER system, hidden from the player's system, and a track isn't going to show that. Someone is going to need to physically test to resolve or at least verify a fix for this, just host the damn server yourself and do it, we pay you, you don't pay us. Stop asking paying customers to jump through hoops for simple to reproduce problems, ask for the steps to reproduce, if it sounds subjective or rare, then ask, POLITELY for the track, don't start your reply with a snarky demanding comment towards paying customers. Saying please halfway through a sentence doesn't forgive the snark at the beginning.

This bug is getting beyond annoying, anyone from the ED team wish to at least acknowledge the existence of multiplayer?

A road map doesn't necessarily include any dates, though they could be vague like Q3, Q4 2018. But even without dates, it would be nice to know the priorities, what we should be expecting first, what should be last, and ideally everything in between.

The problem was, they hadn't decided WHAT they were going to do, only that they were going to do something, and they'd already decided what to call that something. I don't understand why it was decided it was a good idea put it out there, before even the rough idea was hammered out. Pulled the trigger too soon, and now its all the customers fault for filling the vacuum with their own ideas which turns out, didn't agree with EDs own vision... problem is, ED didn't even know what its vision was, but according to Nineline, its own fault for not predicting that. Please Nineline, I don't even disagree with the business reasoning. But please stop blaming everyone, half of your responses have "Its your fault, not ours we hadn't made up our minds". I'm all for transparency, but this is akin to announcing something as sure thing, and then not even getting close to releasing it for a few years... We're still good for the 30th, right?

The game might be improving, it might be growing. But dismissing multiplayer as unnecessary because its in the minority now is shortsighted. People don't invite their friends to play single-player, its single-player... People invite their friends to join them, and fly with them, in multi-player. How many MORE people, would be flying multiplayer if it was more stable, feature complete in terms of scripting and quality of life features? How many more modules would be bought because someone saw someone take off or do a successful attack run, in an aircraft they had previous dismissed as not interesting? Additional, new and diverse aircraft would of gone a long way to improving that. You have to find people to market single-player to, multi-player when done right, markets itself.

With all due respect Nineline, What has happened is ED(You) has gone "FC4 is coming with 4 additional aircraft" then dropped the mic and walking away for a week, then come back and gone "Hey guys, its your fault you moved pass the reasonable expectations that I did not set out for you when I announced it" I'm really not upset over expanding FC3/4 aircraft, I came to this game through FC3. I might wish you were, and think you might of been better served by including at least 2, never before flyable aircraft, to placate that full-fidelity-or-bust mentality people with a dose of "well, if its the only way we're gonna get it..." BUT. I think you would of been better served to state in the original announcement, that this were going to be 4 new additional FC level aircraft of existing full-fidelity modules, and you wouldn't of seen this level of hype and disappointment. You had people dreaming of a F-22 or F-35 (seriously guys? Why did anyone think those 2 planes were possible/likely?). You shouldn't blame your customers when you leave the gate open, and slam it shut a week later.

Just to make it clear StaticObject.destroy() currently only removes the object on the server, all clients will still see the object.

Shows up as Unk on F15 radar, and U on RWR. Its a flanker, the F15 should be able to at least incorrectly identify it as a Su27 (like it does Su33) (And if you wouldn't mind getting ED to finally fix this for the M2000/Harrier etc too, that'd be great...)

Also experiencing this issue, its becoming crippling for gameplay in multiplayer.

Experiencing stutters ranging from minor frame drops to <2 fps, to complete 500ms - 1000ms freezes, to even multi client crashes due to sams firing in multiplayer. S300s and Patriots cause the worst of it, shorter range stuff, mostly radar cause the more minor symptoms.

Read carefully, and you might notice I said, last time, a decade ago. But unless Lasso has managed to find away to literally rewrite and force its own thread interruption logic into windows but... https://bitsum.com/automation/ Its doing the same thing it was doing a decade ago. They can dress it up however they want as somehow better, but all they are doing is flicking some switches for you automatically. And for the record, you don't actually need project lasso because the DCS hitches and stutters are actually largely being caused by disk operations suspending the simulation as it tries to load a new model into memory whenever players occupy new aircraft, or whatever else new is being spawned. And when that does happen, they're alot shorter if your using an nvme ssd that has a lot faster response time over even sata SSDs, I had people telling me they were freezing for over a second, meanwhile my freeze was only quarter of a second. These problems are 10x worse if your on spinning disks, and worse if your running the game on the same disk your OS is running on. Storage is a larger bottleneck than you'd think when it comes to have smooth experience in any application. And, it helps if your not relying on swap/pagefile which apparently means having 32gb of ram, because DCS seemed to love memory leaking its way out to 18+gb of RAM usage especially before the patches, so when DCS goes on a memory leak binge it doesn't have to smash your swapfile, which is stupidly slow compared to ram in the first place, and only makes the other disk related problems worse... And considering I'm writing this from the past on my very old Athlon64 and instead my 8700k, 32gb of ram and separate nvme SSDs that I intend on buying in 10 years. I don't need to drink Project Lassos' snakeoil and give them money for something achieved via right clicking in task manager... And that's what it is... snake oil. Applications don't have authority/access to dictate the execution order of other processes, they don't even have that authority over their own, that's part of why race conditions are a thing in multithreading, the OS can, and does, suspend your thread whenever it feels like it, and there isn't anything you can do about it because its the operating system and its got 2000 other threads from all its services making your computer run, and all your programs like teamspeak that its gotta keep give some processor time to as well. And all this means when thread A and B doing exact same thing complete, one may finish much faster than the other, just because the OS decided let one work more often than the other because its giving other processes some CPU time and that can sometime seem random... All your doing is when you set priority is saying "please give this application more time on the CPU" and at the higher settings available, that can be the expense of other applications freezing. Which is other side of project lasso, is that closes background applications and suspends non-critical windows services meaning there's less thread switching to be done. This is less helpful to say someone like me with 6 cores/12 threads, as DCS is largely singlethreaded, there's 11 other threads to handle the background shit than someone who is running a 4 core/4 thread i5.

You are talking complete and utter bullshit, please stop trying to repeat the half remembered ramblings of excuses from Bohemia Interactive. Physics is NOT a good example for potential multi-threading speed ups, its THE example potential for multi-threading speedups. The same reasons we compute polygon transforms for rendering your games on the GPU (For sake of this point, you can consider them a multi-thousand core processor) is the same reason hardcore physics calculations, like used in movies, science applications etc are all done on the GPU, or more to the point multiple GPUs, which are basically what supercomputers are primarily made of these days. Physics calculations are multiple, straightforward non-branching logic math solutions which have little to no potential to encounter the race conditions and data locking problems (that is the justification for why games cannot be multi-threaded) because they are just expressions of Force = A * B^C - D, as long as don't depending on trying to update that outcome for use in *THIS* frame, and only use the updated value *next* frame. Considering games generally process the world in frames, usually only using the previous frames data for calculations, the data is static, you don't consider anything that happened during the execution of the current frame because than you'd need to worry about order of execution, just like in multi-core execution even if your only using 1, it'd massive headache. So you take the physics force being calculated like speed and you apply your forces like drag, acceleration, you move on, and you do this a couple thousand? Hundred thousand? Million times? You do this in parallel. You can do this in parallel a couple thousand times over on a modern GPU if you want to, because it you don't need the "if this then do that" logic that the CPU can provide, you just doing A * B^C - D and writing the outcome to a new location. But if you do need to do this on a CPU, and even in a existing older designed application like DCS (Don't get me wrong, rewriting a old code base to FULLY integrate threading isn't something to be taken lightly...) you can be single threaded all you want, hit your physics part, and then go "I have 100,000 physics calculations to do, and 4 threads to do them on" 100,000 divide by 4, core 0 does 1-249,999 core 2 does 250,000 to 499,999 etc... Everyone report back when you've done your share and we'll continue in the main thread after wards. And to be honest I'd be VERY surprised if this isnt already done this way in DCS already because I don't think you understand the scale and absurdity of what you're suggesting how things operate... AI is another example of a workload that can be divided, assigned, processed, and then collected back into a single thread. This kind of wide, narrow, wide, narrow, design isn't really desirable because its bottle necking, and a single core has to prepare the work and handle the completion of many, and its very possible DCS is hitting these kinds of bottlenecks. But for a existing application where the complete rewrite necessary for a 'down to the inner core' threading support, it offers perhaps the only way of achieving any kind of comparison in terms of performance. PS. To the guy above me praising Process Lasso, fun fact as of the last time I was naive enough to be using on my old dual core Althon64 a decade ago. All project lasso does is set CPU affinity and process priority, and close applications/services for you... Hate to break it to you but applications really don't and shouldn't have level of authority over other applications, its handled at the OS level ... So they don't...

Any ETA on 1.5 Stable actually being stable?