Most of the commonly reported issues and questions are answered in the Frequently Asked Questions (FAQ) option under the Support menu of this website.
*** PLEASE NOTE ***
Your forum account is not the same as the account used in the shop. They are completely separate accounts.
21st November: A new version of the GoFlight Interface Tool for FS2020 is now available.
12th November: A new version of the GoFlight Interface Tool for X-Plane is now available.
6th June: A new version of Virtual Flight Sim Hardware is now available (huge update)
21st November: A new version of the GoFlight Interface Tool for FSX/FSXSE/P3D is now available.

GIT doesn't see some datarefs FF767 V1.2.6

I'm using the latest version 2.0.14. I have just updated to the new FF767 v1.2.6 and some of the datarefs are no longer seen by GIT. Most alarmingly the 757Avionics/ap/.. heading, alt, speed and vs_act datarefs which feed the display windows of the MCPPRO. There are others too but you get the point. I can see these in Dataref Editor and they are there in GIT when I boot up the old 767 V1.1.32. So obviously something has changed with the new version of the plane but is there a way to get GIT to see these datarefs so I can get my displays working with the new plane?
Thanks in advance,
p

Comments

  • Open up the aircraft files and find one of the missing datarefs by doing a text search. When you find the dataref in a file, can you attach the file here on this thread so I can test GIT against it.

    Thx
    Steve
  • Actually Slayer Pm'd me with the solution so I am typing it in here if anyone has the same issue. I just added all the missing datarefs to the Dataref.txt file and then they show up in GIT and I can assign them to the modules.
    Thanks Slayer,
    p
  • I'm not too familiar with GIT but have noticed that it doesn't work with the latest FF767 update.

    1. How do you know the datarefs aren't seen by GIT? I've noticed that my MCP just doesn't work, but there are no errors.
    2. Can you give the list of the exact lines which need to be added to the Dataref.txt file?
    3. Is this something we should tell FF to fix in a new release?

    thanks,
    Wayne
  • Hi Wayne,

    I suspect FF have slightly altered the config files and the GIT pattern matching is not correctly picking up the Datarefs and Commands in some situations. This is why I wanted someone to send me an actual aircraft file (such as an obj file) that contained the Datarefs that are missing so I can update GIT to work with the updated FF. Failing that I guess I will have to buy the aircraft.

    Best wishes
    Steve
  • edited November 2018
    I know they aren't seen because I can see them in Dataref Editor. I clicked the "Datarefs.txt" button on the right side of the GIT front page and added the lines in the attached file. Then they all show up and it works perfectly. I did have to reassign all of these for the 767-F and then I exported 767-F specific .xml files for the new plane.
    p
  • I did some more looking at the files from the FF767, and it is very different than most other X-Plane aircraft I've seen and studied - usually you can see all the datarefs and how they are used just by looking at the OBJ files. For example, I did a grep -R for "757Avionics/ap/vs_act" across all the aircraft files and it appears in the DataRefs.txt file, and also the three .xpl binary plugin files. I did the same search across the previous 767 and the new one, and its the same across both.

    I even did a strings plugins/757767Avionics/64/lin.xpl | grep "757Avionics" | sort | uniq on both the new and old aircraft, and barely anything has changed. They have added 5 new variables, and removed "757Avionics/ap/isMachSpdTargetInUse". But apart from that, its all the same.

    So I don't have any evidence here that anything has actually been removed or changed. Does the Datarefs.txt file actually do anything? I thought that was generated by X-Plane, but GIT grabs the values directly and doesn't read this file, right?

    If there is a specific exact string you want me to look for, I can do that.

    thanks,
    Wayne
  • Thanks Wayne. It might be that they have added an extra tab or something else in front of the missing datarefs so the pattern will not match, but I agree it doesn't make much sense at the moment.
  • Hmmm, something strange is happening. I just did a test where I started up the Zibo 737 and it worked, then changed to the FF777. After importing the 777 config file, it worked. Then I switched to the FF767, and imported the config file, and now that is kind of working. Only the heading and altitude works, but at least something is happening now. The A/T and FD switch and anything else doesn't appear to work though.

    I don't think I'm testing this right. Actually, I've always had problems with GIT not working sometimes, and I don't think I'm using it correctly, or I don't understand its limitations - sometimes I just reboot and re-import and it works, sometimes not. I've read the documentation at https://www.pollypotsoftware.org.uk/support/user-guide/user-guide-git/16-installation/99-how-to-load-downloaded-aircraft-configuration-files.html about using configuration files. However, I have some followup questions:

    1. Is it possible to switch between say the Zibo 737 and SSG 747 in X-Plane, and GIT will have both config files available and switch automatically? Or is GIT only capable of storing one configuration file in memory? Does it store this across reboots?

    2. When you do the import steps, what is it doing exactly and why does it take so long? Is it reloading the MCPPRO device via USB? Does the MCPPRO store the aircraft configuration in the device? Why store everything in the device and not do all the mappings in software?

    3. The GIT UI says "MODE: Generic ... 767-200ER_xp11". Then it has green check marks on most options, but red X on GlobalDataRefs, GlobalCommands, DREPrivateDataRefs, and OBJ Commands. Does "767-200ER_xp11" imply that it detected the aircraft correctly? What does "Generic" mean? Should I always have green check marks next to everything?

    4. When I run the import wizard, and click the ... to select the file, sometimes it comes up with 777.zip and now it is 767-200ER_xp11.zip - why does it sometimes use the full acf name and others not? ... should the zip always match the aircraft name?

    thanks!
    Wayne
  • Hi Wayne.

    1) Yes, once its imported, GIT remembers and switches automatically.
    2) Import takes a long time as X-Plane has a very poor interface for building add-ons. Unlike Simconnect, GIT has to scan all the files in an aircrafts folder to try and identify datarefs and commands. It does not store anything in the hardware.
    3) Generic mode is a non aircraft sdk specific mode. Not everything should be ticked, it's just telling you what it has found to find datarefs and commands.
    4) Not sure, but the zip file can be named anything you like, but obviously only import the correct zip file for the aircraft currently loaded as all kinds of wield things could happen.

    Best wishes
    Steve
  • Thanks for the info. Some followup questions:

    1. Is there a way to view what profiles GIT currently knows about? What is the correct approach when an aircraft you know has worked before, but doesn't sometimes? (currently I've been just reloading the profile and hoping it works, sometimes it does, sometimes it doesn't)
    2. Aircraft like the FF767 seem to have everything baked into a compiled C++ binary blob, and don't support searching through the raw .acf or .obj files, so how do these work? Can't it just read a dataref like sim/aircraft/view/acf_descrip or XPLMGetNthAircraftModel to get the raw aircraft filename which will reveal which one it is?
    3. How can we tell if everything is working? It seems like sometimes the MCP just doesn't do anything, and after restarting GIT a few times, or X-Plane, or a reboot, everything works. Sometimes. But no idea how to debug what is going on.

    thanks!
    Wayne

  • 1) You can open up the xaml files and inspect them. Wipe the config from each device using the red X button, then go into Detective and click the red X button to delete all bespoke events. Then re-run the import wizard.
    2) GIT can only get datarefs by scanning text files or by mimicking DRE and hoping the developer has used the DRE facility for declaring datarefs. It does use XPLMGetNthAircraftModel to get the aircraft name. GIT does not handle text datarefs.
    3) The profiles are written by customers, I cannot guarantee they will work correctly. Be careful of installing multiple aircraft that end up having the same aircraft name - this could screw things up as the profile is used based on the aircraft name.

    Best wishes
    Steve
  • I'm way over my head here and could use some guidance. I'm probably missing something very simple which is beyond my skill range.

    As instructed by knightracing, I loaded the FF767 and from within GIT copied his datarefs into the datarefs.txt file, which was totally blank to begin with. Then, I relaunched the sim and the 767 and sought to make some assignments for the GF MCP Pro. I assumed that knightracing's datarefs would appear in the pulldown list. But none are there. Is there a step I'm missing in order to gain access to and use these datarefs?

    Thanks for your assistance.
    Robert
  • Have you downloaded and installed the FF767 profile from the Downloads section of the website?

    Best wishes
    Steve
  • Yes, that is part of my existing setup. GIT worked for me with this plane until now using that profile. Either the XP11.30 update or the recent update to the FF767 changed something that caused the GIT profile to no longer work with this plane. The MCP Pro doesn't connect to the plane at all and I thought that by pasting in these datarefs it might work again. When the VC's MCP still didn't respond to any dials or button in my MCP Pro, I then tried to see if I could assign commands but none of the datarefs were in the pulldown list, which is when I posted.
  • Some further information for you. It turns out that the GF-166 units and the EFIS work just fine. It is just the MCP Pro that doesn't light up and doesn't transmit any commands to the VC's MCP and vice versa. I know the MCP Pro is not defective because it works with my other planes in both XP11 and P3D v4.4. Thanks for the assistance.
    Robert
  • Hi Robert,

    You could try extracting the files from the zip file and on the MCP PRO tab with the aircraft loaded, wipe the config and then import the relevant xml file. Alternatively, wipe the config from all devices and in detective wipe all the bespoke events and then run the Import Wizard.

    Best wishes
    Steve
  • Hi Steve,

    Cleaning out the xml file entries and then running the Import Wizard fixed the problem. Thanks for the help.

    Robert
Sign In or Register to comment.