Flagrum

And the SA-342 has also changes that are ready to be pushed out, but aren't. Ok, to be fair Pat01 stated, that the changes were comitted to version 1.5.8 ... thought it was a typo, but apparently it is not. Weren't also some fixes due for the Viggen? Or the Mig-21? I don't know, some devs post their own change logs long before the actual release, others months later ... while I am happy that they put some effort into doing it - and later is better than never - I must confess, that I am really, REALLY losing track of where when what is supposed to be fixed, worked on or at least being reported, and not to forget, for which specific flavour of DCS (and including/excluding Steam). It is annoying, really is. :badmood: I've checked the differences between the installs of the last version and todays version (WinDiff). Not fool-prof, basically only checking the .LUA files, but the differences were minmal - and no module specific ones (except C-101, heh!).

The A-10 was designed as a tank killer but grew into the role of a CAS plane. And in that role, you pretty much want to know exact where and what you are hitting. Luckly, by definition, there is about always someone on the ground helping you with that - and if it is just someone talking you onto the target. The F-16 is an multi-role aircraft that can do things that the A-10 can not do. But for interdiction missions for example, it might not be so cruical if you hit that chem. factory tank more 2 meters on the left or 5 meters to the right. What I am trying to say is, both planes are ment to be used in different roles, both have their strength in areas where the other might perform not so well.

Better, but still far from perfect - Viggen CTDs when page faults go over the roof. I had this twice within an hour or so already when I experimented for my previous posting, but never got a dump file. Now, it happened again - this time with crash log + dump. Maybe it helps. Logs.zip

Looking forward to it!

I think, I could narrow it down quite a bit: I monitored the memory consumption in the task manager while flying over Normandy. With the radar turned on, I get quite a lot of paging errors which directly correlate with the stuttering in-game. After some investigation I noticed that I've set my virtual memory to fixed 16 GB! :doh: Don't ask, I did that a loooong time ago... and never really had any issues so far. Now I've set it to be managed by windows - and guess what: game play has significantly improved! :DI still get some laggyness at times, especially when the radar "sees" some terrain for the first time (i.e. performing a turn or just going up to a higher altitude). But all in all, and considering the fact that Normandy generally seems to be more rough than Nevada (let alone Georgia), the Viggen is now behaving not too terribly bad. :thumbup: I noticed, that the other reporters in this thread all have 16 GB of main memory - same as me. Those who have no problems with this issue - how much memory do you have installed? I suspect more than 16 GB? Anyhow, while this seems to be some sort of PEBCAK - having limited my virtual memory for no good reason - I still think that some optimizing the memory footprint of the Viggen radar would be in order (again: other modules never showed this behaviour, even with limited virt. mem).

Yes, it seems that the current FFB implementation assumes that there are AP controlled actuators that re-position the cyclic. That is in fact exactly what the FFB joystick does: it moves to a position that matches the position that keeps the helo at the attitude at the moment the trim button was pressed. The problem is that this happens instantly. The FFB stick kicks HARD in your hand if you hold it at a different position at that moment. This puts quite some strain on the hardware, I would suspect. And considering the real forces present in the real helo, such behaviour could easily lead to injuries.

We have different components that interact with each other: - Autopilot - Magnetic Brake Trim - Gyros - INS To me, it is not really clear how these components are supposed to work together, especially not when I observe their behaviour in-game. But after spending some time in DCS helos in general and the Gazelle in particular, I would expect them to work like this: - Autopilot: controls the helo when Altitude hold or Speed hold modes are engaged. Control is exercised independently (within limits?) from pilot inputs. - SAS: a separate component that has basically nothing to do with the AP. Basically only dampens pilot inputs - Mag. Brake Trim: "centers" the cyclic in terms of forces that are needed to deflect it. Trim button depressed: no forces (FFB off), button released: current stick position = force center. Unsure, how or if releasing the trim button should interact with SAS and/or the AP. My feeling: the effects should be at least way more "subtle" that they are right now. - 4-hat trim: only adjusts the helo's attitude. Should probably not affect the force trim? Or maybe it should, but as this way to change the attitude is already rather subtle, it would be ok, I guess? The effects on AP and SAS ... probably should be similar to those when using Mag. Brake trim. - Gyros: working gyros are a prerequisite for the INS and the AP. But is that true for the SAS then as well? Anyhow, switching off AP and/or SAS must not require the gyros to be shut off as well, right!? Any thoughts?

