Acidictadpole

This is pretty good information though. It means that your "horrendous" internet still being able to host multiplayer means that it's unlikely network problems but rather simulation problems (either introduced by the mission maker or inefficiencies in the game code). I'm interested though.. How many people were you hosting? After about 10-15 people the upload required starts getting pretty unreasonable for average personal home internet, and starts getting into business / hardcore upload speeds. So having some numbers on the horrendous internet would be useful! But yeah good info. I've been able to run missions like On Station and whatnot from my house, and these typically last a few hours (I guess that's what you meant by large?), but anything more persistent and things start getting iffy.

You probably know more about it than we do, but if AI code gets changed to be more demanding of performance, and a function that was previously stable is calling that AI code, surely that will manifest itself in multiplayer too. The stability of servers and netcode problem isn't limited to people just experiencing lag. The servers themselves grind to a halt processing the mission itself after a while. So I personally feel that this is related to the server stability issue.

Probably including the ones provided by ED too though. We don't have a lot/any of examples of "good" missions that are 2.5+, or any "best practices" for scripting for missions. The way I found out we had a lot more objects than expected was from a Tacview debug output, which I have no idea whether it has any accuracy to it because it's not first party. But I was just made aware of some missions that shipped with ED products that use the lua scripting but are likely out of date. Is there a meaningful log we could provide that has information you can use? All I've ever really seen is the dcs.log, but that has no information about the level of scripting going on in the mission afaik. We also have no tools to help us figure out when a mission's script is actually causing the strain, or if it's the object counts, new maps or performance demands. As you're aware there's a lot of things that could bring servers to a halt, as people that use a scripting engine, we should (and are, for the most part) aware that when we put in bad code we'll get a bad result. But there's no indication about what part of the code is bad, or what part of the sim is slowing down that we can either bring up with you guys, or work to improve ourselves.

This is a tough sell to be the approach for mission making. We did build our large mission iteratively, but still tried to keep each "stage" a useable, playable, and fun mission. Going through stages of mission development that aren't fun / have no substance is a tough sell to get people to try out. Our debut for Georgia at War had 40-50 people on it during the weekend, but we had to provide an actual experience with that before people would really bother giving it a try.

I've tried to code multiplayer games before and completely understand that it's amazingly complex. More so than a lot of people understand. You mentioned official servers, is clarification about that coming soon? Having ED run dedicated servers with an open sourced blueflag-like (or other large-style mission/campaign) would provide immense value to both sides. You would see the pain that we see and have the correct context to be able to work with it and improve things. And the community would get insight into the best way to use the lua engine to code missions/libraries. So if those are the official servers you're talking about I would be totally on board with that idea, and even helping out with working on the content for them.

