fargo007

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.

Nope, and I don't see any way to replicate them either. Bite the bullet and just start plugging them all in man.

Hold R-Ctrl, R-shift, and then keypad / , *, and all the numbers to adjust your center wherever you want it. Takes two seconds to do.

Yeah, it's okay if the error is trapped and isn't fatal to the script (and therefore the server). That's where I was going with it. Thanks again for a great utility here. We are enjoying it.

PKM/PKT's would be better, at least in DCS. Dmitry in the back cleans up while the Kord guy in the Mi-8 never kills anything. :-\

Try using a "once" trigger.

I talked to him in a PM - I think he was observing the default reinforcement time behavior (300 seconds). Seems to be okay now.

Hmm... It would be smart for ED to keep open the possibility of doing a second VP variant later down the road, kind of like what they're doing with BS3.

It seems that the only UN skins that remain are Ukraine's BTR-80 and the Kamaz truck (which is now broken/missing textures). And the UN faction doesn't even have the UN skins.

I don't have channel but I do have Syria and fly only helos 99% of the time. I've got options turned on that I have simply never used on other maps. IOW - it's performing very very well for me. AMD Ryzen 5, 1080ti, 32GRAM, HP Reverb/WMR.

The P is a more recent variant than the V. https://en.wikipedia.org/wiki/List_of_Mil_Mi-24_variants Mi-24P (Hind-F) The gunship version, which replaced the 12.7mm machine-gun with a fixed side-mounted 30mm GSh-30-2K twin-barrel autocannon.

FYI, This is still working in the current version as of today, and it's awesome, but I did find an error,and it stops the server cold with a pop up that must be clicked to continue. 2020-09-26 04:07:30.789 DEBUG LuaGUI: --- onChatMessage--- RED unknown in T-72B killed BLUE unknown in M-2 Bradley with 125mm HE nil 2020-09-26 04:07:30.809 ERROR SCRIPTING: Error in scheduled function: [string "C:\Users\fargo\AppData\Local\Temp\DCS\/~mis0000002C.lua"]:2554: Object doesn't exist I think this one may have been reported in an earlier version so perhaps a regression? local function checkPosAdvance() if self.groupLead then local currentPos = self.groupLead:getPosition().p -- ** this is 2554 ** if currentPos.x == prevPosX and currentPos.z == prevPosZ then self:forceAdvance() end end end A question too - Does anyone have a way to specify the livery? I'd like them to all have 'desert' if possible. It doesn't pull it from the template. ETA - I was able to fix this by basically breaking the problematic call out into its own function and encapsulating it with a pcall() also the schedule pcall which I now don't believe is needed. I ran this hard for four CTRL-z sim hours with not a single error. ... self.destinationIndex = nextDestination if previousDestination ~= self.destinationIndex then self:forceAdvance() else local prevPos = self.groupLead:getPosition().p local prevPosX = prevPos.x local prevPosZ = prevPos.z local function checkPosAdvance() if not self.groupLead then return else local status,currentPos = pcall(getCurrentPosition,self.groupLead) if currentPos.x == prevPosX and currentPos.z == prevPosZ then self:forceAdvance() else return end end end pcall(autogft.scheduleFunction(checkPosAdvance, 2)) end end end function getCurrentPosition(groupLead) currentPos = groupLead:getPosition().p return currentPos end