Flagrum

I think(!), ARBS can derive the relevant information just by itself. I haven't worked my way through the public available ARBS manuals/documentation yet, but my guess is, it works like this: ARBS monitors the rate of change of the slant angle. While a single slant angle tells you nothing if you don't know neither your own altitude or more precisely, nor the targets elevation. But in the end, only the height difference between you and the target is relevant. Now ARBS also knows the speed of the aircraft and the relation of "travelled distance over time" and "slant angle change over time" should all coincidence at the same spot. "Continuous triangulation" ... makes that term sense? (i made that just up - or wasn't I the first one? :-) edit: and now after all my awsome thoughts, I re-read your posting and noticed, that I was replying totall off-topic. lol, sorry. Actually I have no answer to your actual question ...

Another aspect is, that all those simplifications have to be implemented by the devs. It is not just about leaving out some functionality, but instead they have to program new functions that combine existing functions in a meaningful way. So, besides the SFM for the AI, the A/P/EFM for the player they have to implement something between the two just for the Game Flight Mode. The same applies to avionics - the Game Mode has to operate the systems in a way that the aircraft operates roughly as if the player would use the ASM avionics, but with completely different and reduced controls. So, to free developer ressources, I would not object if those Game Simplifications would not necessarily have to be implemented.

... and I like to add my own question regarding the topic at hand: I understand, that not all fuzes can be simulated in DCS in a 100% realistc way. But for those that support the "OP" feature - that means, the fuze provides a second, alternat set of settings that the pilot can choose, right? Will we be able to utilize this? I.e. will we be able to configure different settings (HOF and whatnot) in the mission editor for example?

(NWP 3-22.5-AV8B)

When Razbam says, they submittet their changes to ED, they are usually talking about the changes of the program code, not the change log.

The thing is, that the spacing just does not seem to work atm. The other thing is, that the releasing is not evenly spread over all stations. Instead, release 1, 2 and 3 are all from the same station, release 4, 5 and 6 from the other pylon. That causes asymetric imbalance during the release sequence.

One week should be the absolute minimum, imo. This should then cover the majority of the "I am on a business trip"-cases. But, as I proposed in the other thread already, I really think a dynamic grace period should be the way to go: you get a grace period of 30 or maybe 21 days, but only once. Once you used that, you grace period is reduced for the next time, maybe for the next few times. Or for a certain period of time. Like, you used up your 30 days, then your next grace period will be a now shorter period of 7 days. If you don't use those 7 days for the next 30 ... 60 ... dunno days, your grace period will be extended back to 30 days. This should then also cover those cases of extended vacations and such. Cases where one is overseas for months ... well, this DRM scheme just have limits where it is still be somewhat effective for ED and I guess, not every case can be sufficiently covered with it...

Open Beta TV? Cool name for a new youtube channel - looking forward to watch this TV show. ... oh, wait, this is not about watching the newest DCS movies? Oops ...:D

In reality, the TDC is a 4-way hat with an additional 5th direction, namely "depressed" or "down". That way the pilot can depress the 4-way hat and also still use the 4 directions simultaneously. Such a 4+1 way hat switch is rarely seen on joysticks that we use. So to make it easier for us, we can now use any 4-way hat plus any other button for "action/no action" toggle. This avoids awkward situations where you would have to keep one button depressed with one finger and operate an other 4-way hat with another finger. It is just a simplification for us users of gaming hardware.

I experimented with a mixed loadout of 1 IR Mav and 1 EO Mav. I can select the IRMAV directly at the MPCD, but there is no button assigned to select a EOMAV? Instead I have to use the ACP stores buttons? And: while everyone and the Quick Manual is talking about EOMAVs, the in-game term used by the MPCDs is "TVMAV"?

I can't get bombs dropped one after the other with the ACP settings. Instead, they always drop all at once? I want to cover a lengthy convoi and I have 3xMk81 x 2 loaded. To drop all 6 of them, I can either set the ACP to QTY=3 and MULT=2 or I set it to QTY=6 and QTY=1. The first setting results in 3 x left, 3 x right and the second one to 6 x from both at once. And all that regardless of the INTV setting, be that 10ft or 999ft. INTV = WIP or do i miss something here?

The longer the time span, the easier this system can be exploited. Example: two guys "share" one DCS account. They both log in, refresh their 3 day period, log out, both subsequentially. Now they can play SP in parallel for 3 days. Then they have to go through this hassle again. If the period is now 30 days, they can play a whole month without worrying. If now someone shares his account on "certain" websites and 1000 ppl want to take advantage of it, they will run quickly into problems if they have to syncronize their 3-day-refreshment logins accordingly. But not so much if they had 30 days available. And this got me thinking ... what about a dynamic grace period? Like, the first time you use it, it is max. 30 days. The next grace period refreshment will be shorter, if you used the whole 30 days. For example 10 days. And if you haven't used up the whole 30 days, like for example only 3 days, your next grace period will be again 30 days. Hrm, difficult to explain ... and ofc the actual number of days needs to be adjusted. But does that make at least some sense? edit: maybe this illustrates the idea better: If you login every day, you always have a grace period of 30 days ahead of you. If you login every 30 days, you will gradually run into problems after the first 30 day grace period, because the second one will be shorter. You would probably forced to log in at least after 30, then after 20, then after 10 days again. There will be a "sweet spot", the amount of days where the next grace period is not yet shorter as X. The above example, where the grace period is 10 days shorter each time, it would be 10 days. So if you log in every 10 days, your first grace period is 30d. After 10 days within the grace period, you log in again. Now your next grace period is 20 days. Again, 10 days later you log in again, then the following grace period is 10 days. And from then on, you are just loggin in when the 10 day grace period is about to run out. This allows for some leeway and buffer for the customers, but should make things reasonable inconvinient for exploiters

Repair or Update produces this error right at the start: JSON error: lexical error: invalid char in json text. This happens for all installs I have: 2.1 OA, 1.5.8 OB and 1.5.7 Autoupdate_log.txt: Seems to be a problem with the update servers atm?

Aluminum Donkey probably has some selfies on his smart phone with him at his C=64 playing DCS:W in his F/A-18, back then in dem 80's. So, post them already, Alu! :-D

What do you suggest instead? Shouting them down for what they intent to do, moaning that this now too late and we don't want it anymore and that we won't buy their F/A-18 and their Mi-24 anyways?

From Zeus' posting last week (https://forums.eagle.ru/showthread.php?t=195997): Well, to me this reads (at minimum) like "it will go live at the next possible opportunity". Ok, didn't happen today - we are getting used to things like that. But I refuse to deduce from that, that any expectation is "obviously" not viable.

Zeus said last week that, due to unforseen issues they were not able to push their changes to the ED servers for last weeks patch. I think, he also said that it would be in the next patch - which would have been todays patch as the first opportunity. And next week, for the 29th, would be the next "official" one. And now you are implying that it is more feasible to assume that that will also not happen? Oh well, I guess, we will see ...

Did not pay too much attention, but for me it was rather small...ish. Like <500 MB (with all modules installed). Maybe you skipped an update or two in the past?

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?