robgraham

This bug appears to still be happening, we wasted an hour just now trying to launch Mav's doing everye thing under the sun.. Mav's can be Tracking a laser and refuse to come off. It's annoying.

Not talking JESTER we are talking the KNEEBOARD Datalink page you know the one you use when your a RIO, that is extremely limited and not done by proximity etc. It shows carriers, then Burkes etc etc etc hit shift K and go look on that mission and see the mess that it is. Not every one flys with Jester, some of us fly with humans and right now you can't if there are enoguh ships etc around find the AWACS, there needs to be a way to cycle through if there is more then one page of Datalink contacts especailly given LOS seems to impact the Datalink. And just to show what i mean here's proof. Magic 11 is a E-2D AWACS should show up doesn't. So if your a HUMAN doing the work you can't enter it because you can't find the frequency. Previously it was Carrier, Then AWACS, then Other Datalink providers, Now it's Carrier and it's group, next carrier and it's group etc.

With the latest set of patches etc the Datalink page on the kneeboard now shows every boat in a fleet as a datalink source, this is great except that you can't scroll beyond the page shown.. So if you've a full fleet of ships etc you can't find the AWACS Datalink freq's as they aren't visible.

99.99% of what you've asked is in the SPAWN command but to make this easy... awacsgroup = nil -- this holds our awacsgroup if we need it at anypoint. -- create our spawner. myawacsspawner = SPAWN:NewWithAlias("myawacsgroup","Overlord"):InitLimit(1,99):InitRepeatOnEngingeShutDown():InitCleanUp(600):InitRadioFrequency(252.00):OnSpawnGroup(function(spawngroup) awacsgroup = spawngroup -- store our spawnedgroup into awacsgroup so we can interact with it if ew need to. end,{}):SpawnScheduled(300,1) You'd need to do a task push to adjust altitude and speed.. and well the moose documentation has more then enough to help you help yourself.. but to explain the above.. your creating a variable called awacsgroup to store the spawned group later in. then your making a spawner in that spawner your telling it to spawn your template group with an alias in this case Overlord, Then your saying I want 1 group active at anytime and a maximum of 99 groups allowed to spawn during the mission run on destruction etc. Then telling the script to automatically repeat the spawn when the aircraft lands and shuts down its engines. Also clean up the spawn if it's idle/unable to do anything for 10 minutes. Set the Radio Freqency to 252.00 Mhz. When the group spawns, capture that and run the function, where spawngroup is assigned to awacsgroup. This is also where i'd do the task push if i was doing it.. but i'm not writing all the code, because helping ones self = best way to learn.. or asking on the discord ;) Finally schedule a spawn attempt every 5 minutes (300 seconds) with no randomization. What you should see is at 5 minutes a awacs load in, fly the planned route, land shut down, despawn and another start back at the start point.. IF the AWACS is shot down, 5 minutes later it should respawn in up to 99 times.

would also love to see these api items added as one of the servers that uses Overlordbot a LOT.

My issue with this being 'as intended' other then it not being well correct. is that there is an Incockpit Handbrake specifically for the reason that the airframe does roll when at idle.... and the extra thrust required to overcome the friction that shouldn't be there = extra fuel load that shouldn't be being burnt during taxi.

