chihirobelmo

Try calibrating your monitor. I often calibrate my monitor referring to this gamma chart. https://translate.google.co.jp/translate?sl=ja&tl=en&js=y&prev=_t&hl=ja&ie=UTF-8&u=http%3A%2F%2Fwww.geocities.jp%2Foredisc%2Fmemo%2Fgamma%2Fgamma.html&edit-text=&act=url The webpage recommends to adjust the monitor to Gamma=1.0 but usually 1.8 to 2.2 works. See the checker images at the bottom of the page. You first have to reset any sharpness setting of the monitor as it prevents checker pattern from disappearing even the calibration has been corrected. Also, any non-default or non-standard color mode might prevent your calibration to be completed. First, try adjusting the monitor to make checker pattern less visible as possible as you can, then go to Nvidia control panel and adjust brightness, contrast, and gamma there. Adjust hardware first, then go to software. In DCS UI. Set Gamma number same to which images you referred to. If you used Gamma=1.8 image to calibrate the monitor, than set it to 1.8. Turn DS ON and Global illumination ON.

Well, here is the previous discussions. https://forums.eagle.ru/showthread.php?t=157129

Actually, what FalconBMS has is a bit different to what OP suggests. BMS's mouse cursor usually works just as same as DCS when it is not over any clickable switches, It just keeps same XY coordinates on the screen. When it "slowly" reaches close to a switch, it will gravitate and anchor to a switch. Like golf ball goes into a hole when it reaches the edge of it. After the cursor anchor, it stays in the center of the switch even you pan your view. Moving the mouse with an appropriate speed, the cursor leaves the switch and back to normal behavior. If cursor approaches or flies over a switch with an appropriate speed, it will not gravitate nor anchor to it. If Mouse move has been detected and the last cursor heading is not shown on the screen, the sim can just pop up the cursor from the center or the edge of the screen. Or somewhere appropriate. Anything can be programmable...

Okay, I recently moved from Freetrack to TrackIR, I was forgetting I had HeadTracking.dll at /bin folder. I have removed it and repaired DCS. Now it works fine. The thread below helped me. https://forums.eagle.ru/showthread.php?t=169154

Completely reinstalled open Beta, It still crashes on launch.

