Flagrum

On which maps are you guys flying? My experience is, that Normandy lags A LOT. Seems to be related to loading data while getting to new areas of the map. It takes about 5-10 Minutes in the same area (i.e. flying in circles) until everything is seemingly loaded and stutters get less and less. Might be ok...ish for helos, but fast movers over Normandy is a no-go for me, at least at the moment. On the other hand, New Georgia is working pretty decent, performance wise. A stutter here and there, but manageble. And then Nevada ... is a real gem. A few fps less over Vegas, but no real st...st...s...t...UTTE...rs.

This is bothering me for quite some time now: the Guides & Tutorials forum is more used to ask all kinds of random questions that rather belong to the module specific subforums, the general DCS forum or perhaps even in the chit chat forum. They are not even questions concerning something in a guide or tutorial that was posted there. Or at least requests for new guides or tutorials. If we allow this to continue, the purpose of that forum becomes totally void as nobody will be able to find relevant threads (i.e. containing guides and tutorials) there anymore. So, if some kind moderator with some spare time would find the time to clean up there a bit, it would be highly appreciated. thanks!

Afaik usual sizes are 120GB, 250GB, 500GB. So that leaves not much choice in your case, right? Also considering that the most space is used for maps and 100 GB is worth 3 - 4 (taking the DCS base install into account) maps today, a 250 GB SSD should last for another 4-5 maps easily. That should cover the next 5-10 years of development time, if you ask me. :-) On the other hand, more space is never a bad idea. It is not like it is wasted. You can always use additional space for other stuff.

see also here: https://forums.eagle.ru/showthread.php?t=196099 & https://forums.eagle.ru/showthread.php?t=202962

Why would you want to do that? Communication is one, maybe the most important function of a RIO. That's like, I put a Lantirn POD on my plane, but for sanity sake, turn off all video feeds.

https://getyarn.io/yarn-clip/a85ab2e4-0d44-4589-a933-8d3be74e5d3a#rJDo8Ws0cf.copy

I read your posting now 3 times ... but could not hear anything!

:huh::doh: (Well, if you prefer a "real editor" instead of what ED offers, then you still edit the generated .lua code inside of a .miz file with your favourite text editor .......)

OMFG ... :doh::doh::doh::doh::doh::doh::doh::doh::doh:

Problem solved. Seems that some files of the Nevada map got corrupted somehow and the DCS repair did not notice this. After deleting the mods\nevada folder, DCS repair did it's job and now Nevada is working again in the mission editor.

Updated to 2.5.0u5 today. Start DCS, enter mission editor, click New Mission, select Nevada map at the coalition screen. DCS logo appears and after some seconds DCS crashes. Did then a DCS clean, DCS repair and tried it again - crashed again. Then I tried the same procedure but with Caucasus: that map loads fine in mission editor. Then, while Caucausus map was still shown in mission editor, I selected File->New and selected Nevada again. Result: crash. Logs show the initial attempt (start DCS after fresh DCS clean + DCS repair and tried to start a mission at Nevada). dcs.log-20180321-224841.zip

:mad: Pat, could you elaborate a bit please where the difficulties are? My understanding - which might be wrong, ofc - is, that the Gazelle should not act any different if either FFB is enabled or no FFB is used. FFB should be "just" an other output(!!) device like any other. The input side is the actual stick position - how the stick position was archieved (manual input or by FFB motors) should not matter at all. Calculating which FFB forces are to be set and timing when they are to be set should be all that comes on top of the default, non-FFB Gazelle. I am not saying that it is easy, but honestly I don't really get how this can be so complicated that you just drop such an important feature. :(

Regarding the logs, you have successfully updated your DCS: STATUS: Successfully updated to 'openbeta' 2.5.0.15365.345

I am not sure if this issue just came up with the latest update - it just happend that I noticed it only now as the SA342 is usually grounded for the time beeing. For the requested info: please refrer to the previous postings. But if time permits, I will experiment a bit more with FFB turned on and off and trying a different (non-ffb) stick.

Watch it starting at 3:15. When deflecting the cyclic right, the helo reactis immediately. But when he deflects the stick then far left, it takes some moments until the attitude changes. In the case of min. 3:15, it takes several seconds. That does indeed look odd, imo.

I noticed a tendency for uncommanded pitch downs. Attitude, as OP demonstrated, is locked in the instant pilot input ceases - exept not for pitch down in many cases. I haven't really figgured out under which circumstances this happens. I fly straight and level, well trimmed, hands free(!). Then any tiny(est) inputs some sort of destabilize the helo and she pitches down - up to maybe 70-80 degrees. Note: stick is always centered (trimmed position), maybe +-1-2 % deflection.

Noticed this today with the latest OB (2.5.0.15184.338): trimming using the trim hat only works in a small, off-center range. With this I mean, on X and Y axis, the trim hat moves the stick only between center and about 50% deflection to the right or forward respectively. I am unable to trim a left hand bank or a nose up attitude at all.

Probably old:

I doubt, that an update would solve your problem ... as you are having problems to apply updates ..... But your might want to check your disk space - seems that you have to little space left for the updater to work properly: ERROR: F:\DCS World\_downloads\Mods/terrains/Caucasus/Surface/Caucasus.surface5: (112) Es steht nicht genug Speicherplatz auf dem Datenträger zur Verfügung.

The material is stronger and resists deforming more, even when longer than the other. Imagine bending a 20 cm twig - which is easy. Now imagine bending a 100 cm branch - although longer, it requires much more force. :)

Strange idea, imo tbh. You are implying that only verified module owners are supposed to have a genuine opinion on module related topics? Why? People may have knowledge and expertise concerning several topics that might show up on a specific module - why are those less worth than those of module owners?

Yes, it is a design decision, but not "just because" - as it actually DOES matter. The simulation is a set of equations. A BIG set of equations, that describe the various aspects that we see and experience in DCS. If the satelites move four times as fast, they certainly will not be hurled into deep space - as that is probably not simulated at all. But there is a good chance that something like that could mess up the equations dealing with GPS and navigation systems. You just can't change one variable of an (set of) equation(s) and expect the other side of it to stay the same (i.e. stay correct). Maybe it is possible to find a different set of equations that can handle that - by incorporating correction factors and whatnot. But THAT would be additional work and therefore an actual design decision that would have to be made. It would not be "just a tweak", but a different simulation.

Too bad, the rep system is gone ... The thing is, in DCS time has a meaning and is a necessary component to multiple, vital aspects of the things that are simulated. Right now GPS for navigation comes to my mind. How shall a nav system using GPS function if the day is only 4 hours long and every satelite position is suddenly wrong? Ok, not sure, if really the sat positions are exactly simulated, but in the Ka-50 you can lose accuracy if you lose LOS to too many satelites, i.e. in a narrow valley. And yes, it is a game and does not simulate everything 100%. But ED tries. And if the goal remains to be accurate, then ideas like this _at least_ make things more and more difficult (to find believable workarounds for aspects that are more complicated than "day time ... night time ... day time ...").

As you said, the _sensation_ of speed is different from RL. But that has nothing to do with top speed. It has rather to do with the lack of peripheral vision and maybe other clues that our brain gets from other sensors that a just not stimulated by sitting in front of a monitor. If you want the physics in the simulation to stay accurate, then there is nothing that you can really do to remedy that atm. The top speed depends on many different factors, starting with the engine power and probably not ending at environmental parameters. Fiddeling around with these parameters of the flight model does only one thing: it screws it totally up.