That seems like the wrong way to go about proving a point :( I've made it a personal goal of mine to make hoggit the most welcoming place for people interested in combat flight simming. We run a server welcoming new people every Tuesday, where anyone can come in and ask questions and not be fearful of being called out for doing something incorrectly or not knowing something. Pretty much every week I have been involved in this Tuesday practice, there has been someone asking about multiplayer issues, or complaining about crashes to desktop / "dcs has stopped responding". The saddest part of all this to me is that the response from people is "Welcome to DCS". We've grown accustomed to the crashes, and the instability. But seeing a new person who's just learned to take off, or drop a GBU on target, get so excited about doing a thing in a study sim like DCS, get so disheartened because they take multiple attempts to join a server after their game crashes or the game fails to load entirely just breaks my heart. I do what I can to dig in to the logs and pick out specific problems for them to work on, but in doing so I also think about all the people trying to face this kind of problem alone. I want the "Welcome to DCS" part to not be responses to crashes or instability problems, but instead I want to tell people "Welcome to DCS" when they finish their first multiplayer mission, or first carrier landing.

It's great that you found a workaround, but I don't think I'd consider a game which requires altering OS-level features such as a page-file to get going stable. That's just me though. Pre-load radius alterations are a pretty common suggestion to get things going I think, which is good that people can point to it and say "tweak this" and have results, but the page file shouldn't need to be touched by a video gamer IMO. I'm curious as to your server specs and the internet throughput you're using while running your server with 40 people. Additionally how long you ran the mission for, and how complicated the mission itself is. Our server that sparked this thread is not running the simplest mission, but I wouldn't consider it insanely complicated either, and it seems to get bogged down after around 2.5 hours.

Well, in our case we don't see problems related to the 500 ping so that's why we don't mention it. Warping occurs for everyone on the server, and the server itself has its ingame time skipping periods of 3-5 seconds after about 2 hours of running our mission. I fully understand that our mission is pretty complicated, but only from a DCS mission side of things, it's logic is really fairly simple once you get down to it. But maybe they (the 500 ping issues) don't get mentioned because ping related latency is easy to pinpoint and understand, but the important part is that it only affects the person with the high ping, instead of everyone on the server.

My experience with hoggit is a little bit of both. We try to encourage multiplayer as a way to get acquainted with planes because having a responsive tutor is much easier to work with. Each week we have people that tell us its their first time in MP (or DCS in general!) and that they're having a good time and want to play more. So while I do think that there's a fair amount of people doing SP only because they 'arent good enough' and worry about not impeding or getting in the way of more serious people, that's a problem that's constantly being solved by hoggit and other welcoming communities in DCS. It won't be a problem forever, and as DCS grows and gets more content creators it'll get easier to become comfortable with things. I do know a lot of people that are cautious about joining MP stuff but we encourage them to do so. I have also seen a lot (way more than I should, tbh) that just can't play 2.5 anymore. I understand that as engines get improvements that hardware requirements shift, but even matching the recommended settings and more people still have trouble staying in servers for any reasonable amount of time. So while it's easy to say that MP issues are stopping people, it's just as easy for you to say it's not true. But I've seen it first hand with the people that join our discord and ask for help running MP, and I'm imagining all the people that don't get that far because they can't find the help they need, or are too worried about being branded a noob to ask.

We are completely happy to run our own servers out of our own pocket. It's part of running a multiplayer community. The difference with DCS is that the servers that are required to host any kind of reasonable mission that isn't a one-and-done kind of deal is unreasonable for a user of a video game to fork out. You can rent a linux server capable of running the DCS specs in all but the Windows Requirement and GPU requirement for 20-50 dollars per month. As soon as you add the windows licensing and the gpu requirements it becomes verging on thousands of dollars per month.

Started our multiplayer mission after today's update and was getting reports of the fuel tanks for the hornet's not showing up in the re-arm menu. I checked out the warehouses file in the mission and compared it to a brand new mission which worked, and I noticed some differences in the numbers related to certain entries. I don't understand what the entries mean, and so I didn't fiddle with them. Checking out the warehouses for my player's airfield, I noticed a weird set of missing entries (compared to the working mission, these missing entries are where the tanks that are missing are supposed to be). I've been able to workaround the issue by setting each airfield to unlimited munitions, saving, unsetting unlimited, and re-saving. It seems to fix the IDs in the warehouses file if I do this. However it's not ideal because we had some specific levels we were working with. I've also attached the broken warehouses file (I had to zip it because of the size). bugged_warehouses.zip

Really impressive. I am interested in creating some of the panel myself and have been trying to source components. Which buttons are you using for the Option Select buttons and the faces for the actual keypad? I am going to wait a bit on the displays, and just look at creating the data entry parts for now. Thanks again for sharing this and answering all the questions!

I hope I'm not speaking out of turn on this. But after a few discussions with others I think the condition of the discount was that they wouldn't be releasing it on Steam until it was out of Open Beta. The shift is that they're now offering people on Steam to buy it earlier, potentially much earlier, but they won't offer the same discount as part of it. If you wait before buying it on Steam until around the time it may have been released before, you may find a sale on the module at that time. I guess all this is doing is offering an option for Steam people to get it now and pay full price, or wait (like they would have had to before) for a discount.

I think I understand the shift then. You're allowing people to grab it on Steam earlier than anticipated so they could get it at the same time as Standalone people. The sale _may_ still happen when it comes out of Early Access on Steam, but we don't know yet. Does that seem fair?

That condition wasn't really conveyed to anyone in the wording of the original FAQ though. I don't think this is true. Valve offers launch day sales provided that you don't want to put the items in a seasonal sale within 30 days of your launch sale (the policies are public). Then again I'm not entirely sure if this is different for DLCs but it doesn't state that anywhere in the policy.

You make it sound like "Switching" doesn't include a fairly substantial financial investment due to the policy of modules not being transferrable after the Mirage. If you're trading off the discount for the earlier release date on Steam, I don't know if you guys made the right call there.

Kind of interesting, but makes sense. Does this mean that the variation in altitude we're seeing might be affected by what season the flight is in? If not, then it might still be a different problem.

I'm having this problem too, I'm not entirely sure if a re-install of World will help. I will do a little bit of diagnosis and see if I can find the bottleneck. Edit: It's disk usage, network usage, and CPU usage were all minimal during the wait. However, the process is blocking during this stage, so I think it's something in code that may not be working as intended.

Maybe it's the fluttering, and it's using its ailerons moving up and down rapidly for extra propulsion.