Dojo

No. I have no interest in synthetic benchmarks, other than fun reads on Tom's/Anand's. I'm re-baselining my machine at the moment, using some handpicked "scenarios" in DCS. I'll then re-run them once I've switched cards later today. In the training mission we most frequently play in DCS with my group (a heavy Nevada mission), the largest bottleneck for the Oculus is the VRAM required. Our scenario requires about 9.1GB VRAM on average for the Oculus, under a standard config with 1.7 pixel density. The dropped frames can directly be tied to that. (i.e. an A-10C empty Nevada mission only uses ~5.5GB of VRAM, and is solid at 45fps on my machine, regardless of where I fly). I imagine the 1080Ti, at a minimum, will solve that easily with its 11GB, preventing the machine from leveraging with the much slower system RAM in this scenario. The Caucasus are a completely different consideration, due to the terrain engine differences. It doesn't play as nicely with new shiny hardware as Nevada does.

Properly evaluating performance in VR. For the interested: http://www.tomshardware.com/reviews/vr-benchmark-fcat,4943.html

Hey Brixmis, curious about your experience disabling ASW. What differences have you noticed? (If there's a thread where this is already discussed in the context of DCS, please feel free to point me to it, I've been unable to find it.) As an aside, I'll have a 1080Ti later today, switching from a 1080. So I'll post some initial performance comparisons when able. ... You had me at "VR recording direct". You've now managed to earn yourself an ED forum stalker.

I suppose I'm not following the issue... vJoy Feeder keeps the button permanently pressed for me. Could you elaborate on what problem pressing it every 10 seconds solves?

I believe implementing it in the client would be totally fine... as I'm running this from the "client" on my server, just connected locally to itself. I solved my PTT issue with vJoy, which I'm totally certain you could solve easily within the client interface. If you're going to look... (I know... I know... totally giving you more work), the more challenging item for us is extracting the weather from the mission, converting it to the ATIS format, and then pumping it into a text-to-speech program to generate the audio file... that of course Simple Radio would then play repeatedly on a designated frequency. One of my squadmates pointed me at this: http://wiki.hoggit.us/view/DCS_singleton_atmosphere, which of course can get the weather out of the mission. :::Liam Neeson Voice::: I need your particular set of skills to bring this home! Again, I know you've got a long list, so I've been trying to create bandaids in the meantime!

I arrived at vJoy last night, so sounds like we're on the same page there. I didn't need FreePie though (the built in Feeder was sufficient to maintain the button press). I'm curious to know what you mean by this. Might you be willing to hop on Teamspeak to discuss your setup? I'll PM if so and thanks in advance!

Decided to give ATIS a go. Initial test was a qualified success (I had to perform MacGyver-ish feats to keep the PTT depressed on the machine hosting the ATIS.) But, from the spectator window on a separate machine, I was able to connect to our multiplayer server, tune a frequency for the ATIS to play on, and play the looped recording (an MP3 played through Windows Media Player, that was generated with text to speech software). Quick and dirty, but it works. Pay no attention to the actual ATIS format, I hastily typed it up for the text to speech test.

Coug4r, Have you had any luck with this? If so, may I inquire as to your approach? I'm considering playing with it myself until such time Ciribob can include a native one. :music_whistling: I'm assuming your approach was to have a text to speech client loop with the PTT set to pressed?

