Havner
-
Posts
347 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Havner
-
-
On 10/31/2024 at 7:21 PM, Raven (Elysian Angel) said:
I have no idea if I use different settings but for me it works fine.
Thanks, but I found the culprit, described it in further posts.
On 10/31/2024 at 7:21 PM, Raven (Elysian Angel) said:Yes the Apache is very twitchy
Yeah, same feelings here (compared to equally heavy Hind or Hip), but that's a thing for another thread. I presume someone covered that already. I'm not following the forums.
-
1 minute ago, Number481 said:
I will agree and disagree with everyone in this thread
Well you basically agreed fully with me
And I fully agree with everything you said.
1 minute ago, Number481 said:*Saturation* (axis scaling) should not be hard to implement. It's supported in the Rhino telemetry software for the "Civilian sims" where the entire FFB implementation is handled by the application.
Correct.
1 minute ago, Number481 said:*Curves* are a whole other animal. This doesn't bother me though since I generally believe curves are bad. Most people who are using curves should be using saturation/scaling instead.
I never said anything about curves. Not using them and (would have to think this through) but probably might not be so easy to fix as the saturation is. But again, not using them, didn't report them, did not claim they are easy to fix or should be at all. With high end equipment and long sticks there shouldn't be a reason to use them anyway as you said.
3 minutes ago, Number481 said:The fundamental issue here though is that there is zero relationship in DCS between the axis x/y and the FFB x/y. When you invert an axis, the "ffb stack" has no idea, so forces would be backwards until you also invert the "FFTune" for the same axis. When you set up saturation on the axis, you've essentially made the full physical range of the axis only produce some % of the virtual range... but the "FFB stack" still thinks its %100 stop to stop
Correct. The question is what a specific option is for. Because the "invert" might be to fix some discrepancy in the base that have X/Y mixed for output and FFB (akin to inverting wheel brakes axis in DCS). The saturation is not to fix discrepancies in the base. It's for the user (cause he prefers them for whatever reason) and the axis output and FFB output should match the settings, be consistent. It's not ATM.
5 minutes ago, Number481 said:I can show you a trick using the configurator software to produce a "saturation" of sorts. In configurator, simply manually increase the calibrated range the same amount both on the upper and lower ends of the range. For example, if your calibrated range was 1275 - 3000, you could manually increase the range by 200 on either side (1075 - 3200). This would cause the full physical deflection to only account for roughly %80 virtual deflection.
Thanks, but no need
I'm fully aware of that. Also Rhino can implement its own force trim keeping all the other FFB effects from the game intact. I have no issues with workarounding this bug in at least 3 ways in total. The thing is that this behaviour should be fixed in game. I can workaround it, Moza users I presume might have bigger issues with that. And knowing FFB stuff from racing sims, different bases have different options. And none commercial bases have so many options as Rhino. So the issues should be fixed in game as people with more commercial bases might not have means to workaround it.
-
11 minutes ago, MAXsenna said:
Call it what you will. It's not a bug. DCS probably implemented FFB without the devs ever having a suitable device, so there's that.
About time they went back to the drawing board and expanded the implementation with more and more devices on the market now.
-
8 minutes ago, MAXsenna said:
Well, it's not a bug. Call it well known limitation if you wish. I really don't care as it's a known fact. It is what it is. Make a wish, or the Rhino has super software. Can't you just tune it there?
Sorry, you can call it what you wish. A missing feature, a bug, a known limitation. Something doesn't work as expected and can be fixed. Doesn't matter. There is no section on the forums to report "known limitations". For all intents and purposes here it's a bug. Also why would I care that you don't care? This is a bug report forum. This post was not meant for you, but for the devs.
Also this post is not about what I can do with it. I can workaround it in Rhino software, but it doesn't make the bug any less of a bug. Moza users probably won't have an option to workaround it.
-
3 hours ago, MAXsenna said:
Not a bug. You can't use curves or saturation with FFB sticks.
How would your FFB stick know that you have changed the virtual length of your stick? That's what saturation does. 33+66=~100The FFB doesn't need to know that. The game needs to send a rescaled center for the FFB spring effect center. And the game has this is info as it has both, the saturation and the "virtual" force trim center. There is nothing that stop DCS to implement this.
So if you have a saturation of 50%, the force trim center at:
physical: (100, 100)
logical: (50, 50)DCS now sends (50, 50) as the FFB center (hence the stick moves to the center). It needs to send a physical stick location (100, 100). Simple as that.
-
3 hours ago, Hiob said:
That‘s not a bug.
You are not supposed to use saturation or curves with FFB sticks.
3 hours ago, MAXsenna said:It's not a bug. The FFB base doesn't know how to behave when you change length of stick virtually, (saturation).
Sorry guys, but completely disagree with you. There is nothing that stops them to implement this. There is no technical, logical or any other showstopper to make it work. The FFB can "know" everything as FFB is driven by the game and the game knows the saturation.
The same as saturation changes the logical output of an axis it can change the logical "center" of the spring FFB effect as that center is sent by the game.
-
I've reported this:
-
This is for helis, tested Apache, Hind and Hip, so I presume it's bugged across the board.
1. Use FFB stick
2. Set saturation on the pitch/roll axis, e.g Saturation Y to 66%.
3. Use force trimWhen releasing the trim button the stick moves away from the set position ~33% closer to the center that it was released with.
Makes using FFB force trim impossible with some saturation set. -
10 minutes ago, Hiob said:
No curves or saturation applied to the axis?
I had saturation, just tried without it and it's fine now. But this is definitely a bug when using saturation + FFB.
10 minutes ago, Hiob said:Have you tried the different trim options in the special options?
FFB should be used with instant trim.
EDIT: just checked, this is bugged on all helis... WOW.
-
I have VPForce Rhino and the FFB in DCS in general is working fine, not an issue with setup. Flying Hip/Hind/KA50 without any issue.
The issue is with Apache. When I hold the trim everything is fine, the stick is light. When I release the trim the stick sets a new center, but not the one I had when releasing the trim, but one 20-40% closer to the center. Every single time. It's impossible to trim the heli. This doesn't happen in any other heli in DCS.
I can workaround this by implementing the force trim outside of DCS and then it works fine. But with the DCS FFB it's broken. Is it by design? Is there some Apache autopilot thing I'm not aware of? Or what is happening?
I've seen mentioned in other FFB related thread to spaw FFB axis, but as expected this completely broke the FFB (after releasing the trim the stick moves to the oposite side of the center).
-
@MadKreator thanks for the answer. I guess you answered my question in a way, that there is no correct way to achieve what I want
Doing what you suggest is a workaround. I might experiment with it. What I don't like about it though is that dimming the in game displays will compress the histogram which will then loose details when brightening them with reshade on exported displays. But like you said, nothing more that can be done here anyway.
Regarding the Apache, what I meant is that that's the only module that actually has a proper solution done by ED (albeit by chance I presume). The in game displays have a brightness rotary that affects only the in-game displays, but not the exported ones. So I actually can dim the in-game displays completely (they are black) without affecting the exported ones at all.
-
Hi,
Is there any way to hide MFDs or any other exported display when it is being exported?
The issue is that there are brightness differences between exported displays and the ones in virtual cockpit. I already brighten the exported ones with Reshade + mask (as describe in a thread elsewhere) but the brightness difference can be significant at night that blinds me (I have OLED tv with high brightness). The ideal option would be to hide the exported displays, e.g. make them simply black.
In Apache I can achieve that with the brightness rotary that affects virtual displays, but not exported ones. But it's only for Apache. Is there a generic way to do that? For A-10, or F-16.
Screenshots to visualize the issue. Sorry for low quality, but my phone has broken stabilization.
-
On 4/15/2024 at 1:29 PM, Devrim said:
CHANGELOG v1.8
> New textures by Heatblur have been applied (04/2024).
Everything's perfect again. Much appreciated
-
2
-
1
-
-
10 hours ago, paco2002 said:
Wait
Thank you for this very insightful and much needed knowledge. I don't know what we would have done without people like you.
-
1
-
-
Hi Devrim,
Found some misaligned textures using 2.9.3.
Thanks for your great work on various cockpits
EDIT: Also the FM/AM indicators on the front panel radio panel.
-
2
-
-
2 hours ago, Hiob said:
Agreed. A by current DCS standards overhauled Hip would be my wet dream……
Ditto
-
I second this request. Another thing where it would be nice to raise the Hip up to the level of Hind (including all the options for rudder trimming and microswitch behaviour as well).
On 9/30/2023 at 7:49 PM, AeriaGloria said:So the “release microswitch by return pedals to center” works better for the 8 then the 24, as center point doesn’t change nearly as much
Yeah, unless you use non centering pedals.
-
1
-
-
4 hours ago, Hiob said:
I don't think this will happen, unless the Hip receives a general (much needed and wished for by me) overhaul.
Would be nice though to have a proper civilan version.
You're probably right. But still posting this in case they ever do such an overhaul which I also think this module deserves the most.
If they do, maybe this forum will be a base for ideas for new things. And hopefully this post will get noticed.
I would really like a Hip v2. That would upgrade the Hip to the level of Hind. Would gladly pay for such an update.
-
3
-
-
With the option to remove external hardpoints and/or with an option of "civilian plane" to have a fully civilian variant.
Not only to remove the hardpoints and the sight as it is now but to remove all the other cockpit controls related to weapons. Basically have a variant as would be shipped to a civilian buyer.
-
2
-
-
I've just stumbled across this bug. As it's been reported more than a year ago can something be done here?
-
1
-
-
9 hours ago, admiki said:
Like AG said, unless you are constantly dancing on your pedals during turn, how would it work?
Exactly like that. Doing micro movements in a turn to "press" the microswitch. It's not ideal but everything we do without having exactly right hardware is a compromise. The same way as pressing regular force trim and returning the stick to center for sticks with a spring. Again, not ideal but we do it anyway.
The fact is the setting is there. Someone thought about this use case and implemented it. The setting doesn't work though, ergo it's a bug. I reported it. And I for one see this option as useful for me.
It's rather sad when others say: "don't implement it, remove it, etc, cause I don't need it". There are probably lots of things I don't use. But I don't say they are not needed just because I don't need them.
9 hours ago, AlphaOneSix said:Well, in an ideal world, I think ED would just add keybindings for the pedal microswitches, and people can implement those physically however they see fit.
There is a binding for the microswitch. You can implement it physically if you want to.
-
1
-
-
18 minutes ago, AeriaGloria said:
I and everyone I know who has tried has found the “enable by presence of movement” setting to be useless. I think it could be removed and not be missed, but that’s just me.
It wouldn't be useless for me if it worked properly. You need to account for a fact that some people use non centering pedals. And with such pedals the other option (Disable by setting pedal axis to neutral) is useless.
So saying it could be removed you actually assume that everyone uses the hardware in same way you do.
Also maybe you found it useless because it actually doesn't work and doesn't do anything at all?
-
1
-
-
Some background:
I use non-centering pedals with damper without a spring. Hind is set as follows:
Pedals trimmer mode: Default (I suppose it's irrelevant here)
Pedal microswitch: Enable/Disable by presence/absence of pedal movement
Pedals trimmer button: Do not trimFrom some old changelog:
QuoteEnable/Disable by presence/absence of pedal movement (this logic is added and it activates microswithing only for duration of pedal axis movement, deactivates it when axis stop moving)
And it doesn't seem to work. Looking at the AP channels I can see the YAW channel working (with AP channel enabled). When I press the Microswitch manually (default Y) it behaves as expected. The YAW channel is reset, new Heading is set.
But nothing like this happens when I only move the pedals. No indication that moving the pedals actually enables the microswitch. The YAW channel is not reset, it fights against me when I move the pedals. It behaves exactly the same as when I set "Automatic Microswitch Off".
EDIT: I've tested the "Disable by setting pedal axis to neutral" option. This one works. It's useless for me as I use non centering pedals but I clearly see symptoms of microswitch being pressed when pedals are off-center.
-
1
-
-
I wanted to report this, but I see that it has been already. More than a year ago. Can something be done here?
Apache AH-64D Flight Model and further Development Status in 2024?
in DCS: AH-64D
Posted · Edited by Havner
Thank you for your posts. I don't follow the forums, but I had very similar opinions on the Apache since day one. I love "using" it. I hate flying it. And I love flying all the other choppers in DCS. I can't believe that such a heavy machine is so twitchy in the yaw. And even if for some reason it was inherent characteristic of its model I can't believe they wouldn't fix that with SAS. Right now it's actually a little (very little) easier to fly it with yaw SAS turned off. Which says a lot.
Anyway, I don't have much problem with flying it like as we all I got used to it. But the behaviour of its flight model (comparing to equally heavy choppers like Hip and Hind) amazes me, how unbelievable it is and how unbelievably uncomfortable for the pilot it is. I really do hope that the announced flight model rework will come relatively soon and it will be good. I love this chopper, I want to love it fully. Right now unfortunately I hate flying it.
Another things that is seriously missing is FFB. But it goes to all modules made by ED, so nothing special here. It basically only implements force trim and that's it. We have to use external software that generates some (unfortunately) static effects to have something more. And here goes another point you mentioned. Lack of cockpit shake.
One of the effects I add to the FFB is ETL shake. Unfortunately it doesn't come from telemetry, you need to statically set between what speeds to add it. And when I was doing that for the Hip and Huey I had no issues to see those speeds as the cockpit was shaking like crazy. I couldn't see that in Apache at all. I feel the ETL changing the handling characteristics (obviously) but I have no idea when exactly does it start and when it ends. I'll have a look if maybe the sliders you guys mentioned is fixed now.
Anyway, count me in to the list of people eagerly awaiting Apache flight model revision.
EDIT:
Nope, no effect whatsoever.