JaBoG32_Dirty

Hi I've been playing around with DCS' export interface and I would need the aircrafts angular acceleration for a project. Does anyone know if this is available for export directly? Of course, I can use angular rate ( LoGetAngularVelocity() ) and calculate ∆value/∆time, but that would give me a one frame delay that I would like to avoid if possible. Cheers,...

Excelent question to ask before buying I've been using Realsimulators FSSB sticksbases in various versions for the past 18 years as my only stick and for anything FBW there's really nothing that even comes close. Reason is, in FBW aircraft you use the stick for a single input parameter: Stick deflection (Airbus/Boeing) or sick force (F16 etc.). The flight control laws in the FCCs will then decide wether this input leads to AoA or G-load or pitch rate depending on flight phase, configuration.... Also, in FBW aircraft controll inputs are one-way, meaning you do not get any feedback from the aircraft through the stick. For converntionally controlled aircraft (cables, pushrods and alike) stick deflection and stick force are not directly correlated and can be used somewhat seperately: In pitch for example, stick deflection will be proportional to an alpha-demand, while stick force will be proportional to a G-load demand. At least over a wide range of the flight envelope. That's why conventional sticks are better suited for conventional aircraft, even though few people use a proper controll loading system at home. It still gives you that element of deflection in your controll setup. Helos are even more leaning towards being controlled with deflections rather than force, so I would definitely try out that stick before deciding to keep it. In Europe, you generally have a 14 days return policy on online purchases. If you're unpacking it carefully, you will be able to just get it refunded if you don't like it. And above all: This is an awesome stick!! You will never be flying with deadzones again, that's for sure. Cheers,....

That sounds interesting. 30% is a huge error indeed. Even for a 1970s aircraft. What you could do is check the data in the export interface and see if that matches up. Maybe I will do that when I find the time.

There is another thought that crossed my mind: Does anyone know how the value of trim is represented internally in DCS code? I mean, if it is stored as a single byte value (only 256 states), it would explain why it behaves so granularly. Again: I found the numbers to be very plausible, I just think it should be adapted for easier use given the restrictions of simulator flight. Dirty :-)

I have been observing similar behavior on trim as Sylosis, and am kinda glad I am not the only one noticing it. The funny thing is, that a few years back I looked into the trim rate of the real T38 (knowing it is a similar airframe as the F5) and found the trim rate in DCS' F5 to be very close to the real thing. Still, I would suggest slowing it down or adding an acceleration ramp to the trim rate, to make it more useable in the sim. After all, most of us are flying without any tactile feedback and it could help precision tremendously. I even used an Arduino to generate the smallest possible trim increment (1 frame) and I noticed, that in an F5 at typical cruise airspeeds, this "quantum" of an input was already enough to change vertical G by about 0.01G. That is quite a big change. For example: Typical autopilot inputs in airliners use changes in vertical acceleration of around 0.15G at max for flight level changes. Cheers,... Dirty :-)

Hey, just watching the video you posted :-) (Messerschmidt) "The Book" is also what I learned from back in the late 90's. Back then I already thought it was a century old, but he's right: "The Book" is THE book to read when it comes to aircraft performance! Great video!

Thanks, nice to hear that :-) It was fun exploring the data and I guess I will do a couple more. Concerning the video, I clearly seem to be too dumb for that... If I write [YOU_TUBE] [/YOU_TUBE] (without the _ of course) I get this: ${1} Anyways, thanks for watching :-)

Hey :-) I took a closer look into the power-on and power-off characteristics of the L39C. I know this in not going to be the Blockbuster of the Year video on YouTube, but maybe there are a few die-hard flight-performance-data-nerds (like I am) around here who appreciate :-) A bunch of more videos still cooking in my mind. Maybe cruise performance, turn performance or fuel consumption could be of interest for serious pilots flying in squads. Not sure,... let me know. Power-on perfornance: Power-off performance: Enjoy... Dirty p.s. If someone could explain to me how to properly embed YouTube content in here, I'd appreciate :-) EDIT: Finally got it :-) Thanks a lot, @Ramsay

