Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by MikeMikeJuliet

  1. I'm not sure if the game actually benefitted from the original idea, or if it would just cause massive confusion among newer users... That said I would want to see a similar feature when flying campaigns and "dynamic" multiplayer sessions, where not every aircraft always gets shot down. Say, combine a limited aircraft count to structural fatigue overtime and significant repair times for damaged airframes... That would certainly be for those wishing for "the long haul" of combat ops. War of attrition and whathaveyou. Naturally this would have to be optional and I am not sure if I would want to see that many moving parts but I am intrigued about the concept. Regards, MikeMikeJuliet
  2. I guess most people haven't even found said observatory, or knows where it actually should be. So there is literally nothing for anyone else to add to your post. Regards, MikeMikeJuliet
  3. The only aircraft that would have this phenomenon affecting the pilots would be helicopters, the upcoming Yak-52 and Christen Eagle II... all jets and military props fly too fast on approach for water to "fill" the windshield. If rain is plentiful enough to impact looking through the canopy, it is the splashing of water. Hornet and others approach at such a high speed and hve the canopy shaped such that the water will just flow away. Regards, MikeMikeJuliet
  4. A fair point, especially with even lite-pit builders...
  5. Fair points. As a side note a perfect vision is not mandatory. I would still argue model enlargement is still exactly for the purpose of allowing you to see the target with enough detail, but without compromising peripheral vision. In the same way I would not call it a cheat, since A: everyone has the ability to use it if they want, and B: it tries to achieve the same effect (to simulate the ability to see better than your display allows you to) without sacrificing FOV. On the subject of axis-bound FOV. It is good if you have an axis to work with. My Warthogs only available axis (the friction lever) spikes constantly and will produce a vomit-inducing effect on use. Plus I actually prefer to use constant FOV. It is most comfortable way to play that way. Regards, MikeMikeJuliet
  6. Which is exactly why I suggest adding a single-press button with nothing bound to it by default
  7. :D I literally posted this two days ago. Look at DArts response to the request 4 posts above yours (post no. 362)
  8. You indeed can, but the less external programs you need, the better. Plus, not everybody knows this is a possibility, or knows how it is done.
  9. ... both of which have the point of countering the fact that the users visual system (the type of display) can't accurately represent the view in the world because of size, FOV and pixel amount limits. I don't know if you have noticed, but pixels in similar sized 4K displays are way smaller than with 1080p displays. For reference I use a 2K monitor and I can clearly see the difference between 2 and 4K. I'm not saying 4K is a disadvantage. But a lower resolution screen has an advantage with AA turned off. And I fly with AA turned off. Because of the trigonometry (namely target size, distance to target and pixel size) means that reducing pixel size by half for example has a significant difference in distance. I choose to play with AA off because AA on makes spotting targets (especially ground targets) a pain at ranges I would begin an attack run. And I very much do not enjoy zooming. It is unimmersive, disrupts my sense of space and allows me to zoom in way beyond 1:1 scale compared to the physical size of things. Target enlargement at certain ranges is way less interruptive and doesn't have as large an effect size-wise. In addition the zoom does way more than simulate 20/20 vision. It goes way beyond that because you can zoom in to ridiculous levels effectively acting as a cheat that everyone can use. I do not see how this would differ from model enlargement, since that too would be available to everyone. I fully agree the models should not be enlargened so as to allow spotting at overtly long distances. The system doesn not need to apply to all instances at every distance. I fully agree on that. The previous model enlargement made it possible to see missiles as dots in the sky at ranges over 20NM. My take on this is that model enlargement can be used to help overcome system and hardware limitations if implemented correctly. And the previous implementation was not correct. Regards, MikeMikeJuliet
  10. As I posted before, the variety of the problem and if it exists or not depends on one's monitor resolution and do they use AA or not. If AA is on, the problem is with lower resolution screens blurring the target making it difficult to notice way before a hi resolution screen. If AA is off, then high resolution screens give you much smaller pixel to go by, making spotting easier on a low resolution screen due absolute minimum size of the target in your field of vision. This is of course comparing monitors that have similar physical dimensions. If the monitors are sized according to their resolution (thus keeping the pixels the same size physically) then both displays show the same effect on the same physical viewing distance. This is partly amplified or smoothed out by changing physical viewing distance, since a pixel's size in your field of vision depends on the distance to the viewed pixel as well as the pixel's physical size. ----- Another factor that I briefly touched previously is the player's chosen in-game zoom level. The farther in you zoom (i.e. FOV decreases) acts as if you had a higher and higher resolution display, since you spread a smaller and smaller field of view in-game to the same amount of physical pixels. And vice versa when zooming out. Given that VR HMD's have a relatively low resolution per eye you almost need to use AA in order to remove the ugly edges, but this again amplifies the problem of spotting with AA on with low resolution screens - you can't spot targets far away. ----- My point in the end is, there should be a technique to, firstly, reduce the effect that changing from 3D to 2D rendering of an object has on visibility of said object. And secondly to dynamically change the algorithm thresholds to try to level different screen setups' output to the user. What I would like everyone to understand by this dual-post of technical babble is: Model enlargement, dot-labels and similar techniques try to achieve the exact same thing that zooming currently does. They just do it the other way around. Model enlargement tries to keep the objects visible on a higher range of ranges, where as the more simple, but less elegant option is just to zoom the view, which achieves the exact same thing target-wise. Next time try and see what happens when you zoom in and out on a target. The model enlargement is not there, but don't you consider it exactly the same effect if you zoom out enough to see your targets more clearly (by forcing them to be rendered in 2D and thus more visible, unless using AA), or zooming all the way in to see your target better in 3D? The only way to get rid of both solutions completely is to transfer to VR only and wait for human-eye-resolution displays. Then the FOV is always correct and objects always render in 3D. Otherwise it is either zoom (breaks immersion) or model enlargement or similar (possibility of exploits and more difficult to make it work correctly). Regards, MikeMikeJuliet
  11. @SharpeXB The issue with monitor resolution is two-fold. The resolution does indeed matter and it depends on graphical settings. Given we have two identically proportioned and sized screens, one running 1080p and the other running 4K. The screens have different pixel sizes. DCS draws a unit as a 3D object as far as it is able, which stops when the object is the size of a single pixel. After that it is drawn as the size of a single sprite until an arbitrary draw distance is met. What this means is, that with lower resolution screens you have the advantage of larger pixels meaning the target will appear larger at distances when the target shrinks to the size of said pixel and beyond, where as the 4K display target get's smaller and smaller until that screen's pixel size is met. Now all this is with no anti-aliasing. With anti-aliasing the problem reverses. On lower resolution screens once the target passes the pixel size downwards it starts to be blurred against the background (in case of a white background for example a black target will get increasingly grey and eventually white). What this means is that at distances where with a 4K screen the target is still drawn with full pixels + some edge anti-aliasing, the target on the 1080p screen would be a single pixel blended into the background. Additionally, at least a time ago, once the target stopped 3D rendering it's lighting calculation either stopped or got simplified, meaning that a target that was barely larger than a pixel may appear much lighter (and thus harder to see against certain backgrounds) than the sprite-render beyond the 1-pixel-size-distance. This meant that as you came closer to your target the target suddenly appears to vanish, when in reality it just starts to render in 3D making it more difficult to spot. You can see this in action especially with ground targets. Zoom out and you see nice dark dots on the ground - zoom in and you first appear to loose tally, and then regain it as you realize that the targets look a different color. As for the target size enhancement breaking BVR, there is a simple solution: Use the system only when transitioning from pixel-rendering to 3D rendering to smooth out the transition. In fact, most aircraft (apart from their contrails) should not render at all at distances beyond 10-15 NM. Perhaps they might glint in the sunlight at times, but nothing else. I dare you find a person spotting a fighter-sized target much beyond those distances. Especially if the air is not 100% clear. Regards, MikeMikeJuliet
  12. You do realise this is DCS, yes? A few weeks or even a month or two of silence is a standard fare in so many cases. The less time Brian has to devote/worry about keeping us posted ensures more time for efficient work on the module. Posting and readingthe forums takes a suprisingly large amount of time and breaks ones flow of work. At this point I would not worry. The mod/module is huge and the developer team is quite small. I expect them to take long. Regards, MikeMikeJuliet
  13. DArt, I have three suggestion and an apparent bug to report! Firstly: I suggest to draw the distance/bearing ruler on top of units on the screen. It is a bit annoying trying to read the info on a screen with a lot going on (and especially a lot of aircraft in close proximity) when the units are drawn over the ruler. This could be an option to toggle the draw priority. Secondly: requesting ability to set a third type of altitude readout - "kft", thousands of feet. As GCI calls target altitude in thousands of feet I believe it'd be best to be able to show the altitude as such instead of full or short (flight levels i.e. hundreds of feet). This also shortens the labels on the screen making a busy situation more readable. Third: ability to change target label outline (and pointer) color. at my currently preferred map color the label pointer is almost impossible to see making a situation very hard to decipher if there are a lot of aircraft in close proximity. And the bug?: DCS chat in the "all" chat tab in lotATC shows every user as red regardless of side and regardless of which side the lotATC user is on. Thanks for one of the most useful DCS external softwares! Regards, MikeMikeJuliet
  14. ED should add an unbound (meaning not even a keyboard key for it) key for single-press ejection as an alternate to the current 3x method. That could then be bound to whichever control the user desires. This should satisfy all possible users. Regards, MikeMikeJuliet
  15. If only the controls would change... You are practically controlling a tank with legs by using the stick and pedals...
  16. I don't think this is really the appropriate thread but... The HSI should work. It just needs around 3 or 4 minutes to have gained enough speed to the gyro before it starts to align. I wouldn't bother reporting texture issues before the new PBR textures are out. If issues persist after the update then go file a report on the appropriate subforum and thread. Regards, MikeMikeJuliet
  17. I've been looking forward to these news for a long time! I guess the spring is starting to melt the ice on top of the "post news" button, huh? I'm looking forward to the Hawk with excitement! Regards, MikeMikeJuliet
  18. I am so glad the zoom-out is going to go away! Looking forward to the future.
  19. Trust me, it is heck annoying with an actual TrackIR too! I really, really want the mouse to be bound to the cockpit and not the view.
  20. Yes! Have the units be changeable anywhere on runtime & add options to show either imperia or metric + both at the same time!
  21. Yep. As I said, I am aware that it is a simple systel at the moment and I would like it be fixed/expanded upon. But I am also very positive that this is actually going to be expanded upon. Exciting
  22. Alright, firstly, 4 altitudes for wind is in my opinion a good start, but not enough. I am very aware of the system limitations in that regard. I wasn't quite clear on the jetstream example. The difference is indeed not that big if both of you reside in the exact same wind. Though jetstreams are quite local, meaning there will in most cases be variation between you and your opponent, especially if there is any altitude separation... + missiles loft, meaning if you shoot your missile from below a jetstream that increases speed to the missiles loft altitude for, say 50kt, that affects your missile performance. And if nothing else, a jetstream changes the dynamic of flying over AO areas in regards to SAM sites. Regards, MikeMikeJuliet
  23. I've spoken about the mouse control methods on multiple occations for, I'd guess, two years now. And yes, there should indeed be options. I would primarily want to see the mouse unbound from the viewport, so that the mouse stays in place relative to the cockpit and not relative to your view. Some have said this would not be feasable, but it in fact already works in VR when using menus wether in cockpit Esc-menu or the main menu (which in VR resides in a 3D rendered hangar scene that you can look around in. So that's already half way here. Another option would definitely have to be the snap-to-control scheme. And before anyone says "don't ruin my mouse controls", I am suggesting these as options. Not a mandatory change to the current system. Options are always good. Regards, MikeMikeJuliet
  24. Looks very promising. The only issue after the gloves is to position your HOTAS into a very specific position for each aircraft.
  • Create New...