Every time I launch DCS. DCS.exe will appear on the background process lists of Task Manager for a second and disappears from there. It never launches anymore. Repair won't help. No modding. Using Only Windows Defender for anti virus. === Log opened UTC 2017-12-18 15:10:54 00000.000 INFO VFS: Using 'Saved Games': "C:\Users\chihirobelmo\Saved Games" 00000.160 INFO DCS: DCS/1.5.8.12667 (x86_64; Windows NT 10.0.16299) 00000.160 INFO DCS: DCS revision: 132665 00000.160 INFO DCS: Renderer revision: 14969 00000.160 INFO DCS: Terrain revision: 14987 00000.160 INFO DCS: CPU cores: 4, threads: 8, System RAM: 16341 MB 00000.171 INFO EDCORE: (dDispatcher)enterToState_:0 00000.176 INFO Dispatcher: 2017/12/19 00:10 V1704040900 00000.191 INFO INPUT: Device [Keyboard] created deviceId = 1 00000.198 INFO INPUT: Device [Throttle - HOTAS Warthog {1DD12FC0-718F-11e7-8002-444553540000}] created deviceId = 2 00000.198 INFO INPUT: Joystick created[Throttle - HOTAS Warthog {1DD12FC0-718F-11e7-8002-444553540000}], ForceFeedBack: no 00000.217 INFO INPUT: Device [Joystick - HOTAS Warthog {1ACA3150-718F-11e7-8001-444553540000}] created deviceId = 3 00000.217 INFO INPUT: Joystick created[Joystick - HOTAS Warthog {1ACA3150-718F-11e7-8001-444553540000}], ForceFeedBack: no 00000.217 INFO INPUT: Device [MFG Crosswind V2 {191699E0-710B-11e7-8009-444553540000}] created deviceId = 4 00000.217 INFO INPUT: Joystick created[MFG Crosswind V2 {191699E0-710B-11e7-8009-444553540000}], ForceFeedBack: no 00000.220 INFO INPUT: Device [Mouse] created deviceId = 5 00000.222 INFO EDCORE: try to write dump information 00000.223 INFO EDCORE: # -------------- 20171218-151054 -------------- 00000.224 INFO EDCORE: 00000.225 INFO EDCORE: # C0000005 ACCESS_VIOLATION at C28318B0 00:00000000 00000.227 INFO EDCORE: 00000000 00000000 0000:00000000 00000.230 INFO EDCORE: C28318B0 00AFF470 0000:00000000 00000.231 INFO EDCORE: C32FBACF 00AFF4B0 0000:00000000 D:\Games\DCS World OpenBeta\bin\Input.dll ?applyUpdates@ForceFeedback@@AEAAXXZ()+7AF 00000.232 INFO EDCORE: C32FB754 00AFF4E0 0000:00000000 D:\Games\DCS World OpenBeta\bin\Input.dll ?applyUpdates@ForceFeedback@@AEAAXXZ()+434 00000.233 INFO EDCORE: C33027A3 00AFF5A0 0000:00000000 D:\Games\DCS World OpenBeta\bin\Input.dll ?isHeadTrackerDeviceAttached@Input@@QEBA_NXZ()+3B23 00000.234 INFO EDCORE: C33024EC 00AFF6B0 0000:00000000 D:\Games\DCS World OpenBeta\bin\Input.dll ?isHeadTrackerDeviceAttached@Input@@QEBA_NXZ()+386C 00000.234 INFO EDCORE: C32FE548 00AFF700 0000:00000000 D:\Games\DCS World OpenBeta\bin\Input.dll ?initialize@Input@@SAXPEAX@Z()+148 00000.235 INFO EDCORE: C13BB63B 00AFF7E0 0000:00000000 D:\Games\DCS World OpenBeta\bin\DCS.exe 00000.235 INFO EDCORE: C10421DE 00AFFE90 0000:00000000 D:\Games\DCS World OpenBeta\bin\DCS.exe 00000.236 INFO EDCORE: C154AB73 00AFFED0 0000:00000000 D:\Games\DCS World OpenBeta\bin\DCS.exe 00000.236 INFO EDCORE: F51D1FE4 00AFFF00 0000:00000000 C:\WINDOWS\System32\KERNEL32.DLL BaseThreadInitThunk()+14 00000.237 INFO EDCORE: F5E5EF91 00AFFF50 0000:00000000 C:\WINDOWS\SYSTEM32\ntdll.dll RtlUserThreadStart()+21 00000.308 INFO EDCORE: Minidump created. From Windows Event Viewer - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Application Error" /> <EventID Qualifiers="0">1000</EventID> <Level>2</Level> <Task>100</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2017-12-18T15:10:54.248373000Z" /> <EventRecordID>1299</EventRecordID> <Channel>Application</Channel> <Computer>DESKTOP-chihiro</Computer> <Security /> </System> - <EventData> <Data>DCS.exe</Data> <Data>1.5.8.12667</Data> <Data>5a33941b</Data> <Data>WorldGeneral.dll</Data> <Data>1.5.8.12667</Data> <Data>5a16cb00</Data> <Data>c0000005</Data> <Data>0000000000054cb4</Data> <Data>3a4</Data> <Data>01d3781265a6aa94</Data> <Data>D:\Games\DCS World OpenBeta\bin\DCS.exe</Data> <Data>D:\Games\DCS World OpenBeta\bin\WorldGeneral.dll</Data> <Data>860f886f-f458-4b21-bc4d-35928b858e8c</Data> <Data /> <Data /> </EventData> </Event>

I just got the same problem in 1.5.8 too.

I already have calibrated my monitor with nVidia Driver to get collect color and brightness curve. In my case, I referred to the following URL. https://translate.google.com/translate?sl=ja&tl=en&js=y&prev=_t&hl=ja&ie=UTF-8&u=http%3A%2F%2Fwww.geocities.jp%2Foredisc%2Fmemo%2Fgamma%2Fgamma.html&edit-text= Gamma calibration has been already possible for DCS(or for any other sims) as it is the matter of monitor settings. Then what is the point of implementing gamma setting per sim? I am afraid new Gamma slider setting will be adjusted by anyone's favor to get "tally more easily" rather than adjusting the color to provide you "what vision developers think is close to real". Well, it is okay for me some individuals adjusts there environments to win the game rather than simulating. I hope ED is developing there graphic engine to provide us what they believe is the most realistic visibility when properly calibrated monitors were used.

How tally distance change when you reduce your Windows resolution to 1080p with your 4k monitor? I don't think sharper image without larger pixel size(as close as possible to 1:1) helps to find a target that much. I hear from Oculus user that finding a target is not a problem even they feel they need more resolution for VR.

+1 !

It was so from before. Finding dots 7-8NM away is easy if planes are at the bright part of the sky. This was captured before the latest update.