Ah To be fair my other thread didn't just pop up Stal2k I pointed Newy to it and I posted it over a year ago, it has a lot of extra info in it that I thought might help given that this post now exists. Thing is people need to take a step back for a moment, there is a very real chance that part of this is being driven by a time out caused when the vram gets dumped etc which means that peoples graphics settings, actual systems etc could play a very big part in all of it. What I've had it happen on some one with a 2080ti might not have it happen on, what your reporting etc I might run and never have an issue on, steps are all well and good but if just doing the steps isn't allowing some one to reproduce then you need to start breaking things out a bit more and again look at: 1. What are peoples System Spec's? Specifically - Video Cards (and VRAM amounts), Driver Versions, Windows Versions, SteamVR Builds etc. 2. What are peoples DCS Graphic settings when the issue occures, does REDUCING the settings IMPACT how quickly it happens, does INCREASING the settings. Getting graumpy at each other when all ppl are wanting to do is help and or get help isn't helpful.. I get that it's frustrating, I know that for me I have had it personally happen after a hour or so in the F14, F18 or another high detail ac and then hitting F10 and boom i'm out .. But then I adjusted some settings etc recently and its occurence rate has.. Dropped on me, I can't say fully what I've changed because tbh I've played with a few settings. The steps as I understand it that ppl believe will reproduce from those of us experiencing it are: A. whatever rigs we are running (mine is in my sig with a NVME needed to be added). B. whatever our dcs settings are. C. whatever our VR settings are. then 1. Running DCS in a mission with a large amount of units and or memory use. 2. Switching through views that cause items to need to load/scene changes to happen. 3. Eventually at some point Steam VR will encounter an error leaving the user with the following symptoms: A. SteamVR window states "SteamVr has encountered an issue/error". B. If your in WMR you get a breif flicker and or blue shifting zone.. then you go to a black screen with nothing. C. The Window on the Desktop of DCS will still have DCS RUNNING, Were you asked it to be in VR mode, your likely to still have headtracking etc.. but no vid on your HMD. D. Due to Steam not allowing you to simply 'reinitalise' your forced to close steamvr and thus DCS, restart and symptoms go away until you do step 1. The issue here is and please take a breath, there are Multiple areas where this can be happening... It could be DCS itself (which is possible... based on the logs that I supplied a year ago and back earlier this year) that it's going into a state where it doesn't communicate with steamvr's server just long enough for it to time out. It could be SteamVR/OpenVR having issues when large amounts of memory are in use. And for WMR users it could be the steam - wmr plugin as well. So while it's frustrating etc.. and i get it's frustrating the more info ppl can give and having paitnece while Newy etc pass that info on.. the more chance there is that the exact things needed to get a Dev to reproduce can happen.. That is what Pikes is trying to explain when he's asking for steps he can't reproduce it currently on his system. So maybe give him some more info on your settings etc.. I've handed over mine elsewhere.

Can I offer a suggestion as well, those whom are having this happen: Post not only your steps to reproduce, but also go and get your STEAMVR logs and post those as well, when this happens, as these give the steam vr client side of what is happening and might help.. also post your DCS settings and PC settings, SteamVR settings etc. I've hazarded an opinion privately that it's due to a time out likely happening when the scene changes, but with out it being able to be reliably reproduced its very hard for any programmer to ever look at it.. and I mean I've had the issue myself.. The Steam logs you can find here normally: C:\Program Files (x86)\Steam\logs you'll see a bunch of vrclient_xxx.txt and vr_vrcompositor.txt, vrserver.txt files.. these are the logs for steamvr. but again as pikes, newy etc are all pointing out and there not being condecending etc they really want to get to the bottom of this, with out repeatable steps that testers and programmers can get to happen and system info etc.. driver versions, (Dxdiag report easiest way here) it's kinda hard for it to be solved if the issue can't be caught on a dev machine.. and Trust me I've had this happen for 2 years and I can't even reproduce it all the time. so I get their frustration.

