aledmb

amazing product and exceeding expectations! keep up the great work, you deserve all the success my man!

nice! thank you!!

mine just arrived and it is indeed a great product!

i think the seating position is good now... at least you're seating with your back rested in the seat... before, you were sitting on the top of the stick. maybe they could recalibrate the HUD projection so it's visible for this new distance?

i wish i knew this before i ejected a few minutes ago. :doh:

this is so weird. i wonder if real pilots have to lean forward and down as much as i do with VR in this thing. :D i guess we just have to get used to it. ;)

i'm trying the startup lesson, but there's nothing i can do to this knob to make it work. i tried clicking, double clicking, right clicking, clicking and spinning the mouse wheel, right clicking and spinning the mouse wheel. nothing works. is this a known issue?

yeah, i get it... thanks for the input! :thumbup:

i can send you a mission where the airfield designated for landing in my route is not available in the PVI-800. i don't see why you wouldn't want this to be fixed.

well, sure, you can use all waypoints as "fly over point" and the human will understand that he is supposed to land in the last waypoint in his route. i just think one could opt to properly describe every waypoint with as much information as possible... if you want the human to follow the rules for a "fly over" and not a "turning point", why wouldn't you make it explicit? anyway, not having a waypoint show up in the PVI-800 system just because it's of a specific type is a bug. that's why i reported it. ;)

no, those are two separate issues. :) one issue is that the ABRIS does not show the waypoint name for certain waypoint types... for example, if you set a landing waypoint in the mission editor and you give it a name, it will not show in the ABRIS like it does for other types. the other issue is that a landing waypoint will just not be available in the PVI-800 system.

the ABRIS shows the last waypoint, no matter what type it is. the problem is with the PVI-800 system... if you have your last waypoint set as "landing" by the mission designer, it's not available in that system.

yeah, i was just pointing that there's this difference, if someone wants to check it, but i'm not saying it's a bug... if the real systems in the ka-50 are like that, keep it. i don't get your thinking here... if you mean that mission designers should not define waypoints of the "landing" type, that option should be taken out of the mission editor, because currently, that waypoint goes into a black hole... it's a bug that needs fixing (same as the names not showing for a few waypoint types).

while studying the ABRIS and PVI-800 systems, i've come across a few inconsistencies and bugs. in the mission editor, when you are defining waypoints, you can choose the waypoint type. the initial waypoint can be: mid route waypoints can be: and for destination waypoints: i've noticed that the ABRIS does not load the waypoint name defined in the mission editor when the waypoint type is any of the following: - take off from runway - take off from parking hot - landing as an example, check the flight plan loaded into the ABRIS when the last waypoint is set to the "landing" type: i think this can be a bug, because there's not much logic here. also, i noticed that waypoint numbers do not match between both navigation systems... waypoint #1 in ABRIS is actually #2 in PVI-800, and so on... this can be confusing when you want to set both systems to a common destination... i mean, life would be a lot easier if both systems matched these indexes. one more thing that i think is a bug... when the waypoint type is "landing", it cannot be selected in the PVI-800 system... you have to rely on the ABRIS to be able to land.

doesn't fix this issue. i'm playing in VR, so maybe it's related? any news on this?

when i turn on NVG in VR, it only renders in the left eye. the right eye stays the same. also, when i press ESC, the pause menu is not rendering in the left eye (the one with NVG being rendered). sorry if this has been already reported... couldn't find anything.

i mean there should not be multiple implementations and configurable key binds for the kneeboard system. it should be independent of the aircraft you're flying. in my opinion, they should take the gazelle implementation (as it's the most advanced i've seen until now) and make it the only one available to all aircraft.

well, ok... but why do we need specific kneeboard implementations for each module? kneeboards only have next/previous and mark/go to key binds.

another thing that is spread accross multiple places is language settings. you can have your ka-50 with an english cockpit and abris in russian without noticing... you need to set another language option in the gameplay tab of the settings screen. these probably don't need to be tied to each other, but they certainly deserve to be shown together.

yeah, as @ouPhrontis cited above, it's expected that the fenestron will be much better at keeping heading, but as you said, when more torque is added, there's got to be some reaction (which does not seem to happen - at least very noticeably - when i increased the collective to arrest my descent in that video). thanks for looking into it!! :thumbup:

there are settings that would be best dealt with if they were unified accross modules and not specific to each module. a simple example of this is the controls indicator (accessible with rctrl + enter)... each module has its own implementation, but the location on screen (corner) and maybe even the color scheme could be unified in the general game settings, as well as the key binding to show or hide it. another example is the kneeboard key bindings... each module seems to have its own bindings and some even have extended functionality... the gazelle lets you set and map shortcuts to specific pages, while most of the other modules barely offer next/previous page binds... in my view, kneeboard functionality should be unified accross all modules... it should be a one time configuration for all existing and future modules. these are the two features i can remember right now, but there are probably a few more that could benefit from such change.

well... everybody uses right pedal to leave the ground in this thing, no? :D i'm not saying i should be on the left pedal all the time when descending (while lowering collective that aggressively), but there should be some kind of reaction of the frame due to the high variation in torque being transmitted to the main rotor, right? being a much less heavy helo than the huey, you would expect it to be very snappy under those circumstances... the huey feels like an elephant, but it still gives you a bad time (body roll and some yaw) if you try that. when you say "you need less pedal", i assume it would be something other than zero at some point, but i can land this helo without any pedal... in fact, i think i can even take off without any pedal. everything is so strange... many things i've learned about helicopters in the past few months do not apply to the gazelle.

i just did that test again and you're right... pulling 70% collective requires right pedal all of a sudden... but if you want my opinion, that makes it look even more bizarre! but it still does not explain how the helicopter keeps heading without left pedal on that aggressive descent. by SAS you mean the aids for the pitch, roll and yaw channels on the bottom? those are disabled with a keybind i have on my hotas. but anyway, i just tried a minimum startup procedure to be able to fly... no trim, no gyro, no AP, nothing... it showed the same behavior... no left pedal needed when dropping the collective.

yeah, VR in this model is a blast!

I turn the dials up and get them ready before flight, in case I want to use something like auto hover or altitude hold at some point. But I disable the AP before taking off. You can see that all gauges have the bars disabled at the bottom (they are not centered).