Lost pan views in virtual cockpit

[Jean-Claude]

After tweaking a number of new activities, thanks to FSUIPC 3.22, I must have made a mistake somewhere since I lost my horizontal pan views in my virtual cockpit and I am unable to restore them.

I have programmed (with FSUIPC) my "hat switch" with two switches for up and down pan views and they work fine as they did before. I have done the same selections for left and right pan views but they do not work: all I get is a "shaking" move to the correct side but no other effect, as if something was preventing the view to pan further than a couple of millimeters to that side. Since the values selected are the same for "up", "down", "left" or "right", where did I miss something?

Could anyone assit? With anticipated thanks.

Best regards,

[Pete Dowson]

I have programmed (with FSUIPC) my "hat switch" with two switches for up and down pan views and they work fine as they did before. I have done the same selections for left and right pan views but they do not work: all I get is a "shaking" move to the correct side but no other effect, as if something was preventing the view to pan further than a couple of millimeters to that side. Since the values selected are the same for "up", "down", "left" or "right", where did I miss something?

Why not program these in FS assignments -- or even let them default. I think Fs assigns pan views to hats in any case, doesn't it??

Are you programming them in FSUIPC using Keypresses or FS Controls?

Did you make sure your buttons (hat switch values) are not also programmed in FS anyway -- it sounds as if your have more than one action going on with the left/right? FSUIPC cannot stop FS reading button presses just because they are detected in FSUIPC as well. It is different for key presses as FSUIPC can actually intercept those.

Let me know exactly how you programed them please.

Regards,

Pete

[Jean-Claude]

Thanks for your prompt reply (on a Sunday!) Pete...

I have programmed my hat switches only in FSUIPC, I did delete them in FS9. I used the FS control of FSUIPC and ticked the "repeat command when pressed".

I tried to reset all default in FS9 to no avail, it would not give those settings back to me, hence my predicament having to find a way to programme them in either FSUIPC or FS9!

What puzzle me is that the vertical axis was no problem to programme, but I can't fix the horizontal one, so simple and yet so tricky it seems.

Many thanks for your kind help.

Regards,

[Pete Dowson]

I have programmed my hat switches only in FSUIPC, I did delete them in FS9. I used the FS control of FSUIPC and ticked the "repeat command when pressed".

There is a potential problem with the 'repeat' action in FSUIPC 3.22 -- it can run away. But this would be the opposite of the symptom you are mentioning. However, just in case this is the problem I am emailing you an interim test version of FSUIPC to try.

Otherwise please tell me exactly what you've tried to program and I'll see if I can reproduce it. The panning versus view-change operations in FS2004 are rather confusing in any case, and are different between normal and virtual cockpit views.

If you want FS to pick up and re-configure itself for your joystick connections you may need to delete the FS9.CFG so it effectively starts again. The "reset defaults" option in Options-Controls-Assignments doesn't seem necessarily to re-establish joystick parts which it has stopped dealing with.

Regards,

Pete

[Jean-Claude]

Hello Pete,

It looks like I now have a mess in my hands...

I tried about everything you suggested and I could think of to no avail:

- I used FS9 assignments instead of FSUIPC, no change

- I cleaned up FSUIPC and reprogrammed, no change

- No luck with rebooting with no FS9.cfg, the new one would not change the problem

- No joy either with copying my old FS9.cfg file which I kept in archive just in case

- Version 3.229 test did not help, I still have the same "hat switch" setup as follows:

1/ Upper button left for pan up (works fine in 2D cockpit, virtual cockpit and exterior view)

2/ Upper button right for pan down (works fine in 2D cockpit, virtual cockpit and exterior view)

3/ Lower button left for pan left (works fine in 2D cockpit and exterior view, DOES NOT WORK IN VIRTUAL COCKPIT)

4/ Lower button right for pan right (works fine in 2D cocpit and exterior view, DOES NOT WORK IN VIRTUAL COCKPIT)

The effect I get when pressing pan right or left (in virtual cockpit ONLY) is a slight move on the correct side but immediately rejected and sent back to forward view and repeated as long as I keep pressing. It cannot be a hardware problem since the same two buttons work normally for 2D and exterior views.

