Markus Posted February 26, 2011 Report Posted February 26, 2011 Hi there, I can only guess what happened. Today I installed some airports and tried some overclocking, afterwards I reverted my clocks back to my standard settings. Later I started a flight and noticed my flight controls were not responding, every light on my controller was off. Back in Windows I pulled the usb cable of my logitech g940 and put it back in, it immediately came back to life. So I thought problem solved started FSX and began another flight, but the key I used to start the engines with on a beechcraft would not work, so I went into the FSX controller dialog to see the "use controller" option checked. That got me puzzled as I did uncheck that option because I gave fsuipc full control over my g940 flight system about two weeks ago. Now I had no control over nothing within FSX, I rebooted my machine with no change. Powered the computer and started it from cold, still no change. Then I went into the modules folder to take a look into the fsuipc config file, and was quite shocked to see that it had been completely replaced by default settings. Ok, I am a grown up man, but that really gave me a shock, I think I spent over two days creating the profiles for my Embraer 195, PMDG 747 and Wilco Airbus, it was just so much work. I am so sad and pissed right now. Honestly I never ever thought about backing up my fsuipc config file. How could that happen ? :( Markus
JSkorna Posted February 27, 2011 Report Posted February 27, 2011 Hi, When you unplugged and re-plugged in your USB hardware, Windows reassigned them new IDs. Look in the FSUIPC.ini file for your settings.
Pete Dowson Posted February 27, 2011 Report Posted February 27, 2011 I pulled the usb cable of my logitech g940 and put it back in, it immediately came back to life. So I thought problem solved started FSX and began another flight, but the key I used to start the engines with on a beechcraft would not work, so I went into the FSX controller dialog to see the "use controller" option checked. That got me puzzled as I did uncheck that option because I gave fsuipc full control over my g940 flight system about two weeks ago. When you unplug and re-plug in a controller, FS assumes it is a new connection and does its automatic assignments. Then I went into the modules folder to take a look into the fsuipc config file, and was quite shocked to see that it had been completely replaced by default settings. That can only ever happen if you actually delete the file. FSUIPC never does this on its own. It will only create a default INI file if it cannot find one already there. How could that happen ? Somehow you deleted the FSUIPC4.INI file, or else your hard disk is playing up. Regards Pete
Markus Posted February 27, 2011 Author Report Posted February 27, 2011 When you unplug and re-plug in a controller, FS assumes it is a new connection and does its automatic assignments. That can only ever happen if you actually delete the file. FSUIPC never does this on its own. It will only create a default INI file if it cannot find one already there. Somehow you deleted the FSUIPC4.INI file, or else your hard disk is playing up (it's an SSD btw). Regards Pete Hi Pete, I did not delete the config file nor did I mess with the modules folder. As you can see here. I ran checkdisk, and no errors were found (the log is german sorry) [Window Title] Datenträger FSX (F:) wird überprüft [Main Instruction] Das Gerät bzw. der Datenträger wurde erfolgreich überprüft. [Content] Auf dem Datenträger bzw. Gerät wurden keine Probleme festgestellt. Der Datenträger bzw. das Gerät kann jetzt verwendet werden. Wenn Sie den Datenträger bzw. das Gerät entfernt haben, bevor alle Dateien darauf geschrieben wurden, fehlen möglicherweise Teile von einigen Dateien. Gehen Sie in diesem Fall zur Quelle zurück, und kopieren Sie die entsprechenden Dateien erneut auf den Datenträger bzw. das Gerät. [^] Details ausblenden [schließen] [Expanded Information] Die Volumebezeichnung lautet FSX. CHKDSK überprüft Dateien (Phase 1 von 3)... 205312 Datensätze verarbeitet. Dateiüberprüfung beendet. 2 große Datensätze verarbeitet. 0 ungültige Datensätze verarbeitet. 0 E/A-Datensätze verarbeitet. 4 Analysedatensätze verarbeitet. CHKDSK überprüft Indizes (Phase 2 von 3)... 213598 Indexeinträge verarbeitet. Indexüberprüfung beendet. CHKDSK überprüft Sicherheitsbeschreibungen (Phase 3 von 3)... 205312 SDs/SIDs verarbeitet. Überprüfung der Sicherheitsbeschreibungen beendet. 4143 Datendateien verarbeitet. Das Dateisystem wurde überprüft. Es wurden keine Probleme festgestellt. 117218303 KB Speicherplatz auf dem Datenträger insgesamt 43713740 KB in 200951 Dateien 63060 KB in 4145 Indizes 274871 KB vom System benutzt 65536 KB von der Protokolldatei belegt 73166632 KB auf dem Datenträger verfügbar 4096 Bytes in jeder Zuordnungseinheit 29304575 Zuordnungseinheiten auf dem Datenträger insgesamt 18291658 Zuordnungseinheiten auf dem Datenträger verfügbar Thank you for your responses so far, Markus
Pete Dowson Posted February 27, 2011 Report Posted February 27, 2011 I did not delete the config file nor did I mess with the modules folder. As you can see here. I ran checkdisk, and no errors were found (the log is german sorry) None of that shows anything useful. As I said, FSUIPC would only be able to reset things to default when it didn't manage to read assumed existing ones. Maybe you had some sort of crash in the middle of an FS session whilst the file was being used. I don't know how it happened, but nevertheless it happened. Files can get corrupted by crashes, power failures and so on, as well as by hardware faults. FSUIPC's INI and MCRO are examples of "configuration settings" files, just like FS's CFG files (FS9.CFG, AIRCRAFT.CFG, PANEL.CFG, SOUND.CFG etc etc), and are maintained through an interface in Windows called "Private Profiles". FSUIPC itself does not perform direct input / output on the files, it relies on Windows. Each line "xxxx=..." and section [xxxx...] are addressed by parameters in calls to functions in the PrivateProfile API in Windows, and it is those which find them and read them or write them, in the appropriate places. I'm sorry such a thing happened to you, and I wish I could help, but like most things you use on a computer it is wise to keep backups. Never trust a single copy on a single computer with any data which takes work to reconstruct. Regards Pete
JSkorna Posted February 27, 2011 Report Posted February 27, 2011 Your FSUIPC.ini file is that top file on that left side picture, the file with the little blue gear on it. You can open it using Notebook and your settings will be in there.
Markus Posted February 28, 2011 Author Report Posted February 28, 2011 None of that shows anything useful. As I said, FSUIPC would only be able to reset things to default when it didn't manage to read assumed existing ones. Maybe you had some sort of crash in the middle of an FS session whilst the file was being used. I don't know how it happened, but nevertheless it happened. Files can get corrupted by crashes, power failures and so on, as well as by hardware faults. FSUIPC's INI and MCRO are examples of "configuration settings" files, just like FS's CFG files (FS9.CFG, AIRCRAFT.CFG, PANEL.CFG, SOUND.CFG etc etc), and are maintained through an interface in Windows called "Private Profiles". FSUIPC itself does not perform direct input / output on the files, it relies on Windows. Each line "xxxx=..." and section [xxxx...] are addressed by parameters in calls to functions in the PrivateProfile API in Windows, and it is those which find them and read them or write them, in the appropriate places. I'm sorry such a thing happened to you, and I wish I could help, but like most things you use on a computer it is wise to keep backups. Never trust a single copy on a single computer with any data which takes work to reconstruct. Regards Pete I know Pete I justed wanted to show that I didn't actually delete it myself. Fact is FSX crashed several times during my overclocking test runs, maybe it got corrupted there. I'm keeping backups now just in case it might happen again. I did not want to make it look like your program had a flaw, I just wanted to know what circumstances might have caused such a thing to happen. I love fsuipc! ;) I got another question related to my Logitech G940 flight controls, it seems this device has a little problem with an axis slider on the thrust lever. I got the spoilers on this axis and whenever I move the throttle the spoiler axis value changes for probably a millisecond and immediately reverts back. With a lot of planes this is no problem, but with the embraer 195 I get a "Spoiler LVL disagree" takeoff warning, this is of course not fsuipc related, but fsuipc might be the cure. I tried increasing the delta, but is there another way to just disregard the erratic change in the output sent to the controls? Regards Markus Your FSUIPC.ini file is that top file on that left side picture, the file with the little blue gear on it. You can open it using Notebook and your settings will be in there. I know, but it had reverted back to the default values :( I got it configured again and I am keeping backups now ;)
Pete Dowson Posted February 28, 2011 Report Posted February 28, 2011 I know Pete I justed wanted to show that I didn't actually delete it myself. But how can you show that? The folder listing would list the new one created by FSUIPC if you'd deleted it then run FS. I got another question related to my Logitech G940 flight controls, it seems this device has a little problem with an axis slider on the thrust lever. I got the spoilers on this axis and whenever I move the throttle the spoiler axis value changes for probably a millisecond and immediately reverts back. With a lot of planes this is no problem, but with the embraer 195 I get a "Spoiler LVL disagree" takeoff warning, this is of course not fsuipc related, but fsuipc might be the cure. I tried increasing the delta, but is there another way to just disregard the erratic change in the output sent to the controls? Odd that the throttle affects the spoiler. What sort of bad value does it generate on the spoiler? Maybe you can simply calibrate those values as part of the dead "spoilers down" zone. If you are not sure what values it produces, just Log axis events in the FSUIPC logging tab and check the log after it happens. Regards Pete
Markus Posted March 1, 2011 Author Report Posted March 1, 2011 But how can you show that? The folder listing would list the new one created by FSUIPC if you'd deleted it then run FS. Odd that the throttle affects the spoiler. What sort of bad value does it generate on the spoiler? Maybe you can simply calibrate those values as part of the dead "spoilers down" zone. If you are not sure what values it produces, just Log axis events in the FSUIPC logging tab and check the log after it happens. Regards Pete on the right side of the picture I provided is my recycle bin (german "Papierkorb") , there's no fsuipc config file in it. Yeah I know it's odd, doesn't really affect the flight though because it just changes for an instance and immediately reverts back. The problem is the eicas on the embraer seems to notice the slightest change and will report the issue with an annoying "bing" followed by an aural warning "no takeoff". I think the normal closed spoiler value is -16384, the erratic value transmitted around maybe -8000. that would make a pretty big deadzone
Pete Dowson Posted March 1, 2011 Report Posted March 1, 2011 on the right side of the picture I provided is my recycle bin (german "Papierkorb") , there's no fsuipc config file in it. Oh, I see. (But I usually press Shift+Delete, which bypasses the recycle bin! ;-) ). I think the normal closed spoiler value is -16384, the erratic value transmitted around maybe -8000.that would make a pretty big deadzone Not necessarily. Is that value from the Log file? Try it anyway -- see how far up the axis movement that really is . And don't forget that the first 20-30% of the lever is normally speedbrakes off and Armed zones in any case. The actual speedbrake deployment is about 27% to 67% (flight detente), 100% only as landing spoilers. One other way you could do it at present is by directing the Spoiler axis to a Lua plug-in script which checked for sudden short changes and discarded them, forwarding the others on via the spoiler control. For transient button presses I did add a facility for the [buttons] section called "EliminateTransients" which discarded button presses of less than one poll width (about 25 mSecs by default). I'm not sure it's a good idea for axes though -- I'd first like to see the log showing the problem on your system first, to see how to tackle such a facility. Finally, the "filter" option in the FSUIPC calibration might remove it too. Have you tried that? Regards Pete
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now