Hey folks, given that we were directly involved in the design and testing of the server side recording, I thought I'd offer an expanded explanation for reference, in the hopes that it will be useful to you. Below I'll describe the feature, how it works, the performance implications (both client and server), and other tidbits. Feel free to skip the origin, it's just background for future reference. Origin A little over a year ago, we noticed that Tacview was having a severe impact on frame rate in DCS. The reduction in expected frame rate was anywhere from 40% to 130% within a given mission. Yeah, that bad. We use Tacview virtually after every mission to debrief, so turning if off was a non starter. We provided the feedback to Vyrtuoz, who began to troubleshoot with us. After evaluation, it was demonstrated that the size of our mission (specifically the number of objects), was directly related to the impact of Tacview. If you're not aware, the 476th Nevada Training mission that is public, has thousands of objects in it, in order to reproduce the real world ranges on the DCS Nevada map. In other words, it really stresses the export handling, although there are many missions which do the same. Proving the relationship between object count and increased performance impact with Tacview is easy: Launch an empty mission (one plane on a runway at Nellis) on a given machine, with Tacview turned off, and look at the frame rate. Let's say that was ~130FPS with VSync disabled on a given machine. Launch the same empty mission with Tacview turned on, again 130FPS. No difference as there's really nothing to export. Now run the 476th NTTR mission with no Tacview. Results: 70FPS. So a substantial drop due to the object count, but still highly playable. Next, re-launch that mission with Tacview on: Results ~35FPS. So we have a significant problem. Of course, our initial thought was "Hey Vyrtuoz, can't you just fix it please?". After analysis on his side, he concluded that he could optimize his own export handling, but that much of the problem lied within the way ED handles the exports, so he could only do so much to address it, and he has. In the above example, that machine's frame rate with Tacview is now ~45FPS after Tacview's optimization. A substantial uptick (~29%), but far from ideal. As I understand it, the inefficiencies in how DCS handles object exports has been reported to ED before, but thus far, optimizing the exporter hasn't been prioritized. In summary, while the argument can be made "You only receive a performance loss with Tacview on, so isn't it Tacview's fault?", the real issue is that enabling Tacview is exposing inefficiencies in the DCS' export handling. We have log files that demonstrate where the processing fault lies per frame (and by definition the frame rate loss), but for now, take my word for it. So how do we get the benefits of Tacview with none of the frame rate loss? Recording on the server Tacview has always been able to record on any machine running it (client or server), so technically, you've always had the ability to record on the server instead of or in addition to the client. However, this creates two problems: If you were only running a single mission with everyone involved in that mission, for a reasonable amount of time (let's say 5-6 hours max), this isn't so bad. However, if you ran a massive scenario, where players could join and disconnect at anytime, and after they disconnect they want to review the Tacview, well now there's isn't an elegant way to handle it. Additionally, in previous versions of Tacview, compression wasn't built in, and a Tacview file would be literally hundreds of megabytes, making transfer a "process" to say the least. The real issue for us, and many other multiplayer servers, is that the server is up for much longer than 5 to 6 hours, and as a pilot, I'm typically only interested in my flight, not the entire scenario. This is explicitly the case when a server such as ours is used: It's a training environment, which means it's up all day, and pilots can join and leave any time. Pilot 1 and Pilot 2 may join the server and go to one area of the NTTR to practice bombing. Pilot 3 and 4 may join the server an hour later, and fly to the tanker, while pilot 5 and 6 can join later still and practice formation flying. When they're done, the server is still running waiting for others to join and disconnect. Why should any of them have to review a tacview file that might be a few days old, searching for their flight time? Yes, they can run Tacview on their own machine, but considering the massive performance drop, that's not desired. "Per Client" Recording Enter the design proposal for server side user recording. The idea is simple: Install Tacview on a server, and have it create a separate Tacview (ACMI) file per connected user. Start recording when the user connects, stop recording when the user disconnects, and place the ACMI file in a folder with the pilot's name. This means that a long running server, can have users connecting and disconnecting all day long, with each user getting complete ACMI files that just includes their own flight window. When the server is put in this mode (called "Create one file for each client session" in the DCS Special options) it will not create an additional ACMI file for itself, just for the individual connected users. Client Performance Benefits This one's obvious, because Tacview doesn't need to run on the client anymore, there is zero impact from Tacview on the client's performance. Calling back to my previous example, that machine runs at 70FPS plus now for the heavy mission. Server Performance Implications The story here is great too. I'll spare you the gory test details, and cut to the executive summary: We conducted a lot of testing in Alpha, and a few Beta tests with 10+ pilots to evaluate this. It should be noted that there is no distinct Tacview process running for recording, so Tacview's entire performance overhead is captured within the DCS process itself, and has no noticeable impact whatsoever from a CPU or RAM perspective. So of course the big question becomes disk performance, and the news here is great: A rough summary: In multiple tests on our heavy mission with 10+ pilots, DCS disk write rate was ~9KB/s (note this includes Track data and Tacview), with a 450KB spike every ~5 seconds as Tacview empties its memory buffer to disk during our test scenario. While that spike is below .5/MB, and well within the performance parameters of even 15 year old mechanical disks, the small block write size would likely stress them, and I wouldn't recommend anything less than a 4-5 year old SSD. The performance impact scaled linearly in tests, so extrapolating our results to a 60 pilot connected server (the most I've personally seen), you're looking at ~3MB spikes at the buffer dump interval. Certainly a stress test would be prudent to prove my assertions above; I was unable (and unwilling ;) ) to coordinate a 50+ pilot test myself. There is the question of network upload speed, but I'll come back to this at the end of the next session, as it's optional, depending on how you plan on "distributing" the server side ACMIs. How did you set it up? Our config is as follows: We enabled the server side client recording option, and advised our members that they can stop running Tacview locally. We then used Google drive to create a share folder, and configured Tacview to save recordings to that folder. The Google share was then made available to all of our members (they can read/download, not delete). After a pilot is done flying and disconnects from the server, Google, within a few seconds, syncs the share. Each pilot can then easily download their own Tacview and review it on their desktop. For maintenance, we wrote a very basic server script, that will delete the ACMI files in the pilot folders after 24 hours. **It's worth noting that the ACMI file production has been extremely optimized. On average, a 3 hour mission for us produces a 4MB ACMI file size per pilot, so the transfer and sync are really fast. Here's where the additional performance consideration is the Internet connection; If you use Google Drive, Dropbox or any other network sync mechanism, this of course requires the server to constantly upload the ACMI files as they're being dumped to disk while Tacview is running. Make sure your upload link can support regular Google Drive/Dropbox transfers if you go this route. We're plenty happy, although we currently have a 100Mbit symmetrical link. I've also done this with plenty of room to spare on a 25Mbit upload link during the test phase. Additional Pros Tacview will produce an ACMI file for a pilot whether he/she has Tacview installed or not, allowing admins to review pilot flights, even if the pilot isn't interested. Local client recording can be disabled on the server, allowing the server to create an ACMI for the pilot, but the pilot won't be able to generate his own, even if he tries to record Tacview locally. We don't do this in my group as we don't have cheating concerns internally, but public servers may use this as an alternative solution to the anti-cheat feature, because a pilot can be provided his server generated ACMI file at any future time period. (i.e. after the scenario completes) Are there any cons? Well, yes. It would be accurate to say "you get most of the benefits of Tacview with none of the performance loss." You don't get all of the benefits, because a remote host can not export "cockpit" data for a connected client. For example, if a client runs Tacview locally, he will get the following additional data in Tacview: Gear State Flap State Air Brakes State Magnetic Heading (vs True) *Accurate Indicated Air Speed (IAS will show, but it won't be accurate on a remote recording) Since a server (or any remote host) can't export the above, the ACMI file will not be able to provide the data. It's certainly my personal opinion that those are minor sacrifices for the huge performance gain.

This is a game changing feature. Outstanding. I have huge plans to take advantage of this!

Which version still has it working, might I ask? I did some extensive testing today, and it's certainly broken as is. But here is the experience (multiple Oculus users were testing with me). We used TACAN yardstick to verify distances. 1. At 9-10nms, we appear as dots to each other. (this is too far but let's not go there) 2. We are able to see each other clearly as dots until we get to 3nm. At 3nm, we disappear from each other. 3. At ~1.5 we are visible again. This was re-produced 5-6 times with all players changing the values from OFF to LARGE, and the mission being re-saved (as the server settings when the mission file is saved effects this enforcement). There is no change no matter what you set the values to, this experience is the same for all testers, and not really playable for dogfighting at the moment.