In FSUIPC, I use the following selections: FS9, Pan left, Pan right and tick on repeat when held. I also tried to allocate keyboard commands for the same in FS9 assignments, no change!

FSUIPC version 3.229 (test) also did not perform well (for me that is) with the GoFlight hardware, I could not use any of my GF modules (rotary buttons or press buttons) with this version whereas I could with version 3.224 at least use the press buttons and some of my rotary. It looks like there is a fast repeat command freezing my keyboard. And I keep losing my FS9.cfg file as I did with version 3.22...

Sorry to get back with more challenges, I am really lost here!

Best regards,

Jean-Claude

[Pete Dowson]

>> 3/ Lower button left for pan left (works fine in 2D cockpit and exterior view, DOES NOT WORK IN VIRTUAL COCKPIT)

4/ Lower button right for pan right (works fine in 2D cocpit and exterior view, DOES NOT WORK IN VIRTUAL COCKPIT) <<

Hmm. I suppose they are supposed to work in VC mode? I don't normally use any aircraft with a VC. I'd need to load one of the defaults to try.

I don't know what is going on -- it sounds like you have something really messed up in FS, as you say. It's certainly not related to FSUIPC by the sound of it.

FSUIPC version 3.229 (test) also did not perform well (for me that is) with the GoFlight hardware, I could not use any of my GF modules (rotary buttons or press buttons) with this version

Erthat is very odd, as this is the precise version that several other GoFlight users have confirmed works most responsively and consistently! There have been problems in some of the development versions beteen 3.22 and 3.229, and the one I sent you resolves all of them for my other testers, and performs excellently here too!

It looks like there is a fast repeat command freezing my keyboard.

No, that problem is most definitely removed. There is no possibility of it occurring with 3.229, as the code responsible is binned. Sorry, I cannot imagine what is going on there.

And I keep losing my FS9.cfg file as I did with version 3.22.

Losing your FS9.cfg file?!?! What on Earth does that mean? FSUIPC has absolutely nothing to do with the FS9.CFG file. It cannot get "lost" in any case -- if one doesn't exist when you load FS, it gets generated again.

Are you sure you are looking in the correct place to check/edit/delete the FS9 file? It isn't in the FS folder you know! Assuming you are using WinXP it is in your Documents and Settings\\Application Data\Microsoft\FS9 folder.

Sorry to get back with more challenges, I am really lost here

Sorry, your panning in VC mode is completely beyond me. I don't even use VC mode (never have) so I'm not sure what to expect. But if you cannot get FS to obey its own controls in any case it sounds as if something is corrupted. If it is simply that you have a messed up FS9.CFG file, which you may have, then try locating it and dealing with it.

However, you have me very worried about the GoFlight button recognition, as that has been subject to much improvement between FSUIPC version 3.22 and the 3.229 I sent you. I am currently delighted with the much more sensitive response I now get (a quick touch on a button is now detected whereas previously I had to press and hold a short time). Other testers have also found 3.229 an improvement!

Can you tell me more about your system please? I'm rather curious to know why your experience is so different from everyone else's.

You can also try again adding the PollInterval=66 line into the main [buttons] section of FSUIPC.INI. This effectively reverts the response time for all buttons to 3.22 levels.

Regards,

Pete

[Jean-Claude]

Thanks Pete, I spent the past three hours trying to resolve this problem, again without meeting with any degree of success.

My system is a Dell 8300 Pentium 4 3.2 Ghz with 2Gb of RAM and ATI Radeon 9800 Pro 128 DDR. I have 12 GF modules including the MCP, which are plugged on three USB cards.

Incidentally, I do know where the FS9 cfg file is and how to amend it. Given the number of incidents I met this past week when attempting to "improve" my FS experience, I made a permanent FS9.cfg backup file with a shortcut on my desktop, this allows me for speedy recoveries...

My view problem did not change a bit, I am still stuck with no pan views in my virtual cockpit (which did work perfectly until I stupidly wanted to refine it with views of my own on FSUIPC!)

To make another attempt to solve my problem, I downloaded Active Camera on trial basis and used it, to realise that it too would not want to pan left or right (up and down is fine as a reminder).

