Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It's all very simple actually. Whenever you release the trim button, your physical FFB joystick should be trimmed to the current physical position of the joystick. That's the whole point of using a FFB joystick. That physical position will translate into some in-game position after going through whatever curves and saturations are set if any, that's a different story. But the trimmed position should correspond to the actual current position that the joystick is reporting in the moment of releasing the trim button since that's what trimming means. I see I'm failing to get the message through as ED is not seeing it as something that needs to be fixed and moved the thread from bugs and problems. I use simffb with DCS because of the very thing I'm explaining here. Also some people enjoy the extra immersion of that dampening/friction effect provides over the spring effect alone that feels just like that, a stick connected to springs and nothing more.
  2. I use SaturationY to reduce the sensitivity of the stick without losing the linearity. Unfortunately, with SaturationY the force trim does not trim at the position of the physical FFB joystick. There's is a gap between the current physical position of the joystick when releasing the trim and the new trimmed position that gets bigger the more saturation values are used. Actually, is a problem in all modules that has the ability to change the neutral position of the FFB joystick when you trim, both airplanes and helicopters. For years I've been using simffb as a workaround. But I thought it would be a good moment to report it now that the Apache has so much visibility.
  3. I was thinking about a possible cause. I wonder if, perhaps, the mirror view is messing with Window's process scheduling, which is already not that great for games to start with, and less so for VR.
  4. There is this ctrl+f2 camera that I didn't know about before, so I'm not sure if it was already there, but it seems to be similar to the free camera but attached to the frame of reference of the object. I wonder if this is the one that the changelog refers to.
  5. Same thing. I've been noticing this for some time and every time I do some googling out of frustration I get the same results with no fix or suggestion that works, and not even some sort of theory about the reason this happens. Extremely frustrating.
  6. Just me fiddling with the settings just in case they could have any effect. Also, it amuses me how with too much sharpen the image looks like old analog TV, kind of trippy in VR.
  7. Above the magic altitude number (11215 ft) Below that If you can't reproduce it then it's something on my particular setup I still haven't isolated. I'll try to find what it is by myself.
  8. Interestingly, now the scratches are rendered at the correct size below 11215 ft and are replaced by the bigger version above that height. I provide a track. scratchesII.trk
  9. Hi. After checking everything I still get those scaled canopy scratches. I'm attaching a track. There is another ignored performance bug with the crew of the supercarrier. I wonder if it can be approached the same way than the problem with the craters and fix it in the same fashion. scratches.trk
  10. I knew about this mod recently when asking about any fix for the poor performance of the craters. As far as I can tell only the CBU fix is activated but I get scratches like this in the canopy glass: As I'm still unfamiliar with the mod I'm a bit lost about why the scratches are resized like that.
  11. I enjoy the view angles that the F4 view provides, so I use it quite often. And also I often change the point of view while I'm in the F4 view. It would be great that whenever I switch back to the F4 view the position of the camera persists where it was when switched to another view for the rest of the flight. Edit: I'm really bad at this thing of putting the right words in the right order... I meant, if you've been playing around with the F4 view and then continue your flying from the F1 view, when going back to the F4 view the position of the camera doesn't reset to the default position of the F4 view but stays where it was before. Furthermore, I'm sure that people doing DCS videos would appreciate something like that.
  12. I wonder... no tester is seeing this problem? Any retinal conflict is pretty obvious and annoying in VR.
  13. Now that you mention, I also think that the glow of the clouds when the sun is behind them is exaggerated. It seems to take a lot of clouds to stop the glow of the sun from coming through compared to real life. Although it may be that in real life I just don't stare at the dazzling glow of the sun when the layer of clouds is too thin to stand it. Actually, I'm not comfortable anymore with this kind posts based on "feelings", but just in case ED finds it useful, there it is.
  14. I just did a track with the latest OB. What I see when I play the track is what I described above, and same as OP. I don't know if it may be different for others. yak52turnind.trk
  • Create New...