BenBaron

As distance data is specific to every airport...it naturally needs to be provided by the developer as part of the vdgs placement workflow. But as I said...complexity is scalable, so if the developer does not have the data he/she can also choose to just use generic/same distance values for every parking position and aircraft type.

Mind you that this project is still a very moving target in its early stages. So things can change. But currently, it is targeted to be available for developers who are working together with Aerosoft. Due to the highly scalable complexity there is also a certain workflow that needs to be followed by the scenery developers. With Brussels we are really maxing out what is possible here complexity-wise: thanks to available information every aircraft type parks at the correct stopping distance which is different for almost every gate. That means even down to the specific version of the aircraft type. So a 737-300 will be parked differently than a -500 or -600.

Hi guys, so as promised last week here is a quick update and some background information about what is going on with version 2.2, development-wise. Due to its different components, targeted simulators (FSX, P3D, X-Plane, soon MSFS) and operating systems (Win, MacOS, soon Linux) the Honeycomb package is a team effort and each member of that team is simultaneously working on multiple other projects. The result of that is that the individual components are moving forward at different speeds...or at time periods just not moving at all, as the day only has 24 hours, people have vacation, get sick etc. But we are constantly evaluating available resources and taking decisions to improve the development process, in order to get things moving quicker. We e.g. have decided to discontinue development for the x86 platforms (that is everything FSX), as some of the under the hood changes in 2.2 would have required a major code rewrite in order to get them to work for those simulators. In that same light, speaking for myself, being originally at home only in the FSX/P3D/MSFS and Windows world, I also had to get myself acquainted with X-Plane development and, most recently, the MacOS environment. Like that I can now help out with that side of things as well, like...being a bit technical here...getting the plugin to compile on a M1 Mac for the x86_64 target architecture. Which happened just today. So, bottom line is, while functionality-wise 2.2 is completed and also already tested for P3D/MSFS/X-Plane on Windows, there is still some components missing for MacOS. Those should be coming in until end of the month..so we can start testing them. If all goes well, it should not be too long after that before we can build the Windows and Mac installers and send them your way. The Linux version will most likely have to be decoupled from the other ones, though. I hope to have some further info on that next month. Like I had indicated above, we are annoyed by the delay as well, but we hope the above clears it up a bit. As soon as there is something new, I will come back to you in here.

Hi, while I don't have that aircraft, at first glance, I am also not seeing something in the profile that would explain this behaviour. Maybe check, if there is something in X-Planes control menu itself, that might explain this altitude jump?

Hi Terry, in addition to what Cedric stated I just wanted to mention that the default throttle profile that we are providing with the honeycomb software download is coming with assignments for the flaps lever. So, if you use that profile and additionally have an assignment for flaps set via FSX' control menu you will always get double events sent out to the sim and thus no incremental flaps movement.

Hi, please attach your exe.xml here. For the Steam simulator version the file can be found under "C:\Users\{CurrentUser}\AppData\Roaming\Microsoft Flight Simulator". If you start the AFC_bridge.exe manually, make sure you wait until the sim has loaded into main menu. Then you should not get that error anymore.

Glad it's working for you now. With those profiles I've always tried to model the mcp LEDs as close to the real one as possible. As you see, there simply is no LED indicating HDG SEL being the active lateral mode. This only exists for HDG HOLD. So..if the LED stays indeed off with HDG HOLD being active..come back here as there still seems to be something wrong.