Thanks for the good news. Looking forward to seeing the next update. Perhaps it would not be needed anymore if the fix worked but I just have finished my video so I uploaded here. The video is showing results of both ideas what if SmartScaling enabled for DCS, and what if Dot Overlayed to 3D model.

That is also believable depending on aircraft size and air condition but would like to see the quotation and research title... FOV zoom until 20-degree in-sim also seems too easy to keep visual though it is trading off the sense of attitude. In some hard-core server, it should be limited depends on the resolution.

Sorry quoting this from an indirect source as original papers could not found on the Internet but again from Serfoss 2003 it was said... Reading also several other quotations on the paper it seems about 3.0nm would be an average detection distance to find the F-5/A-4 size target when you do not know where they are coming from, and 5.0nm If you already know where they are. Not sure about air conditions for each research.

Again, whether it is VR or Monitor the important idea to concern whether the image is providing 20/20 acuity, is whether the imagesize+headposition is providing enough resolution to define 1/60 of a degree for your real vision. At the same time, in-game resolution+FOV has to be enough to define 1/60 of a degree for an in-game image. If pixel size is 0.078mm(iPhone4-5) seen from 26cm distance would be 0.000078(m)/0.00026(km)=0.3(mil) =1(minute) =1/60(degree). If pixel size is 0.311mm(27inch 1920*1080 monitor approximately) seen from 1.04m distance would be 0.000311(m)/0.00104(km)=0.3(mil) The human eye has a short-range vision and a long-range vision so even if you see a pixel when you close to the monitor that might be because your short-range vision is finer than 20/20 even if you are not so good at the long-range vision. http://lookafteryoureyes.org/eye-conditions/short-and-long-sight/ Anyway concerning your head position to match in-game FOV is simpler than concerning your head position to match visual acuity for the monitor. As because if in-game FOV+Resolution matches 20/20 acuity then simply put your head position to match monitor FOV also matches 1-pixel size to seen 1/60 degree. For VR monitor, the Device-HeadPosition FOV against In-game FOV is already matched and no need to concern your head position against the monitor size. Only a resolution against FOV would be a problem.

It is medically defined that If you can see 1 min arc of a Landolt C or E chart gap you can say you have 20/20 eye vision. http://webvision.med.utah.edu/book/part-viii-gabac-receptors/visual-acuity/ I guess it is because VR gears have 110 or higher horizontal FOV. For 110hFOV at least 6600 width resolution might be needed to achieve 1 dot for 1 min. In such a wide FOV Perspective Distortion should be stronger and calculating 20/20 eye vision equal resolution, might not so easy. At least the center of the image will have 20/20 eye vision by this simple calculation (hFOV * 60).

Hi ST0RM, So you have an experience of flying RW air!? I recently have asked a question at F16AMA how things can be seen in SIM vs RL. The answer was "It depends on Atmospheric Condition" I agree it should be like that. https://www.reddit.com/r/falconbms/comments/5xkfd3/askmeanything_with_a_real_life_viper_pilot/desn8va/ I also would like to hear more from others who sees aircraft daily in Real World and also is familiar with SIM too. I assume that For 4K resolution, hFOV64 would be enough to get 20/20 eye vision equal Acuity(1dot=1min if not take Perspective Distortion into account). and for hFOV64 the monitor width*0.8 distance would be where you see things Real Size. The assumption is coming from following URLs. http://webvision.med.utah.edu/book/part-viii-gabac-receptors/visual-acuity/ http://www.mathopenref.com/isosceles.html Other than Acuity and Size, Contrast/Haze/Glints should affect visibility. So with above condition(4K/64hFOV/proper distance) how SIM is correctly representing those elements might be predictable. Could you give me how you feel SIM is different from your experiences?

Another interesting reasearch article I have found recently. http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0005594

Or close your eyes to the monitor enough... I was said from an Oculus user "Even in Oculus they are visible. It's only matter of skill." well, I guess it's more because VR device provides 1:1 FOV. We had a different image FOV size. If I were to fly with FOV70, monitor width*0.72 distance would be a good place to position my head. At there, things are seen the equal angular size to VR(and real). I could barely maintain tally 1.5-3.0nm distance at that position.(but be careful it is only representing correct angular size but not fineness) However, if I keep playing DCS with such a close distance to the monitor my eyesight should get worse. I guess current "keep dot" method is implemented to help VR user who's FOV is fixed to 110 and thus things get smaller in a shorter distance than in usual monitor. Rather than to see far enough things. Without the dot, smaller than 1-pixel tally will disappear, than VR users will lose sight of tally shorter than monitor users, that might be why it is now enabled regardless of server imposter setting. But They also could not determine where to stop displaying a dot is good for realistic visibility, so the dot will be seen the same contrast and same size even in the 50km distance, is also breaking the reality. I was also said by the Oculus user "Now things can be seen even in the 50km distance, in DCS getting sight of tally is becoming much easier than before." Yes, that should be...