Getting back to GF programming with FSUIPC, I simply gave up as I was everytime freezing my system after programming the GF MCP, and since I could not use anything anymore, I had to exit FS9, messing my cfg again and again in the process (FSUIPC does not do that, but the key commands seems to be causing that phenomenon). I am prepared to forget about this facility and, for once, be part of the unlucky guys who can't make it work.

I am much more ennoyed with that virtual cockpit business and don't have a clue as to where to look now, and it does not appear to be a FSUIPC either.

There are times where this hobby becomes too obsessive, this is one of them!

Thanks for your help anyway.

Best regards,

Jean-Claude

[Pete Dowson]

My system is a Dell 8300 Pentium 4 3.2 Ghz with 2Gb of RAM and ATI Radeon 9800 Pro 128 DDR.

Running WinXP?

Incidentally, I do know where the FS9 cfg file is and how to amend it. Given the number of incidents I met this past week when attempting to "improve" my FS experience, I made a permanent FS9.cfg backup file with a shortcut on my desktop, this allows me for speedy recoveries.

Right. In that case I cannot understand what you mean by "losing FS9.cfg". I can't see how that can happen. Whilst developing software for FS I am often crashing FS or leaving it in odd states, but never once have I had to resort to a backup of FS9 or delete it and lt it make a new one. It really sounds as if something rather odd is going on with your system. Have you considered re-installing FS9 from scratch? It might be well worth it.

My view problem did not change a bit, I am still stuck with no pan views in my virtual cockpit (which did work perfectly until I stupidly wanted to refine it with views of my own on FSUIPC!)

Whatever you do with FSUIPC is easily reversible just by deleting the FSUIPC.INI file, or in this case, at least its [buttons] sections. It doesn't hide anything anywhere else, nor affect anything else, only its own behaviour.

I'd not used this before, but I just went into my test installation version of FS9 (one which gets really mucked about with all my tests, crashes and all), connected a little Saitek gamepad which has a "hat", told FS to revert to default assignments, and the hat controls now views in 2D mode and pans in VC mode, in all 4 directions. Checking the Assignments, the setting there is simply "View (pan) == Hat Switch". There are no separate assignments for each direction. Possibly that where yours is going wrong?

The entry in FS9.CFG that this makes is:

POV_MOVE_EVENT_00=PAN_VIEW

POV_MOVE_REPEAT_00=1

Getting back to GF programming with FSUIPC, I simply gave up as I was everytime freezing my system after programming the GF MCP, and since I could not use anything anymore, I had to exit FS9, messing my cfg again and again in the process (FSUIPC does not do that, but the key commands seems to be causing that phenomenon).

I really cannot understand how anything, even FS crashing in midstream, can mess up the FS9.CFG file! What actually happens to it? I am finding your experiences most perplexing and quite outside anything I've ever heard of. And please, what do you mean "the key commands .." causing a problem?

I am extremely worried about your experiences with FSUIPC and GF buttons. It is quite the opposite of all the other reports I have, and although it is a very much minority finding, it is enough to prevent any further FSUIPC general release until it is resolved. I am therefore utterly dependent upon you for trying to understand what is happening, why it is only on your system, so that I can resolve it between now and the next release.

I understand it may be frustrating, but if you are prepared to try some tests please let me know. To start with, the reults of again including the "PollInterval=66" line in the FSUIPC.INI file's [buttons] section would be useful, please.

Regards,

Pete

[Pete Dowson]

I am still stuck with no pan views in my virtual cockpit (which did work perfectly until I stupidly wanted to refine it with views of my own on FSUIPC!)

Just as an extra test, I went into FS's Options-Controls-Assignments and deleted the assignment to the Hat there, then went into FSUIPC's Keys page and assigned the hat switch values to the 4 main Pan directions.

I only used the main 4 directions, though this hat returns 8 codes, 4 for the quarter views each side too. The 4 main directions turned out to provide "button numbers" 32, 34, 36 and 38. The Pan controls were Pan Left, Pan Right, Pan Up and Pan Down (but not necessarily in the same order) The [buttons] entries for this are:

10=R1,34,C65672,0

11=R1,38,C65671,0

12=R1,32,C65734,0

13=R1,36,C65735,0

(for example). As you see, I engaged Repeat as well.

These worked exactly the same as the FS control on the "Hat Switch". So, to see if I could get them interfering I left the FSUIPC ones programmed and went back and reassigned them in FS as well. result -- still okay. maybe a bit faster (understandably), but not noticeably so.

