Pikey

Yessir, They were fixed the previous week along with Ammo renaming ( https://forums.eagle.ru/showpost.php?p=4251512&postcount=94 - March 20th) but I didnt want to moan because this week we got the patchnotes in English and better late than never and they did add them after I suggested it so i can hardly moan :) We had fixed airbases a few hours later than that post :)

There are 8 word callsigns but its 76 flights because you can use Ford 1-9 as a flight. Now each contains 4 possible units, but because of multiplayer messaging restrictions you cannot use the flight numbers in a flight, so the multiplayer method is Ford 1-1, Ford 2-1, rather than Ford 1-1, Ford 1-2. I'd rather they created an API to message and send sound to a client unit than add callsigns so we can actually use the flight numbers inside a flight.

i found the variable name funnier if I am honest!

Is there any German specific information you can share as there wasn't much on the differences across the nations. Also are there any public sources on the PD version of CAPTOR? SOme capabilities, I can only find marketing on CAPTOR-E (CAESAR)

The Houthi in Yemen have been complaining about multiplayer balance for over a decade now.

For AI, there is a magic link with radars. There was an example of creeping up on a Mig from behind and below, but I've never been in a position to execute that on a mission without some other radar giving me up. CAP tends to go wild in unbeleivable ways. AI seems to share a datalink type knowledge. This isnt a documented part of DCS. Turning ROE off is an established way of preventing over zelous behaviour and is used with all its disadvantages in many scripts.

DCS World OpenBeta\Bazar\ParticleEffects\effects The files are there and human readable. You can swap out the png of the particle or play with the numbers. Pick your poison.

I don't understand that code. Can I ask what you are trying to do? Can't you just write schdr:Stop()? Or, just have it stop or run x amount of times with the initial arguments at the bottom?

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/develop/RAT%20-%20Random%20Air%20Traffic/Caucasus Your best approach is to take a sample mission then change it to suit once it makes more sense. Link above, look through them. 1. The files are in the example. Use a zip extractor to open it. Run it first, see what it does, then look at what made it happen. Then tinker. 2. Notepad is fine. Notepad++ would be better for you, depends how long you do it for. 3. Your mission script can contain more than RAT things, You don't need to seperate them out, you can put in as much scripting as you want to in the same script. You can create two scripts if you like, which is sometimes easier to compartmentalise. I think there's more than 20 files on my server, it really doesnt matter.

CAESAR laughs at your puny Jeff budget planes at a quarter of the unit cost. The difference is immense.

It's difficult for us consumers to know what is classified, widely known but the engineering is secret, against permission, breaches trademarks/licensing and so on. If i recall, there was a long post on difficulties another 3rd party had and they had settled on a much earlier, mainly air to air variant. I think it's fair to ask what is off the table for sure, as soon as you can say, and what the module aims to replicate in terms of tranche and block and weapons. Because there was a lot of this type of discussion going on for years and people got quite uptight that X feature wasn't on X aircraft. And these are difficult discussions to have, someone will always be disappointed! Especially around Helmets iirc. Like what helmet might we get? Striker II? . That stuff gets people excited.

I never asked for this because I never thought that we would get something like this. If i'd have known I'd have been crying about it weekly. This is amazing news. I wonder what tranche because if I think back to the VEAO forum days there appeared to be a lot of issues with restricted information in the later tranches and early ones were A-A only with a pulse doppler radar rather than the later AESA ones. Which, has to be something ED might find easier to incorporate, I imagine an AESA radar is easier to simulate and guesstimate, but it would certainly put the cat amongst the pidgeons because an aesa radar would literally be unfair when played in multiplayer. _Runs off excited to check deeper and predict the tranche_ >>

try the modders forum. The people here are less knowledgeable. I dont know myself.

OK on to the VR stuff, brought ahead slightly rushed, I narrowed down the modules I looked at to the top and bottom performers and took screenshots of the in game FPS, the Nvidia overlay and FPSvr tool. Same mission. The FPS results are broadly in line with the way 2D presented, except the Hornet fell down a bit in relation to the top and bottom performing modules. I believe there is a change in performance when switching module, that is most likely to do with textureloading/memory, so take that into account. However the data still shows the 2D>3D relationship and gives a very good idea of 1. The VR overhead 2. Module differences (significant for VR users) 3. Direction of view and link to terrain 4. Something new - CPU frametime on look direction The 2D and 3D FPS timings showed relationships on module performance. Just looking at the best performing and worst (best being C-101 and worst was JF-17, with Hornet middleground and A-10 being lowish) C-101 2D: 120FPS, VR: 52 Frametimes both in the yellow. The data point I have great interest in is the sideways look (the picture attached looking right the 45FPS top right) Something I cannot explain is the CPU frametime peaking and going up. Why? Returns to normal when looking forward. A difference of 5.5ms 16ms framtime compared to 21ms. Same plane, it was faithfully repeating this and all planes did. JF-17 2D: 80, VR: 36 GPU frametime is now in the red, 25ms for the majority of the time, thats 6ms higher than the C-101 or if you like percentages, FORTY PERCENT difference. Why? GPU went down when looking sideways, CPU went up to nearly 26ms. Why? There's only two things I know for sure from this. Modules are very much in play with the VR differences and both CPU and GPU interact with looking in certain directions. Points that aren't easy to absolutely say for certian, but GPU appeared to be much higher on planes with complex instrumentation when looking ahead. I'll get back to work proper, but have a look at doing this properly this evening. At the very least I discovered which modules perform better in VR.

Correct, VR was my next step, but it has a CPU and graphics overhead. So the 2D is your "never will be exceeded numbers" and it's always been at maximum half of those numbers, there is a relationship, it's just not as simple as "/2" but it is useful for working out what you might achieve in VR and where issues arrrive before you add the complexity of VR on top of the configuration. And it's very much close to /2 for me, I can say that I can see where my 45FPS comes from in single player, and how I get less once you add it to MP. If you see less than 90 FPS you know you will begining to see less optimal numbers. Additionally, there is a Multiplayer overhead for some unknown reason, probably due to pushing the network cards offloading to the CPU as well. Your optimisation must start from the 2D, because it's the same scene being rendered twice and the simpler that is, the more overhead room you have for VR. Of course, its not the same, but most folks using VR will know how much it eats and have loaded up in 2D to tinker with settings. And I will do the next step, but I began here and it took so long to do the basic data to compare against, I thought I'd share early, as well as a personal reference. Also +1 for a standardised benchmark tool or even scene/mission. Even without a "tool" per se, just the process to be followed could be settled on for now.

Perhaps I'm lucky with a reasonable card but I don't find DCS "unplayable". Nevertheless I've followed this thread because all VR fliers want more frames. I went to try some FPS tests and only got as far as recording 2D FPS from a running hot start at Kutaisi looking south. I was surprised at the variance in modules so I'll provide them. I rounded the numbers by eyeballing them, they fluctuate. Jeff: 80 (75-85) Harrier: 102 Tomcat: 102 Viper: 98 Mirage: 97 C-101CC: 120 A-10C: 95 (tried about 10 times and discovered the FPS take a lot longer to come up in the A-10C (55 at start sometimes)) Mig-15: 116 Fw190A-8: 109 Mig-21: 110 F-18: 102 This is using the stock default 2D forward view and not budging it. All on the north ramp facing the same direction. I picked Kutaisi because it's somewhat notorious. I then did airborne flying tests up north of Mozdok with the best and worst performer: A-10C: 120-135 C-101CC: 160 Remembering VR gets half of that at best, there's already significant module to module and location difference. But the real takeaway is where you are looking and how much CPU is going on. The GPU, is unthrottled and mine runs at 99%. The CPU steps up from 3.30GHz to 4.45GHz reliably every time, this is in 2D on less screen real estate. Mid way through the tests my legs had warmed up, the fans were at full revs and I started to consider my hardware lifespan and the money it might cost to replace! Given my GPU runs with no vsync for the test, the map view during the mission gave me 170-180 frames, that was the ceiling. The CPU however was still trying to push more with nothing in the mission. When I added units I expected frames to go down. Not so, a blip of a shudder when 16 planes began dogfighting and a ship and three sam sites began to get involved but the GPU was still gettting everything, and the only indication was the increase in CPU from the AI. What is far more telling was where you 'look'. I started thinking there was no GPU issue, it's running as it should but I looked around the cockpits and the big changes occurred. Looking up into the blue sky I hit the F10 view cap of 180+ frames. Looking around certain places were eating frames unexpectedly. I always thought CPU bound and AI as the cause was the first limit, but there are more complex things going on with the terrain being the chief use of the frames. I provide no analysis, just the experience and data. Hardware CPU: i5 8600K @3.60 (no OC, air cooled), RTX Nvidia 2080S (only 8GB mem), RAM: 16GB, Drives: DCS is on an NVMe, C: on a SSD, VR: HP Reverb, Peripherals: lots of irrelevant stuff DCS config (current 2.5.6) System: T: high, TT: Low, CT: Low, W: High, VR: High, HB: Off, S: Flat Only, Res: 3840x21260, AR: 1.77, M: 1, RoCD: 1024 Every Frame, MSAA: Off, DoF: Off, LE: None, MB: Off, SSAA: Off, SSLR: Off, C/G: 1500, TV: 80%, PR:100000, CSD: 1, G: 2, AF: 8x, TOS: Flat, CGI: On, MFS:1.25, SG: 2, RD: Yes, Vsync: Off, FS: On. VR: PD: 1.0 Mirrors: Off, WT: Off, Simulation settings for all else. SteamVR: · 90 MHz · Per App (DCS): PD: 1.0 · MS: Always On · Legacy Reprojection: Off · SteamVR Developer mode: · Disable Power Management applied Additional Config · VR shaders · All shaders (not just fxo+metashaders, but terrain too) were blasted · VR shader mod applied · Drivers: 442.74 (3/19/2020) · Nvidia Control Panel (acting up but iirc I did look ahead frames to 3) Feel free to use these results and mission to provide actual data to the thread. There's a real shortage of quantative testing showing data in this thread, most of it is just using words like "unplayable". The miz activates a bunch of AI after 30s, just so you know. Useful for before and after comparisons. FPStest.miz

SimpleStatic Saving has been reworked as per 2nd post. I've fixed unit headings in SGS also. I wanted to scribble my mad findings about statics as it's taken me the best part of the entire day to workaround the seemingly endless issues DCS has. But I learned something worth sharing. 1. Farps. Jeez-Ohh. Farps (and rigs), as statics refuse to obey normal DCS static conventions in some of the methods you can use on them. In this way, I found it better to treat them as Airbases, since they reliably work in that manner. I've now excluded them fairly easily from attempting to be manipulated by checking if the name of the static is also an airbase. Mad scientist workaround, but its perfect. Farps and Rigs will not be touched. I've never destroyed one either, but just know that the script will not persist farps, or try to do anything with them. This means they stay in all of your missions through restarts. Which is what you want. 2. Other statics like "Effects". Effects like Bigsmoke are fairly new to DCS and do not observe all of the characteristics of other statics. They are always dead, getDesc() and other requests for type, heading do not work, but they end up included as a Static by moose. I've filtered these with nil checks also. 3. Ships For some reason ships always return that they are alive when asked. This absolutely puts the kaibosh on this script and there is nothing you can do about it either. I'd recommend only using ships as static units when you are decorating and couldnt give a rat's arse about their persistence. Statics will always work as cheap alternatives and visual fillers very nicely so are important because scaling multiplayer missions is vital. However ships are one to avoid for statics. 4. Cargo was fine and I tested the "Barrage Balloon" in the assets pack too. You have to remember that not all statics have a destroyed model. So you can bomb the DCS airshow crowd all you want and they will carry on cheering. The other issue to touch on is the error that occurs when a static object is spawned. I use the core scripting method rather than SPAWNSTATIC because it's the only way I can spawn a dead object. I have a feeling FlightControl hated statics with a pasison and they litter moose with SET issues, filtering issues and bugs, just by the nature of them having had bugs and quirks. The error is caused when the event handler for the birth of a dead static object is attempted to be added to the MOOSE DATABASE. It's a lot of error lines in the log, but it's entirely of no effect to either the game, Moose or the progressing of the script. Moose just can't deal with it because there is a missing index on the birth event, probably caused by the static itself being missing something from the event data. I'm choosing to ignore it for now as fixing it has no benefit to anyone once they know what it is. However, I've written code comemnts so you can choose to comment out the part of the script that replaces live statics with dead models of itself after a restart. If someone knows what they are doing, then they might have a care to do that and can. Someone that doesn't understand the error message, has no reason to ask how to remove it, since they should have read this or the known issues part and would also have desanitised their mission environment modules and are likely a danger to themselves and others with the copy/paste shortcut.;)