While I too would like very much if the Gun Camera images were naturally exported (e.g. to the Screenshots file), there should be something we can do to improve the in-game experience. I suspect the Gun Camera is exportable as a Viewport. So if you've got more than one monitor (or virtual monitor), you should be able to export the camera output there, so it's off of your main screen when pulling the trigger. Once that's done, any screen capture software with the second monitor set as source should make it easy to pull out the video/stills. I'll try to poke around with it myself over the next few days and share the results if someone doesn't beat me to it.

Hey guys, love the enthusiasm! But this isn't the second contest. That won't happen until the episode airs. Please read the original post. Can a moderator close this thread please? Thanks!

The contest for the first giveaway ended on the 16th... but if we were giving it away based on best entry, this would be it for me. ;) We will be giving away a second flight pack when the next podcast episode airs. Please see post 1 in this thread for details. Again, the first contest ended at post 182.

CONGRATS! PilotRyan! Hey everyone, the winner of the first giveaway is PilotRyan, post #125! Congratulations PilotRyan, and good luck finding that TrackIR!! ;) For everyone else, once we're done recording the episode of the podcast, there will be a second giveaway of a flight pack! For anyone curious of the selection process and how PilotRyan won, I recorded it and stuck it on youtube... because who doesn't like to watch a playback of themselves lose a contest? ;) Thanks for participating, and good luck in the upcoming second chance to win! Happy Holidays, The 476th Podcast