Finally, I left both sets allocated -- i.e. FS assignments and FSUIPC assignments, but went into FSUIPC and reversed left/right and up/down.

Now I still get it working, but slow and jerky -- the FS assignment is obviously "winning". But the one certainly doesn't cancel out the other and give that little "twitch" effect you are getting. Mind you, differences in computer speed and therefore repeat rates could change that I suppose.

My conclusion from all this is that, assuming you've not got "view reset" or similar programmed somehow to the same buttons, then either something in FS itself has become corrupted, or you have some other add-in module or gauge which is interfering with this.

Sorry I'm not able to solve it.

Regards,

Pete

[Jean-Claude]

Thanks Pete for all your assistance, I understand your point regarding testing further. Eventually I will do that tomorrow and see if I can bring you better news for your latest version, I really had enough today and need to cool down as my experiences today and yesterday and the day before yesterday were quite frustrating, leaving my weekend with no flight and only FS tweaking.

I thought about reinstalling FS9, but this is a heck of a job with all the add-ons, updates, patches, sceneries, hardware I have, probably a two-day job if I get it right the first time.

Being a real world pilot does nothing to help as these problems have nothing to do with flying... and that's probably what I find most aggravating!

Tomorrow will be another day. Tell me if there is anything you would like me to do for your tests. By the way I am running Windows XP Home edition.

Best regards,

Jean-Claude

[Pete Dowson]

Thanks Pete for all your assistance, I understand your point regarding testing further. Eventually I will do that tomorrow ...

There's no big rush, though obviously I'm a bit worried.

I thought about reinstalling FS9, but this is a heck of a job with all the add-ons, updates, patches, sceneries, hardware I have, probably a two-day job if I get it right the first time.

What I normally do, and would recommend if you have enough disk space, is rename your current FS folder then install a completely virgin copy again, using the same original install folder name. Check it all out, make sure it does the things you think it should, then rename its folder "FS9orig" or something and then change your older, full, molested copy back to its original name.

This gives you a reference copy with which to compare things and also copy things back when in doubt. you can also use the otherwise "virgin" copy as a test bed for individual add-ons to make sure you've not got some interaction between them.

Tell me if there is anything you would like me to do for your tests.

First check is that PollInterval parameter. If that makes the GF buttons work okay again I have some logging which may tell me what is going on, but one step at a time. If there's no difference with the PollInterval addition I'll need to think further.

Regards,

Pete

[Jean-Claude]

Hello Pete,

I reinstalled FS9 as you suggested with PMDG 737 NG only to test it.

First good news, my virtual cockpit is back! Thank you.

Second good news, my PMDG/FSUIPC/GoFlight orchestra plays in tune... Even if further rehearsals may be in order.

