0zz

Climbing at Vmcl - minimum control speed is not a good idea. Ideal climb IAS is around 75 kts for BN-2. And dont forget the fact, while it does not have any failures, you shouldnt maintain full props during climb. Lowering rpm to green zone, and adjusting manifold pressure accordingly should give you an ideal climb angle at 75 kts.

Nevermind guys. Problem was dataref tool does not see the hidden commands. And since the earlier version of commands.txt and datarefs.txt was deleted by the 1.1 installation, newly generated lists don't have the previously visible commands and datarefs. I rolled back the installation, compiled the lists again in version 1.0 where that commands were visible in sim. Got a backup of those, and installed 1.1 again. My control profile is working again. The only question remains is that, is there any other way than dataref tool, that I can use to gather the datarefs and commands, even if they are hidden in sim?

Hey Cole. In the previous version I was using commands like bat_on, bat_off to switch battery on and off. In this version I can only see/access battery toggle command which is not ideal to use with on/off switches on panels. The switch state won't be persistent, unless I also add conditions, and match code I use will be more tricky. It is the same case with every other on/off switch. When I check the commands and datarefs via dataref tool, I don't see those previous commands there either. Question is, what am I missing here? How can I access those commands again? Is it simply a matter of adding those lines to dataref.txt and command.txt? If so I'll need a full list, as the dataref tool, which is my go to tool to sniff the custom commands and create text files, is not seeing the commands hidden in this version. I hope this makes sense

Thanks for the info Coop. I use dataref tool to sniff the custom datarefs, and create dataref.txt command.txt files which are needed for interfacing addon specific commands. However I can't see the previously visible on/off commands. Is there a way to access those?

I just had the chance to try the 1.1 update and I noticed most of the on/off commands that control switches are removed, leaving only toggle ones. It is quite frustrating to bind toggle commands to on/off switches on controllers/panels, as they are not persistent with the state of the switch. Normally I wouldn't mind if switches can also be driven by changing dataref values. But those seems like they turned into read only, or something overwrites the changes. When I try to change the value of the switch state, it resets back. Is it because I installed the beta version of Gizmo plugin? Or they were intentionally coded that way in the latest update? What was the reason for such simplification and restriction? I always add a match button positions code to my control profiles, so after aircraft is loaded, the switch positions are altered to match the state of the buttons on my controllers. But with only using toggle commands, and restricted access to datarefs, that is a quite frustrating task to do. Is it possible to add those on/off commands back along with toggle commands? Or at the very least allow us to manipulate the datarefs? That way simmers who use momentary buttons or keyboard can still use toggles if they like. While home cockpit or panel users with on/off switches such as myself, can be able to bind their controllers properly.

Im good thanks Cole. What I meant was, there is no defined simulation event, like 'turn knob clockwise' but it can be controlled by changing the variable. It is possible to do it with lua scripting, defining a command that exactly does that. But interface I use is quite flexible anyways, I can use simulation events, change dataref variables, or simply send keystrokes. No need to run an extra script.

Cheers scot! Nice one!

There is no command (simulation event) for manipulating that knob. But you can control it by changing the value of the dataref below; afm/islander/f/knobs/cockpitLight Set it between 0 (min) and 1 (max) values

After you saved the datarefs.txt and commands.txt, you need to restart the Xplane, and load a flight with bn-2 in order to activate the custom datarefs and commands. Check spad.next window for connection status. After that you'll be able to see the custom ones in the list as well. Keep in mind, custom ones will only be visible when sim is running and aircraft is loaded. Some of the bn-2 switches are controlled by generic switch datarefs. Those may be elusive to find, as dataref editor does not show those command groups separately. In such a case try using data monitor of spad next. You can load as much datarefs as possible and monitor those in realtime. I can compile a quick device profile for you if you like. Just let me know which functions you want the switch panel buttons assigned.

All Saitek/Logitech panels work perfectly using Spad Next replacement drivers. It handles all the integration outside the sim, so you wont be effected by any sim related binding issues, conflicts etc.. Initial configuration and sniffing datarefs can be a bit overwhelming first time you are using it. But the flexibility well worths it. It has 14 day trial version. Feel free to reach out if you want to give it a go. I can guide you in more detail with the configuration.

Thanks! Looking forward for it!

Hey Coop, any news on the release date? When should we expect the update?

Yes, @4535jacks those commands turn off shadows created with shadow_maps. Both internal and external. Directional lighting still works, and looks decent enough as a temporary solution till the issue is fixed.

Interesting. I thought REP B58 was quite realistic, as it does not auto-slew HSI. How did Simcoders missed that? Roger. Will change the bind script to add Autopilot VVI Sync before servo activation. Thanks for the tip. Systems simulation in BN-2 need more work, more depth in general IMO. Hope AP rework will be one of the early updates. EDIT: Just saw the script. I use Spad Next to handle bindings. I think I can easily create a scripted event using the simulation events you listed there. Thanks