Same question. The video shows a launch configuration. How does the carrier get into recovery mode and clear the little men out the way?

Fair point on the tone of the message above yours, but, it might have been better ignoring it and spending the time you spent responding on saying exactly what is wrong? With data, with a track or mission to reproduce. It might be something in the mission, the location and the terrain, an object, it might be something explainable, since others don't have that issue, and I can certainly view the Yak model and don't have any framerate drop when looking at it. I find in 2D all the modules are within 10% of each other for frames based on a look at more than ten types of them as I was recently doing some FPS tests and checking precisely that. Even a quick video, all cards come with basic free recording software and YT is free, but I'm left clueless with no data to work on as a reader wanting to help.

I get this sometimes when swapping aircraft or reloading the cockpit. It is literally half the frames, but in VR, we are half your frames of 2D so it's a big issue. Restarting the game usually fixes it, although sometimes getting into a fresh cockpit works. I haven't worked out why, I just assume something didnt initialise correctly or some memory was exceeded or texture memory or something.

Good work. One comment, if I may on the RWR. This is an internal DCS behaviour and has been for as long as I can remmeber. If you get any RWR lock on any aircraft, it's only switched on or off in "heartbeats". This means, the RWR will continue to signal a lock, even though the targetting aircraft has since died, until the next heartbeat, when it will be checked and turned off. You can see this in action with Active missiles that fly past you and continue to lock you, firing their radar backwards. You will also see it when you terrain mask. The mountain may block line of sight, but the lock remains until the heartbeat fires again. It's strictly a DCS mechanic and a cheap way to simplify the lock received. I believe its about five seconds, at least I can reproduce that time frame consistently for many years when ducking behind cover. Once i understood what was going on, I relaxed a bit, but yes, core DCS issue.

