Pikey

I can only suggest CTLD then controlling them by hand or script on the other side. DCS clearly is trying to "path the impossible". All routing calcs are expensive, but this one perhaps more intricate than the usual and it's perfectly expected when you know how DCS does things. Seems like a limitation of the game you will have to find a different way to resolve, like just spawning them directly from menu when you arrive. To be honest, once you know they got deleted and aren't really in the chopper, spawning them at the other side is no different to what you are getting from DCS anyway.

I've had to rewrite this reply based on me actually trying to save the debreifing and look at it. The issue is multiplayer. I would look at Tacview since it exports many of the events. In MP, the export is controlled by the server, so you might be SOL. However in Single player the events are available to export to text file from the debriefing menu. So it entirely depends on exactly what you want and the conditions of such.

The only thing I can add to the above is that learning is iterative, you can't expect to do it all at once, that is why all people go through a normal process of try>fail>identify weakness>revise>try. What I mean here is that do not be afraid to try and fail, because it is a sim and your health is not at risk, you may find that your existing knowledge get's you over many obvious things that come to you via instinct. Most of the ergonomics in modern fighter jets are designed to be fairly intuitive as it costs more to train and anything complex in combat is very very bad. Things I always do: Never use just one source of materials. Whilst I might prefer RedKite's overall, it doesn't mean I've had the luxury of being exclusive to his channel, he can't cover everything, but a search term can. Cross checking is standard internet practice. Start with learning the start from cold and don't skip it until you can do it unaided, because it goes through most of the switchology so you can then follow up by knowing where things are located. It's two lessons in one. Orientation and naming, and a process. If it's not an english cockpit or if anything is unclear, put cockpit labels on and learn the names of the buttons. Only do keybindings on your HOTAS after you know what is important. Often the ergonomics is designed well for a purpose for common items, but this is a sim and we have to be choosy on valuable switches. It's often beneficial to attempt to keep bindings common across multiple modules assuming they are logical and your fingers remember them well. Whilst learning in an order (building blocks) is the most effective, it might not be the most fun. Learning what you want to or doing it out of order is good if it means you are more engaged, because that's essentially what you paid for. If you never want to touch ADF navigation, that is your call to make. Still, jumping into a specific weapon without knowing some basics might take you longer to learn if you have to stop to bind certain switches, review some other system like stores etc before, but if you want to do thing backwards, it's still valid if you enjoy it, just beware you had that advice and chose to take a fun route and that's your limitation. If you get a chance, doing the process with someone else is faster because the engagement creates more cranial pathways. Showing someone how something works (teaching) is actually a time proven method of reinforcing your own knowledge, help others where you can. You'll find these posts are always bustling with advice because people like sharing and engageing. This is the tip of the iceberg, there are a lot of squadrons who like doing training from 0 (there's a lot that don't too, it's very hard work) But It's better together.

This should work on a group called Stennis and a zone called aZoneName: MyGroup = GROUP:FindByName('Stennis') MyGroup:TaskRouteToZone( ZONE:New( "aZoneName" ), true, 28)end) Note if you ever implement AIRBOSS you need to get rid of this as the two will argue. There are more examples in https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/develop/GRP%20-%20Group%20Commands

