Jump to content

DroptheHammer

Members
  • Posts

    35
  • Joined

  • Last visited

Everything posted by DroptheHammer

  1. @speed-of-heat In the current OP version you mention "shader cache to 10GB" twice, but I cant seem to find how or what you did for that. Could you elaborate?
  2. Dear Deka, For the TDC Cursor slew, there are 2 separate sensitivity customization options in the SPECIAL menu, that allow you to have separate tuning for those cursors (personally I like my TDC cursor for radar fast, but for the pod slow). It's great! But for the ZOOM on the Pod, it's linked and tied to the Radar elevation. And I'm finding that you only get one of 2 results. With the factory setting, the zoom is great for quick zoom in and out on the pod for A2G work, but at this setting the radar elevation is WAY to sensitive. It's basically so sensitive you can almost never easily get low contacts inside 20nm etc since you go to -30 degrees or worse way too fast, especially in a crisis situation when a fine touch might not be possible. Alternatively, if you tweak your axis limits or sensitivity to make the radar friendly to move up and Down for A2A merges, then the Pod zoom is extremely slow.. so it feels like it takes forever to investigate multiple ground contacts from range with the pod in this scenario. Could you separate these out? It would be really helpful for those of us whom have an axis slider for zoom (rather than an axis knob). I'd want to have one setting in the SPECIAL menu for Radar Elevation Speed and a seperate one for WMD7 Pod Zoom Speed. Alternatively, you could build an option set of 2 separate axis in the controls menu so I can bind the radar to one axis, and the pod zoom to a completely separate axis. Either solution would be great, but programming both sets would be AMAZING. Thanks again for a great jet, DTH
  3. Good evening, Given how friendly the UI of the jeff is.. It seems very strange (and maybe unintentional) that the zoom amount within a mode isn't retained when switching between WIDE mode and NARROW mode. For example, to ID a target, I almost always use the furthest in analog zoom within the NARROW mode. But to search for a new target, I typically switch to WIDE to scroll (since that's way faster than manually zooming out within NARROW mode) and once I have my pipper over the new target, I want to go straight back to NARROW. But when I do, the narrow zoom is now at it's default setting, rather than the fully zoomed in before. Also if I go back to wide, the sub-zoom I was using within wide is lost and it goes back to default.. Why is this? You'd think that the pod would keep the sub zoom between modes so you could quickly toggle back and forth. Is this intentional? Seems strange and it adds a lot of unnecessary analog zooming in and out. Esp noticeable if your WIDE is at it's tightest zoom and you also want narrow at it's tightest as well, you're constantly switching and zooming again. Regards, Michael
  4. I haven't yet updated since I typically check this forum first to see if it's OK or a disaster like earlier this summer. Anyone on this? Especially VR Users?
  5. Regarding TSS small... Any missile which is going mach 5 and then only goes pitbull in the last 3-4 NM will only have 1-2 seconds at most of warning before hitting. First of all, an IRL RWR doesnt "instantly" light up, it does take some time for it to register a real threat, identify it and present it to a user. Next, there's human lag, once you hear something, it takes time for your senses to perceive it and classify that. On top of all of this is netcode lag. So yes, things can work completely as intended, and if it takes 3/4 of a second for the RWR to classify it and 1 second for you to react, that leaves about .250 second before the missile impacts you. It feels "instant". But typically it means you made a mistake much earlier in the fight (see below).... TSS small is avoidable however, because if you're within 70NM of a tomcat, you should be maneuvering in a preventative manner anyway, and that means the tiny cone the missile makes at 4NM Pitbull is only 4NM across (60 degree acquisition cone). So if you've displaced yourself more than 2NM or so from where the AWG 9 thought you were at launch, the missile will never acquire you. Dont fly straight is the lesson to learn... As a T-cat pilot or RIO, your tradeoff is to either cast a larger net with TSS Large, where your acquisition cone is 12NM across at PB, but you warn many seconds earlier, or warn much less but catch much less in the narrower cone from a shorter pitbull. I only toss TSS Small at targets I believe are not aware of my presence, or are doing something stupid like flying along straight and level at 50-70NM, where they dont believe i'm a threat. In all other cases against aware targets, TSS Large yields a higher PK since it's more likely to catch a bandit inside the larger net that occurs with an earlier activation.
  6. I'll have to rig up something specifically for this. Maybe a left to right pass at around 21-14nm, need a human rio... acquire with STT, cancel STT lock, ensure TCS still there, fire weapon, tell target to maneuver vertically and then see if the missile continues to the pure launch bearing first before going active and turning up (which would be working just perfect, no explot at all) or if the missile begins to turn up immediately (TCS acting as an STT and telling the missile to maneuver, but even this would only really be an exploit if the missile was taking an intercept instead of a pure course). If the missile in the second output is "pure", that would seem feasible since you'd just be doing basic trig between the missile, the plane and the plane's "bearing to target". Similar to a sub torpedo shot where you dont have ranging information, it would be plenty to guide the weapon. Very interesting.... Given how much this has blown up in the last couple weeks, I've been doing less time testing and more time figuring out how I can make this process scalable but still trustable... Also, in the past I was doing the testing much for myself and our squad.. but now making the data easily packaged and distributed to ED or HB in a way they can utilize it has been an engineering challenge....
  7. Thanks for working on this so well Cobra. There are many of us rooting you on and trying to gather data to best help your team and the ED team to make the tweaks required for a fix to many of these "issues" as claimed. Just because the phoenix is fast and speed means spacial displacement (in terms of netcode) does not make it a cheat. In fact, any missile arriving at the 3-4NM range in excess of mach 3 can exhibit the exact same desync rates and magnitudes as the phoenix just due to lag and client server differences. 100ms lag client to server is really around 300-350ms difference target to server to shooter and 350ms at mach 3-5 can be several thousand feet... It's amazing the netcode is as good as it is. How do we make this better? SCIENCE! There are a multitude of claims, some new to me and some not. But it's important that we isolate each of these claims, rig up controlled tests to verify if it's merely user perception, server lag or an actual mechanical issue and then isolate that issue. To date I've gathered the following list of individual issues and deployed around 1200 weapons in controlled tests utilizing server tacview and machine learning techniques on to find answers. TWS Target Switch Size exploit PAL Target Switch Size exploit (these are different, because of the type of lock involved, type of test required and type of positive,negative determination required) PAL and ACM Switch Up Target Switch Size exploit claims of "missile not warning" (these are different, because of the type of lock involved, type of test required and type of positive,negative determination required, the ACM switch also effectively makes the missile "Launch Active on Bearing") High AOA Launch with PAL High AOA Launch with PAL and ACM Switch Up TCS Camera launch starting with PAL (new to me as of this thread, however at the ranges involved, it's feasible IRL that this is an intended capability of the tomcat to "launch on bearing" using visual information only at a range under 20NM and the missile would easily find something. The TCS would barely differ from PAL + ACM Switch in how that would work.. HB - Is this an IRL feature / tactic?) TCS Camera launch starting with STT at range >30nm (new to me as of this thread, but I've imagined this scenario) Of all of these, they have to be divided into tests targeted at the two primary gripes.... Desync (a missile is where it doesn't appear to be, and either misses or hits something that isn't true to the CLIENT), missile does not "warn" (a user perceives that they don't receive an RWR indication prior to impact). Overall, Of the ones I've tested extensively (TWS TSS, PAL TSS, PAL ACM TSS) The RWR indications always happen, and we know this because the F-16 and AI targets both auto deploy at the moment the missile acquires and changes course so the target clearly "knows". Desync is tougher to test for and I've never seen a repeatable test that consistently shows desyncs being provoked, initiated or reliably exploited with these scenarios. One or two random match Tacviews (especially from client side) are just anecdotal evidence, but it appears the mass majority of "bans" seem to stem from these non-repeatable incidents. I'm happy to collaborate with whomever to try and rig up peer reviewed tests on these subject matters, as only this will lead to concise and actionable bug tickets for either HB or ED. It's extremely likely that when the Eurofighter starts lobbing mach 5 meteors everywhere we're going to see lots more of this, and we already see plenty from Jeffs and the SD-10 when it's launched from fast parameters as it can easily arrive on target at mach 3.5+. I would love server side tacviews of this being done multiple times and provoked. Is this available for me to look at?
  8. Copy paste of a series of research tests and tacviews I've done this week (patch 2.7.1.67090) The test was built to see if the missile guides but does not warn. This is confirmed false as shown by the test and documentation posted below. All I can say, is that in trying this around 100 times in the past 48 hours from various angles and using a very low latency server for the two of us to fly on that any perception of those on growling sidewinder or otherwise is due to server, sensor or perceptive lag and not due to any sort of bug. If the missile isn't tracking there is no RWR indication, and the moment it tracks there is RWR noise and the missile begins to steer at the same moment. PALSwitchtest.zip
  9. Confirming my appointment for LowBlows wing. Sounds like a great event fellas.
  10. Hello all, I'm trying to improve the viewer quality of people watching on standard 16:9 displays for when I fly in VR using the HP Reverb G2. There are many options such as the OpenVR Capture Source for OBS and the Game Capture as well as Mirroring the Steam Mirror.exe or WMR Display Output. With so many options it's hard to find a combination of high res, smooth and correct size. Also, we still have yet to see an Image Stabilization for VR similar to Oculus for the WMR platform... Today Mine is setup using Game Capture source in OBS, to capture the DCS.exe Window on the desktop, then I use a transform to take the center portion at the 16:9 aspect within a bounding box and allow that to cover the entire canvas of my OBS. Below are my screenshots, please share yours! Thanks, Slash621
  11. I'm a little frustrated with the fact that sometimes the IC check happens like 30-40 minutes after I'm into a server, doing things and close to my briefed objective. Had a flight I was streaming with my dad (takes a long time to get him setup via discord etc.. hes 79 years old) and it was ruined by an IC check from a skin mod (apparently it had a modified rust texture). Why is the IC Check so delayed sometimes? Can I manually execute an IC check before flying. on this particular flight I had a GREEN SHIELD before logging into Hoggit.. Is there a console or other command for me to run once i'm on the server as a part of my startup procedure to ENSURE I pass IC check so I dont waste time starting a jet and flying around before being punted.. I like sharing my flight time on saturday mornings with my dad, but stuff like this really puts a bummer on that special hour each week. Sometimes I feel like with DCS VR Streaming, I have to sacrifice 5 goats in a perfect procedural order just to get the damned thing to load.
  12. Went to check on these and decided I'd make this a more user friendly list. Radar Silent Radar Active TCS Narrow TCS Wide ECM Off ECM XMIT Flare Mode : Pilot Flare Mode : Normal Flare Mode : Multi Thanks HB!
  13. Good Morning, Is there any plan to make this accessible with a Mouse? I'm in VR, but I don't want to clutter my desk with "yet another device". It would be nice to just draw on a nine-line with my mouse. Not pretty but good enough. Can I do that with this tool? -Michael
  14. I concur with this. I also use that setting on my G1.
  15. What's been working for me is install the kegetys first and then mustang's second. That seems to work great and I get best of both.
  16. So, just to confirm. My choices are keep the performance (option TRUE) and loose the lights in the left eye... OR ... go slower and have the lights (Option False)? Works for me... I just figured since y'all fixed the crew not displaying with Option TRUE that the lights might get fixed also.
  17. https://forums.eagle.ru/showthread.php?p=4489778#post4489778 Copied from the link above since Heatblur affirmed this was a DCS Core Issue.. Hello all, Since the last patch, the interior lights ( or rather the light they show on surfaces) of the tomcat do not render in the left eye of the HMD. To be clear, both eyes can see the light origin (the bulb itself) but only the right eye sees the light cast unto other objects as intended, to the left eye, even with all white and red lights on at night the cockpit is pitch black. Prior to the patch, this bug existed in the same way only when Culling was manually enabled by command line/LUA. The bug is similar to how the deck crew prior to the patch wasn't rendering in the left eye either (an ED bug they fixed last patch). It is most likely that the change ED made to ensure the Deck Crew was rendered to both eyes with Culling = ON needs to be followed by either ED or Heatblur to ensure the F-14 interior lights effects on the dashboard replicated to both eyes. Since Culling is now on by default since the last patch, all SteamVR , Windows MR and possibly oculus users should have this issue. I've tried toggling culling of via the lua, but the option can no longer be manually disabled (at least by the same line we used to manually enable it last patch). Hopefully this puts you on the right path and what ED did for the deck crew can be applied again for cockpit lighting. If they are unrelated, good luck finding it!
  18. Hello all, Since the last patch, the interior lights ( or rather the light they show on surfaces) of the tomcat do not render in the left eye of the HMD. To be clear, both eyes can see the light origin (the bulb itself) but only the right eye sees the light cast unto other objects as intended, to the left eye, even with all white and red lights on at night the cockpit is pitch black. Prior to the patch, this bug existed in the same way only when Culling was manually enabled by command line/LUA. The bug is similar to how the deck crew prior to the patch wasn't rendering in the left eye either (an ED bug they fixed last patch). It is most likely that the change ED made to ensure the Deck Crew was rendered to both eyes with Culling = ON needs to be followed by either ED or Heatblur to ensure the F-14 interior lights effects on the dashboard replicated to both eyes. Since Culling is now on by default since the last patch, all SteamVR , Windows MR and possibly oculus users should have this issue. I've tried toggling culling of via the lua, but the option can no longer be manually disabled (at least by the same line we used to manually enable it last patch). Hopefully this puts you on the right path and you can enable what ED did for the deck crew on your lighting. If they are unrelated, good luck finding it! Can't wait to gaze on your beautiful tomcat cockpit with both eyes at night yet again. A happy T-cat pilot, Slash
  19. BINDING REQUEST for F-14 PILOT POSITION I'd love to have bindings for all jester wheel commands, but the ones I want most are Radar Silent and Radar Active from the JESTER command wheel... Close behind would be Jester Setting TCS Narrow vs Wide (which isnt available anywhere today from the pilot seat including the command wheel). Finally, bindings for ECM OFF / REC / ACTIVE and FLARE MODE PILOT, FLARE MODE SINGLE , FLARE MODE MULTI. Thanks!
  20. I dont think FPS is going to improve with the 3090 over my 2080TI... but what WILL improve is how much PD I can run on my HP Reverb at the same FPS... I'll be cranking PD to 2.0 or more and enabling MSAA using a 3090 and I'm 90% certain i'll have the same minimum fps, which is most of what matters in VR anyway (maintaining 45 or 90hz).
  21. I'd like to do this as well. How do I go about it?
  22. Dear Heatblur, I'd love to have bindings for all jester commands, but the ones I want most are Radar Silent and Radar Active from the JESTER circle... Close behind would be TCS Narrow vs Wide (which isnt available anywhere today from the pilot seat). Thanks a mil! Hammer
  23. Do you guys have to reinstall the shaders or did they survive the patch if they were installed and working pre patch?
×
×
  • Create New...