There is pro's and con's to both sides of this and arguments that can be made on both sides and seemingly confusion on what/why/how lmits are set and people going 'no its not' to information that is correct. The Limits set in the flight manuals are typically anywhere from 1.25 - 2x's lower the the maximum amount of G forces the Aircraft itself can pull case in point the Viper can and has been recorded even by it's General Dynamics creators as being able to go above 9g's but 9g's sustained was set for a few reasons the same reasons that go through for each and every aircraft namedly: 1. It's extremly hard on the biological component of the system ie the pilot, a lot of the G limits especailly in modern aircraft are actually based on this, the G load changes greatly depending on the size of the aircraft due to the moment of movement around the center of gravity, (this also has an impact on 2 below), some AC have hard limiters in them specifically for this reason the Viper is a great example of this, the Jet can and will go above 9g's. 2. Life expectancy of the Aircraft based on the Materials used, the size of the Aircraft etc. Every time in real life you pull G's your putting stress on the materials of the Aircraft and because no production manufacturing is ever 100% perfect and materials all have stress limits etc this puts a lot of stress and strain on said components greatly increasing the fatigue loads and limits of the AC itself, until such a time that the material fails. This is compounded by the size of an Aircraft vs it's Center of Gravity in moments of movement something a lot of people don't actually realise at all is happening.. Your Aircraft is not seeing a 9g turn at 9g's across the entire airframe, various parts of it actually experence different amounts of G's dependent on the size and angular velocity of the entire aircraft, the G meter simply records it normally at the point that they expect it to be the highest but you also have to remember that with G wing loadings also become extremely high which is why 'ripping the wings off' is normally the biggest issue with pulling excessive high G values. What that adds up to though is over time fatigue cracks forming typically in the main spar and keel of the airframe but also in many other systems, which in real life causes 2 major issues. 1. Maintence time goes up significantly as aircraft require more checks per hour flown to make certain nothing has broken. 2. Eventually the Fatigue amounts vs the safety margin set by the aircraft manufacturer reachs a point where the 2 meet, accidents start to happen and an aircraft is retired, great example if you want some real world ones: The F111's, their wing spars, keel and root boxes had over their Australian life time taken that much punishment that even after replacement of many of the actual wings it was deemed safer and less costly to retire the fleets then to try and repair them. So how does this essay impact the G limits? Manufacturers set a Bold Face Limit based on how long they expect the aircraft to be in service and how good/bad they expect their materials to hold up against the punishment, beyond those limits they don't 'promise' anything.. There have been cases where Hornets have pulled well of there 7.5G limit and then had to be written off, and any one thinking that the G pulls don't have an impact on aircraft afterwards has never ever been up in an Airforce trainer! there is a reason they don't ever seem to 'fly straight' because unless their fresh out of the factory chances are that some students bent them up really good. In game it would be nice to see not a 'hard' limit modelled but actual simulation of G force issues on the aircraft, Heatblur actually did a really nice job of this in the F14 and it would be nice to see it continued in other aircraft where: 1. Minor short over-g's have no effect as again there is margin in the #'s specifically for this reason. 2. Longer low over-g's can leave systems like Gyro's etc messed up and not functioning correctly, stores might start to hang as they've been over-g'd on their rails (another reason for G limits), MFD's might fail, you might get a FCS fault as somethings come loose etc.. 3. Continous excess high G's start running the risk of Wing root failure and or keel failure (The root is likely to fail first btw as it's got the highest load on it at any given time) In the end though DCS is... as much as people don't like this word a 'game' even if it's a simulation.. it's still an 'entertainment' product, there are and will always be fudging of some things simply because you can't always do what is needed on the scales needed and have an entire region simulated etc. ANOTHER option though which can be done is that Mission/Server owners simply run a script that checks every CLIENTS G loads every second or so and if it exceeds a value they either destroy the unit or kick the player to spectator etc.. it can be done, of course it'd be adding more checks on scripts that at times are already extremely complex. In the end though if it's a SERVER option like wake turbulance etc I don't get what the 'argument' is other then the 'how' of it being implimented which is what I think the back and forth is over here, as some people seem to want just a hard arbitory if you go over this your dead (which sorry isn't how Material sciences work..... well unless your pulling like 14+ G's etc constant) and others are saying 'Yes, but make it REALISTIC'.

Aren't 100% certain what caused this as there were a few events happening at the time and I had tracks turned off (log etc is attached but.. ).what I know happened is that I moved in Game Master slot into a M113 and dcs locked up and crashed out to the reporter. Log simply reports it as a weapons.dll access violation zip attached. dcs.log-20200829-135733.zip

Title says it but I've noticed that on Multiplayer I can't get the link 16 to work for 'INTRAFLIGHT' setup UNLESS I set up the flight as 2-4 ship flight 'group'. If each client is set up as it's own group then no matter what we seem to enter into the Link 16 data the most we get is the Radar information and the 'Green' MIDS datalink, not the BLUE flight data link information. So the question is is manual configuring of the Link 16 datalink actually working in multiplayer properly? Steps we did: Spawn in Hot birds. - Make certain Mids was 100% in the 'On' position List - Enter to bring up Link 16 page. Dobber Switch to get to P2 On ALL AC: FC: 001, MC: 001, SC: 001 On Lead: ED11, FL YES, XMT: HI On #2 ED12, FL NO, XMT HI on #4 ED13, FL NO, XMT HI Dobber Switch to get to P3 List was #1 00201 #5 00205 #2 00202 #6 00206 #3 00203 #7 00207 #4 00204 #7 00210 with lead set as OWN #1, -2 set to #2 and 3 set to #3 On all AC the HSI XMT was set to L16 No blue Flight Numbers at all. Is there a step missing or is something not working ? I know with the IDM i'd have to do the Long Press on the IFF OUT so CONT was boxed but I didn't think that was required on the L16 version. And both the chuck guide and wag's videos etc don't seem to mention a step that has been missed. I even checked the HSI CNTL to make certain that everything was highlighted as it shoul dbe.

