Jump to content

firmek

Members
  • Posts

    1370
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by firmek

  1. What the VR crowd is missing is that the technology is not that new and cutting edge: The VFX-1 VR set had a premiere in 1995... which means there had been a 20 years gap after which VR makes it's come back. Much more successfull this time but there are still a lot of applications like the office, engineering and even games where VR will not be a prefered way. Actually I would say that the simulators are kind of a niche that work with VR exceptionally well. FPS, RTS, RPG's, sport games like FIFA will stay on the monitors for a long time. Not mentioning the price that is not only connected with a VR set but with a top spec PC components required to support it. IMO the future will evolve more towards a big, flexible, light, high resolution and contrast range screens like OLED which have much wider application. VR will stay for good but rather in a specialized areas. Finally there is also a soft aspect related to the VR. I'll be fine having my new born son playing a console in a few years. But I can't imagine him with the VR sorry to say bucket on his head. That would be allowing him to isloate from the real world too much.
  2. +1 :thumbup:. I used to play FPS a lot and didn't know a single person that would use or say anything positive about v-sync. DCS is the first community where I see a lot of people using it. Funny you mention the turn based games but personally I couldn't stand the mouse rubber-banding v-sync causes even in a game like Civ V. Though I guess different people are sensitive to different things. With V-sync On the TIR makes me feel almost seasick. While I can't stand the input lag I get the point that some hate the screen tearing. Anyway, adaptive sync like a G-Sync is a great thing - not only it's a better tech but the concept behind it actually makes sense - which is not a case with v-sync. I agree it's all worth the money and once you experiance a high refresh rate monitor with G-Sync there is no going back.
  3. C'mon guys please.... At least bring some more details than "don't you think" and "see this youtube" - from which you don't know anytying about the weight, load, etc... . Some charts would be welcome as a starting point.
  4. Unfortunatelly yes. The only way is manually merge the files. Programs like WinMerge can make it easier but the mentioned JSGME is not a solution at all. Quite opposite as you don't know if something hasn't been changed with the update you may end up overwriting an updated file with an old one. Just create a clearly commented out secion on top of the file and copy it with every update. The solution? Developers should stop screwing around and to their job of creating 2 and 3 way switches abstraction for every single switch in the cockpit. Seriously, I'm more than tired to have to do that on my own for every single module - quite often failing as only toggle action is available while separate on/off are not. It's not asking too much - such list is created and posted on the forums within hours after a module release. The bottom line is - devs are taking a shortcut thinking that community will manage it. It's not funny that the only single module in DCS which is working correctly out of the box with TM-Worthog is A-10C.
  5. Actually, the number of prerendered frames is worth playing with regarless of v-sync being turned on or off. Increasing the value - lets say to 3 or 4 can really help with the micro-stuttering but with a drawback of a higher input lag (noticable with mouse coursor and in-game camera responce delay to real TIR/head movement). Decreasing - opposite, can introduce the micro stutter but reduces the input lag. Still, I'm not changing my mind about v-sync which is just conceptually a flown idea. It creates way much more problems than the screen tearing it tries to solve.
  6. It's an old issue. I had seen it in 2.2, not sure about 1.5.8. Seems it had been propagated to 2.5. Basically the cockpit is rendered with the "missing texture" texture.
  7. Disable the VSync. It's normal that the FPS fluctuates - you can't guarantee constant 60 FPS. It's not DCS problem, just VSync which IMO is a piece of cr@# and should be labeled with a clear marking "seriously damages your health" like a pack of cigarettes.
  8. Errr.... noooope. The changelog aside being a single point of communication on what has been and what isn't included is at least an indication that there is some plan. No changelog - no clue what's functional (or supposed to be) in EA module and no plan or list of priorities in which order the features will be added. Frankly speaking, a clear bullet point list of missing/to be added features, a change log and at least a high level plan should be something obvious for every beta/EA software. The world starts to be a strange place if "customers" have to push for such things.
  9. Just leave it as automatically managed. It's already located on SSD which gives you the best performance. What is quite often misunderstood is that paging file should only be needed when low on RAM. This is absolutely false. Windows will use the paging file all the time, also as a memory for non-performance critical or non-used applications even when plenty of free RAM is available. Becase of this don't turn the paging file off even if on a new system with a lot of RAM - for instance 64GB. Doing so may have a negative impact on the performance and system stability.
  10. They work basically the same way. You need an up and down action for 2 position switch and two up and one down action for a 3 position one. Look for a similar thread under F-5 section. I'm sure it's there, if not start it. It would help to write which keys are you interested in.
  11. As many said Viggen is in-work before the official release. Still it's quite feature complete and overall a stable module. Yes there are things that need to be looked into but really nothing game breaking. HB is also maintaining a good support with steady flow of fixes (just look at the latest update log :thumbup:). If the 4 concerns are expressed with such attention you should begin with staying away from the Harrier. Comparing to other early access, Viggen looks almost like a complete module. I wouldn't be supprised, hell based on recent statements from Cobra I'm sure the F-14 will be really polished for a DCS EA standards. Ad 1. It's a striker, not a fighter so IMO it's perfectly fine to give mirrors a lower priority. Ad 2. Unfortunatelly that's an issue with almost every single module. It's possible to create own bindings by editing the lua or just using the file maintained on the forum. Not everything however is possible especailly if the actions are not defined. I wish every devellopper would ship their modules with a full list of 2 and 3 way bindings for every single switch in the cockpit. Ad 3. There are some parts that could use a higher resolution texture but really, the Viggen cockpit is one of the if not the best at the moment. Ad 4. All devs are facing a challange with DCS moving to PBR. Not every cockpit is optimized and Viggen has some extensive lightning due to the radar screen. Just compare it with some other modules where the radar screen does not light the cockpit at all.
  12. Just to "relax" a bit:
  13. :thumbup::thumbup::thumbup: Though, why trainers are not included?
  14. I'm not really an expert but you seem to mix the insturment with visual charts. If you read a complete document you'll find out that landing on 31 is allowed only with visual rules, during a day, clean weather conditions and only for a relativelly small planes. If it's a night or adverse conditions, even for instance a cloud base at 3000 feet, noone would be cleared to land on 31. Thus we can safely assume that if the wind component does not allow landing on 13 the plane would be diverted to another airport. Look also on the minimum safe altitudes - it's 15.7 k and 9,5 k feets when approaching from any other direction than the sea. Landing on 31 really does not make too much sense in any other then perfect day visual conditions.
  15. Short extract from the Batumi flight procedures. It seems that IFR arrivals are RWY 13 only, departures 31. As for VFR both directions are possible but with limitations. On top of that there is pretty much no infractructure (lights, ILS) on RWY 31.
  16. It is when the files within module are modified which is not the best way to do it anyway. If you use the server.lua stored in saved games the change is IC Green.
  17. Obvioulsy no clue how it looks in reality but +1 to the opinion that the night photos will make the effect looking more dramatic then it's in the real life due to the longer than day time aperture setting.
  18. I'm not proposing to strengthen the air defences around the targets. They are fine as they are. Just to create scattered AAA and maybe flak at over the complete area, maybe around the cities so that flying at low level behind the front line, during ingress to the target would create a risk of being hit by ground fire (as in real life).
  19. Just an suggestion to consider - how about adding some AAA around the cities and maybe even including the flak script. The point is to bring the fight or at least the flights to a higher level then 10-50 meters over the ground where pretty much most are flying. Its quite evident especially in the phone booth mission where majority are flying like they would be piloting a jet engine propelled lawn cutters :D
  20. As far as Tornado is considered I believe only the interdictor variants would make sense for two reasons: it is the reall soul of Tornado after all and on top of that it would bring something unique to DCS where there is still quite a big gap to fill in. Yes, there is the Viggen but at the same time it's quite a different pair of shoes. As you say the electronic warfare is simulated in really an simplified way in DCS while the interceptor variant would mix with already a big, with all due respect more capable and specialized crowd.
  21. If you're interested in running 2.5 open beta you should be able to update 1.5 stable to 1.5 open beta - and then obviously to 2.5 OB when it comes out. Search on the forum how to do this but IIRC it takes as much as running the updater with approporiate args.
  22. Couldn't agree more :thumbup: To be honest I'm not sure where the issues are coming but they look to be pilot related. Haven't experienced problems with F-5, maybe because I fly the Russian aicrafts more so I'm used to diff breaking and don't use the NWS for other purpose than taxi. On top of that there is always a possibility to modify the curvature for rudder peddals.
  23. It's not a joystick issue but the devs which: 1. don't create an approporiate commands 2. don't offer a 2-3 way switches key binding for their module even if the commands are there As for the first point the problem is that there are quite often only a single, toggle command implemented in the module - basically the same key that will go on/off (up/down) depending on how many times it's pressed. There are no separate actions defined to put a switch into up or down position. In such case sorry but it's almost a dead end, this will not work 100% correctly with an up/down or a 3-position switch (2xup/down). Second point is just the devs saving time and transfering the effort to the community. Eventually after the community creates a list of switches they'll just go and put it into the module (see M-2000C for instance). Still this means that usually only the most often used - popular switches have a 2/3 way switch bindings while other are missing. Being fully honest, every module should have a complete list of bindings for every single 2 or 3 way switch in the cockpit created by the devs. I'm really tired about the fact that for every single module that I get I have to go to the lua file to create those list by myself. Then I find out that some switches have only a toggle action instead of up/down representation. On top of that I have to pay attention if the updates didn't change a action binding that I used. There is no issue with the TM Worthog. It's one of the most populare HOTAS and it should be considered as a standard. It also has been working with A-10C in DCS since many years. It's the devs that are not dedicating enough attention to make the support out of the box :thumbdown::thumbdown:
  24. Sorry if this had been already asked but what are the plans for BF after next Wednesday - when 2.5 comes out? Will it remain on 1.5.8 while 2.5 version is tested internally or there is an assumption it'll work with 2.5 Caucasus right off the bat (IMO rather a risky assumption) ? Just to understand if it's a good idea to keep the old 1.5 installs for the time being.
×
×
  • Create New...