fargo007

Wow - Very nice! This is a novel concept. We are keeping a close eye on this one.

Thanks for the response and the extra investigation here. That's certainly easy enough to try.

I am seeing an issue with dedicated servers where they randomly fail to start up. The failure is consistent. It is very early in the loading process, seemingly related to, or right before the login sequence. This is the entire log from such an occurrence: (That's where the log ends when this occurs.) When a server loads successfully, the very next lines after this are the login sequence: This is not reproducible on demand. There are four DCS servers that are started from the same installation, each with its own write path. The issue will occur with each of them randomly as the servers are started. Today #2 and #4, but other days one or two of the others, or sometimes none of them. It would seem that since the issue occurs so consistently right before the login sequence, that this might have something to do with that. If there's any advice on how to keep them from getting stuck here, I am thankful for the counsel. Thanks! /Fargo

Yes, that will work. You need to have minimum 1 group each on the red side of HEAVY, LIGHT, and SUPPORT for it to work. There's no reason you can't make them be a single group of 50 in LIGHT/HEAVY and a single unit of the same thing in SUPPORT.

Yes, it absolutely works. We use the MOOSE CTLD classes for this, which create them without issue. It has FSM events that you can tap into and basically do whatever you want. Here's some more detail. So within that FSM event function, you can pick out the groupname. In our case "FOB." Then you spawn the invisible FARP as a static object. These are just some excerpts that show one of many ways it can be done. I believe I made a 'walking skeleton' style example of this for the UH-60 mod guys. I'll see if I can dig it up if there's interest. Remember that you also need to populate the FARPs with the correct objects or vehicles to allow them to provide fuel/rearm/ATC services if you're not spawning them contemporary with the farp object or using a mod that includes that. Adding CTLD troops/crate functionality to the new FOB/FARP is also an option.

I also would have lost a lot of money on this bet had I made it. The UH-60 is absolutely iconic, celebrated, and capable with what is probably the widest mission set of any helicopter when you consider it's deployed in several different configurations across Army, Air Force and Navy. Of course we now want both.

We're a community. All you have to do is ask. Many people enjoy helping others, and furnish & support all kinds of scripts, projects and code. and there's so much of it that is released for people to use. This is how you got CTLD, CSAR, Mist, and MOOSE in the first place. People on the MOOSE discord provide code to each other every day. The limits that are going to be hit with asking ED to build such low level details like this into DCS are that it will need to be done in such a basic, rudimentary way that it will please very few if anyone, and the requests to modify it this way or that way will be both endless and tiresome. I point here to the in-sim handling of ground troops. There it is. Built right in. For YEARS. Nobody uses it.

Pointing out that much of what's being asked for here is already possible through the scripting engine. The new CTLD and CSAR available through MOOSE open up tremendous possibilities. We've been deploying Fat Cow style FARPs, airframe recovery missions (Snake Doctor) as well as a fully operational Rotary Wing logistics network for quite some time now. I'm not opposed to ED building some rudimentary stuff in, but you will always get a far better experience with scripting than something from a box. This is why nobody uses the in-sim troop loading, though it's always been built in. For the Fat Cow, after deploying, we use an AI 47 to sit there. It's hard to find a pilot that wants to fly to a location, and then sit there for 2 hours, waiting for someone to need fuel. Now the cargo objects (artillery,scout vehicles, armor, etc) and the FARP ground objects (now the job is done with mods) OTOH, that would be excellent. Some of the other interactions I'm looking forward to creating is having a C-130 Squadron land on a makeshift airstrip, forward deploy four OH-58D's for us, and then have a ch-47 Fat Cow come in and fuel/arm them up, and away they go.

< .... //// - - - *** This might be when it's coming. Better reactivate Bletchley Park.

Hi, we're setting up a dedicated server and are stuck at an error involving netview. Instead of getting a true condition here, it's throwing this error. Does anyone have any advice or hints on what to check? Was caused by attempting to use a pretty old version of slmod. Leaving the post in case this helps someone.

Nice work on this guys. Looks really good!

Absolutely still works great, and also with newest MOOSE version. dcs.log will always show you what's up.

How about supporting Troops in Contact? You will probably want to change the makeup of the enemy to suit. https://forum.dcs.world/topic/286538-troops-in-contact-v10-released-now-on-github/

Honestly any medium or heavy lift helicopter is going to be celebrated like there's no tomorrow. CH-53, CH-47, UH-60, SoopaPuma, Sea King, UH-1Y. This is where the gap is. A fast, Western lift helicopter will close it.

It's not the UN/PW that is at issue here but the hardware ID.

Thanks man, was hoping you would pop in. That certainly simplifies things but brings some other considerations. Does the dedicated DCS even run on Windows Server 2019 or 2022, or does it HAVE to be Windows 10? The license fee for windows server editions makes the cost/benefit no longer worth it. Outside of Azure, I don't see hosting companies even offering Windows 10 as the native OS.

Hey yall, looking for some pointers from others who have set their squadrons up in a fashion like this. We're considering moving up from self-hosted desktop computers acting as BSD's dedicated server base to getting our own Linux server and running 3-4 DCS instances on Windows VMs there. I'm a Linux guy by trade, so I am not unfamiliar with setting up and managing that part of it. I know some have used promox for this. Is there any advantage to it over kvm? I'd prefer kvm personally as I'm very familiar with that. Aside of using virtio drivers, what are some other performance vagaries you've watched out for? If there is any other guidance, tools, or resources you can point me to I would appreciate it. Thank you!

If that were changed to match the coord format the map is already in (e.g. MGRS) it would be a platinum level improvement. But the other improvements suggested are really good too in terms of making them act like IRL. Being able to adjust bracketing rounds in, then fire for effect etc.

This is reaching to extremes in order to position a fringe, edge case as the center of gravity for mission designers. The people commenting on this here ARE mission designers and code maintainers of various projects, and are speaking in general support of what is being requested. If you read more carefully, every single static and unit from EVERY coalition appear this way. It's ABSOLUTELY TRUE that people who actually make missions do not want every friendly, neutral and enemy unit and static recorded in the internal systems of their aircraft, by DEFAULT. There is no credible use case for this. Please, let's allow the thread to get back on track.

Thank you! Is that done in the (unpacked) mission file?

This affects more than the Apache, that's just the easiest example to point out. Which aircraft do you believe benefit from having every single blue, red, and neutral static and unit consumed into their internal systems, and would be harmed by this? I cannot think of a single case. The "Default" we're speaking of here is this - assuming that a mission designer wants every friendly, enemy and neutral static to be automatically visible to internal systems unless those manual checkboxes are checked. Nobody creating missions wants this. The default behavior in this case is literally the opposite of what it should be. I trust ED to determine the best way to handle it.

To be clear, I'm asking for either the boxes to present themselves as checked when the unit is put on the map, or to have a mission level option to apply that to all. It's literally filling up the TSD's memory on the Apache with every single unit and static on the map. It can't stay this way.

This is a key reason why mooti-CRU has been far superior to a single crewed Mi-24 or AH-64D in terms of mission performance, survivability, etc. A person will always be better, but this will help a lot to close the gap. Very much looking forward to it.

Hopefully this one gets picked up!

Sadly I think the Cobra has already been hard nacked. But one can dream.