xplane crashes when quitting

mmerelles

I just installed my GIT for xplane. Amazing by the way, my mcp pro is back to work

Just wanted to report xplane crashes at two scenarios:

1. xplane always crashes if you quit xplane and GIT is still running

2. xplane crashes randomly when opening xplane weather menu to the the current weather representation on the map

thanks

admin_pps

Hi,

OK, I'll add your problem to the bug list and look into it.

Best wishes

Steve

mmerelles

I do have another xlpane crash scenario.

I had to create a simple bespoke for an aircraft that flipping the MCP's A/T ARTM switch to ON writes an 1 and flipping it down to OFF writes a 0 to a custom aircraft dataref.

Using the switch once or twice works, but if you flip it 3 or 4 times it crashes xplane as well. I also tested it giving it a few seconds in between the flips but it crashes anyway.

I have tested writing the custom dataref repeatedly & fast 1 0 1 0 1 0 1 0 around 15/20 times in a row via Datarefeditor plugin and xplane never crashes.

Any cue on this? do you require i do any test or capture to help diagnose tis?

admin_pps

This is odd because no one else is reporting crashes except for the known issues with the IXEG and that's not a problem with GIT but the aircraft itself.

You should really have the Dataref Editor plugin removed to get the best out of GIT.

What aircraft are you using?

Update - I have just done a test on the 777 with the AT ARM and Bespoke Events and it worked fine. Can you try another aircraft, maybe a built in one so we can determine if there is something corrupt in your XPlane installation or its aircraft specific?

Best wishes

Steve

admin_pps

As for the other two bugs, I cannot recreate what you are experiencing either. I have opened the weather menu 20 times straight and no crash. Can you load up a basic built in plane and see if the issue appears. If they do, there is something wrong with your X-Plane installation or something is clashing with GIT for some reason.

Best wishes

Steve

mmerelles

ops my issue is with the IXEG as well, did not tested any other aircraft yet but i will later today.

Just wondering, if the problem is the IXEG bird, writing the variable via datarefeditor as many times as you want doesn't crash the aircraft as well. Weird

admin_pps

No problem. See this thread for more info on the issue http://www.pollypotsoftware.org.uk/vanillaforums/discussion/349/a-few-questions-on-git-for-xp#latest

But you do make an interesting point that the Dataref Editor is not crashing with it. I do have exception checking around all code that manipulates DataRefs in the GIT Plugin so if my plugin is causing a crash it would handle it and not bring down X-Plane. I will double check though, because I'm intrigued that the DataRef editor is handling the crash in the Gizmo code of the IXEG.

Best wishes

Steve

mmerelles

yes i did test dozen of times writing the ixeg dataref via datarefeditor sending 1 0 1 0 1 0 much faster even than flipping the swtich calmed and it never ever crashes, and flipping the switch on the mcp giving it 3 or 4 seconds in between always crashes xplane. Sometimes it crashes on the first try, sometimes it crashes on the 2nd or 3rd try.

admin_pps

I think I have found how the Gizmo exceptions are crashing GIT. Replace the GIT Plugin with the attached. Upzip it and place into your X-Plane Directory\Resources\plugins and overwrite what is already there.

Let me know if it works Ok please.

mmerelles

I am at the office now, i will be at home in 3hs, Testing and report back.

thanks for your prompt support!!

admin_pps

Actually try this version as I've added even more exception checking code.

Thx

Steve

mmerelles

ok great!

mmerelles

tested, still crashes

admin_pps

Can you double check you pasted it in correctly i.e. its not been pasted in as a subdirectory of GIT Plugin as the old code would still be used. If in doubt re-download GIT for X-Plane from your account as it has the new plugin code now. Uninstall the old version, make sure GIT Plugin is completely gone from within X-Plane and then install the new version of GIT XPlane.

Thx

Steve

mmerelles

i did replace all "GIT PLUGIN" folder existing on the xplane/resources/plugins as per the new one you provide me.

My structure is xplane/resources/plugins/git plugin/32 & 64 bit subfolders. The files within 32&64 are dated both today 11:14hs

admin_pps

OK. I'll review the plugin code again tomorrow and see if there is anything left that isn't trapping exceptions.

Best wishes

Steve

mmerelles

thanks a lot! 

Slayer

Steve I just wanted to offer some input on this too. I think we are dealing with 2 or 3 potential crash sources here. 

1)  Crash caused from sending a dataref via GIT, where sending the same dataref via dataref editor does not cause a crash.

2) Manuel saId something in a message that gave me pause, about sending an int, where a float was expected making gizmo complain. To be fair IXEG doesn't list the expected input like it does with the FF T7. So some of the crashing could be caused by me sending an int when a float is expected?? I don't know

2) Crash when we send certain datarefs from any source causes Gizmo exception( Nothing you can do about this one obviously)

admin_pps

Hi Steve,

Number 1 is the issue that troubles me.

