M1Combat

What I "try" to do, terrain permitting... is set up my attack from a hill-top about 8-10KM from the target site. with enough elevation you can kill targets out to about 10KM.

I would but I've been super busy for the last few months and I decided that if I could offer some insight into how to isolate the cause I could speed the process. More heads are better than less :). My suggestion to do so was to be certain that the trim was derived from a super stable flight envelope. It was that simple... but as soon as I didn't just say "Oh yeah.. a bug for sure" then RAnma just jumped my shit and refused to actually think about anything I said. I continued to try to explain in an effort to get the damn thing tested :). Also I don't use FFB... Which I mentioned as a reason as to why I didn't provide the tests myself. As soon as I said anything regarding "maybe it's a bug, maybe it's not" it became very difficult to get through to various folks due to them just deciding I was simply trying to say "Nothing to see here... Move along"... but I wasn't. The motorcycle example is quite relevant. It does require that you know a little about unstable self righting vehicles... but it's pretty simple if you just take a look at cited references or read my explanations. I can't control someone else's mis-calculation of what my intentions are... and I certainly can't control their feelings that I'm trying to prove I'm smarter than they are... I mean seriously :)... WTH? Anyway... If it's a bug, and it's starting to seem that way... I'd love to see it fixed :). As I said the Shark is my favorite Sim toy :).

Yes exactly :).

Well that's not my problem... I'm still making an excellent point :). Also... you're obviously starting to get my point as you're starting to test better and starting to suggest the same things I have been :). What's more... the more you test and narrow down the likely cause of the issue... the more it points in the direction of what I've been saying for a while now :)... that the issue comes from how the current logic is applying or mis-applying the trim offset. So yeah... Feel free to ignore but if you had listened to me and accepted that maybe there's things you don't know a LONG time ago and tried to understand what I was saying... we would ALL be a lot further ahead now. Thanks for that :). It's been super amusing to watch through the course of these two threads :) One more thing... Sorry not sorry for switching to "tell it like I see it mode" regarding you... But you got under my skin when you decided to start dismissing what I was saying just because you decided I was wrong based on your own lack of understanding of what I was trying to say. I general you seem to bring relatively good info and presence to the forum but as soon as I said "I'm not sure this is a bug" (or something like it) in the other thread you started being super dismissive and rude to anything I said later. That's on you. I'm still trying to help :). The Shark is my favorite sim toy :). Maybe the Lotus 79 in iracing is a close second :).

Isn't it backspace? Or is that for stick only?

Well they mostly did that jctrnacty :)... Then the people who stuck with the "release" version complained that they didn't get new features fast enough :)... And then some people who decided to switch over to Open Beta decided that it should be much more stable :)...

@RANMA No pretentious "I'm so smart" bullshit going on at all. Also... thanks for suggesting that maybe it's in the way the trimmer mode handles the "trim offset"... Just like I suggested a few posts before you... Post #6 "That offset is what I think is causing the movement you're seeing. And... I'm not sure it's a bug. If it is... It may be that the logic behind the FFB mode does the wrong thing with the AP channel's trim offset." and "I still feel that the cause is the AP's CURRENT control authority magnitude and how that gets applied to a NEW trimmed state." Post #10 "If you catch the oscillation (by releasing trim) at a place where some of the 20% control authority in the AP channel is used... Then re-trim... We don't know what the shark's computer (and by that I mean the selected control logic ini the options really...) is doing WITH THAT EXERTED CONTROL AUTHORITY. We need to." No. Only motorcycles and aircraft and maybe a few other unstable yet self righting object. Anything on the ground with more than two wheels specifically does NOT fit in this category. In any case... It's not my fault you don't understand the concept I'm trying to point out that could be effecting the results we're seeing based on where in that oscillation you're releasing trim. It is a motorcycle or airplane's natural tendency to oscillate back and forth on both sides of an equilibrium. Simply that. So yeah... get off your high horse. I'm trying to help. _______________________________________ Anyway... back on topic :)... Yeah... As I said... I'd like to see a few tests to isolate where the issue is coming from so we can decide if it's a problem with the trimmer mode.. Thanks for those :)

"they could do a bit better highlight it (like the recent AI update, or the wake turbulence a while back)." Yeah... One would think that would be the way to go... Then they do that and 1/3 of the forum complains about their pet project not being worked on because some dumb feature like "Aim120" or the stupid "Ground Radar" or even that useless "IFF" crap is more important... So then ED catch enough flak and they go quiet for a while... Until people start complaining that they never hear about the new features or what's being worked on and they should be more open and transparent with us... I've watched that cycle for years... They have too...

So... I thought the major thing in 2.5 was the terrain engine? I seem to recall they moved to PBR as a somewhat attainable goal during that move because they planned to re-do a lot of textures anyway... but that the terrain engine was the primary goal of 2.5...

Steel sharpens Steel... Try harder... JK ;)

"Best preformance with small marging of safety" Yes :)

"Best Performance" is to run as fast as possible and start with 4s open (close fully, then hold open for a 4 count) and adjust open/close with speed. Open when you go slow, close when you go fast. PLAN AHEAD... It's super slow. 20s opened to closed. All that said... The Mustang isn't really a turn fighter so... auto generally works fine if you keep your speed up. Just don't consider that as "best performance" because it isn't.

