fargo007

Thank you, this is enough of a lead for me to figure it out!

Looking for a method to obtain the cargo status and mass of a static cargo object. Thanks for any direction.

Guys, there are two open bug reports on slingloading with the Mi-8. 1 - Cargos over 5000kg are not visible. 2 - The weight effects of slingloads on the MI-8 are not working. e.g. It takes the same blade angle to lift 4000kg as it does 1000kg. Both already reported.

https://github.com/jkhoel/dcs-mission-intel Found that, but it doesn't seem to be maintained and has no documentation.

Issue #1: Cargo objects over 5000kg will not appear in the dynamically generated cargo list in the radio menu. Reproduction: Place a cargo object of 6000kg (iso container or Uh-1H cargo) on the map and observe that it doesn't appear as a cargo object in the dynamic menu. Reproducible in single player. ----------------------- Issue #2: Cargo weights of the iso container large object do not seem to be correctly modeled. Reproduction: Place a 5000kg iso container and lift it with an Mi-8. Observe the blade angle required. Observed in MP. Example: This is the power requirement to lift a 1500kg ammo container for comparison. You can see they are virtually identical while they should not be:

A big thank you to all at ED who worked to add this functionality to DCS. It seems to work great and is truly a transformation-level improvement. There are five of us in this picture. Very great work gentlemen, DCS is a whole new thing now in many different ways for helicopter folks.

Hi guys, Maybe I'm overthinking this... The goal is to have an "IED" object explode when a blue ground unit is within a given distance of 10-15m. I have a number of red IED objects, named IED-(n) These will be dynamically spawned, and will have unpredictable names. They are collected into a SET_GROUP. I've tried creating zones & triggers in the ME for the explosion, and using ZONE_RADIUS:SetVec2(vec2), and while that DOES relocate the zone (verified with bounding), the ME triggers don't recognize the change. Also tried using detection (from the IED) which appears to be an unreliable dead end road. Is there another high level approach here that you see possibly working? It's already a very large and very busy & frame-rate-taxing mission, so I'd like to avoid creating a 1 second scheduler for each of these devices. Thank you!

You want an awacs to spawn, take off, do awacs stuff and land somewhere else? You don't need scripting for this at all. The AWACS plane can fly for hours and hours. If you stacked three of them up like this you'd easily cover a full 24 hours of running time.

First, CTLD is truly an awesome feat, and Ciribob deserves solid respect for producing it and making it become what it is. We use it as an absolute staple of our operations in every single mission. I don't think you understand what I'm suggesting. Your knowledge quotient of MOOSE would be limited to loading MOOSE at mission start. The same way you do now with MIST. The rest would be navigating the radio menu. Have you looked at the code? As well as it works, it's 100% devoid of any documentation. I don't mean end-user instructions here, but the sort of documentation that a developer would require to understand it. Without this, it's very difficult to unwind how it works when you need to extend it or fix issues. The entire purpose of suggesting a rewrite it is to give it MORE support, more features and an actual development cycle with real documentation that anyone can pick up and begin to contribute with. It could work the same way externally. Consider that: 1 - The SRS project (also critical software for MP DCS) has its own discord. It's sometimes updated multiple times in a single day. 2 - The MOOSE project has its own discord. With dozens of contributors & subprojects. This is where the momentum is. 3 - CTLD & CSAR, as critical as they are to so many, just don't. 4 - ED could very easily break all of this with one very small API change. 5 - When's the last time you saw a new feature in CTLD? Users who took lots of time to unravel it all have contributed code fixes and enhancements to CTLD/CSAR that have been sitting there for almost a full year. Please know that I'm writing this from a position of great admiration for the creator, the product, and the transformational effect it offers a RW experience in DCS. We all love this software and want to see it flourish. I'm doubtful that the present path its on is the one that offers it the most longevity.

Most awesome Sir, it's good to work with you!

How does it work and what does the image look like?

We've discussed navigation, but what about the targeting system for the Ataka's? Any idea what the camera will look like or how it will work?

You'll probably need some mods for this, but as far as DCS itself I'd put some static Hueys with 'nam skins, a Cobra or two, plain green tents... and I would use some music (CCR, e.g.) to set the tone. Or some of the old recordings from AFVN radio. In the absence of having the right stuff for it, my approach would be to keep it spartan. It will look like 'nam until they see an anachronism.