Hey folks, Just an update. The podcast episode will be a little delayed as we're dealing with holiday vacations, but we're going to go ahead and wrap up the first giveaway this Friday. I'll post the winner in this thread, this coming Friday. I plan on recording the selection process and posting a youtube here. I've noticed there have been some folks who didn't follow the rules (e.g. multiple posts) so they'll be disqualified if they win. I will use the random number generator, probably click it 3 times (just because) and whatever number comes up after the 3rd click, that's the winner! (so long as they didn't post multiple times, and gave a "reason" for why they deserved it). Again, almost no one will be disqualified. I've only see 2 out of the entire list! Please, do not reply to this post! This thread is only for entries. We'll be back this Friday to announce the winner, so if you haven't entered here, please feel free to do so, and thanks for all of the support! Happy Holidays, The 476th Podcast

Pilots! Just in time for the holidays: Thrustmaster and the 476th Podcast, in promotion of an upcoming of episode where we get to know Thrustmaster, are giving away TWO complete Thrustmaster T.16000M Flight Packs! Each flight pack includes the new Thrustmaster T.16000m Flight Control Stick, TWCS Throttle, and TFRP Rudder! Learn more about the flight pack itself by clicking HERE WHEN DOES IT START?! NOW! We're running two separate chances to win; The first starts immediately! RULES To enter into the first chance to win, simply reply to this thread with why you deserve the flight pack. Feel free to be funny, sad, or both to qualify! It doesn't matter, just tell us why (really, almost no one will be disqualified except for existing & former 476th Virtual Fighter Group members, so have fun with it... make up something if you have to! :pilotfly: ). Your post does not have to be particularly long to enter. The contest starts now. We'll use an online random number generator to pick the winner's forum post just before the episode is posted, which should be sometime in the next week or so. As long as your entry meets the standard of "tell us why you deserve it!" You're in for a chance! If you don't win in the first contest, you can enter the second contest immediately following the episode! The rules for the second contest will be described during the episode. :music_whistling: NOTE: One entry per contest. Multiple posts in this thread will automatically disqualify you. If you have questions, contact either Ragtop or Dojo via private message here or on the 476th website. Please DO NOT reply to this thread with questions or comments. Entries only! If you wish to generally discuss the podcast or contest, you can also reply in the 476th podcast thread here: https://forums.eagle.ru/showthread.php?t=132796 DISCLAIMER: Unfortunately, we can only drop ship the pack directly for free to the continental United States. Most of Western Europe will likely be free as well based on sourcing location, although we can not guarantee all countries. However, if you live outside of a "free region", and win the contest, we'll communicate directly with you to determine if shipping and duty will be required, and if you wish, you can pay those costs. If you decline to do so, no problem, we'll simply randomly generate another winner. Good luck & Happy Holidays from the 476th Podcast! To learn more about the 476th podcast, check out our podcast page HERE