The reasons it doesn't happen often are many. - The basic unit is always two ships, solo flying doesn't happen, a wingman is required for every flight for many reasons. It's the same in infantry, the basic rifleman is always buddied. The wingman's role or at least the pair's role is that they execute the same thing with two hands in concert in order to be effective at that one thing. Split flight tactics are super advanced and not readily undertaken. The idea that if you are doing the same thing... you wont be kitted for different roles. So essentially you describe two flights that have lost a wingman and joined up together. - In the real world, technology fails. In the sim world, DCS doesn't fail your radios, radar or many of the expected situations that exactly taking a wingman can cover you for. - Squadrons, which derive the mission plan and purpose the planes were airborne in the first place, are of a single airframe. Squadrons aren't mixed because of cost, training and engineering complexity. If two roles can be accomplished by the same airframe and are required in the same mission, the flight joins another flight in a package. - Getting two squadrons working together would be put behind getting the first squadron operational and working. The military find this difficult, we find this much easier as our bureacratic restrictions are minimal. - Multiple roles in one group are called a package. So by definition of your example, it would be a fourship (with no WM). Dissimilar fourships might exist, uncommonly though. I do recall a story of a 4v4 DACT with Brit and US fighters, where the Brits had 2 Tornados and 2 Hawks working together. You could call it a dissimilar flight or a package, it likely doesnt matter, but they operated in their role and airframe with wingmen, in concert. Now, exceptions in wartime or complex training might exist, but generally the package concept is driven by existing doctrinal standards as a multiple role group of aircraft. It's simply more about understanding that the smallest unit that ever should be considered is a two ship, and not a singleton. It's not a fantasy in a simulation, to create your own airforce, doctrines and whatever, it's valid and fun. On your OP though, you've applied mixed logic. You applied "cost" in a sim, with sim logic of not planning and taking a mixed bag of tools because you have no idea what you are fighting. Pilots don't do taxpayer math until they are laughing in the bar. They apply the mission first, IDcrit, ROE and shoot the weapon that is the most effective for the job (albeit it is doctrinal to release one slammer per aircraft on a single engagement, etiher both by the lead or one each if the SA is right. Either plan for the flight to do one task well, with a light load and use the wingman, or, just accept you aren't trying to fly to generally accepted lead-wingman basic concept, which is fine, in the sim world because you can do just that and I believe it's more viable in the sim world because the WM-Lead relation is less powerful by virtue of low or no risk factor (you simply dont care if you 'die') Bad visual SA, impatient players who don't like watching out for their lead and have to shoot something or go insane, near perfect avionics and technology with no breakages and similar stories that erode the 2 ship cornerstone.

My parents are in their mid 70's fairly healthy, but obviously aged immune systems. They are supposed to be living a nice retired life now. They are afraid of this. It's also very hard to fight for food and negotiate the new world as it is today with all the restrictions. Myself, I'm more scared of the economic impact. I rent, I will most likely lose my job this summer, a job that kept me as a remote worker which was great for being with my family. My wife had pneumonia once, she said it was like drowning. I'm not looking forward to that, but it's keeping the family afloat that really worries me. My son is 17 and doesn't care a crap about anything. He's convinced he is immortal, doesn't think of others or infecting them and has welcomed the longest summer holiday ever from his room, attached to the internet, wasting his brain. There is lot to be worred about, whether it's losing your job, business, family, house, freedom, access to the things you like. But the real change in the long term is how we all have to get everything back on it's feet again, which is going to take the best part of this decade to solve. Next job interview you have, ask how they treated their employees during this episode. I know my employer couldnt give a rats arse.

It's threads like this I wish there was a type of "match-making" app that can sort people by Geo, time and topic - pve, pvp, training. I wince at folks being unable to find someone online in a relatively small community, knowing that learning with someone is the fastest and most rewarding benefit that DCS has to offer. Surely, in this day and age there is some way to make this process smoother? I've offered countless times to do 1 on 1 on the broadest of topics, and I never got any pickups.

Real pilots don't attempt 180's and J turns with A/S off in their Hornets since tyre wear modelling in real life is far more accurate than DCS ;). But due to the stable nose gear double wheel, I can reliably lock the wheels and spin the Hornet, you need 40kts. Don't try it on the Viper though... Type screeching and skid "feel" doesn't come through the handling of the sim. You simply don't feel it like you would on a driving game with forcefeedback. It's far more reliable to check out the long black wavy line down the runway to find out if you had A/S on or off and what it does.