At least I didn't see such a behavior even in 1.5, I still haven't checked 2.0 but would there be? Seems 1.5.5 to 1.5.6 changed dot color to transit more continuously to a 3D model which made a dot less visible. While I am checking this visibility behavior I started to make a video which describes how FOV/Resolution work for simulator, How a dot is working for DCS now, Shows Prediction image what it looks like if my scaling idea or any other idea mentioned here were implemented to DCS. See you in a few weeks.

I think it would help a bit but also feel it is not trying to "simulating" visibility, instead, it is "increasing" visibility. What I wanted to do was to match the aircraft fineness(how clearly I can detect his outline) beyond 1nm as much as possible to that of RL 20/20 eye vision with my "scaling idea" post. I wanted to "simulate" the visibility. (It also can overcome non-1:1 FOV monitor setting so that planes in the monitor would be seen with realistic size as a second effect) (Screen shots were taken in FHD resolution) You can see that 3.0nm distant F-15 showing its left side still has 6px but beyond 1-2nm is already becoming a problem here so simply keep 2-3 pixel might not help. Perhaps "dot idea" is to increase its contrast by overlay 2-3 pixel drawing so that it can overcome the lack of aircraft fineness. However, that is where I feel the way of the idea is "increasing" and not "simulating". I can't guess how reliable the contrast increase made the possibility of target detection close to that of real life vision. It is like increasing thrust parameter so that take-off length matches to that of RL while Lift coefficient parameter is wrong and make take off speed broken. Pixel size and contrast should be simulated to as close as possible to RL. Also, if we set minimum pixel size, plane size stops to decrease by distance so pilots will lose their sense of closing/leaving of opponent aircraft, and might lose distance relation to visual plane size. Plane visibility will lack a relation to orientation(seen from a back/front should be less visible than seen from the side. seen from the top should be most visible orientation). Plus, the main reason why I am for "Add Magnification by Range" is because what I want is not an only probability of target detection(I found him! tally!) but also a probability of orientation determination(how is opponent attitude now? and aspect angle relation?). "dot" idea seems only to increase the possibility of detection and does not help orientation determination. F-16 flight lead above 2-3nm distant (like in WEZ-in depth formation used in RL tactics, they fly such a distant formation!) should be still fineness enough to detect when he starts turning so that wingman can follow him. As I mentioned in my former post my idea is originally coming from this research paper and I added a few function so that any monitor resolution or FOV setting can get the same result. http://www.dtic.mil/docs/citations/ADA414893 If the scaling idea would not be a feasible compromise for future official DCS updates, at least I want ED to allow users to implement "scaling against distance" factor by LUA file so that it would be optional setting and can try own equation. Each squadron or server can set what they believe is realistic visibility.

Yeah, that is where I feel uncomfortable while doing close combat or WEZ In-depth formation in DCS. 1-2nm is a distance where we go and come while doing these actions. It even goes 1.5-2.5nm range combat when establishing mutual support for a lead in 2v2 ACM. Current "dot" aid is activated only when the aircraft 3D model is no longer rendered above 1 dot because of resolution/FOV but that only happens in far more distance/extreme wider FOV situation. In FHD 70FOV, 1-3nm is where planes are still drawn 3D but we start to lose our sight because of decreasing contrast/size. In this situation, no matter how ED brush up current dot system, it will not help anything. Losing my sight because of decreasing contrast is ok if DCS graphic engine simulates the contrast against atmosphere/distance correctly. I am still not sure how can I check contrast reliability so I hold on about this matter. DSR might cheat against this bit. Losing sight while looking down is also natural behavior. Plane pixel size is obviously smaller than in RL vision...

Okay, in my case it seems VIGGEN's problem. I could assignment key to A-10A. When I enter 3D and open control menu I could save key assignment for VIGGEN.

After 1.5.6 update when I assign any single joystick DX button and push "OK" DCS crashes.

Why485's demo is not a MOD for DCS. It is just a 3D demonstration of my scaling method. We post this to suggest ED our idea. Happy Viggen's Day:)