Seriously, Prowler, it's got to be the CH-53... :music_whistling:

This is the video I had watched as well, that first alerted me to the possibility of a local problem. The two time stamps you've included capture each of the issues I've reported perfectly. As for the distortion, we'd dealt with that by lowering the mic boost. It's true that different values worked to mitigate the issue for different folks, but there was some adjustment. As far as I know, most of us haven't updated .NET, so we'll do that, retest, and report. As for the difference in transmission receipt quality, strangely, it's working well for me now, i.e. everyone sounds like they're "suppose" to, according to your first link. I'll provide the samples a bit later, and will retest all again after updating .NET. (would have updated .NET sooner, but assumed that was only relevant to 1.2.8.1, and we're still on 1.2.8.0 for the moment. Thanks again.

What we've done, since 1.2.6, is turn the mic boost down below negative 50. Several are using Negative 90. Try that.

Hey Ciribob, Reporting two issues that we're experiencing: First issue: Since we first began using SR, we've had an issue with the microphone boost, whereby if a speaker had his boost settings above 100, AND he spoke above a certain volume, the receiver would get a very distorted transmission. Speaking at a relatively normal/low volume would not produce the distortion. We solved this by simply informing all members to keep the boost below 100, and the issue was not experienced. Since 1.2.6, this distortion is back, unless we change the mic boost to be below 0, usually in the -50 to -90 range. So it's manageable, but certainly an issue worth reporting. Second issue: The "radio effect" is a bit more difficult to describe via forum, but I have recorded some audio samples if my explanation here fails. First, I had felt that the radio effect being applied to the voice was a bit weak... that is, I would hear the transmitter in an unexpectedly high quality, with some background noise applied to make the transmission sound "distorted". To my surprise, I was watching a Ralfidude youtube video, where he was using SR, but all of the transmissions he received sounded pretty aweseome... so I assumed there was something misconfigured on my side. Yesterday, while testing the first issue above with a fellow member, he reported that I sounded very much like I was coming through a radio, while I reported that he sounded very much like we were on TS, but with background noise. I attempted to retest with a another member today, and it was the opposite, although I've changed nothing! That is, I sound to him as if I'm talking on TS with some background noise accompanying my transmission, while he sounds to me as if he's on a radio! Please let know what I can do help demonstrate this experience if my explanation above fails to convey the problem. We're currently on 1.2.8.0, although I've experienced the above previously.

NO! Thank you! and +1 to what Eddie said. We'll be standing by.

