Flagrum

The A-10C shows the estimated impact points ("BATA"? those little circles that appear in the HUD) which are supposedly representing those 5 mils - which is consistent with the measurements of the other HUD symbology. The actual impacts are occuring a lot way outside of those predicted impact points. There were tests performed and result videos posted by the 476th guys back then.

It actually is always perpendicular to the horizon, but yes, if it were connected to the target diamond, it would indicate where to fly to, even if the target disappeared beneath the nose. That would make sense, I think.

Before the latest patch, the ASL moved to the opposite direction of where you would have to steer the aircraft to. This seems to be fixed now, thank you Zeus! But ... it is still not really working as it should (I suppose). Now, after the patch and after applying the HUD lines quickfix, the ASL moves in the correct direction, but is (and probably also was already before the patch) somehow strangely related to the banking angle. If I follow the ASL with my FPM - and therefore have to bank a bit - the ASL moves further out. So, "chasing" the ASL makes me turn further and quicker away, the more I try. See the screen shot: target is to the left, but I am still supposed to bank right - but will never catch the ASL as I am off target eventually. If I level out, the ASL moves back in direction to the target and once I am completely level - in case of the example of the screen shot - the ASL coincidences with the target, but ofc left of my flight path.

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.

The ASL right now seems to be quite unusable. You can chase the ASL with your TVV all day, but that will never align you corretly for a good release. If the ASL is i.e. left of your TVV and you bank slightly left, the ASL wanders off to the right. You have to level off again to re-judge your steering error and try again ... Gathering from the RL NATOP manuals, the release cue should also appear a few momentes before it starts to fall. This does not happen in my tests - it just suddenly appeared and started to move down immediately. At first, I wondered, if I did something wrong, because my target designator symbology was never the "diamond" for a locked target. It looks rather than what I assume is the Mav. target designator symbol, a square with 4 ticks at each side on the inside of the square. This looks quite like WIP, or did I make some mistakes?

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?

Fireing sequence of two loaded Zuni pods with ACP set to QTY=4, MULT=2: first time firing: 4 x left pod, then 4 x right pod --> ok (i guess?) after "unlimited weapons" spawned new Zunis: alternating 1 x left, 1 x right, 1 x left, ... until depleted (I _like_ this better, but i think, the other way is the realistic one?)

Probably an error only in conjunction with "unlimited weapons"? When setting the Manual Control Rotary to, for example, N/T, it's setting is overridden once new bombs are spawned and selected. FUZ then says "SAFE" while the rotary still is set to "N/T". Bombs go dud in this case. I would expect that the Manual Control should have priority in any case? edit: reading the section about the APC in the Quick Manual ... maybe I was using the Manual Control under wrong assumptions. Seems that there is more behind it than setting the fuzing - it also selects weapon stations - which could result in somewhat (for me?) unexpected results. Need to re-evaluate.

Decrementing the left most INTV digit does actually decrement the left most QTY digit!

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?