Exactly! :-) Adverse = Against the direction of the control input (as opposed to proverse). Yaw = Rotation around the vertical axis (for DCS this is the y-axis) Btw, I actually work in the field, and I wouldn’t know what better term to use to describe this behaviour. But whether you like this expression or not really isn't the topic. What is, is the fact that in this scenario the simulated vehicles in DCS experience an angular acceleration around the vertical axis that is in a direction that is opposite to the control input. I did my best to bring this to the developers attention and have unfortunately not gotten an answer from anyone who actually worked with vehicle motion dynamics in a professional way. I found this behaviour on other models, so I guess it is not type-specific. Furthermore, I found taildraggers topple over forward (not sideways!) easily with high sideslip angles as well. That observation too supports my thesis: The reason for the strange behaviour at high wheel sideslip angles is that DCS calculates a drag-term that is opposite to the vehicle direction of motion, when it should instead be opposite to the relative direction of the sliding surfaces. For a free spinning wheel that direction is always along the wheel axis. And again: Yes, you can still enjoy DCS World. I do too! Not a big thing! It’s just that I would’ve expected to at least hear from a developer briefly.

...Oh, and something similar: I saw somewhere... MainPanel = GetDevice(0) local ias = MainPanel:get_argument_value(49) ...again, where would I find a list of what data this function returns for the posssible arguments? Any help would be greatly appreciated!

Hey there, I would like to export some data out of DCS for a project. Somewhere in a post I stubled across "LoGetAircraftDrawArgumentValue(n)". Now, I'd love to use this function to read data, but I only know what the function returns for very few arguments. e.g. local NoseGearStrutCompression = LoGetAircraftDrawArgumentValue(1) local RightMainGearStrutCompressionr = LoGetAircraftDrawArgumentValue(4) local LeftMainGearStrutCompression = LoGetAircraftDrawArgumentValue(6) ...can someone point me off in the right direction where I might find out what the returned data for more (all) possible arguments of that function is? That would be a tremendous help!

Hey there :-) Can anyone tell me where exactly the exported accelerations that LoGetAccelerationUnits() returns are picked up from? I would assume that it is vehicle center of gravity, but it might also be pilot eye reference position or any other reference position on the aircraft. Does anyone know this for sure? I am building a hexapod motion system, and it could make a small but noticeable difference. Not in flight, but certainly during taxi. I will have to correct for this anyways, but it would narrow down my trial and error process a lot. Dirty

Hey guys :-) I'm observing the same system behaviour as Moafuleum. And am also wondering where this is coming from. Basically I understood the question to be "Is this a bug or a feature?" I am aware that it would make sense to use two different phrases to make the left and right fire warnings easier to distinguish. But still: Is that part of the design, or unintentional? I am aware that it does not show if the start-up procedures are followed correctly. But still: Why does it have two different sound files? And yes,... I'm aware that it doesn't make a difference for the casual gamer who just wants to fire up the Hornet and blow some bad guys out of the sky every now and then. Nothing wrong with that :-) ...but if someone (devs? ...anyone?) has a plausible explanation for this behaviour, I'd appreciate! Dirty :-D

Yes, yes,... I said it before, I say it again: This is NOT pressing, major-issue, important, urgent, deal-breaker, necessary,... etc. This is simply an attempt to find like-minded people to discuss with and exchange ideas about something we are all somewhat interested in and passionate about. In mutual respect and with full knowledge and acceptance of the others thoughts and ideas being their own and not a copy of mine. If someone finds other aspects of the sim worthy of discussion, they may start a thread and I'd be willing to add my point of view to it, if I have anything substantial to say about the topic of discussion. But at no point will you ever see me questioning the very existence of the discussion itself. If I ever did that, I'd have to question my own participation in it first! Dirty

Hey Weta43, I'd like to comment on your post, if I may :-) Please take this in a friendly way. Open-minded and respectful. After all, we wouldn't be here if we weren't infected with the same borderline insane obsession with simulated flying. I really don't care WHO's right, but I do care very much WHAT's right :-) Cars also have caster wheels. It is what lets you feel the lateral forces in your steering wheel when cornering. Even modern power-drive steering provides such feedback. It is essential for controlability in any car. It is not static. It does still spin. It spins at cos(NWS_angle)*groundspeed. It even does so in DCS. Exactly how it should be. If it weren't spinnig you'd be right, but it is :-) Correct! ....for a vehicle in an OVERsteering situation :-) A situation where the angular rate is higher than the wheel deflection demands. A situation where PROverse yaw is being induced from differing friction coefficients between the front and rear tyres. This situation is indeed unstable (at least in fwd motion) but that is not the case here. It is not OVERsteering, it is not even UNDERsteering,... it is ADVERSELY steering :-) ...hmmmm... *blushing_slightly* ...let me PM you :-) I guess many of you understand, that the caster wheel will offset to the adverse side when deflected. What I'm trying to convince you guys to do, is take the "next step" and ask yourselves: where does the resulting force point? Dirty :-D