Jump to content

hughlb

Members
  • Posts

    450
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by hughlb

  1. So image sharpening has worked all along for me, but the Framerate limiter doesn't. I have a gsync screen, but I have disabled gsync, tried vsync/fastsync, no vsync, reinstalled the driver and only enabled the framerate limiter, still nothing. It's odd because V2 has been working fine, just thought I would try V3. I have also tried the limiter with both ProfileInspector and without ProfileInspector. I have tried disabling Asus Tweak II and Process Lasso, neither of which make a difference to the problem.
  2. I cannot for the life of me get the new V3 Nvidia framerate limiter to work in DCS. Can anyone verify? V2 works fine, and V1, but the latest version does nothing.
  3. The intent of this thread is starting to get fuzzy at this point. Consider this OP - it is better for all involved, including the consumer, if two ‘big ticket’ modules are available, rather than not. If we are happy to buy, then making the product available to sell is a good thing. We then get the ultimate choice of investment. To the subject of this thread – this is being blown way out of proportion. There is the presumption that this temporary resource reallocation to the Viper is only detrimental, without considering the advantages of shared development pathways over the course of early access. Which I can only imagine is because the OP feels one or several systems have been compromised in the immediate future. If that is the case, then it comes back to the decision made to take part in early access, a period where the order and rate of development is understood to be dynamic. Did you buy in too soon, OP? If it is not one or several specific features, and simply the principal of timely delivery and adequate early access product support, then consider the benefits of parallel development and don’t focus on periodic compromises, which will happen. Also use a metric of comparison - the only fair comparison would be third party developers, as they are developing the same products within the same ecosystem. They too have multi year early access periods, and manage development in parallel, especially on complex fourth gen aircraft. Would it also be reasonable to assume that this is the only instance of resource reallocation during development of a module? I honestly don’t believe so, but I also don’t see a problem with that. I see the only issue here being the expectation placed by some on early access. Make no mistake, we all want completed modules, and if it is missing key features when it is released out of early access, I would be asking questions too. Sent from my iPhone using Tapatalk
  4. Such a shame when a post like this appears. It serves to casually disregard all the ongoing work since the Hornet entered early access, the near fortnightly effort to update the module, and the depth of systems already available. It’s disappointing for the team working on the Hornet to read. Sent from my iPhone using Tapatalk
  5. I think that might help Harli. Anything that clarifies both the purpose and scale of early access is a good thing. If it weren’t a Steam product, getting away from calling it “early access” would also be a good idea, because yes, people equate it to other games. That’s why an “insiders program” really makes it clear that this is a public phase of development, and not a released product. Sent from my iPhone using Tapatalk
  6. You don’t get incomplete planes unless you opt into early access. The Hornet and Viper are still being developed. The systems we have now is actually fantastic, because it doesn’t discriminate. It gives all of us the option to buy the product and use the product when we wish. I could buy the Viper with the prerelease discount, then not use it for a year if I wanted to. Or I could buy the module when it exits early access. This is brilliant because no one in this thread is prevented from doing what they want to do. Personally, I was able to buy the Viper at a discount then start flying it last month, which is exactly what I was hoping to do. I didn’t have to wait for it to have TWS or other random features, I could just fly early on. The problem is, for whatever reason, people don’t want to wait. So I don’t think a different model is needed, they just need to help people understand the compromise of early access, probably through an application process for alpha testing that people sign up to. Sent from my iPhone using Tapatalk
  7. Here’s a solution, and I quite believe we would need to do something like this. But anyway - Have an early access period split into two stages. An Insiders Program that customers can apply for, that doesn’t discriminate based on circumstance or hardware, and doesn’t have a number cap for participants. But it does have essentially an agreement that serves the purpose of testing the product whilst it is in mid development, with the standard fluidity of development, and everything subject to change. Those of us who aren’t worried about the state of early access modules like the Hornet and Viper can gladly sign up and test a basic product, with all its bugs and missing features, and be happy. Later on, once the product reaches a high level of completion it can progress into public alpha, in a state where most of its features are implemented and most of its bugs are squashed. Those that are concerned about missing key features have far less to be concerned about. In a perfect world we would all just buy into the product on our own accord, because you know, we’re adults right, and we invest into things when we have weighed up what we are getting. But for whatever reason some people need ED to call the shots on when they spend their money. So this way, those that are concerned have the public alpha as their purchase window, and those that aren’t concerned, can enter into the Insiders Program. We can then all be generally confident we invested at the right time. Sent from my iPhone using Tapatalk
  8. You could make the educated assumption that ED have another 4th gen fighter lined up after the Viper. I mean, the Hornet and the Viper must generate the most interest in the customer base, so I don’t see why ED would not have a third fast mover lined up. We could deduce that it is the F-15C because they have already completed the flight model, perhaps some of systems based off the FC3. Its a hugely popular plane, less weapons systems and capabilities to create. Finally, we can probably rule out a MiG-29 or Su-27, and out of the big 4 US fourth gen, only the Eagle isn’t full fidelity. Also Wags likes puns and wordplay ;) Sent from my iPhone using Tapatalk
  9. They can't. It has been discussed already by Nick Grey: "without early access we would spend 50% more time and money to engineer the products as developers work better and faster with direct user feedback and when they see their product in the market. we would not be profitable. we would be vulnerable to customer 'fade' as they switch to other products or genres. we would not enjoy the 'right' to imperfection" You may want them to finish the Hornet first, but the scale of that project is too great for them to just work on that, and that alone.
  10. To the people complaining consider this: When you purchased the Hornet, what you were purchasing was the final completed product, with TWS, all the bells and whistles. That product hasn't been released yet, because the product is still in alpha development, meaning it isn't feature complete. Then what happened is you got given fair treatment - ED tossed you the keys and said, "because you paid us money before the product was released, we're going to let you come down to the factory and sit in the cockpit until it's done. You can offer some advice about the order you would like it finished, you can tell us where we have made some errors with the paintwork, button placement, stitching." Then when the Hornet is released, you get the product you paid for, with TWS, all the bells and whistles. This is what Early Access means. It is there to help ED develop your investment, but more importantly, it is a way of repaying you for buying the product before it has released. You actually have somewhat of a say in the order of development, as was the case with the Hornet, but at the end of the day there is a team of people still hard at work building your plane, and they are going to have to make some calls themselves about building the plane - that's just how it goes. If you are only happy with a completed product, wait for that product to be completed.
  11. Solution here: https://forums.eagle.ru/showthread.php?t=251003
  12. EDIT: My apologies, I achieved a successful result by doing the following, so please use this as a rough guide for anyone who is experiencing a large 'deadzone' with a long extension, centre-mounted stick - I appreciate that is an unusual graph, but this is my understanding of how it works - basically there isn't a software deadzone for the DCS F-16 because you can see the control stick moving in the cockpit with minimal input. So my guess is the F-16 in real life has a certain amount of 'play' in the stick before input is registered. It is very minor, and on a short throw stick you wouldn't notice it. But with an extension, that 'play' is exaggerated. By making the curve the shape above, you basically skip through the play quickly, and get straight to the input. ____________________________________________________________________________ Original message: Fantastic module, but I have an issue with a centre mounted flight stick. I appreciate the real F-16 uses a side mounted stick that behaves very differently to a centre mounted stick with an extension. However, those of us who have centre mounted sticks with extensions, have an enormous deadzone in pitch and roll, which makes controlling the aircraft sluggish. I can adjust the saturation, but unfortunately that just makes the aircraft harder to control.
  13. How many man hours are put into the development of a complex module like the Viper, and what is the approximate monetary cost?
  14. Ah good information. I see what you mean, I have found the Hornet sounds that must constitute the sound, but obviously when you play them as files, it doesn't take into account the dynamic position of the sound, as the aircraft passes by - the 'whoosh' is actually just a pitch shift I guess. That's cool, I might have to try adjusting some of the radius in the sdef files. I'll see how I go.
  15. Does anyone know what sound file is used for the 'whoosh' sound, for lack of a better description, when an aircraft passes in close proximity to the flyby (F3) camera. I have always felt this is overdone, and was looking to replace it with a different sound.
  16. Yes, 63.8 with 143 files is exactly what I have too. May I ask, how did you install it? Where are the files sitting?
  17. Just a strange one. I have successfully installed Jafa's Merlin mod, which sounds great with the cockpit open and external. But with the cockpit closed, it seems to revert back to the default sounds. Also, I had previously tried Rlaxoxo's weapons sound mod v3 for the Spitfire, and the same thing occurred. Sounded great external and with cockpit opened, then reverts to old sounds with cockpit closed. Anyone else experiencing this? I installed using OvGME. I did not install these mods at the same time, just to be absolutely sure there wasn't conflict between them.
  18. Can anyone make a list of the changes they have spotted?
  19. Anyone have any experience with these drivers?
  20. With the MkIX now having a counterpart in the A-8, what is the likelihood of a DCS Spitfire XIV to fight directly with the late war German and US Western Europe counterparts? Especially considering development halted on the VAEO in-development module.
  21. I can share my experiences with this issue. I had this issue on my Mk1 Gunfighter base on the y axis. I eventually had a replacement base sent to me by VKB, which was checked by them. Guess what, the second base had the same issue, though this time on the X axis. I never got an explanation as to the cause of the problem, nor was the issue ever resolved. Both bases were from different batches. You can see my thread here: http://forum.vkb-sim.pro/viewtopic.php?f=25&t=2666&sid=93d5ed23a6c69b6295891cad582eb199&start=15
  22. Does the Mid-life overhaul also include any graphical improvements to the interior and exterior? Little things like the cockpit wall textures, and HUD glass modelling are still a bit inconsistent. They are only little things, but the MiG-19 really raised the bar.
  23. I get that, but is it used exclusively for firing at targets that cannot be locked, or does it serve another purpose?
  24. It would be really useful to hear about the correct process to engage targets transitioning from extreme BVR distances to the merge - from the pilot seat. Is there any content available that details this chronology? As a hypothetical - let's say we have a two ship, Su-27’s at 50nm, hot. Do we remain with TWS to ensure both targets are tracked, maintaining a better situational awareness by tracking both and allowing us to get two missiles off? Or do we STT a single target at that range to provide a better chance of hitting the target? When we have fired, do we turn 180, or continue to the merge? Do we have to remain within gimbal limits for the radar? Let's say the two Phoenix both miss for whatever reason. What is the process? Do we change to PAL within 15nm or maintain TWS? I am aware that raising the ACM cover does the following: Enables High Gun Rate, Missile Prep, SW Cool, Shortens Ph/Aim7 launch from 3 to 1 seconds Should I always enable ACM at a certain distance from an inbound target to "prepare" the plane for a merge? What if the target is still BVR, will ACM mode adversely affect my potential tracking? ie. does the reduction in launch time also compromise the ability to detect or track targets outside of a range threshold? How about when to switch from Normal mode to Boresight? I find I’m often losing situational awareness as we approach a merge.
  25. It’s used to really compensate for the joystick length variance between a desktop joystick and the stick in the plane. Most desktop sticks are both really short and offer no real weight. This totally changes the way the aircraft responds to input compared with the real thing. Curves allow you to mimic the input response around centre, without it, the aircraft can feel really twitchy. I have a long extension and still use curves, but I use “user” curves to set for a flat response around centre and a fairly linear (straight) response for the rest of the travel. Works really well.
×
×
  • Create New...