1 - Password protected game master slots. 2 - Undo (Ctrl-Z) functionality. 3 - Native polygonal zones. 4 - Waypoint loop, and randomization for all units/groups. 5 - More accurate patrol boat objects/models (boghammer, etc.) 6 - A native technical with terrorist/insurgent looking guys in it. 7 - Fixed 12.7mm gun positions. 8 - A machinegunner for the red side. 9 - A Javelin, LAWS or other RPG equivalent for the blue side.

PM Sent!

Hey man, thanks for the great work here. I took a look at the code and found it very easy to navigate and extend. Since we're a big CTLD shop, I added three functions/commands in that: 1 - Allow you to spawn in a CTLD extractable group and specify the quantity. 2 - Allow you to spawn CTLD crates. 3 - Spawns a few different types of statics. If you are interested in merging these, LMK and I'll send it over.

No problem, just wanted to pass on some thanks, observations, and suggestions to you. I'll follow the ongoing work with interest. /F

Thank you for the great input and ongoing discussions gents. What's the impact of a large number of SAM systems & units? Any certain type more "lightweight" or "heavy" than others?

I rather appreciated the locker room humor! ;-)

First of all, thank you for the great work on this. It's awesome and I see amazing longevity and potential in it. I would like to discuss an issue and proposed enhancements. Background: We tried using skynet in the context of a persistently maintained mission and found some code & architecture issues. We are using a modified version of SGS.lua (Pikey's). How this works (for background on the issue) is that at a certain time after start, it wipes all the units off the map, and then replaces them from a saved file, which is periodically written to record the units that are still alive. The basic skynet config works 100% with this off the bat. "-ish." It has all the SAM systems in autonomous mode all the time, which is not what we wanted. So we added connection nodes, and other arch-specific attributes to build out a system. The process of doing this is by manually referring to the group name in the script. Okay, all good so far... Then the mission runs a bit, and stuff starts getting killed. The mission is shut down, and restarted. The SGS script restores what was alive at the last save. Some SAM systems are not there anymore. Others are "partially" not there. (nota bene: the methods for including nodes, power sources, etc. refers by name to groups) If those groups don't exist (anymore), or the group is partially destroyed to some extent, it's fatal to the skynet script. Reproduce: 1 - Define a SA-6 site with the radar and 3 launchers. 2 - Add it by prefix to skynet. 3 - Add a connection node to it. 4 - Now go back and destroy (remove) all but one launcher. 5 - Restart the mission and observe the log. What I think is needed: 1 - Prefix based approaches to the ":add" methods (node, power, etc) to remove the need to manually maintain group names. Or an approach by boolean that unless told not to, automatically adds the system to the nearest node & power source if they exist alive within a given distance. 2 - Error handling to account for a partially or totally destroyed system so that it's not fatal to the script. These are basically automation requests that obviate the need to maintain lists of the site's group names by hand if that's undesirable or oppressive. --- I realize that what we're doing may not fall completely inside the targeted use case of skynet, but there is a campaign engine in development and odds are this circumstance would exist there too.

Avoiding the obvious joke I could make here. The number of objects is the single biggest contributor to degrading the frame rate that I've been able to find.

That's a damn great idea man. Thank you.

We're a helicopter squadron, so I use a "Hugh Jass" zone that's the entire size of the combat area. Let's say 10-20K from the furthest point out that an enemy could be.

Just starting a discussion around managing the architecture, construction and design of large missions with frame rate being a consideration. I fly VR, and the stutters ruins the experience for me so I'm hyper sensitive to this. I know enough to know I don't know everything, so let's share approaches. Some very basic tenets I follow: 1 - Minimize moving units. The amount of moving stuff at any one time. 2 - Never use a unit where a static will do. If it's not expected to move or shoot, it's a static. 3 - Object count - There's a threshold where this starts to really degrade. Usually seen with lots of infantry. This is still a black hole to me in some ways, but I know it's there. 4 - Designing large missions with a framework that has only the objects of current interest live. Examples include using MOOSE :InitLimit() / SpawnScheduled() and also using a function based approach tied to radio menu items to launch entire missions, or segments of one. 5 - Stopping big ground formations & convoys at waypoints (hold) when nobody is close enough to even see them moving. Stop condition is a flag that is on when any client is in the area. Interested to hear everyone else's tricks. Cheers! Here's to a smooth, high FPS flying experience. Thanks guys!

Or the :InitRandomizeTemplates(templatetable) method.