Jump to content

Dave

Founders [premium]
  • Content Count

    513
  • Joined

  • Last visited

Everything posted by Dave

  1. I'm not agreeing with your assessment that anecdotal evidence receives little weight when I say this: The case could be made that the number of subjective observations supporting a point is far less relevant than the intent of and procedural integrity of the measurement being undertaken. In other words, all those Axis pilots who nostalgically recall flying their 109s weren't there with the sole purpose of objectively quantifying the handling characteristics and performance of their aircraft, both in absolute terms and relative to a database of other types. Nor were their "measurements" made in a remotely scientific manner. While we would be silly to discount them, they can't be considered in exactly the same light as the output of flight tests of captured aircraft, the purpose of which was to map as precisely as possible the envelope of the test aircraft so its weaknesses could be identified and exploited. As a side effect of the two different aims and viewpoints, test reports tend to dispassionately compare strengths and weaknesses, while pilots almost universally remember only the good things about the aircraft that carried them through the war unscathed.
  2. Based upon what exactly? Do you have stick time in a 109?
  3. If you fly VVS and are online between 0900 and 1300 UTC you are welcome to join myself and a few other English speakers on WOL. We use the BoS Official Teamspeak VVS English channel. Just as in WW2, teamwork decides most outcomes and sprogs need to start flying with wheels.
  4. There isn't enough room here for specifics of every possible combination of adversaries so I will make a far more generically useful suggestion: Get to know the strengths and weaknesses of your aircraft. Then do exactly the same thing in your opponents' aircraft. You should do this offline so you can "rinse & repeat" more frequently. Record the tracks and replay them to see what you did wrong. Every time you win or lose an engagement stop and analyse what happened and try to evaluate why it went the way it did. The AI aren't brilliant but when starting out they are good enough if repetitive and predictable. Once you think you have an understanding of what areas of the envelope are yours and which are your opponents, do some mental flying - start with a familiar situation that didn't end well for you. Try an alternate sequence of manoeuvres, this time also thinking how your opponent would counter each given your knowledge of his aircraft's strengths. It is important to actually fly the opfor aircraft so you see things from their POV rather than just relying on your perception of their strengths as seen from your cockpit. After you've done all this then you can make more sense of specific suggestions and decide for yourself how good or bad those suggestions might be. Also, don't forget the importance of your attitude (defensive/offensive), aggression and how these affect the behaviour of your opponent.
  5. This is reality. It is the tradeoff for the 109. The skill of the pilot is in accounting for it. The current FM seems much improved to me for all aircraft.
  6. I have subjectively noticed an obvious hit in VR with the mirror fitted.
  7. You probably don't understand some technical details of online multiplayer games. Most online multiplayer games use client-side prediction to extrapolate where other actors will be (from your perspective) within the next polling interval. Due to latency neither you nor your opponent have either the same, nor a "true" model of the virtual battlespace - there is no single "true" model. What most likely happened in this case is that from his point of view there was no collision, but from yours there was. Your game client dutifully destroyed your aircraft. His did not - because for him there was no collision. The "celebratory" shooting on his part was simply lag - from his POV he shot at and destroyed you. Real ramming is a very very rare occurrence. No-one wants to actually collide except in some rare cases where, out of ammo, a pilot desperate to prevent a bomber from succeeding may try to take off a tail surface with their prop. The likely reason you weren't nailed by 20mm from your POV was again - lag. Get over it - the Internet sucks for games where precise timing of globally-distributed events is important. It is a software engineering miracle that this game plays online as well as it does and there is nothing that can reasonably be done about this particular consequence of lag. Having given it a lot of thought I believe the solution we have is the most reasonable compromise and it usually benefits the attacker. So avoid head-on passes - its a crap-shoot anyway. If you fly LW it is more often than not working in your favour. It may seem fairer to destroy both aircraft on a first analysis but I encourage you to conduct some thought experiments yourself - it is easy to come up with ever worse player experiences given the root cause of the issue using your suggested fix.
  8. You went off half-cocked - a bit like I did. My earlier judgement of Pimax was based on the 4K which I tested - it was rubbish. I corrected these earlier misunderstandings of the Pimax 8K in post #92 after spending a few straight hours reading every detail available on the Pimax 8K. Thanks for the condescension - the link suggestion would have been fine without the supercilious remark. Now you're into territory of which you have patchy knowledge. Only the draw calls in DX11 are single threaded. Here is an intro to multithreading in DX11 if you are interested. Personally I'm not a fan of DirectX at all. Vulkan is my preference too but you will not see BoX running on Vulkan any time soon. DirectX is a much higher level API than Vulkan, which is even lower than OpenGL was. The work to port to Vulkan would be immense but would open the possibility of Linux and Mac ports. Vulkan, Metal2 and DX12 all allow parallel operations in submission of geometry to the GPU. This is a bonus for VR as it almost halves CPU involvement in presentation of frames to the display but it doesn't fix an application underutilising the CPU's parallelism. While Apple-specific this video describes this and other VR optimisations in Metal2 (some of which I think were borrowed from Vulkan). Incidentally Valve are development partners on the Metal2 framework and learning about it offers insight into modern rendering techniques targeting VR generally. FWIW I don't think AMD are significantly behind on VR support in their GPUs. They worked very closely with Valve and Apple (who actually are behind) in development of VR support for macOS and the Radeon Vega 64 kicks the shit out of my 1080Ti in raw processing power. Vega provides hardware support for single-pass stereo, multi-res shading and VR across multiple GPUs. Aside from enabling-architecture on the GPU most of this stuff is in software anyway and Vulkan is very well supported on Radeon. Stuff like LMS (well at least lens-matched scene masking) is already in SteamVR. Is the Vega64 the equal of a 1080Ti in VR? Not quite but the difference would not be enough to make me sell it and buy Nvidia. I bought the 1080Ti mostly because I have only bought Nvidia for years and felt that game support for Nvidia was very slightly better. I pay for that choice when dual-booting to macOS though.
  9. One major hurdle here is that C++ only added explicit language primitives for multithreading in the C++11 standard. I suspect (and this is based mostly on my own speculation given the age of the ROF engine and the development team) that BoX is implemented in C++98 and would need a wholesale rewrite to properly support multithreading. The level of difficulty in writing, and more importantly testing, concurrent code can not be overstated. After doing it myself for over 25 years I still have to be very careful and hurt my brain a lot when implementing thread-safe and performant data structures and algorithms, which is why smart developers don't - we use thoroughly tested and proven language support and concurrency libraries. Well these things are relatively new in C++ (the implementation language for most performance critical games).
  10. I am well aware of BoX's poor CPU parallelism but this really has little to do with the cost of rendering to two 4K displays over a single 2K display. Supersampling is not something we do because we can, it is required to get acceptable subpixel-like smoothing on low resolution VR displays and works because of the way downsampling works in our favour on the Vive and Rift DSCs and because our GPUs are capable of rendering most scenes at 4K resolution. SS does fcuk all on the CPU actually. It increases load slightly on the compositor which does use CPU time. But it drastically increases the framebuffer size, taxing the GPU in all phases of the render pipeline including and after rasterization (eg fragment and pixel shaders). It also increases memory bandwidth and transfer bandwidth demands on the GPU. This game is absolutely GPU limited in VR - largely due to the additional frame presentation timing overheads of outputting to VR displays (Apple had a very good presentation on the topic at WWDC17 on the MTL2 track). I currently play at a lower (supersampled) resolution on my Rift than I was previously playing on my 2560x1440 screens and it still runs like shit. Thats with graphics preset to High and all options set to Medium. On my screens I was running on Ultra with every option maxed. CPU utilisation hasn't changed at all. Honestly I don't care how hard the Pimax will push a GPU because I have another 3 1080Tis sitting on my desk. But the Pimax won't be the issue. The game will because it fails to optimally use two cards in SLI and fails to take advantage of vendor-specific VR support. The single threading is problematic but not for me because even my single threaded CPU performance is more than enough for this game. It would be nice if the game offloaded physics processing to my other GPU too - but it doesn't. It would be nice if the game used OpenCL or CUDA to accelerate parallelizable tasks on the GPU - but it doesn't. Not bashing the game - just telling you how it is. Having just spent a few hours digesting everything I can find on the web about the Pimax 8K, I have to say that some of my reservations with it were due to the shortcomings of the rather underwhelming Pimax 4K, and the 8K seems to have actually addressed all of them. I do like the modular architecture and the development potential that it opens up. I will probably buy one anyway just to see for myself - and maybe to integrate it with my Leap Motion. Its not truly 8K but it is still a much higher pixel density than my Rift. Hopefully BoX will improve to take better advantage of my GPU investment before December rolls around. Edit: I forgot to mention that Pimax 8K being in kickstarter really doesn't indicate immaturity as I suggested in an earlier post. The goal was a paltry $200K. That wouldn't even come close to paying for the R&D of a HMD and was more than likely just a PR play to get the internet talking about their product - which has apparently already been through one production run using Lighthouse V1 tracking hardware. I have read that devs and integrators can even get their hands on some limited stock of the Lighthouse V1-based units which are already warehoused but not going to market since Valve already shipped V2. Also, the extensible design of the Pimax 8K does already provide for pupil tracking modules which they have demonstrated contrary to my earlier assertion. This will allow software developers another out in the form of foveated rendering of scenes to drastically improve the perception of fidelity in the foveal region for the same or lower GPU load.
  11. There is way more to building a good HMD than increasing resolution and FOV. Oculus dump billions on Rift and that hasn't improved the CV1 beyond 110 degrees and 1080 * 1200 per eye. I really hope the new Pimax is a quantum leap forward but I'm not holding my breath. If you are at kickstarter stage then you aren't even remotely close to the high production quality I am looking for - more like a prototype with all the attendant issues. My 1080Ti still can't run this title at what I previously considered minimum acceptable levels of detail. Its only the low resolution that is saving it from not running at all. I have tried SLI 1080Tis but it actually ran worse. Nvidia have their own (sadly proprietary) VR SLI solution called VRWorks using the 10 series cards as a minimum where each eye is rendered on a discrete GPU. But You need DX12 to even use it, and then the developer must actively support it. There is no equivalent functionality AFAIK in OpenVR but DX12 does have limited support for non-SLI multi-GPU acceleration for VR. So even if Pimax 8K is everything we wish for you can't buy a GPU configuration that will run BoX on it. Caveat: Because most of us use supersampling anyway, it may be possible to not supersample and simply project to native screen-sized framebuffers, but this doesn't address the issue that you basically have to render two scenes (one per frustum) every frame. So until BoX uses DX12 or native VR SLI APIs like VRWorks I doubt the experience on Pimax will be any improvement over what we have with Vive and CV1. Note that the real issue with the Rift (at least for my taste) is not its smaller FOV - it is the pixels per radian. It is the painfully obvious gaps between pixels that create the eye-bleeding screen door. In this respect Pimax 5K promises no improvement. Where I expect Pimax to really fall short though is ergonomics. It is clear when you examine CV1 that a lot of thought and iterations have gone into the Rift. The tracking is close to perfect and the comfort, fit and finish are exceptional. Even with its level of refinement however it fails to support 100% of users ergonomically. Minimum inter-pupilary distance for the Rift is about 58.5mm (give or take) and Vive is about 60mm. For plenty of people that is just a bee-pube too wide. Close enough for short periods, but bad for your eyesight for extended play. Another issue with CV1 is there is no adjustable eye-relief. For me this means my eyelashes graze the lenses and it is very annoying. Vive was better in this respect but dimmer in the central region of the displays than Rift. I have more faith in an earlier-than-anticipated release of an incrementally better CV2 than an earth-shattering Pimax. Lets hope Oculus and HTC at least feel some pressure to accelerate their schedules. Edit: Where the VR leaders are focussing their attention at the moment is pupil tracking and foveated rendering. Oculus plans to implement this in CV2. HTC are also working on it. Pimax don't appear to be. Neither are StarBreeze. This adds a whole new level of packaging complexity - which is part of the reason for the long wait time for CV2 et al.
  12. Reinstalled the game - no difference. Reinstalled Oculus software - no difference. No Steam updates have happened in the last month so it isn't Steam VR. Australia is experiencing worse than usual Internet connectivity to Europe so I thought maybe - somehow - slow network is causing the whole game to lag - nup, even offline play is affected. Lowered my settings to Balanced - no difference. WTF is wrong with this game since the last update? Going nuts trying to figure it out for the only game I play. Can someone please tell me exactly and completely what was in the last update?
  13. Oculus app version is 1.18 - same as it was when it played well. Can someone at 1CGS please look into this. The game is completely unplayable for me on Rift with the hardware below. Graphics settings are high with all options on Medium, 2xAA, Sharpen. Symptoms are constant jiggling of the left and right images. And when I start the game now - every single time without fail I get two error messages about Authneitcation Server being unavailable and Master Server being unavailable. I dismiss the dialog and the game seems to work but for the massive graphic issues. I am now suffering a full reinstall of BoX (about an 8 hour experience thanks to the pitifully slow update speed). Can anyone reproduce this?
  14. Good to know - I will check - if it did there was no notification.
  15. Just updated today - and with settings that used to play smooth as butter the game is now unplayable in VR. Constant glitches, twitches, lag and dropped frames. The only system change between solid play and crap was the update. Updating to the most recent Nvidia driver made no difference. Win10 Pro i9-7900X EVGA 1080Ti Rift I was using 1.6 x supersampling (in Oculus debug tool) with ASW disabled. I removed the supersampling override in Oculus debug and instead set SS in SteamVR (set it to 3.0) and the twitching (image shifts rapidly left and right - often only in one eye) stopped but I instead get many dropped frames (jerky screen updates) as soon as I get near anything - either terrain or other aircraft. I've given up playing for now. It just hurts my head too much.
  16. http://www.planepicture.com/ Just a small sample ... And one for my friends on the other side ...
  17. Tripped over this today - quite old - old enough to include lots of interviews with pilots, crews and engineers. "Spitfire!" produced in 1976 by BBC South. Does anyone have a link to a better copy?
  18. Rhubarbs were very low level interdiction missions flown by RAF fighters over France in the lead up to and following the D-Day landings to disrupt the Wehrmacht's ability to resupply its troops. The sorties were usually so low to avoid detection that navigation was mostly by compass and stopwatch. On the outbound route they would avoid firing; on return from the primary objective they would use remaining ammunition on targets of opportunity. My favourite form of air-ground mission.
  19. Jesus - you know I didn't say that. If you had quoted with context you'd also have noticed that the point of that observation was to note that [/i]when we are defensive[/i] it exacerbates another issue - not to state that being in a defensive position is itself the problem. That's great for them but shit for the rest of us. You'll note that my post isn't in the Russian forum.
  20. This introduces another difficulty for the Yak pilot. Most angles plays require very precise timing, and the Yak pilot is more often than not defensive due to not being in a position to disengage at will like a 109. Both of these factors compound the negative effects of network latency for the Yak - because he is the defensive fighter and using timing-sensitive tactics. 1 v 1 it can still be managed by guesstimating the lag. But being defensive and unable to disengage keeps you trapped, unable to escape while the bandits reinforcements arrive. Then it becomes a lot harder very quickly. The only rule of thumb I have for 1 v X is to try to keep all the bandits on the one side of you to help you maintain SA. If you couldn't land a shot early on you should probably have tried to turn cold-side after an overshoot and bug out in the weeds. Remember tracer is visible for miles. So how do you avoid the possibility of his buddies turning up with massive energy advantage? Climb so that you are above them to begin with ... oh wait. Honestly the only really reliable tactic is to fight as part of an element or flight, but because the majority of career sim pilots have chosen to fight at an advantage the VVS is mostly populated by loners and air-quakers. I say mostly - there are those who fly together but the game really doesn't do much at all to support let alone encourage this very important historical aspect of air combat. I think this is actually the game's weakest area at the moment.
  21. While it might be a common sight (I have only seen it once or twice) it can't possibly be an effective tactic. You simply can't "hang" on your prop - thrust to weight is well below 1. Anyone stupid enough to try it is just making themselves a very slow (briefly stationary) target with zero control until they fall and regain maneuver speed. People who complain about it have just been shocked to learn that going vertical without sufficient speed to quickly exit guns range can't outrun bullets. But it's a very low probability gamble for the pursuer given the cost of failure is being out of airspeed and defensive below a higher energy bandit. I've reread your description and it seems your intent was not to describe the maneuver I am referring to. I had a 1 v 1 picture in mind, but I see you were describing a 2 v 1 defensive position with the offensive single sandwiched in a turn - still not drag and bag though as an actual drag'n'bag really requires airspeed superiority to work. It relies upon the lead aircraft pretending he can be caught by the "offensive" bandit but stringing him along fixated while the wingman with superior energy closes rapidly for an undetected kill. What you describe is a sandwich which relies on geometry and can be easily evaded by the higher energy bandit. The energy trap is a 1 v 1 defensive maneuver where the slower or angles fighter is out front and uses geometry to graduallly increase angular velocity while increasing closure to force an overshoot with a bandit fixated on trying to maintain pure pursuit. The angles fighter needs to manage energy to stay at or above corner speed until the overshoot and reversal so that he can avoid an energy depleting guns defense and outturn the bandit for a low deflection shot at the overshooting bandit. It is tricky to get right as the angles fighter needs to passively manage the bandits energy as well to minimise their overshoot speed, still generate an overshoot and maintain enough angular velocity to prevent the bandit from gaining lead all while trapping them into thinking they can pull lead if they just pull a little harder and burn energy. It is actually energy fighting in an angles fighter and can be equally thought of as being offensive while in front. It's the classic card for a slower but better turning Yak to play when 1 v 1 with a 109 but as I've said before it is very easy to misjudge given that we play online with varying connection latencies. I get shot down a lot performing this maneuver - usually by an opponent who doesn't appear to be pure pursuit let alone leading. On local servers it works every time.
  22. I understand the point you are trying to make - the additional mass of the 190 requires more energy to climb. My contention was with the assertion that they were co-energy - which they were not.
  23. Thats not a "drag-n-bag" its an energy trap to force a flight-path or wing-line overshoot. Which, incidentally, is your most accessible tactical play in a Yak because the bandit will almost always be behind and above you with excess airspeed, and simply legging it isn't an option. Note that it is very difficult to consistently pull this off if your ping is shit, due to the difficulty in judging the hard turn with ~400ms of lag and the game using what would appear to be client side hit prediction calculated by the shooter. For the OP: If you can manage to turn to the bandit's cold-side following either a merge or overshoot, and either they are overloaded with other threats or the turn happens to take you downward against terrain that hides you long enough for them to lose sight, bugging out may be possible. But this is generally not the case. If you can't bug out you WILL have to turn and fight at some point - its just a question of if, when and how you are able to effect it. I find the J-hook energy trap to be most effective with a single opponent and even with 2 if they aren't well coordinated. But as I said above - depending on lag this can be hazardous. There is no by-the-numbers maneuver that works. You have to judge each situation and your opponent and make tactical choices on the fly based upon how shit is going, how sloppy or good your opponent is, how much energy you can afford to spend on an angles play etc. You don't always have to turn fight a 109. It is possible to energy fight the energy fighter in some circumstances but this takes a lot of practice and much more skill and patience than for the 109 pilot. It is usually not possible due to the circumstances not allowing you the time needed. Whatever tactic you choose in a Yak you need to get it over and done quickly before the rest of the LW turn up.
  24. Obviously, but the problem is that for VVS this is much easier said than done, so it starts to sound pretty patronising after a while. Not even close. In the scenario described the 190 has more than 50% more energy. Kinetic energy is proportional to mass. So is potential energy due to elevation. So at the same altitude and speed the 190 has 4420kg/2880kg (or about 1.53) times the Yak's energy. So the Yak is already at a significant disadvantage. The 190's initial zoom climb is MUCH better, due to momentum (which is again proportional to mass). Its power-to-weight ratio is close to identical and its sustained climb performance is so very slightly less than the Yak's (about 3% - at lower fuel load it may even be as good or very slightly better) that the deficit will never overcome the advantage built in the initial zoom from 3000m. Pop flaps???? Are you mad? Flaps == drag. Not something you want when trying to outclimb someone. NB: I used the 190A-8 mass from wikipedia as I don't have the 190A-3 value at hand.
×
×
  • Create New...