Order 4130 Arrived today thanks man.

Title says it all, the CMS system isn't working if SIM is boxed even if the Master ARM is on, believe this is tied to the strange idea that continues to exist that the Hornets ALE requires the master arm to be on, however even with the Master ARm in the ON position the ALE system will not dispense even in BYPASS if/when SIM is boxed. This is a bug and incorrect, as it is quite common for CMS despensing to take place during SIM boxed ACM etc (normally with training CM's in the dispensers). Steps to Reproduce. SMS - Box Sim. Master ARM - On ALE - Bypass. CMDS - Either. Result: No dispensing. What should be happening/Expected: Flares/Chaff should function as normal. Also another point as to why the CMS is not tied to the Master Arm.

Can confirm this one track attached. azimuthbug.trk

So I bit the bullet on TGW's server and rolled us all back to stable and we all instantly noticed almost a 20 - 40% increase in performance on our machines measurable in both Monitor and VR, but not only that there is a significant increase in the server side reported FPS if your using something like Tacview to monitor said performance. Here's just some things we noticed performance wise over the last 4 weeks or so... Prior to the SC dropping we saw server frames of about 70-90fps base line dropping over time down to about 60fps with a lower limit of 40 on our 'heaviest' mission at the time. (Red Iberia). When what is now 'stable' dropped that jumped with 119/120 being the 'baseline' fps and the lowest being 70fps. At the same time on my own machine I was seeing 40-100fps prior to stables release but often with extremely large frame time 'spikes' on monitor and well VR wasn't useable half the time as bowwave would crash out. With SC release frame rates went back to 60 - 120fps monitor and 30 - 60 fps on VR. There is still almost a 'stutter' in frame times every 12-20 seconds but it's not a 'major' stutter.. The releases in open beta after SC however saw all that drop rapidly again, I don't know if it's the radar, if something is messy with AI or what but something is defiantly causing a perf hit that impacts the GPU cycles on machines running GPU but also the reported 'frame rate' on servers.. as at times our server frame rate was falling to as low as 24fps and we were actually forced to stop running 1 mission all together due to the performance hit. Worse the frame times are not anywhere near smooth which makes drops in frames even more noticable. Wednesday we rolled back to Stable .. and with out any changes to the missions we are running instantly we are back at the 100+ fps rates on the server and the smoother frame rates in clients. If I was a gambling man I'd almost place bets on it being A. The Radar code changes. B. The lighting code changes. C. fixes to AI Routing. I'd lean more towards A and C given that C has had this type of impact before in the OB release 2 prior to the Super Carrier and with A we've no idea what is actually being done server side etc if anything or client side to drive all that.. Though we saw all 3 items drop at once so it's hard to work out what caused the impact. Just my 2$ to the discussion.

Frames this latest OB are.. ugly, and not just in the rates, the frame times are a MESS rather then nice smooth frames you can actually watch visibly the frame time spikes happen and seemingly for no reason at all. The Perf is the worst I've seen it in a very long time.

