Propellers no longer move - anyone got a clue?

[Nicola_M]

Propellers no longer move - anyone got a clue?

In the last 3 days, I've bought a Gizmo serial and updated the Dash 8 Q400 to v1.1, and also updated Khamsin and Arno's T-28 to v1.1.

I noticed today that ALL the other propeller planes in my xplane now have props that don't move, even when the engine is clearly running, and the plane's moving down the runway!

Oddly, the only two planes unaffected and with moving props are the Q400 and the T-28! And it's not affecting helis.

Had a look at the log file and none of it makes any sense to me.

Does anyone have a clue what's doing this?

thanks

Log.zip

[woweezowee]

(edit)

I realized the same. May have to do with arnos plane (or both, as Arno indicated below).

Because I had the issue after opening xplane with the T as first plane loading, the switched to the Q, and only the left props of the Q were turning.

Open the one you want to fly (in my case the Q), reload xplane, and all will be fine again.

[arno54]

Quite certainely a side of effect of override_prop_disc writing, which I assume the dash is using too.

I'm going with a process an hour from now on.

[MaidenFan]

Same issue with the main rotor on the BK-117. After re-starting the sim, everything worked fine...

[Nicola_M]

Mmm, I've run xplane a few times today (owing to having the rubber landing gear syndrome on the BK117, which happens if I put too many liveries in the BK117 liveries folder) and the rotors on the BK have been fine.

I only noticed the prop issue when I ran the T-28 (fine), then tried the Mudry CAP 232 for some aerobatics (still prop), then the Pilatus PC7 (still prop) and wondering what was going on I tried the default Cessna C172 (also still prop).

Knowing the T-28 was ok, I then tried the Q400 and it was fine.

The point is, xplane's been loaded about a dozen times today while sorting out rubber landing gear, yet the still prop issue surfaces after that many restarts.

[arno54]

Hey Nicolas.

actually very few planes use the volumetric propeller that xplane offers (it's more usually the flat png disc)

Unfortunately, to use it, we have to write a particular dataref, and this dr doesn't reset properly when you load a new plane... it's not the only one in this case, this is a known issue of xp. It often makes a plane carry variables from the previous ones  >

Not much we can do about it, except : load the plane you want to fly THEN restart xplane.

it doesn't come neither from dash/trojan nor any other plane, that's a xp issue...

[Nicola_M]

It's really odd. I've just run xplane again, starting with the Q400 and all was fine, props turn. Loaded up the BK117 and rotors were fine. Then went onto the CAP232 and then the default C172 and again all was fine, props turn as normal.

The only thing different from earlier was that I was running FaceTrackNoIR, so going to run that again now and see if the problem resurfaces. I'm glad it's not caused by the Q400 or T-28, because at least it shows that they are faultless.

Beginning to wonder if FaceTrack's using up a lot of CPU power and if it's cutting out the first non-essential thing it can find instead, although I kind of expected the fog to be the first thing to show up....

Thanks guys.

[MaidenFan]

Hopefully X-Plane 10 will be more add-on interference friendly...

[Nicola_M]

Well, I didn't manage to replicate it. Ran xplane again with FaceTrackNoIR and a series of aircraft and helis and all ran fine.

Arno, whether it's WinXP or xplane I don't know. I'm just relieved it's not one of the aircraft at fault.

Had me worried. Never seen so many "Fails" in a log text....

thx

[Dozer]

Hey Nicolas.

actually very few planes use the volumetric propeller that xplane offers (it's more usually the flat png disc)

Unfortunately, to use it, we have to write a particular dataref, and this dr doesn't reset properly when you load a new plane... it's not the only one in this case, this is a known issue of xp. It often makes a plane carry variables from the previous ones  >

Not much we can do about it, except : load the plane you want to fly THEN restart xplane.

it doesn't come neither from dash/trojan nor any other plane, that's a xp issue...

Arno54 can't you put something in XPLMPluginStop to reset that dataref?

[arno54]

I'm affraid no : the plane goes with Gizmo and not SDK C+. The release of the ovverides is actually done when unloading Gizmo, it's just that Xplane ignores it. The same applies for lots of dr, sliced-drag, min/max thro, etc etc...

It's to the point we make sure to load each airplane twice before any measurement, and preferably restarting xplane meanwhile.

[UH-60 Blackhawk]

I know this is a long shot, but did you check the fat plugin for BrettS' Hughes 500D?  Because I know that has a slow/stopped rotors option.  It's a longshot, but worth a check.

[Dozer]

I'm affraid no : the plane goes with Gizmo and not SDK C+. The release of the ovverides is actually done when unloading Gizmo, it's just that Xplane ignores it. The same applies for lots of dr, sliced-drag, min/max thro, etc etc...

It's to the point we make sure to load each airplane twice before any measurement, and preferably restarting xplane meanwhile.

That's really annoying! Just to be clear - if plane A overrides the prop disk and planes B and C do not, if you load A then B then C, B won't have prop disks but C will (or is more likely to)?

There's a plugin I've been meaning to write for a while now, to assign key commands to load two or more specified aircraft. This would speed up the time I spend developing other plugins, where I have to switch from one aircraft to another every time I want to replace an aircraft's plugin. Stalled while I summon the effort to learn an interface for using .ini files which, long-term, would be used to record (or store) which aircraft are to be swapped. But if swapping or repeatedly reloading several aircraft can restore the propdisk, then my unwritten test-tool plugin could be used or adapted to load a dummy aircraft on T-28 exit, and immediately afterwards the aircraft requested by the user.

[arno54]

That's really annoying! Just to be clear - if plane A overrides the prop disk and planes B and C do not, if you load A then B then C, B won't have prop disks but C will (or is more likely to)?

Exactly.

There's a plugin I've been meaning to write for a while now, to assign key commands to load two or more specified aircraft. This would speed up the time I spend developing other plugins, where I have to switch from one aircraft to another every time I want to replace an aircraft's plugin. Stalled while I summon the effort to learn an interface for using .ini files which, long-term, would be used to record (or store) which aircraft are to be swapped. But if swapping or repeatedly reloading several aircraft can restore the propdisk, then my unwritten test-tool plugin could be used or adapted to load a dummy aircraft on T-28 exit, and immediately afterwards the aircraft requested by the user.

This was my primary option. A fake aircraft only intended to load a plugin that would reset Xplane in it's ideal state. But I gave up the idea for two main reasons :

1) Much too long a work for a side-effect of a flaw of the sim we're not responsible of, specially considering restarting xplane is a matter of minutes but testing each potentially unreseted dataref is a matter of weeks

2) doing it would induce the feeling that the "good" aircarft are not so good and need some kind of side-fix not to spoil the sim.