Another thing you can try: in your PMDG aircraft folder (e.g. "...\SimObjects\Airplanes\PMDG 737-800NGX\") create a new folder "honeycomb_profiles" and copy the "BFC_Throttle_Config.json" for that specific aircraft into this folder. Then load up the sim and don't "Reload Bindings". This is a hidden feature that allows you to auto-load a suitable local profile for the currently loaded aircraft, effectively bypassing the global one in "...Honeycomb\bin\". This does not bypass the fact though that there seems to be a deeper issue with your installation causing some weird behaviour.

Hmm...that is weird indeed. Also have never seen this one before. Please load up the Configurator and open up its Console via "CTRL+SHIFT+I". Do you see any errors there if you try to activate a different profile? What you "can" also do as a work around is open up the "Honeycomb\bin\honeycomb_profiles" folder and copy the profile you want to use (e.g. "PMDG_747QOTSII_Throttle.json") into "Honeycomb\bin\". Then, you rename it into "BFC_Throttle_Config.json", making it the one which will be used the next time the sim is loaded up, or "Reload Bindings" is selected. Like that, you are basically doing what the Configurator is doing everytime you activate a new profile.

Just to be sure we are on the same page: everytime you want to switch from one PMDG plane to another, you manually have to load AND activate that profile from the HC Configurator. If the sim is already running, you additionally have to select "Reload Bindings" for it to become active. The profiles never switch automatically based on the airplane you are currently in.

Looks like we are making progress, though. No..this is a one time thing, until of course you do a new install of one of the pmdg planes. Then you will have to activate again. So...you mean you are selecting AND activating the profile for the T7 or QoS in the HC Configurator? What is coming up as in-sim text message once you select "Reload Bindings" for the Bravo from the Add-On menu?

Yes..of course..as that is by Airbus design. But the question I was refering to was asking about a problem moving out of reverse, not moving into it. And you can stow the paddles before bringing the levers back into idle.

Hi and welcome to our forums, are you sure you read and complied with the "Please read me first.txt" contained in the download? Especially where it reads:

Hi guys, unfortunately, providing full custom support for the NGX in FSX via the PMDG SDK is not possible from our side. This is only available for the x64 simulators, that is P3Dv4 upwards. That means you are limited to whichever way the NGX likes to react to default simulator events, like John described for CRS. But there is no official way of doing things apart from experimentation.

Hi, so it seems like the connection to your PMDG aircraft is not correctly setup. For starters, in the Honeycomb Configurator, did you activate the required support before trying it out?

Glad it's solved on your end, Gérard. Because we believe this topic has been answered we have closed it. If you have any more questions feel free to open a new topic.

Thanks for your understanding, Ariel. Because we believe this topic has been answered we have closed it. If you have any more questions feel free to open a new topic.

Hi guys, sorry for the delayed response: please have a look into this thread here for a quick update as to where we are standing right now. Things should pick up steam again from next week onwards.

Hi guys, so...I know that development towards 2.2 has been slowed down considerably during summer. Sorry for that..I am the first one who is also annoyed. Especially, as there are some show stopper issues on Mac and we want to get the Linux version out, as well. I wanted to get back to the project full steam in September already, but then...health interferred, unfortunately. So, the team is now planning to meet up next week to decide on how to shift into high gear again quickly and get this out to you as fast as possible. Feature and bugfix wise version 2.2 is basically completed, there is just some adjustments that still need to happen for the Mac and Linux versions and we will have to decide on how to deploy available resources most efficiently towards that goal. I will come back to you again next week once there is a clear understanding on what still needs to be done.

Hi Ariel, please have a look here. The issue is caused by a feature incompatibilty with MacOS and will be fixed with version 2.2.

Hi Jesus, yes...I'd like to help. But I'd need more specifics of what exactly you are trying to do and especially for what aircraft.

Hi Gérard, the unequal operator is indeed "!=", so this "should" work. If it does not for you, I'd need more details. Maybe you have a profile I can take a look at? EDIT: I just double checked a profile I wrote: and there I am making use of the "!=" operator.

I just checked our profile: we are using AUTO_THROTTLE_ARM, so that should be working...but only for autothrust disconnect. As in order to activate A/THR in the Airbus (also in real life) you need to have the thrust levers in the CLB detent, I am not sure there is even a way to connect autothrust via a button.

Hi Jesus, maybe it is best to take a look at the profile we specifically created for our professional Airbusses, then. Get it from here.

Again Jesus: first and foremost we need to know which specific A320 you want to address. It is our Airbus Professional Addon for P3Dv4? As everything else depends on that answer.