Hi Martin, there is not a control for base ownership, it is a calculated result of the ground troops inside an invisible 2km range around the centre that DCS itself makes, so always represents what is actually there. What we do is ask DCS for the blue airbases and take actions there. It might not be compeltely simple if you are starting out and I'm concerned I'd put you off, but the way i did it in words was; Create a spawn object that is scheduled and limited to the amount of units in your group template that you want to appear. Set the SpawnScheduled() to off. Create a SCHEDULER that asks if that airbase is blue and use and if statement if so, to start the scheduler or stop it if not. Here's something i have in my snippets you could adapt: function checkblue(ABname) local tmp = coalition.getAirbases(2) for i=1,#tmp do if tmp[i]:getName() == ABname then return true end end end MySpawn = SPAWN:New("MyLateActivatedGroupName"):InitLimit(1,0):SpawnScheduled(500,.2) MySpawn:SpawnScheduleStop() SCHEDULER:New( nil, function() if checkblue("Batumi") then MySpawn:SpawnScheduleStart() else MySpawn:SpawnScheduleStop() end end, {}, 15, 30) That will keep the late activated template group called 'MyLateActivatedGroupName' respawning whilst the airbase is Blue. I think I did an entire campaign based on this code sample, it's so simple. NOTE: THE INITLIMIT IS SET TO "ONE" YOU HAVE TO CHANGE THAT TO THE NUMBER OF UNITS IN THE GROUP. If InitLimit() is higher than the number of units, then it will spawn again to fill the number, if it is smaller than the number of units, no spawn will happen at all, so before you go creating a large occupying force with 20 units in it, change initlimit or you will have problems. HTH, join the moose Discord for help.

hmm doesn't sound good, I think this would require the miz and log together, I dont have any arty to hand, if you are in the discord frank is online for a sanity check elsewise drop it here.

Let me know if you need any more information. There was a lot more to this than just aircraft and ground units, like moon and affecting any unit including parachutes etc. I presume the comment from merged thread was now redundant about matching track to video? If not, let me know, I have some time.

Not suggesting it's this specifically, but my server has been quite deflated in numbers at a time when there is a lot of free time to play iin the world. Playing with "labels on" any time there is a moon is pretty harsh. We are PvE, I feel for multiplayer with PvP at night, and chopper pilots.. damn, that's horrific man. I love those little chopper pilots on servers, it's like drowning kittens.

Yep, but your settings might be saved so some sound may be turned off. You can turn the music slider up and that would be a good first indication if something went wrong if you dont hear anything.

No need to labour this bickering folks or backseat moderate, or join in! Clearly the OP finds this very obvious which is why he abbreviated the OP as such, we have all been there! :) Subsequently it does need to be defined well as there are lots of similar issues to un-duplicate, so tracks have been provided and the rest of the commentary doesn't add anything. However I will add to the report some findings from looking at this. The imposter dots are exactly the colour of the moon, so if it hits horizon and is orange, that also creates an orange dot. Additionally, it matters not on the time of day, only the presence of any moon, it can be a quarter, half or full, doesn't matter, any moon will do it Moreover, any presence of moon no creates a lot of ambient lighting, but, when the moon is under the horizon or not visible that ambience is gone, leading to very odd dusks and complete darkness until the moon rises and then a massive change to very light. This leads to a very strange environment that goes LIGHT>DARK>LIGHT inside of the hour. Resultant dots on objects also observe that odd behaviour, makign the sim absolutely weird as hell around dusk.

By the way I tested this, it's the same with a quarter moon. At a low moon that is orange on the horizon, all the dots take the colour of the moon, i.e the aircraft turn into orange dots. So it's much more pervasive than not picking a full moon, it's literally any moon in the sky.