I guess in this particular case, the cure is worse than the illness.

[Pete_SMS]

Yes, that is a really annnoying shortcoming of X-Plane. I kind of have the same problem with another dataref.

I am completely overriding the flight control surfaces, which means my plugin is handling all the stuff from reading joystick input and finally deflecting control surfaces. The override flag keeps being set when I change aircraft. That means other aircraft, without my plugin can not be controlled any longer.

The only cure I have found so far: Load the default Cessna, close XP and start it up again. Switching aircraft during runtime won't work.

...but I am still working on a solution. Not much priority at the moment, though, because as Arnaud said, it is a shortcoming of XP, I guess.

function OnAicraftUnload()

--This function needs to accept an index number telling us which aircraft changed, currently it does not.

--You know an aircraft was unloaded, but not which one.

end

..might work, if there was a way to find out the index number of our own aircraft. Then the dataref could be reset to the default value, when the aircraft gets unloaded.

[arno54]

Much more more complicated than it sounds, because event acfunload is called when you reload your own plane. So if the new plane you would load after yours uses gizmo to, the "unset-overrides function" would simply not kick-off.

For it to work, it would be necessary to have a super-global function in gizmo's core that check if the plane uses gizmo or not, and if not, lauch a special script in the previous plane (kinda "un-init.lua").

I guess this is not gonna happen.

Anyway, it's globally a good thing to get used to load the new plane, then restart xplane, then fly, because there are soooo many variables that keeps alive... And if you change your plane twice or three times in the game session, the end result of the last plane is very likely not to resemble what the author did work on!

[Pete_SMS]

Yip, totally agree. Had strange side effects as well, when changing aircraft multiple times during a session and working on my own. Loading a default aicraft and starting XP over again, always solved the problem.

[Ben Russell]

function OnBeforeReboot()
 xp.commandOnceByName("sim/operation/fix_all_systems")
end

Gizmo automatically resets all the sim/operation/override/.... datarefs you're likely to use.

[Pete_SMS]

Good to know. Thanks!

[arno54]

I'm exploring this - it could be of "some" help  ;D