ChaosRifle

precisely that, currently, in my testing (at release of 2.9, not in current hotfix) we found (group of friends) that radios were not displaying degradation of quality or loss of signal based on range. good to hear that was previously a feature that worked, so likely a bug. (never used built in voip until 2.9's overhaul) AFAIK they do however account for terrain?

no, thank YOU This is great news!

wouldn't the fact the head leaves 'normal body position' just be because the user is leaning forward to get clearance for their shoulder to turn ?? that what I always thought it was, and just lacking a body animation. +1 for removing the helmet, this looks awful: I don't use the new body because I can't see with it, but I exclusively flew with the old body enabled when there was no helmet.

not a bug, just a problem.. The new model has a helmet that when looking left/right you can see your own face. the head really should not be rendered when you are in first person, like the old model was. or at least have an option in special settings to turn the head off - much preferred the old model because it didnt get in my way with the head when it was enabled, because it lacked a head.

Loving the new changes, but a few things I think are needed to supplant SRS 1: default VOIP volume needs to be like 10% tops. holy crap, you are blowing peoples speakers and eardrums. its INSANELY loud by default. People are genuinely warning their friends before they boot up 2.9 because its so loud. That should NOT be a thing. I get that high impedance audio devices are a thing, and you need to be able to go that high for very specific, high end older gear, but that is not the norm. defaults are for the norm. Lets tone that default down to 8%-10%. 2: routing of audio to one ear, if desired: IE, Com1 to left ear, Com2 to right ear, com3 to both ears, as an example. user definable. This is partially an accessibility option. 3: Mic clicks to know when someone, or you, are keyed up. 4: Hornet MIDS is not present. Would like to see that added to the default radios and supported. 5: Distance based VOIP ranges - being able to radio someone 1000nm away on 30fm is, afaik, wrong. to my knowledge, there is no ill effects of range on the voip solution at this time. Not a huge issue, but would be nice to have some restrictions to play with the radios 6: standalone software to support people doing stuff like overlordbot or lotATC. (I know, this is planned, just reinforcing the need for this. Great stuff ED) 7: a tickbox on the server options to not allow connections from users that do not have VOIP enabled, giving them a popup warning (like integ check or server full warnings). (yes, technically, when we get the standalone software we could write some sort of script to do it ourselves using the slot-in callback for lua scripting, but having a native option would be nice) 8: bit controversial possibly, and assuming its not a bug: I really struggle to understand people over the ARC-210 (in hornet) when the receiver filter parameters are on. They make it sound like you are talking into a fan, and make the audio clip horribly. I know, radios are not perfect, and I am out of my depth here as to what is should sound like, but even if it is meant to be this bad, it might be worth allowing users to change its volume or disable that without server permission to do so, as it really is an accessibility thing, that won't affect other peoples experience. To be clear here: i don't want perfect radios. I just want to not have to ask a guy to repeat himself five times before giving up and reverting to using SRS instead. 9: the UI is opaque, and has a TON of wasted space. SRS is a great example here, its compact, transparent backdrop (on one of its modes). again, really digging the new changes, its so close to making SRS obsolete, which is one more barrier to entry for players doing multiplayer getting removed.

what I am talking about will happen even in a straight on pass - nose to nose, ACM the guy, it breaks without either party ever turning, and you can then fly home with it stuck on hud the entire flight, and the ACM boresight will never reacquire anything you point it at.

can confirm AIRSTART spawns also cause it.

@Lord Vader I just took the time to learn how to use track files, and watched that track file of mine back several times, that is definitely not what I saw in game but it does show the core of the issue. 3rd fight, first lock after the merge. for me in game at the time this happened: what I saw was a square appear denoting a lock *behind* the F16, the helmet still showed boresight symbology denoting it was trying to lock, despite claiming to have one with the box pinned in place to my hud, and when i kept pulling the stick i noticed the box for the lock was not moving at all on the hud: it was frozen, and when i kept pulling the stick, had no bearing on the outside world at all. I did correct it very fast though by exiting ACM with a double tap of undesignate (~6 months of practice against this bug ) for the track file: What the track file shows is a square lock appearing in a totally different position of the screen (in front of the jet, instead of behind), while still showing the boresight ACM symbology (dashed line locking circle) (which itself is the issue here, it's stuck in some weird "i have a lock, but I am trying to lock" state, and the 'lock' it has is fake, its just a square pinned to your canopy, not the outside world/enemy aircraft) The lock the track file shows goes weird and off to the left where the real fight it stayed in the hud the entire time, not moving at all relative to the bandit or the world around me. I'll keep working to find out why my SP tracks are broken but not MP ones, and try to get one where i don't undesignate it, because I know for a fact I can turn 180 and just fly 300nm away with this state (ACM boresight dashed line at the same time as a box denoting a lock, stuck on the hud, and no further radar locks can be obtained until you correct the bug by undesignating twice to exit ACM). Not sure why the track file shows something different, but it does still show the bug (though dubious how much help the track is if the data shown is not the same)

@Katsu that paper is for V1, which didn't account for atmospheric propagation, RCS fluctuation due to constructive and destructive interference of the radar waveform, noise variability (not educated enough to confidently speak on this one), and the doppler resolution changes we are currently in V2, which does have those things, and its worth noting, the hits are transient past 70nm (30000ft+ coaltitude, knock off 20nm for the f16 being on the deck) for an F16, not guaranteed. Locks are easier to hold once you have it, but getting it isnt always the most reliable past 70, given the hits are transient (you may get a hit, you may not. only within 70nm (again, coalt 30k ft+) can you be confident you should have got a hit)

couldn't get singleplayer trackfiles as they are broken for me in 2.9. not sure why, but here is a 1v1 PvP fight showing it on a simple server. User to look at is Chaos in the hornet dcs.log debrief.log Free Flight & Practice Novorossiysk v4.1.2-20231021-171052.trk

Trackfiles broken in single player, they refuse to generate in 2.9 for me, used the simplest server I could to get some in 1v1 PvP. here's some debug logs, and track file. issue is relatively common though, so if your trackfile generation works, just go into a BVR scenario a few times and start STT'ing them from various methods (RWS TDC depress, TWS TDC depress, SOI to screen to lock L&S, you get the idea) you will encounter the issue. debrief.log dcs.log Free Flight & Practice Novorossiysk v4.1.2-20231021-170053.trk

Lets be honest though, not many people play on anything but Caucasus, PG, or Syria. Sinai looks to be an upcoming good option though. I doubt many people would care if the initial implementation did not support nevada/normandy/falklands as very few people own, or play them. Marianas has weird issues with being on the islands anyways that dont seem related to the trees at all (GPU frame present gets hit randomly and arbitrarily cutting framerates to exactly 1/3, but not always, and even in empty missions.) also not a stretch for a lot of this to just be handled by the map makers, or existing data - the maps are made of objects placed at coordinates, its not a stretch to just tie into that. Either way, even for fixed wing players, we need ground unit improvements - most missions are having us fire at stationary objects that might as well be patches of dirt with a tarp for marking the target point, because nothing actually moves or reacts dynamically. Convoys have a lot of issues, and it would be so much more fulfilling for fixed wing guys to do CAS where its actually CAS, not a 'strike mostly abandoned armour units over there' mission. +1 for wanting a bradley or abrams. Also ground AI improvements - as a mission maker, we sorely need improvements to ground AI: doing anything beyond a target range is like pulling teeth to get them to behave.

once you initiate an STT lock, the radar can get stuck in a state of trying to acquire an STT lock - when you undesignate, the radar tries to acquire an STT on the spot its looking at again, which, will be the target you just had locked. This results in the radar permanently locking a specific target, potentially making the radar entirely useless if it locks something not helpful (like distant awacs or rear echelon forces in 40nm trail) Radar screen symbology when you undesignate is showing AACQ in the top left, radar re-scans and tries to lock targets. If you are in this state and turn away from bandits, when you recommit the radar will lock the first thing it sees and get stuck on it (ie, recommit, you get a hit on their AWACS and it gets stuck STT'ing the AWACS). workarounds: switching weapons with WSS apparently breaks out of this state according to other users I have spoke to about it (cant personally confirm) changing radar mode (TWS/RWS/VS) cycling radar power system notes: Multithreaded binary, HMD on, HMD blanking off, otherwise stock configuration of the jet from hotstart. Bug happens to cold-started jets too though. video: https://clips.twitch.tv/LitigiousCooperativeBeanPogChamp-NhZo_PNiYK3hRGfe .BVR AI testing.miz

When the player crosses 10nm from his bandit, the STT lock is lost 100% of the time, if an aim-7p is in flight towards target. fly at target, launch at ~15nm, keep closing distance, at 10NM the lock will be dropped (yes, even when they are not evading and in the doppler radar notch) drop of lock seems to be almost exactly 10nm every time (when the lock box becomes just outlines of the corners of a box), at which point fox-1's go stupid. workaround: ACM boresight the enemy to recover the lock, if you are fast enough the missile will begin homing again. system notes: Multithreaded binary, HMD on, HMD blanking off, otherwise stock configuration of the jet from hotstart. Bug happens to cold-started jets too though. video: https://clips.twitch.tv/ScrumptiousFlirtyKoupreyEleGiggle-88M2U86hGTtvKQv8 more footage of the issue, showing a workaround being used: https://clips.twitch.tv/SteamyHumbleJaguarRalpherZ-Ff4ItXayZTRO20c- fox1 Testing.miz

locking a target with ACM Boresight with HMD on can sometimes give the symbology of a lock that doesn't follow the target (sits there stationary on hud/helmet), and firing on it results in missile doing nothing, as its not a valid lock. this state is a false lock, where other actions do not always work and the radar ceases to search for targets. Particularly frustrating, as using ACM boresight is done within 10nm, which is always a time critical situation. this state is semi-permanent until the player uses a workaround. workarounds are: double press undesignate cycle radar power i think switching weapons with weapon select switch will also work past it. system notes: Multithreaded binary, HMD on, HMD blanking off, otherwise stock configuration of the jet from hotstart. Bug happens to cold-started jets too though. video: https://clips.twitch.tv/SteamyHumbleJaguarRalpherZ-Ff4ItXayZTRO20c- not the best video, as I work around it pretty fast (having known this bug well for several months now) to try and secure the kill fox1 Testing.miz

also getting this

Is this still not understood? documentation i could find was not enlightening at all.

Map in the hornet on syria not set up for use out to 40nm scale like every other map in the game (barring Marianas, also having this bug). Simply displays a black screen underlay until scale is 10nm or lower - it should work to at least 40nm as other maps do.

Runways reported by lua using the airbase class function getRunways() returns a table of data for runways - most of this information is correct, except for length. Length is off for almost every single runway, except al mansurah 35/17 (which is only off by 20m, good enough for me, its functionally correct, and looks it on the map at a glance if used for marking the strip) Lengths are not off by a lot, it varies. Some are only off by about 100m, others off by closer to 400m. not a particularly severe bug, the lengths are all 'close enough' but for those of us that use that data to mark runways on the map, for various lua functions, etc.. its imperfect. Looks like a simple oversight of a placeholder slipping in, as many are sharing the same numbers for length. Possibly just unfinished? low priority bug for sure.

IRL satellite images show all of thier naval assets, even their LHA's, docking in the yard. We cant do that via mission editor with many of the craft that should fit. N31* 11' 13", E29* 51' 56"

would you be willing to share information regarding this and possibly reference materials? This is news to me (and several other modders).

You can't talk about mods without having the context of why you would want them. Sorry I bothered to explain why I cared. I am not suggesting mods are mission editing, nor am I suggesting modding should be doable via the editor. I am suggesting this because after doing extensive research into the subject for writing my own, and after consulting several other mod authors, the capability does not exist due to a limitation in the way modding is currently done. What I am asking for does not exist, because it can not exist, under the current system. No, what I am asking for is modding capability to the weapons systems on the aircraft that already are implemented as modules, which currently, is impossible to do as it is embedded in a DLL. We can make new aircraft with new armaments, but not change existing aircraft armaments (at least according to every modder and dataminer I have spoken to, as well as my own research into this). The examples I gave were examples as to why someone may want this: adding functionality that should be there but is not (ie apache stingers)or in order to make a mission file in an alternate timeline (ie 2020 hornet) (besides, its not like we have a screwed up timeline in DCS already with the times selected for various aircraft to already be time travelling, whats another year or two) By all means, if you know how to do in the current version of the game, please, do inform me of my (and many of the modding community) mistakes. Currently, this modding capability simply does not exist though as I, and many in the DCS modding community, understand it.

the specific weapons were examples, either way, its a hole in the capability of modding as a whole, as I currently understand it. We should be enabling modders, not restricting them. I could just as easily say stingers for the apache, but that was not the point.

On Sinai specifically is seems (I have not witnessed it on other maps, only Sinai), tuning to a TACAN channel for a carrier, or airfield (only tested Azzaqaziq) will return the wrong location. It appears to be a floating point error, where the closer you get, the less error there is. The beacons drift around as you get closer, and slowly drift onto the actual location. This is minimal for airfields, only a few lengths of the runway off, but for the supercarrier this is extremely bad, and the beacon can be off by well over 80nm and as you get closer can move towards the right spot at over mach 10. This also breaks ACLS (automated landing) on the carrier because it requires an accurate tacan beacon, and even when right on top of it, it is still off by a little bit. Notable reproduction information: Testing done on a server, on Sinai, in an F18 Hornet, using TACAN for terrain/tech locations (airfield/carrier). for airfields I have only tested Azzaqaziq. Easiest way to see it is be greater than 150nm from location(supercarrier is the worst one by far), tune to tacan, fly towards the beacon, watch the HSI page in the hornet and see the tacan beacon moving around in ways it simply should not. 71X on Teddy.

can reproduce. Makes me reslot to fix it. Literally 100% reproduction. If I hit the edge of the screen, my cursor dies, no more motion. I can 'reset' its position by using the swap screen button, or by entering boresight mode, but the cursor remains dead from this point on, the only solution is reslot. Relevant hardware is Stick - Virpil WARBRD + Connie Alpha Throttle - Virpil CM3 passed through joystick gremlin (VJoy) Heat tracker - TrackIR5 Relevant software Keybinds are Analogue Axis input, NO axis tweaks (curves/deadzones/saturation etc), from the ministick TDC on the throttle Cursor Enter as the depress function on the ministick used for motion.