:( but I like the moon :( And ED just improved the night lighting now so it's worth seeing! How will I call my leetUberSquadron "the Werewolves"? :D

Actually this track was custom built and smaller and better for seeing the air and longer distance >30nm for ground units settings extracted from logs are: 2020-04-07 06:59:37.562 INFO DCS: options.graphics = { ['messagesFontScale'] = 1.25; ['rainDroplets'] = true; ['LensEffects'] = 0; ['heatBlr'] = 0; ['anisotropy'] = 4; ['water'] = 2; ['motionBlur'] = 0; ['outputGamma'] = 2; ['treesVisibility'] = 6000; ['aspect'] = 1.7777777777778; ['lights'] = 2; ['shadows'] = 1; ['MSAA'] = 0; ['SSAA'] = 0; ['civTraffic'] = ''; ['clutterMaxDistance'] = 1010; ['cockpitGI'] = 1; ['terrainTextures'] = 'max'; ['multiMonitorSetup'] = '1camera'; ['shadowTree'] = false; ['chimneySmokeDensity'] = 1; ['fullScreen'] = true; ['DOF'] = 0; ['clouds'] = 1; ['forestDistanceFactor'] = 0.8; ['flatTerrainShadows'] = 1; ['width'] = 3840; ['visibRange'] = 'Medium'; ['SSLR'] = 0; ['effects'] = 3; ['SSAO'] = 0; ['useDeferredShading'] = 1; ['sync'] = false; ['textures'] = 2; ['scaleGui'] = 2; ['preloadRadius'] = 97800; ['height'] = 2160; ['terrainMapMFD'] = { ['distance'] = { ['mapLodDistance3'] = 200000; ['mapLodDistance2'] = 100000; ['mapLodDistance0'] = 25000; ['mapLodDistance1'] = 50000; }; }; }; dotlabelnight.trk

I posted the same here with a video and screenshot https://forums.eagle.ru/showthread.php?t=268805 This is absolutely a bug and undesired, I think it's actually a bug with some sort of dot only label setting getting stuck, but I cycled them and double checked and repaired. Something as small as an ejected pilot appears for 30 miles brighter than a star. Dogfighting at night is a case of turning off your radar and looking out the window for the stars. As for people that haven't seen this I have to wonder if you actually play the game, looking at ground units at night is like looking at the night sky full of twinkling stars. Its as clear as... day..... no, its much much clearer! In day you dont get dots! I did like cheat mode for a bit, but I've grown tired of it and would like the simulation normal difficulty mode back please ED! see next post for better details & trk.

I repaired and cleaned and the issue remains, the view is excessive like a label setting is stuck.

Not myself. DCS became more hardwork to setup the environment, especially preparing kneeboards and not having pen and paper to hand. The Rift did have me less satisfied with some smaller cockpit avionics and especially the Vipers radar caused me to upgrade to a Reverb after 2 happy squinting years. However now, I can see everything just as well as my 4K screen. Yes... the ammo counter in the Tomcat... Spotting is 1:1 same as 2D. I miss the peripheral vision, especially when trying to look behind me where I miss using my eyebal gimbal due to the facemask, it can cause strain at 47 so I tend to warm up my neck and back before dogfights. Ground targets are always tricky if you dont have some sort of optics, unless you fight at night currently where everything has a silly white dot on it and you can see a car for 30 kilometres in the dark, so, I don't see VR as a visual handicap any more since the Reverb, but I do find it an ergonomic handcap when I need the keyboard. The only honeymoon I can remember was a period of 1 week where I felt a bit sick to be honest.

I liked it. I sat just slightly close to single player, theory and PvP and I'm more of a sucker for process and training and team play, which doesn't fulfill the things I wanted to see. I know you said you want to bolt on "multi-ship" tactics, but to me, the smallest unit is always two. Even in a pvp environment, the principal of PvP and warfare a like is creating an unequal matchup from the outset, so it's fairly fundamental to start with two and begin the theory based on two. Just my personal thoughts, it doesn't detract from the information, but it leaves a bit of a hole in the picture slanting it towards solo theory that leaves you wanting the next part. Herein lies a problem you completely avoided. You made this suitable for multiple audiences. Any next step needs to talk about the wingman, and useful crossover topics like scanning responsibilities, sorting and communications, the crossover into the merge and then you have to tackle this awkward part which is the sole fundament of a very different type of sim enthusiast, which is the Timeline, the process, sorting mechanics, and continue with things that aren't strictly public like split flight tactics and multiple flight mechanics where you have to introduce things like chainsaw that aren't really publicly mentioned that much, because the public books stop about there and it begins to swing into pure PvP tactics, which is very uncomfortable territory to write about on forums. I'll be interested to see how you approach that. For virtual, mainly PvE and process squadrons it's a lot easier because they can simply make up their training and process and take the parts of the AWI and SEM etc and use what they like, then discard the rest that doesn't fit, but what those squadrons do use is a lot of the surrounding fluff you didn't touch on, like IDcrits, CAF, timeline, AWACS integration (because those guys often work with human controllers and multiple flights) and so on. The other side of the coin is where PvP departs from documentary process used in airforces. You hear brackets mentioned throughout older books, but really airforces don't like split fighter tactics, yet the times I've nailed 2v1 pvp with a simple bracket and good comms, practice and a yardstick, I tend to wonder if there's a lot of validity in the unorthodox that simply does not crossover. And that, will make a follow up a very interesting read ;)

Frank does it with Airboss so it's possible, but I'm not sure how to do it, maybe have a look at his class.

The map is in development but they've been playtesting elements for a long time. I can tell it's real because of the players on it. Not sure why anyone would think it's some sort of conspiracy theory going on, it exists and it's not a figment of imagination, hype, marketing or any other silliness, it just takes a long time to do a map and assets, assuming you are doing it in your spare time with a job etc. Quit the drama!

I've done a quick video which makes this more clear. It's worth noting that, the livestream quality of the video is nothing like the clarity of in game with a reverb, as the white dots are dulled by the video capturing reducing the size and colour depth of the scene. So imagine the dots being twice as bright and twice as sharp as what the video shows.

Nighttime visibility excessive (15nm white dots no labels) I've cycled both the mission and the systems labels to NONE to verify, and this is current OB. I do use the VR shaders mod, so everything that follows is really a check to see if that mod has broken something, so please dont take this as accusatory there is a fault, until someone can confirm (please) that this is on a vanilla install or not present by design. The issue is that all objects, planes, ground units, parachutes, ejected pilots create a small white dot that can be seen at night without aid or zoom from over 30 kilometres away, perfectly, unaided. When close up the imposter dot disappears (<1 mile, varies). This means that tank columns at night, from 15nm, or anything really, like a parchutist landed on the ground stick out massively and wreck immersion. Whilst I appreciate some attempt to add glints or vision aids, it just makes tank columns look brighter than distant runway lights and is entirely aritifiicial. Now, you can fly to the merge perfectly with aircraft beneath you, at night, and execute a stern conversion and shoot things with ridiculous ease, or see ground units from 30km excessively brightly and it gets worse because, when you use this imaginary aid for night gunnery, just at the moment of opening to fire, the imposter white dots suddenly disappear with a new lod, rendering you blind just before you fire! In VR, it's actually even more pronounced. I find in 2D the dots a bit more subtle on my 4K monitor. In VR they are most definitely brighter and larger! I'm all for aids, and I think some of the folks out there with poor eye sight should have this as an option, perhaps the labels if this is indeed stock behaviour. Is this a problem with the game or is this something else?

Hi Scifer, SCHEDULER has subtle arguments so that multiple things are achieved with differing optional arguments. But i think it was one of the more poorly documented classes. With the first number argument it runs once after X seconds. With two, it runs repeatedly, with three it runs repeatedly but with a variance. With four it runs as before but now stops after X seconds. Which is much more flexible, if a tad longer for the basic timer. Sure for a single use timer, it takes less characters to write timer lines, but if you were designing that class you would try to get the most out of a single function, so it's just the way it is, pick your poison.

For sure there are more lines to the moose one. But then when you use a single argument it becomes a run once after X seconds, when you add an argument you get a run once after X and repeat after x and when you add another it becomes the same but with a variance. So copy and paste it is :) I can't live without them, in fact if I had a script template it would have a scheduler at the bottom called "Main script", a bit like how I used another language which required a "While 1" in the main body

Don't want to fat shame, but looked... a bit heavy?

Inside a second schedule that runs slightly later than the first (variable schdr already declared): if x==y then schdr:Stop() end