Thanks @Graeme_77 That makes much more sense now. If you have access to Carenado B58, check the KFC on that mod. I think the logic on that one is more accurate.It is a good reference for a realistic rendition. I noticed, the erratic behaviour when AP is activated during the climb is due to the command I am using. 2x 'servos_up_one_level'. First time it activates AP, and second time it toggles VS. But since the AP button auto-activates VS in BN-2, second command cause the auto-enabled VS mode to deactivate. Then AP auto-switches to ALT mode, that causes the pitch up attitude to zero out.

Nice @clecorouge ! Just to nitpick, I think the head should be darker orange, same tone as the leg.

Exactly thanks tADEUS73. After some more testing, I finally noticed the tiny INOP sticker on FD button. Man, I am blind! I think the behaviour I was missing was FD mode, as it is not coded (yet?) AP module tries to make up for it by force switching to HDG or VS mode instead. That cause, abrupt behaviours like I explained. It steers out of course during GPS to Localiser transition if heading bug is not set as same as course bug. Or it just zero out vertical speed when AP is activated during climb. I am not sure if there is a plan to implement FD mode on AP. If not, at least the code has to be amended for a smoother transition. Simply, when AP button is activated, it should hold the attitude until vertical and lateral modes selected. VS shouldn't be automatically reset to zero. Or heading should automatically be matched to course when GNS auto-switches CDI.

But this is an ILS approach. The earlier GPS navigated part shouldn't have an effect on the final approach. I might as well being vectored to final with HDG hold. It felt like VNAV is properly executed with localiser guidance, but LNAV is not. Hmm. There is something not right with how AP behave. I mean I didn't used bendix/king in real life but quite a lot of addons use the same device. For example, the one on Carenado B58 keeps vertical and lateral attitude when AP button is activated. In BN-2 it directly goes to VS mode with 0 setting, resulting a sharp pitch down during climb. Im not sure if this is how it behaves in real life or not, but it is disturbing. Weird. Maybe someone with a real life experience on BN-2's can pinpoint the issue.

Not while in GPS mode. I generally hit approach button after GNS switches to VLOC, before the GS capture marker.

Tried my first ILS approach today. ILS03 App to WAAA. Course and NAV radio set correctly Up until transition I was in GPS mode. It automatically switched to LNAV got the ident of the localizer on screen and all fine. But AP switched to heading mode and steered off course. Tried it several times. I mean if you are exactly on course and set the heading bug to runway direction, with magnetic deviation, it flys as if it is doing approach. However, this is not LNAV at all. I don't think KFC225 should act like that. Anyone else experiencing same thing?

Nice one Cole! That was driving me crazy

No problem Glad it worked It can happen with any addon, and I discovered it in a secondary FSE leg similar to your situation. Some addons like TBM900 and KA350 has dedicated switches that turn electric trim on and off, which are part of their checklists. Even if you turn it off with AP disengage, you'll activate it back on following the checklist before next leg. Keep in mind though, if you bind it to a non momentary switch on a controller, it will seem as if it is on which was the problem in my case. Some aircraft like BN-2, dont have that switch and it is suppose to be on as soon as you power up the aircraft or avionics. Disconnecting the AP shouldn't turn it off. I guess, it can be coded that way. But simply using a disengage command without trim_off works.

It seems like electric trim dataref is turned off. AP can't control the trim. That happens if you disconnect AP by "servos_yawd_trim_off_any", or "servos_fdir_yawd_trim_off" commands. It is restored when you restart the sim, so you might not noticed it before. I am assuming this time you started next leg without restarting the sim, thus your electric trims stayed off when you activated the autopilot. Check your keyboard or controller bindings and change it to "servos_fdir_yawd_off". When you disconnect AP this way in the future electric trim wont shut down. To fix it for your recent flight, there is no electric trim activating command that you can bind unfortunately. But, if you have dataref editor installed you can set the "electric_trim_on" value to 1 Or you as an alternative, if you have FlyWithLua installed you can type the line below in a new text file and save it inside Xplane11/Resources/plugins/FlyWithLua/Scripts with .lua extension. set("sim/cockpit2/autopilot/electric_trim_on", 1) And click Reload all Lua script files command under plugins, flywithlua from xplane drop down menu. That should set it right. Hope this helps

Probably one of your plugins are incompatible and interrupting the system simulation. Try disabling and enabling them one by one to check which one. A few others experienced same thing by using an older version of a landing rate plugin. That is one of the usual suspects. Try disabling that one first. If that is the case, download the newer compatible version of that. If disabling plugins don't solve the issue for you, post your log.txt so devs can check.

Easy way to test it is to see if there is any performance change between day and night. Use Shift+K or L to cycle day night. If there is a considerable difference in FPS, then shadows are active. Alternatively, you can check the dataref values if you have DataRefEditor plugin installed. One thing though, if you are gonna turn off cascading shadows (use_csm) crank up the visual effects to at least High (HDR), and check that the scenery shadows are off as well.