Autopilot, trim and the gyros. How do they even (supposed to) work? I posted a bug report regarding the magnetic trim and FFB. But that got me also thinking about all the stuff surrounding these systems. The AP relies on working gyros. That is to be expected - how else could the AP know about the current attitude of the helo. But as it was mentioned somewhere else and I could confirm this in my own tests: the AP not only depends on the gyros, but the gyros are the core of the AP. Switching off the AP only helps so much to disable it's effects. Only if the gyros are turned off as well, the AP seems to be complete disabled. Why is that so? And with disabling the gyros, am I not also rendering my INS useless?

I don't really understand how the AP, trim and the gyros are supposed to interact with each other, but it was mentioned elsewhere a few times already: to disable all interferences of the AP, you have to turn off the gyros as well. That at least eliminates the helo's tendency to assume a 0 pitch attitude for me. But has other effects as well - as twitchy as she is then ... be carefull to no perform a complete forwar roll when you just try to assume a slight nose-down attitude ... :-D

I am reporting an issue that could probably fit in the thread "FFB Implementation" (https://forums.eagle.ru/showthread.php?t=173762) as well. But posting it there seems to be mixing up different issues / a bit off topic - so bear with me when I make a separate thread. :-) I think, the devs stated it somewhere already, but I noticed this as well: the trim system sets the attitude of the helo, not the position of the controls. In the Huey, the magnetic brake basically allows you to set the position of the cyclic. The position of the cyclic then causes the helo to assume a certain attitude. For example, I deflect the cyclic, click-trim and the helo follows the cyclic. In the Gazelle, on the other hand, the trim defines the current(!) attitude of the helo as the desired attitude for the autopilot - even if the current cyclic position does not match that attitude. And then, this is the really weired part, sets the magnetic brake forces to a position that matches that set attitude - again, even if the current position does not match the set attitude. Example: I want to archieve a steep bank attitude and deflect the cyclic accordingly. Before the helo reaches that banking angle, I click-trim - while the helo is still in a not-so-steep banking angle. The click-trim then causes the mag. brake forces to set the new "center" at a different position than I am trying to hold it. Basically the trim system punches me in my hand holding the cyclic in the opposite direction as I am deflecting the stick (i.e. applying force to). So, I apply force to push the stick far left, but the mag. trim pushes the stick a bit right. In real live this would be flat out a health hazard and probably cause broken wrists and what not. And in our simulated world, it causes at least heavy strain on the FFB hardware. I urge the devs to review this implementation of force feedback. For the gradual 4-way-hat trim, the helo's behaviour might make quite some sense, but I have the strong feeling, that the magnetic brake trim should not work that way. I would rather expect it to be a more separate mechanism that works more like a mechanical solution to trim the helo, much like in the Huey, than a way the AP interferes violently with the pilot's decisions. Or to put it differently: the magnetic brake should only help the pilot to keep the controls in the desired position. The 4-way-hat trim should be the (only) way to adjust the SAS/AP. edit: and while we are at it: the "usual" way the mag. trim button works is, that the forces are released when and while it is depressed and re-applied when the button is released. In the Gazelle, the forces remain applied all the time - this makes no sense to me and I suspect that this is not how it works in the real thing...?

I think, I noticed this as well. To me it seems to be related to the autopilot. The autopilot tries to keep the helo's attitude to the last trimmed attitude - which is zero bank and zero pitch when the helo is just been fired up. So every maneuvering is fighting the AP and that is why the helo does not really like to keep a banking angle in turns and pitch angles when accellerating/decellerating.

If the release parameters are really the same, it really should make no difference and the end result should be the same. If it is not, then you might have found a really weired bug ... Think of it this way: the bomb follows a balistic curve when released. This is the natural path for it with the energy it has. To deviate from this path, it's energy has to change: to make it fly farther, energy has to be added, to make it fly less far, the bomb has to be "braked". Now the guidance system makes the bomb try to follow a straight path directly to the target. If the end point of the flight path in unguided/ballistic flight and guided/straight flight is the same (the target) and the release point is also identical, the straight line between release point and end point is obviously shorter than the path of the ballistic curve. Therefore the weapon must lose energy to be able to follow the shorter path. This is the easy part: losing energy is always possible due aerodynamic effects. But if the bomb is about to fall short, there is no way to add more energy anymore. So if it has lost already a lot of energy due to following the straight, guided path from the very beginning, there might be not enough energy left in the end when the guidance system tries to move the flight path forward to reach the desired impact point.

That rule applies to both cases, afaik. The thing is, that it is not set in stone and you will usually still get a good kill even if you (self) lase the whole time. But it can happen that you bombs will fall short - it is a matter of physics, not a matter of who does the lasing.

Will we get this effect for the gun? :D

New color? H...how does it taste?

:huh: https://forums.eagle.ru/showthread.php?p=3280460#post3280460

Terrain should definately have an effect ... so this sounds like a bug? What did you use to check the range of your beacon - or rather: do you get the same results with different aircraft?

Differences ... between what? The initial idea was that the config is just stored in some cloud - but I rather want it stored locally. Yes, ofc you can use other tools to sync local directories with something else, but OP's idea was to simplify things and have a built-in solution.

i5 2500K 3.3 GHz, 16 GM RAM, Win7 (What other/further information could I provide here?) I am a noob here, but maybe I should experiment with some hyperthreading / CPU affinity / other CPU voodoo settings?

After the latest 2.1. update, yes, the Viggen is still unflyable over Normandy (i.e. with radar turned on). Can't recall if I mentioned this earlier: Nevada is not smooth either (but a bit better than before latest patch?), but far better than Normandy. Normandy seems to be a bit rougher on the frame rates in general, no matter which aircraft used. So it seems, that specifically the combination of Viggen and Normandy is the culprit here.

+1 :thumbup:

Hrm, found the problem: the axes of a second (non ffb) stick interfered somehow. After cleaning up the controls setup, the trim now "works". At least it sets the FFB stick to the position where it maintains the helo's attitude at the moment when clicking trim (although that only seldomly really coincidences with the actual stick position at that moment). But whatever, at least that "forces are 180 deg. off"-bug isn't one - sorry for that!

? Oh, ok. Of course I have FFB enabled - as I am using a FFB Stick (G940). And after further investigation: not only the roll axis is affected, but pitch as well. I trim while nose is pitched down, the AP violently pulls the nose up. I trim when nose pitched up, AP drives the helo into the ground. edit: ignore this posting - was a user error. gaz roll trim.trk

I can not comment on specific issues, now fixed or not, but actually ... after admittedly only a brief ride, I really like the way she handles now. It feels like she has ... "dimensions" now instead of just being a "point in space with a flight model". One thing, though, something is odd with the mag. brake trim. I haven't played too much with it, yet, but one thing seems wrong: when trimming while the aircraft is banked results in a quite violent bank to the opposite side - usually followed by PIO or at least servere oversteering (i.e. burning hole in the ground). To replicate: fly straight and level, bank right 30deg. or so to start a turn. Does not matter much if you deflect the cyclic (to keep the bank angle) or re-center it right before you press TRIM. Instead of the AP trying to hold the right hand side bank, it throws the helo into a left hand side bank. Seems like a +- type of error here? edit: ignore this posting - was a user error.