Same, radar is busted as hell, who the hell tested this :(

This issue is still happening, seems to be any time there is a large amount of memory in use and then DCS is asked to 'change' the scene. from tonight Wed Jun 10 2020 19:57:28.952 - [system] Prepare operating system environment Wed Jun 10 2020 19:57:28.952 - [system] Setting power settings to minimum power savings. Wed Jun 10 2020 19:57:29.172 - [system] Transition from 'SteamVRSystemState_Off' to 'SteamVRSystemState_Startup'. Wed Jun 10 2020 19:57:29.349 - [system] Runtime: 1591675834 250820 STEAMVR Wed Jun 10 2020 19:57:29.669 - VR_Init successful Wed Jun 10 2020 19:57:30.357 - [steam] Attempt to connect to Steam Wed Jun 10 2020 19:57:30.361 - Add Json firmware manifest from {htc}/firmware/manifest.vrfirmware Wed Jun 10 2020 19:57:30.361 - Add Json firmware manifest from {indexcontroller}/firmware/manifest.vrfirmware Wed Jun 10 2020 19:57:30.362 - Add Json firmware manifest from {indexhmd}/firmware/manifest.vrfirmware Wed Jun 10 2020 19:57:30.362 - Add Json firmware manifest from {lighthouse}/firmware/manifest.vrfirmware Wed Jun 10 2020 19:57:30.363 - CSharedResourceNamespaceClient::Init(): received namespace data 22292 Wed Jun 10 2020 19:57:30.363 - [Audio] Audio init Wed Jun 10 2020 19:57:31.465 - [status] Graphics driver version is 446.14. Wed Jun 10 2020 19:57:31.840 - [system] Transition from 'SteamVRSystemState_Startup' to 'SteamVRSystemState_Connecting'. Wed Jun 10 2020 19:57:31.846 - [steam] Connected to Steam in 0.09 seconds. Wed Jun 10 2020 19:57:31.847 - [system] Runtime: 1591675834 250820 beta STEAMVR beta Wed Jun 10 2020 19:57:31.847 - [steam] Connect to Steam finished: check for dismissable warnings Wed Jun 10 2020 19:57:31.858 - [system] Transition from 'SteamVRSystemState_Connecting' to 'SteamVRSystemState_Ready'. Wed Jun 10 2020 19:57:33.720 - [Dismissable Warning Added] DismissableWarning_SteamVRUpdated https://steamcommunity.com/ogg/250820/announcements/detail/2244428724301905326 1.13.1 Wed Jun 10 2020 19:57:38.967 - [system] System is running for 10 seconds. Wed Jun 10 2020 19:57:39.501 - [status Warning Added LHR-F94B3BD8 Controller(2)] Searching... Wed Jun 10 2020 19:57:39.501 - [status Warning Added LHR-F94B3BD9 Controller(3)] Searching... Wed Jun 10 2020 22:28:28.815 - [system] Transition from 'SteamVRSystemState_Ready' to 'SteamVRSystemState_NotReady'. Wed Jun 10 2020 22:28:28.996 - [status Alert] SteamVR Fail (-204) Wed Jun 10 2020 22:28:32.829 - [status Alert] SteamVR Fail (-203) Wed Jun 10 2020 22:28:31.512 - Process vrcompositor (33956) disconnected (Thread(0x000001FCBD902890/0x000) Wed Jun 10 2020 22:28:31.512 - AppInfoManager.ProcessQuit processid=33956 eLaunchingApp=LaunchingApp_None Wed Jun 10 2020 22:28:31.512 - AppInfoManager.ProcessQuit: Clearing application openvr.component.vrcompositor PID was 33956 Wed Jun 10 2020 22:28:31.512 - AppInfoManager.ProcessQuit: Clearing application openvr.component.vrcompositor PID because 33956 has exited Wed Jun 10 2020 22:30:56.753 - Closing pipe DCS (31820) because it was broken from the other end Wed Jun 10 2020 22:30:56.754 - Process DCS (31820) disconnected (Thread(0x000001FCABD80FA0/0x000) Wed Jun 10 2020 22:30:56.754 - AppInfoManager.ProcessQuit processid=31820 eLaunchingApp=LaunchingApp_None Wed Jun 10 2020 22:30:56.754 - AppInfoManager.ProcessQuit: Clearing application system.generated.dcs.exe PID was 31820 Wed Jun 10 2020 22:30:56.754 - AppInfoManager.ProcessQuit: Clearing application system.generated.dcs.exe PID because 31820 has exited I've had it happening now for over a year, it'd be nice if something could be done about it at some point.. an easy fix would be to simply have the map come up in the cockpit etc rather then a complete scene change that requires a chunk of memory to suddenly be unloaded and reassigned.

This isn't a fix though it's a bandaid for something that shouldn't be happening or required, DCS shouldn't need manual 'thread - core' babysitting full stop

Two issues here with Neutral Coalition items that have been added to the game. The First is: Neutral Units do not show up on the F10 map despite being well and truly detected. On Discord some one said this is a design feature, if it is.. then it's a poor choice, because it makes for multiple issues both game play and mission editing related. 1. ME wise it means that it's impossible to check if units are doing what you have set them to do at a glance on the map, even when that map is set to fog of war or show all. 2. It causes in game issues for GCI etc, if you can't see the neutral units once they are detected if you have Fog of War/Show all selected. gameplay wise it don't make sense.. the map is meant to be a map showing me detected units, regardless of their coalition/side etc.. Red, Blue, White they should all be showing up on it. However currently as the images show they do not. The second is that Neutral Coalition slots are NOT in Multiplayer, the Multiplayer list shows 'Blue/Red' that's it still, there are senarios and circumstances were you might want/need all 3 slot options in Multiplayer, one might be if you have a limited war going on where the Neutrals are players tasked with simply patrolling their borders from Red/Blue's whom might violate airspace etc. However currently those slots while in single player are not in MP at all.

No but you could want to fly say Oman trying to keep UAE and Irani aircraft from their airspace while still having UAE/Coalition vs Iran etc. There are many a reason for a 'third' faction to be in and to be flyable. Neutrals aren't showing up full stop in multiplayer.

So just to chime in here, the normal list of things to check.. 1. Your Firewall is actually set to allow DCS to communicate through it in both directions This is NOT your router portfowarding, but your WINDOWS Software Firewall, be it something like Windows default Firewall or your AV's . 2. Your Routers ports are fully open or NAT complient. 3. You have checked your ports are all open If all of the ABOVE is correct you have done it on the OTHER machine as well, there is no point in fixing your end or trying to fix your end if the issues on the OTHER end. Your saying your trying to connect to your son's machine, have either of you tried to connect to another server? If YOU can connect to another server then the issues not on your machine/network but his network, if you can't but he can then the issues on yours. Too many people forget that it's not just 1 machine / network in the loop here.

It would be nice to see one of well either 2 things happen with the current communications menu which lets be honest can get really cluttered if you have any ships etc in the list. 1. It filter the list based on the Aircraft your currently in so that things like the Burke or the Ticon or a bunch of FARPS etc don't show up in the ATC list for Hornets,Vipers, etc whom will never and would never be landing on them. or 2. If your not in simple communications mode it only list the agents on the actual frequencies your tuned to. Because currently just having like 6 ships in CV group will mean that you have 6 ATC instances alone, not to mention any airfields etc .. and while yes I know it sorts by 'distance' that can still make going through finding the right ATC unit annoying at times.

It's not yet, but the trend recently has been that ANY modifications to core files in the ED\DCS\X folders = IC breaking Dusty and if that trend continues it's only a matter of time until the ALE_47.lua file fails to pass integ etc, we've seen it with other items that for a long while passed and now all have to be moved out to saved games\dcs\<folders> .. so it's easier to ask if we aren't getting a Data Cart any time 'soon' due to 'mission planning rework' etc that the files which may at some point break IC that are currently being used be able to be edited/added into users\saved games\dcs\whatever. Plus lets be honest we shouldn't be editing files in the core game structure, it's bad design and can/does break track files etc etc because the track data expects certain parameters.. but it's off topic.. hopefully we get the mission planner thread soon. TBH I'd rather they just did an API at the start for reading the data in ala a file simular to the DTC in f4 or the like that way users can come up wtih what ever they want, from web interfaces to 3rd party programs.

Reported this ages ago but the Normals (Polygons) for the S-3 tankers Refueling pod are still all inverted, meaning that A: It looks weird as hell when your in close with shadows on, and B: lighting effects don't work properly on it. as the normals block the light.. because.. inverted. This appears to be on LOD 0, as zooming out the basket once it's geometry is simplified starts to work how it should.. The fix : Flip the LOD 0's Basket normals in 3D studio max and recompile the model (it's literally a 2 command step ) though ideally.. a slightly higher resolution S-3 would be awesome ;) we see a lot of it these days damned meant ot put this in object errors.. Newy or Nine could you move it please?