Jump to content

Pikey

ED Closed Beta Testers Team
  • Posts

    5335
  • Joined

  • Last visited

  • Days Won

    4

6 Followers

About Pikey

  • Birthday 03/18/1973

Personal Information

  • Location
    Reading, UK (GMT)

Recent Profile Visitors

63034 profile views
  1. You could probably write a server side script that forces the client into a slot when one dies of either plane. That would make the mission require 4 slots, two each side and when one dies both are abruptly forced into a new slot, but honestly that quite forceful on people and just hitting escape and picking a slot isn't such a hardship that could give a VR user a trauma.There aren't any mission side API controls to do this from a Mission script. You could make the cockpit unuseable by shoving a picture up that blcoks the view, or destroy the other plane too, none of it is elegant. Also depends on what you really want to achieve.
  2. Just to help out the explanation because the problem wasn't immediately fully understood. Ground units at least, possibly more kinds are substituted for a "static type unit" when they recieve terminal damage, i.e. when they are on flames, no health and 30 seconds later explode. A lot of scripts rely on knowing when something has died so it can be respawned or an activity takes place as a result. This is a fundamental scripting trigger and one of the most obviously used. It has been used for over a decade, and over these years many scripts are created to leverage the fact that something 'died' in the mission. Due to the change of the type of unit that explodes, DCS creates a dead event but its not the same unit type and is missed because it is a static. Depending on the coding, a script can hit or miss this, but at least as far as I know any script created with Moose prior to today (5/6 years worth) will fail to recognise something died in game. We implemented a workaround where we have to examine a static dying and check it wasn't a unit and all sorts of messy and un hygenic workarounds to get it going, but the impact post today remains the years of work people have created using Moose will fail to recognise a dead unit as a result. I dont have an assement for the AGME or Mist or custom SSE scripting related scripts. What the ask is, is to have things as they were before, that when a unit dies, it doesn't change its type, in order to preserve the thousands of published player scripts that are downloadable on the forums and web site. Thanks.
  3. For the record, the MOOSE community were not consulted in this request. Rather than derail the ask, I intend to aggregate the votes of the 1900 active members on the MOOSE Discord and summarise what people are asking for, since everyone will always have their own wishes and I've long since given up assuming I know what people actually want. I doubt any of them will have considered ways of identifying a forest though.
  4. No way is it a cheat! Us simmers are deprived of body feedback! We are instrument gods. Could you imagine flying with right rudder in a real plane feeling squashed up against the left wall uncomfortably. In the sim, we look for a slip indicator... sometimes. Natural G force being absent makes it much harder, but flying a plane to it's limits is 'felt.' It's even used in teaching manuals, the USN use the phrase taking a bite of the buffet and include trying to understand the literal feeling of a plane at various AoA's. In dogfighting, with a small view space, when padlocked onto an enemy plane in the roof of your cockpit, you have almost no sensation of what slow is, in the context of AoA. A haptic replacement only partially meets what is available to the bodies sensation when flying vigorously.
  5. Hi, I didn't go much further but its great to see people expanding upon this hobby and anything you add is no less than awesome. So, it's true what you say, you don't "need" to have a 1:1 signal to make something more immersive. For example any signal to any part of the body almost that something is happening in game adds something. The closer it is to real world, the better. I haven't stalled an aircraft to feel buffet but its well documented. The issue is perhaps more from plane to plane. Some planes show a lot of buffet before they stall, others snap a single wing quickly without warning. Each AoA for each plane will be different. But they should exhibit common signbs, which is a vibration, its basically disturbed airflow over the wing at too high alpha so its bumping throughout the airframe. Rmemebering you can stall one wing you can have uneven feelings irl, but not somehting I think the exports can handle in DCS. It's easy to imagine uneven airflow, everyone has been in a jet liner when it goes through turbulence. https://www.youtube.com/watch?v=yFl6I_a3njg This one is more stall related, but a good example of stall without buffet. So, the TLDR is that it may be very complex to assess the buffet amount and strength for each moment of AoA for each aircraft as its attached to the FM. For haptic arms what about rollrate and yaw? might be soemthing that can be done. HTH good luck making something!
  6. Thank you for your suggestions I tried them. I feel like changing my Facebook status with OpenXR to "it's complicated" The settings at 80% you provided did get MP into the 40's and workable, so that's a thing. Frames are enough, even tested on Blue Flag Syria with an Apache and its high 30's (but not into 20's) which with OpenXR is better behaved than SteamVR by a large amount. So this is a bottom line, with the tracking enhancement I'm keeping it with the following issues. - Water to medium is a hard sell - it makes sense to look at Baileys startup shortcut maker to have that launch on demand. It's a big loss for me for when I look at it. - Cockpit Global illumination I really miss and it also causes some oddities in the game - I've had bright lights - that's not VR's fault, but its a less tested config and I'm going to be busy reporting some horrid lighting bugs for a while, including "Bright white ocean", and "Cockpit under a spotlight" - There's a small distant shimmer, especially with complex clouds at Medium visibility. I need more pixels on screen to resolve that, it's where this is. I'm using NIS and unlocked frames. - pixel detail is bang on minimum acceptable for cockpit reading, but I get high textures, so its give and take. - Chimney and clutter - somewhat irrelevant once completely gone, so a good saving. - AA is x16, I always thought that was fairly cheap, but ED's stock VR has it reduced to 4. Any lower and the runway end turns to mush FPS comparisons for OpenVR and SteamVR are like trying to convert GBP to EUR. A little less OpenXR is equivalent to higher SteaVR FPS, but the tracking and comfort are light years apart. My brain has become so tolerant of all the jerky shaking and stuck moments in WMR ,that putting OpenXR on was like a bandage to the senses. It reminds me of Occulus Rift tracking actually. The Rift had this ability to handle low frames way better than the HPO Reverb with its stations. WithRrift you could have 10FPS but your head still tracked. I don't understand the technical detail, but the tracking for Reverb is dogsh1p - you build up this tolerance to discomfort and just put up with it because you have to. Developing an immunity is no substitute for a gentle experience. I might never reach the pixel density on this card to give me a good horizon for spotting, but it should make me less exhausted. I hope this project continues, if its me, I could trade some of that tracking for some CPU and the end result of more pixels, as it is, I think after a very long battle with settings I will keep OpenXR. Thanks.
  7. sorry to interupt, but I get dead events for the instant kills and slow burners. Is there a more concrete type testing to perform to accept this as officially fixed?
  8. Yeah its close... I think my conclusion is that if you have the system to support it, its superior, with the lack of steamVR items like fpsVR included in that statement, but for MP and lower specs it's ending up losing out on the grunt to carry it up to minimum FPS play. It definitely tackles texture related nonsense, i've even found it more stable with an old bug/thread where swapping cockpits would eventually break SteamVR and cause a black screen. It's really killing me, but the actual result when trying to play on Blueflag is that the overcompensation on smoothness ends up looking like your HMD turned into an eel swimming through jelly. Super sad about this because it tackles nearly all the basic issues with SteamVR. The irony is that if you take down the quality settings it doesn't really affect OpenXR like it does SteamVR. OpenVR remains very stable on frames, both up and down. For example I cant get it over 55/60 FPS and Steam would hit 90 in game, and going lower, SteamVR recovers quickly from troughs of poor performances, where OpenXR seems stuck in the mud. It's like SteamVR took a chill pill. Long wait until 3xxx series GPU are acceptable price for me. But people should really ignore the noise in the thread and just follow the instructions - it's one quick default install and swap three files into your DCS directory, how that can be screwed up I just don't know, also the OP didn't do any favours with the conversation, people don't read that, apparently over 4 lines and you are passive-aggressive these days...
  9. I'm so torn by OpenXR. It gives and takes and I think its just having not enough hardware that's letting me down. i5 10600K and 2080S. I reinstalled things and spent more time using it than benchmarking it and I warmed to it. The way I have found it is that the tracking is the most amazing improvement. Soft in turns, doesn't stop if turning your head fast or at extreme angles like looking down and to the side, the actual tracking issues solved from SteamVR, never have to recentre at the start. But the loss is pure frames and CPU frametime. I cannot explain it. This means that going into MP I get the frames descend into the danger zone and things start to go wrong from then on. Offline, I think its better than SteamVR and in MP it wont get up high enough to guarantee 30FPS all the time. A lot of 3xxx series owners claimed this is just scoring points needlessly as if frames don't matter, but when you are clear of the low frames the benefit of the tracking without loss becomes way more obvious. Pros: Tracking is awesome, smoother turning, get rid of Steam, can change settings with Dev tools on the fly, better offline compraritive performance, easier to play with, starts faster, popular community effort. I think (and its impossible to benchmark) it behaves much better for low texture memory usage. I found the F14 which was notoriously heavy and juddery was smoother and mor eenjoyable to fly. Cons: FPS is lower, it struggles worse at low FPS than SteamVR at the same FPS, can't use fpsVR, its a mod and resets with updates, appears to be more CPU bound and performed badly in MP, some of the settings in the Dev tools dont seem to work well or at all Whatr I do know is that you cannot compare them well, I thought I could, but I cannot.
  10. Just for a point of clarification. You use saturation to change the sticks limits versus the in game one, meaning that there is no 1:1 for real position to game position, but you want that "reset" to neutralise at the point of the trimmed state every time the stick is trimmed so that the accelerated coordinate provides the same accelerated feeling at the new trimmed position? Let's call this, "Dynamic saturation". Makes sense to me if i understand well enough. I'm not sure how simffb works as I read it it sounds like its to do with the forcefeedback rather than the acceleration. Would this work with curves too? For exmple if you have curves allowing precision at the stick center, do these then travel with the force trim too? I can definitely see how making any changes to the stick curves that break from 1:1 would mess up the feeling of trim, but I feel that its a bit of a crutch, since a real stick doesn't gain precision every time it is moved. but since its so artificial anyway, why not. Unless I completely misunderstood, in which case, please correct and explain
  11. Can you see anything in the mirror or is this all derived from in headset comparisons? I don't see the difference. What is actually changing? To be precise I see the same thing but with the OpenXR I get up to 30 frames less than with SteamVR and I can literally see the stutter in the mirror. I don't understand how I seem to be th eonly person who gets worse performance?
  12. it's literally an OVGME double click on/off once the OpenXR dev tools are installed. It backs out and in perfectly. I also tested DCS repair, it removes to the original also and takes less than 45 seconds to do one on NVMe. Simplest thing to add, but obvbiously you have to readd it each DCS update. Classic gotchas are running SteamVR, or a repair afterinstalling. Will cause a Black screen. That's it. I still don't understand the benefit yet, in the HMD i'm not seeing the difference. I wonder if the placebo is caused by the DCS repair?
  13. PD and SteamVR Super Sampling are not the same code but they are the same thing, more pixels/resolution. Community has swung on when is more performant, the only consensus I recall is lower PD and use higher SSS. I use 1.0 and I can go to 130% on Steam, depending on mission. SInce DCS is in open development this can change. The only way you can get a juddery mess in the menu system is by wrecking something outside of DCS. In the menu system most people will get 90 fps until maps and such get loaded in. If you meant something completely different with the word "menus" then please be more detailed, since you can get issues joining servers in MP if they are struggling under certain circumstances. Target frames sub 30ms. outside of MP you should have a lower CPU frametime, inside a MP mission the CPU will begin to overtake and thats when performance bottlenecks elsewhere. You target what you play in consistently. The main change is what you play, not so much your settings unless you do something crazy to the supersampling. Aim to keep CPU and GPU frametimes together. Often to rescue VR performance restart the PC, fo some reason, it can sometimes go into a mess for no reason. Can be affected by latency to the server even, I've seen people mass join servers, server starts to drop frames, players start to drop frames and its nowt to do with the graphics. One of the worst offenders people moan about is on patch day when their shadres recompile and there's a juddery mess. Can watch that in the dcs.log The simple solution to that is allow your PC to run some heavy unit missions offline in 2D until it stops ebfore trying to run that in VR.
  14. Sure, except I benchmarked a track file offline. With the Steam VR I could measure framteimes in the baseline and the Cpu was all green from fpsVR. Am I supposed to see an improvement in frames, I felt from the OP I should? I can say I saw less peaks when I drew out the graph. Has anyone in this thread done before and after benchmarks?
  15. Hi thanks for your response. The loss of 20 FPS when you can dip lower than 45 is damaging to me since the screen is a juddery mess at the 22.5 fps mark which can be reached quite often in big MP servers. For everything not data related It will remain my opinion which is unaffected by your own. VR with DCS is about headroom. MP requires it. I spend most of my time sub 45 frames. The benchmark I used for the tests is offline so the headroom illustration is important. Offline players have less to concern themselves with as they tend to stick to optimised playing configurations. We aren't talking about negligble performance gains, I am citing a recorded straight up loss of 33% against SteamVR. WHere I had 90, it was 60. That theme continued when frames dipped to 30 and I got 20. If this doesn't bother anyone then my post shouldnt be of interest and can be safely ignored.
×
×
  • Create New...