Auto is NOT best performance.

"I also perfectly understand your attempted explanation of the phenomenon. I just don't agree that it's correct behavior in the simulated aircraft system/flight model. Mainly the aircraft system, as the flight model acts just fine when I take the ka-50's trimmer out of the equation, and simply trim using the hardware feature of my joystick." No you don't. As I said... "The oscillation I'm talking about is not what you're talking about. I'm talking about any free body's natural tendency to oscillate around an equilibrium. It's basically the concept that no motorcycle or aircraft EVER can go straight." I'm talking about how you initially set the trim affecting what happens during a re-trim. You're talking about what happens when you re-trim. The issue you're talking about isn't even an oscillation. It's a possibly errant control input coming from somewhere. Again :)... I'm not convinced it's not a bug... I'm just trying to explain a method to isolate where it's coming from so we can go to the dev's with more info rather than less.

Here... this is true for all unstable bodies... Motorcycles are one of these as well. The oscillation is never 0. https://en.wikipedia.org/wiki/Flight_dynamics_(fixed-wing_aircraft) Sooo... If you catch the oscillation (by releasing trim) at a place where some of the 20% control authority in the AP channel is used... Then re-trim... We don't know what the shark's computer (and by that I mean the selected control logic ini the options really...) is doing WITH THAT EXERTED CONTROL AUTHORITY. We need to.

I don't think either of you are understanding what I'm trying to say. No offense meant... maybe I'm not explaining it well. All I'm asking is that you test with a very small trim offset (When the AP channels are exerting very small amounts of control authority to maintain trimmed attitude) and with a large trim offset (when the AP channels need to exert somewhere near their maximum control authority to maintain air frame attitude). This will be valuable information. I'm just seeing both of you perform a minor test that doesn't prove anything and certainly doesn't prove any "cause" for what you're seeing. I'm not saying "there is no issue here... move along...". I'm saying "Test, test, Test. We'll find a bug IF it's there AND we'll have a good bit of info about what settings, procedures and even environmental factors affect it" Until you do that... NOBODY will be convinced :). If you want someone to be convinced... you need to do the leg work :). That's all :). Also... The oscillation I'm talking about is not what you're talking about. I'm talking about any free body's natural tendency to oscillate around an equilibrium. It's basically the concept that no motorcycle or aircraft EVER can go straight. EVER. It doesn't happen. That's the oscillation I'm referencing. Not what happens here when you re-trim the KA-50. I'm going to stop trying to make the point though because I don't think that either of you have the background knowledge to get the reference. Please don't take offense.. That said... I'll try to find an explanation and I'll post it here.

I think it would be enlightening to trim the aircraft so that the AP channels don't need to deviate from the trimmed stick location to keep the attitude. Basically a SUPER stable flight envelope BEFORE you release the trim button. I still feel that the cause is the AP's CURRENT control authority magnitude and how that gets applied to a NEW trimmed state. To elaborate... The air-frame will oscillate around a trimmed attitude... and the AP channels are what's responsible for keeping the nose in the rubber-band... So... Take a for instance... You trim to a super stable hover and note the stick position and trim offset (in a FFB setup these will be the same... and they will be very close to the trimmed position. Now... Press trim and VERY QUICKLY move the stick to somewhere else WITHIN the trimmer's 20% control authority and release trim. The attitude of the airframe won't change much (due to inertia) by the time you release trim. Because of this badly attained trim what you will end up with is the AP channels applying up to 20% control authority to maintain the air-frame's attitude when the trim was released. There will be a large offset between where you released trim and where the stick ends up based on the AP's interest in maintaining the attitude and not the stick position. That offset is what I think is causing the movement you're seeing. And... I'm not sure it's a bug. If it is... It may be that the logic behind the FFB mode does the wrong thing with the AP channel's trim offset. That said... I don't fly with FFB.

They don't just set it fully open or closed. It's a momentary switch that operates the motor in one of two directions that will open and close the rad door. From full open to full close and vice versa is 20s.

I agree Strike... The AI and how it fights and even the tools it uses to fight can , IMO, be fudged. As long as it's VERY believable none of the rest should matter. It can't be allowed to over or under perform and it needs to be "smart" enough to make you work based on the level it is set to. It shouldn't be overly predictable. That doesn't sound like an easy task to me :).

Just update to Beta dude :). Occasionally there are issues but generally not. I'm not sure which branch has more MP servers but I suspect Beta.

Exactly.

Yes. The cable is also for power.

No... it would be a waste to apply it. Like Zhukov said. Adjusting the AI version of the SFM would be better for many reasons, worse for many also. Ultimately what's needed is a model that doesn't allow the AI to do things that a human can't do. "Pro Tip" :)... We have that. Adjustments to how the AI is applied to what we have in the SFM will suffice quite well for that. Using the PFM would also be fine (but with many issues that would arise from doing that) but would use a ton of resources (in many areas) and not be noticeable in almost all situations. That's not really quite true either. There is very good information on each FM and how they differ. Maybe you'd call that "surface" info, maybe not so I'll give you this one because of its subjective nature.

Maybe heat related? How clean are the fans in that video card?

No way man... Keep it VR only... It's ALL WE'VE GOT!!! ;)