Number 2 is handled by the GIT plugin by querying the datatype of the DataRef and sending the value as the correct type using the correct plugin set command. The same happens for retrieval. Internally everything is a double until a DataRef has to be read or changed via the plugin system, its then converted to the correct type before being sent or converted to a double for GIT after being read as the correct type. Of course if the DataRefs return the wrong type and Gizo expects something else, this will cause an exception and that is out of my control.

Number 3) Agreed.

It's why DRE doesn't crash that has me puzzled and why I'm investigating the plugin code further.

Thanks for your input.

Best wishes

Steve

admin_pps

Attached is an updated GIT Plugin to try. Every line of code in the plugin is encased in a try/catch block so any exceptions caused by the plugin or anything that bubbles up to the plugin will be handled and no crash will occur.

However if the IXEG Gizmo code triggers an exception and the aircraft is not handling it then a crash will occur and I can do nothing about it.

I have also double checked the reading and writing routines for DataRefs and confirmed the correct data types and SDK methods are being called.

I have a theory as to why the DataRef Editor is not causing the issue. Sandy wrote the plugin SDK for X-Plane as well as the DataRef Editor which means he had access to the internals of X-Plane. I suspect that for performance reasons the DataRef Editor is not calling the plugin SDK methods for DataRef reading and writing but actually reading and writing to memory directly via a shared memory area and thus not triggering the Gizmo exception. It's just a theory, but I do have an old email address of Sandy's so I think I will reach out to him and see if he is willing to confirm it.

I can't do anymore to solve this, its in IXEG's hands now.

Best wishes

Steve

mmerelles

Hi Steve

thanks for the update, i have tested it and it still crashes the same. We have opened a thread on the ixeg forum already lets see what they come up with.

i have created another profile for the FJS737-200 and it works fantastic. I have to polish it a bit for sharing it to the community.

One last question/advice request please:

Altitude rotary moves +/- 10 ft per clic as per the default xplane command, which makes doing altitude adjustments almost unusable. Going from 3000 ft initial configured altitude lets say to FL250 takes A LOT of clics/turning (+2000 clics actually) you  end up using the mouse to pull the knob on the aircraft.

Is there anyway to create a custom command via bespoke or whatever than when rotating fast or continuos for x amount it multiples per 100 or 1000?

Both course & hdg selector have the same issue, they go 1 by 1 but being 360 degree -is a bit slow- but manageable. 

admin_pps

You can add the "Rotate" Event Action and on GoFlight hardware that supports acceleration such as the MCP PRO, it speeds up the increments when you turn it fast.

Remember to add it to both directions.

Best wishes

Steve

mmerelles

thanks will check for that!!

mmerelles

I had them enabled. I also clocked it going from 3000 ft to 25000 ft takes 4.7 minutes. Insane, your fingers hurt.

what does exactly the SET+ feature? i tried writing a bespoke of the altitude dataref +100, but it only works for the first clic

admin_pps

That should work, but you have a found a bug. I've fixed it and a new version is available to download from your account.

In your Bespoke Event, you could check the logic for the button state of the AP rotary to determine what mode its in and the amount to increase by (1000 or 100)

Best wishes

Steve

mmerelles

woa fantastic, downloading and testing now

mmerelles

I did quick altitude +/-100 bespoke test and works brilliant SO HAPPY

How to i check the ROTATE ROTARY state to make it 100 or 1000? what variable tells me the rotary state?

I can do 100 / 1000 for the altitude and 1 / 10 for the heading. Amazing stuff

admin_pps

It was an idea to try, I don't know off the top of my head. Does Detective not show it?

If not, you could always set a Bespoke Variable to toggle via a Bespoke Event (e.g. if its 0, set to 1 and if its 1, set it to 0) and assign it to the push button on the Altitude Rotary.

Your altitude increase/Decrease Bespoke Events could check the value of the Bespoke Variable and if its 1 increase/decrease by 1000 and if its 0, increase/decrease by 100.

Best wishes

Steve

mmerelles

Steve

I can not see what the rotary status is, could be my fault, so i am trying to toggle a bespoke variable via alt push.

Bespoke syntaxis:

!

ALT_MULTIPLIER

if bespoke Var 0 = 1 Next Else Next Skip

Bespoke Var 0 = 0

Bespoke Var 0 = 1

!

My understanding is: if value is 1 execute next line to set 0 otherwise skip and execute second line and set 1. Is this correct? it always set 0 no matter what.

On standard programming i know, the sintaxis would be:

IF var=1

   set 0

else

   set 1

end

but i am bit confuses if a bug or not understanding how this IF sintax works

admin_pps

You need some Labels and a Goto's

ALT_MULTIPLIER

if bespoke Var 0 = 1 Next Else Next Skip

Goto SetToZero

Bespoke Var 0 = 1

Goto End

:SetToZero

Bespoke Var 0 = 0

:End

Best wishes

Steve

mmerelles

ohh i see! thanks a lot again