No more crashes, just a few keyboard freeze from time to time immediately after programming FSUIPC (I can't have access to the menu bar for example when pressing Alt. After a while, back to normal.

My GF MCP and RP48 work fine and were totally programmed using the key commands of PMDG with fast and slow modes for the rotary buttons.

GF MCP: CRS, HDG, SPD, V/S rotary buttons work very well and are reliable. Some difficulties though with ALT, for small variations in descent, it would not take it (I checked FSUIPC, commands were OK on slow variation).

The push buttons were a bit more impredictable, the CMD button would not work regardless, the APP was not reliable, but SPD, CRS, NAV, ALT were OK at all times.

RP48: I programmed FD, A/T, TOGA, Kneeboard, FS Nav, all were 100% reliable. However LVLCHG, VNAV, LNAV were not reliable at all and needed to be "refreshed" in FSUIPC, although the commands were there and correct, immediately after closing FSUIPC, they reworked.

Rotary buttons were programmed as Baro pressure, ND mode, ND range, Autobrake and performed well in general with a few miss from time to time. They tend to need two increments for one unit of variation.

I used PollInterval=66 in FSUIPC.INI and tested with and without but did not notice any drastic changes if any. I left this setting.

Let me know if there is anything else you would like me to do.

With kind regards,

Jean-Claude

[Pete Dowson]

No more crashes, just a few keyboard freeze from time to time immediately after programming FSUIPC (I can't have access to the menu bar for example when pressing Alt. After a while, back to normal.

I really cannot understand anything preventing keyboard use, whether on exit from a dialogue or not. Such things are usually just indicative of something being busy, probably with disk access, yet you seem to imply that FS is running okay but just not reponding to your keyboard.

Are you sure this is not simply a delay caused by FSUIPC writing back the FSUIPC.INI file, which it will certainly do on exit from the options? This should take no time at all, but if your disk is getting full or, especially, if it is getting fragmented, it may become noticeable. If this is the case you would probably notice some delays in quite a few operations, not just those involving FSUIPC options.

GF MCP: CRS, HDG, SPD, V/S rotary buttons work very well and are reliable. Some difficulties though with ALT, for small variations in descent, it would not take it (I checked FSUIPC, commands were OK on slow variation).

I assume these are all merely keypresses forwarded to the PMDG panel? FSUIPC has no idea what the keys mean, it will simply be sending them on, so for differences like this you really need to ask the PMDG folks. You could also, of course, compare results using the same keypresses on the actual keyboard.

The push buttons were a bit more impredictable, the CMD button would not work regardless, the APP was not reliable, but SPD, CRS, NAV, ALT were OK at all times.

Again, if these are programmed as keypresses, there are no possible differences to FSUIPC. All these inconsistencies must be something to do with the way PMDG does things. To eliminate possible problems with the GF side of things you could swap over, say, the CMD and APP with the SPD and CRS, or whatever. If it is the GF buttons then the same actual buttons should still give problems. If the problem goes with the function then it is either the PMDG panel giving the unreliability, or maybe the key-press combination selected is also invoking something else. In the latter case try assigning different combinations.

To be honest I have never found any panel driven by keycodes to ever work reliably and predictably. Wilco's 767PIC was the same -- I tried programming the original version of that for my PFC gear, and had to do it all with keypresses. It was dreadful. Version 1.3 came out with a programmable interface for many of the controls, and this was a 1000% improvement.

I had hoped that PMDG would provide a programmable interface I could use, but as far as I know they intend instead to sell an SDK for equipment developers, so I wouldn't be able to provide support in FSUIPC. Possibly GoFlight will buy this and provide some drivers for your kit which will work -- it would be worth writing to both of them about this so they recognise that there is a need, a demand.

RP48: I programmed FD, A/T, TOGA, Kneeboard, FS Nav, all were 100% reliable. However LVLCHG, VNAV, LNAV were not reliable at all and needed to be "refreshed" in FSUIPC, although the commands were there and correct, immediately after closing FSUIPC, they reworked.

Erif they were defined correctly then re-defining them exactly the same cannot make any difference. Identical data replaces identical data. It's all the same. FSUIPC doesn't implement forgetfulness :wink: . The data is either correct and works or it isn't. I respectfully suggest that the only explanation has to be that some of the settings were incorrect. Maybe you didn't notice these errors, but really there is no other possible explanation.

Rotary buttons were programmed as Baro pressure, ND mode, ND range, Autobrake and performed well in general with a few miss from time to time. They tend to need two increments for one unit of variation.

All rotaries are implemented to look like on/off switches. Each click either turns the switch on or off. To get an action on every click you have to program the same function both on "press" and on "release". (I'll add a note to the FSUIPC document about this).

I used PollInterval=66 in FSUIPC.INI and tested with and without but did not notice any drastic changes if any. I left this setting.

If it is working okay it is better to leave that parameter out, please. This should give the best results. If it doesn't, I'll need to know, please. I have to get the defaults set to the best and most reliable settings.

What concerns me now is that we don't know what was wrong with your installation as it was. Could it just possibly have been something related to the PMDG panel? It is a very very complex piece of work, and I'm thinking that somehow it got into a strange state, which has been fixed by your fresh installation. Did you do any elimination to check this earlier at all, such as by trying things with default aircraft rather than such a complex one? Have you loast the original installation onw?

Anyway, thank you for the detailed report. Without determining whether your problems are/were due to the complex PMDG panel or not, it is really not possible for me to determine to do anything. At least you seem to have proven that, in themselves, the changes I have made up to 3.299 are not harmful, as I was frightened of by your earlier reports.

Regards,

Pete