That works! Just to be clear, I'm assuming that your sample is just the two sounds side by side for our comparison, not a literal instantaneous click/release (i.e. the natural click/release with no transmission should have no delay between them... which enables a pilot to produce a "zipper", usually with a double tap.) We also did some extensive testing today with 3 A-10s at the NTTR. The scenerio had all 3 jets hot start at the NTTR, right next to each other. No issue getting the radios on, and comms established, and the software had no stability issues throughout the ~30 minute test session. Test results below: 1. When transmitting, the mic clicks are heard repeatedly. All 3 testers experienced the following: Pilot 1 transmits, both pilots 2 and 3 hear the mic click sound effect intermittently throughout the transmission, at the rate of about one click per 2 seconds. I suspect that this is an issue of quality when receiving the transmission based on the following 3 points: a) we used Windows joy.cpl to confirm the mic switch itself wasn't "flickering", b) the transmission itself is never broken, just a bunch of mic clicks througout, and c) the transmitter never hears the repeated clicks, just the receivers. 2. Blocking (i.e. the new "IRL Tx Behavior"). When Pilot 1 transmits, Pilot 2 also starts to transmit. Pilot 1 and 2 do not hear each other at all (great job!). However, Pilot 3 is hearing both pilots speak clearly, which wouldn't be the case. Conceivably, with all 3 pilots sitting next to each other, as we were at the beginning of the test, this would be somewhat reasonable, though perhaps not as clear as it is at the moment. As the distance of the pilots between each other changes, the expectation would be that a number of factors (e.g. the harmonics of the system, LoS, signal type, signal strength, etc) would cause Pilot 3 to be unable to hear the other two pilots at all, and the transmission should be quite garbled. Another consideration,if Pilot 1 was far from Pilots 2 and 3, while both Pilots 1 and 2 transmitted, Pilot 3 is more likely to hear some, if any, of Pilot 2's transmission, and essentially none of Pilot 1's transmit. But generally, erring on the side of Pilot 3 hearing garbled transmissions no matter the case would be more accurate for all scenarios. Here is a BMS video which illustrates a 3rd party hearing the garble while two other pilots transmit. I linked it at 20:52. At 20:58, you will hear a "warbly" sound, which is an example effect (but not THE effect, as there are many different types for garbles you'll hear, depending on cause... but just wanted to provide an example). Apologies for the music, we tried to find a clean example. Separate note: We're aware you haven't implemented HAVE QUICK. There is a "conference" capability there that would make it reasonable for Pilot 3 to hear both Pilot's 1 and 2 while they simultaneously transmitted. 3. I might have downloaded the wrong version, assuming you fixed the "C/RAD 1 to C/RAD 2" mix up. In our test today, where we fresh downloaded the zip, we were getting C/RAD 1 as FM, and C/RAD 2 as UHF, which of course should be the other way around. Please let me know if we had the wrong file some how, or if you hadn't updated it yet. 4. LoS - Line of Sight is working as you know, however (and I believe that this has reported before), it's quite binary at the moment. Where there should be a reduction in quality due to diffraction before the cutoff, but not "necessarily" a complete cut off immediately. I can't remember if you already acknowledged this or not, I know this is all still WIP, but I'll leave you with this image of diffraction for now, and if you need help with formulaic description or implementation of the phenomenon, we can probably get you on TS with a couple of our guys to describe it better than I can. Of course, the performance would be different between AM and FM radios, but that's for another time ;) 5. Distance effects: Don't appear to be working at all. We started with jets right next to each other, and then had Pilot 1 progressively jump into hot air started jets that were 75 and then 145nm away, and once LoS was established, there was no quality degredation whatsoever. e.g. Pilot 1, at 145nm sounded no different to Pilot's 2 and 3 did to each other, and they were within 5nm of each other. That's all for now! Of note, we upgraded to the test version, and downgraded to the release version with absolutely no problem. (though we have two separate server instances setup). And it's little things like this that make Simple Radio a jewel.

Hey Ciribob, Eddie, myself, and a few others have begun to test the new version. Biggest feedback thus far is on the mic clicks. Eddie has already pointed out the missing opening tone on the KY-58 in the previous post. For the actual clicks themselves, in our opinion, the best sound you've got is the opening sound when the KY-58 is enabled. Not the beep, but the underlying "click sound" that you're playing simultaneously. Sort of the "thump" opening. Our opinion is that this sound should be used for both the open and closing mic click for all radios, not the ones you're currently using. Because my gibberish above may not be clear, here's another video with an almost identical version (it's TARS) although yours is already crisper: At the 40 second mark, you should hear someone come over comms with the open. Of course, in this example, there was no close. That same sound should be heard on both the open and release. We haven't gone wide with the update yet, so no feedback from the group on performance, but hopefully soon. Solid so far!

Dude. Seriously. Too F*()&ing awesome. We'll be putting this through its paces soon and of course will report back as per usual. Sierra's note is correct, btw.