Pete Dowson

Going back to your esrlier post, the above statement is odd. The files to be deleted are merely weather files. The .wx files are associated with flights and aren't needed when you run a weather program, and even if not you just don't get the weather changing if the .wx file is not loaded. The wxstationlist.bin file is always regenerated if it is missing. It is also regenerated on updates frm the web, if your sim does that any more. That's often how it gets corrupted. So deleting those files could not possibly lead to "more problems", which you don't describe anyway. So something else was completely wrong in your sim. And it seems a "fresh install of fsx" didn't help. No, never go backwards. I was just saying, something has changed which has messed something up. Logs? More than one? I only se one. The one you provided is VERY different, with a VERY different problem! Somehow FSUIPC is not even starting till it's been running for over 8 hours 54 minutes!!! 32068297 Starting everything now ... 32068 seconds = 534 minutes = 8 hours 54 minutes What on Earth were you doing in the sim for nearly 9 hours. And even then you didn't close it before getting the Log! (Always useful if you close it first to show the summary data at the end). Here 12063 Ready Flags: Ready-To-Fly=N, In Menu=Y, In Dlg=Y You were presumably in the FS srarting menu? Did you leave it there for nearly 9 hours? THEN gave me a log? Looks like it: 32060032 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N32068297 Starting everything now ...... 32068657 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N Very strange thing to do. I really don't know what you expect me to do with this information. One thing does occur to me, though. Could the AES data being used have a conflict with the way the DreamTeam airports are now designed or interacting with the Addon Manager modules? I think the only way to find out what is gong on is by a process of elimination. start with NO add-ons being loaded except FSUIPC. Do that by disabling all entries in both EXE.XML and DLL.XML files (do this by changing the "False" word in the <Disabled> line to "True") , so they're not being used, then rerun the FSUIPC Installer to get just it loading. If that doesn't work it's a problem of corrupt FSX or corrupt scenery files, the latter if it is specific to particular airports, maybe those AES additional BGLs. Then enable entries in EXE.XML one by one, testing each time, then the same for DLL.XML. You can edit those XML files in any normal text editor, like Notepad. Do NOT use WordPad or any word processor. Pete

If there's no INI then it never actually gets to run, which would explain it. Something (virus checker?) is blocking it. That's very odd. It either gets traffic or it doesn't. The count always matches here (apart from the user aircraft being counted in the explorer). The "DeleteVehicles" parameter is now most certainly NOT a factor, it plays no part in this apart from deleting vehicles IF AES is running (is it?). I don't think Traffic Explorer counts vehicles in any case. Unchanged from what? The limiter won't limit if there's no reason too. A log file would be useful, please. Pete

Sounds like the ProTek Throttle has a non-standard Registry setting for its GUID. Please od two things: 1. Download this test version of FSUIPC: FSUIPC 4.966j. Save a copy of your FSUIPC4.DLL and FSUIPC4.INI from the Modules folder, and copy this later version in, overwriting the 4.966c version. 2. Edit the FSUIPC4.INI file, adding these lines to the [General] section: Debug=Please LogExtras=x200000 3. Run P3D, just get to the fully ready-to-fly stage, then close it. Save both the INI and LOG files to ZIP up with some more data: 4. Now please get me some stuff from your Registry, as follows: Export the contents of these sections of the Registry: HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties Do this by running RegEdit from the Windows start menu, going down the Explorer style layers to those and with that layer selected do File-Export give them each a name (it’ll save as a .reg file -- please do not give it a different filetype in that dialogue). Then rename them from .reg to .txt so the mail system or my anti-virus doesn’t reject them (.reg files, when run, change the registry), and send those to me at petedowson@btconnect.com. Okay? thanks. I have similar problems with a couple of Saitek X-55s, unsolved yet, but from the above data I should be able to provide work-arounds, as I did for the X-55s. I am currently trying to get hold of an X-55 set so I can sort it out properly. Pete

That's weird. It remembers the last position and size for the Window, so look in its folder for a "TrafficLook.ini" file. Open that in notepad or other text editor and see what Windows coordinates and sizes it has somehow got set. Mine are: [Window] Airborne=[687,85,697,800] Ground=[139,88,548,800] Try setting them to something to suit your screen. The numbers are top left x and y, then width and height. If in doubt 0, 0, 600, 800 are a safe bet. Don't understand why it isn't in the Applications list. It is a straight-forward Windows application, nothing complicated. Can you try FSUIPC 4.699j, changing that parameter back, please? I can't test it here, not having any FSX-MS installations any more. Keep your current FSUIPC4.DLL safe, and just copy this one into the FSX modules folder. Pete

I don't know about the code, Paul will have to help with that. Are both control and its parameter being sent as one package, one 8-byte structure? If not, the parameter needs to be first. Did you test the control and its parameter by assigning in to a keypress or button in FSUIPC first? You'd need the actual numbers. Some of the parameters are not obvious -- not necessarily 0 and 1 for a switch for instance. You might find more about that in the User Contributions threads. I can't really help on that as I don't have any PMDG aircraft. Pete

Ah, that's interesting. Thank you. I'll take a look, and fix that in the next update. There are no instructions! It really doesn't need any! Not ALL programs need instructions! You just put it in a convenient folder and run it. It provides a window which you can move and size and which displays the traffic FSUIPC is receiving and placing into its TCAS tables. Just run it an play with it. It is just a free demo. You can select Ground or Air traffic (Air has a range defaulted to 40nm but adjustable in FSUIPC options dialogue). Currently ground has a range of 6nm if you are in the air (but that will be changed), or 3nm if you are no the ground. You can run the program twice, selecting Air on one and Ground in the other. Traffic is updated once per second. You can print, move the columns around and sort them just like in any other windows tables.e.g Explorer) It isn't mysterious. Didn't you even try running it? You'll see what I mean then! Pete

Sorry, what is the problem? Who is the "lad above" you? That is not really a good reference ifyou expect me to look it up. Even if I knew what post you referred to I cannot view to and yours without abandoning your thread. Having a brief look at the log , which thankfully is not too long (not knowing what I'm looking for), I assume it must be a problem with the FSUIPC options dialogue not appearing, as shown here: That sort of thing is pretty much outside my control. The options dialogue can only be brought up in the special "dialogue mode" implemented by SimConnect for this purpose. If this method is not used, parts of the sim would carry on regardless, and there's a good chance, in full screen mode at least, of the dialogue not being visible in any case. In the past this has always been due to some other "rogue" add-on somehow stealing the SimConnect notifications needed. "BGLMAX.DLL from DreamTeam seems one of the regular culprits, especially if it isn't kept up to date. I use GSX, which needs BGLMAX, and I also have some DreamTeam European Airports, but I've never seen the problem. Ah, yes. That's the one which installs BGLMANX. Can you make sure it is fully up to date, please? Download the very latest Addon Manager and run it to update all components. Pete

That sounds like FSUIPC's traffic information is not being updated. Can you try using TrafficLook (the Additional Program in the thread in Download Links above). It reads trafficfrom FSUIPC, not from FS, and displays what it gets withing a set TCAS range. And please show me the FSUIPC log file. If needed I can provide options you can use to get more information. Traffic Toolbox includes the User aircraft in the count, whereas FSUIPC assumes that is not controlled by AI (Artificial Intelligence) but by Real Intelligence! ;-) Without more information I can't really help further. I ALWAYS need the log, for any support question or problem. However, the code is identical in this area in FSUIPC between FSX-SE and FSX-ACC, so it is a bit of a mystery. Do you have the same add-ons in both, the same settings in FSUIPC's INI file? Oh, also you started off by saying "I have recently tried using the Traffic limiter within FSUIPC in FSX", but from what you say the Traffic Limiter has nothing to do with it. It is just that SimConnect stops providing AI updates. So, any other changes recently, or have you only just taken such an interest in the traffic? Pete

Thanks for the report. I will take a look at the files, out of interest, but since you've solved it i'll consider the matter closed. Pete

Sorry, I really have no idea. Steer clear of large complex aircraft add-ons, or don't use Autosave ,is really all I can say. I assume you tried using the ; key and nter a name method of saving, just so you could see for yourself that it's the act of saving which is the problem, not getting it done automatically? Instead of using autosave, try to solve the problems which cause you to want to use it. With my complex cockpit setup there's no way I can make use of autosaved files in any case -- I can't simply start in the middle of the flight and expect all the relevant components be there with me, let alone ensuring all the hardware is the same (switch positions and dials etc in the cockpit). And I don't use any complex aircraft add-ons -- no FS cockpit panels and so on ay all. All the systems are handled by ProSim. If my system crashed I'd need to find out why and fix it. In a well setup system with all working ad-ons you should never really need autosave for crash recovery. If you are using it just so you can "try that again" in the event of something unexplained happerning, or making a mistake, then try manually saving on occasions when you think it might be worthwhile. Nothing I know of. It's a manual setting only. But that cannot be actually responsible for anything. If the system is overloaded so much that SimConnect data supplies dry up for even the default or 1 or 2 seconds (whatever it is now) then there's something wrong in any case. And certainly if SimConnect does stall you WILL get pauses whilst FSUIPC re-requests all of its data and sets everything up again. If it does happen and you can't find out whay it might be necessary to increase from the default so that the stall doesn't simply repeat over and over, clobbering things entirely. With 20 (the maximum) set then FSUIPC won't care if no data arrives for a full 20 seconds. None of the add-on aircraft you are using cares about that as they don't use SimConnect (well, the PMDG ones don't in any case). Andit won't happen more just because you increase the time -- that's just increased tolerance. Pete

Well, you don't mention which version of FSUIPC you are using. If it isn't the currently supported version (4.966c) please update. FSUIPC is totally unaware of the screen mode and is completely uninvolved with graphics altogether, especially if you aren't running any Lua plug-ins (which can use the screen, and in most respects could fall under the category "add-ons"). The only thing the presence of FSUIPC will possibly influence is what is in memory and where it is. A crash like yours indicates a corruption or other error elsewhere which sometimes affects nothing apparent and other times crashes. "BEX" is normally an attempt to execute data (or rubbish) as if it were a part of the program. Since it occurs with no other add-ons I would suspect the installation of the Sim itself, It it isn't that it might be hardware -- memory or its accessing. Try an uninstall and reinstall of the Sim first. Also make sure FSUIPC is up to date. Pete

Well, not really. They contain some of the parameters that flight dynamics programming in the sim use to determine what to do with them. The MDL file is mainly concerned with the appearance of the aircraft. And the parameters in the AIR file are, these days, often overridden or modified significantly by those in the aircraft.cfg file. You can obviously decode those files and use them for your inputs, but you need to know a lot about how to do flight modelling yourself using those parameters. It would probably be a lot easier and quicker starting from scratch. Anyway, I repeat. You are in the wrong place! Pete

Wrong forum, really. Check the list of forums on Avsim. I assume you mean to write a program with your own flight dynamics? If so it isn't a subject suitable for any forum. There are whole books written on subjects like this! You need a good understanding of aerodynamics and aircraft or helicopter design, and good basic mathematics, especially trigonometry and advanced algebra. Check on Amazon for suitable books. If you mean to take the dynamics out of a flight simulator and use them for something else, then no, that is not possible. The code is well built into the Simulator, in FS mostly in the module called "Sim1" plus a number of control files specific to each aircraft. I suppose you could disassemble Sim1.dll to see how it works (though of course that would violate Microsoft's copyright, so it would be illegal), but you'd have great difficulties even if you were an expert in Intel assembly level code. Compilers these days, in their efforts to make things more efficient on modern multiple pipelined processors, produce very obscure code. Pete

I would simply make a shortcut to MakeRwys.exe (just drag a copy to the desktop with the ALT key pressed, or right-click on it and select make shortcut), then right-click on the shortcut, select Properties, and enter the command line details there. All standard Windows stuff! ;-) I will move this thread to the main Support Forum where it belongs. Pete

All FSUIPC does is pass on the flight save request to FSX. It does nothing else. It is almost the same as pressing the ; key (with its default assignment) and entering a name, except that it does it based on the timer, and creates the name by itself. Automating those parts will not create any pauses. It is something to do with the aircraft or its systems. Pete

Well, unless you can get a similar effect by using all 10 ranges accommodated, the only way is to use a Lua plug in,. A simple one which keeps the previous value in a Global (via ipc.set) and which checks ehether the new one is higher or lower would do the job: just assign it to your axis using the normal left-hand side assignment. The Lua would receive the axis value in ipcPARAM, so it would look like this prev = ipc.get("MyTrim") if prev ~= nil and prev ~= ipcPARAM then if ipcPARAM > prev then ipc.control(70310, 16384) else ipc.control(70310,8192) end end ipc.set("MyTrim", ipcPARAM) Try that. Save it into the Modules folder as, say, "mytrim.lua". The run the sim, then in Axis assignments assign your trimmer to "Lua mytrim". Test it. Check the FSUIPC4.log afterwards in case I've made a mistake (sorry, haven't got time to test it here at present). Pete

If you have te registration details, from SimMarket not me, then those are the registration details. You use them to register whenever you want to register. If you didn't want to use them you'd have to buy them again. When registering you must enter all three parts EXACTLY as shown on the registration details - name (presumably not the strange "Zl2bmh"), email and key. No other spelling. You personally don't install it anywhere -- the Installer does the installing, which it does into FSX automatically for you. You can put the Installer itself anywhere you like. Once you have run it and registered it it is not used again unless you need to reinstall it or re-register. Be sure to use the latest, which you can download from the www.schiratti.com/dowson page, or from here, in the Download Links subforum. Pete

Yes thank you! Much easier for me! I'll shortly be providing a special test version of FSUIPC where the only real change is to log the results of a different call I'm making to get more information about the device associated with a GUID. I'm hoping this will allow me to choose the right one of the pair provided by each X-55 unit. I'll send it by email with instructions, and would be grateful for the results. Thanks, Pete

Thanks, but please, next time, just zip all the files into one file which I can download. It's a bit wearisome clicking on each in turn so they open up in my editor then saving them for full analysis. I've got a lot to do here, with all this and other stuff, so I'll get back to you. It will probably be at at least early evening tomorrow (here, Tuesday) at the earliest as I have to go out in the morning. So, Wednesday morning for you,. Pete

The GUID lines HAVE to be there! They are absolutely needed to address the device. The lines would have been generated right at the start of the good session -- please, you should have saved the log. They must have been correct for that session, and correctly written. So what could have changed by the second session? It's as if the order in the Registry changes each time! When you are wide awake (tomorrow?), please delete the GUID lines again, but before running, get the Registry export files for me (actually, now, only the CURRENT USER one is needed -- the other seems to only give the device name). Then run the Sim, and after that session, save the INI file and the LOG, and get another REG file export, as above. Run the Sim again, and, assuming it reverts yet again, then after closing it save the LOG and INI and get yet another REG export file. So there will be 7 files. Please name them desriptively, ot even 1-7. There will be: 1. REG export from before anything 2, INI file after first (good?) session. 3. Log file after first session 4. REG file after 1st session 5, INI file after second (bad?) session. 6. Log file after second session 7. REG file after second session It's still a puzzle, but perhaps we are gradually unravelling it? Pete

Right. with the new information, and the same from OldPop, I've worked out what is going on at last, hopefully. Please delete the 0.GUID= and 1.GUID= lines in your FSUIPC4.INI file's [JoyNames] section -- the two associated with the X-55 units. It seems that somehow the X-55 installation creates TWO entries for each of the two devices, and these are indistinguishable (the entries, I mean, not the devices). They have different GUIDs. It looks like the order in which they occur is not predictable. At some time the incorrect ones (the ones which don't work) were first, and it was these that FSUIPC found. But those are now second in the Registry, So if you make FSUIPC take another look without it being guided by the GUID entries in the [JoyNames] section, it should work. The case for OldPop was different. In his case the correct ones are second. I've currently got no way to determine that, but I'm looking -- I've given him a temporary work-around. I think this problem did not date back to 4.966 but way before, when FSUIPC started actually checking the GUIDs. However, I can see if could have gone wrong in any case, at any time in the past, since the GUIDs have to be used to access the devices and I can't see how Windows would choose the second if that was the correct one. I think folks just uninstalled and re-installed the X-55's until they worked. Maybe each time you do that the GUIDs swap over. Please let me know if what I suggest to do above works. Pete

Add add-ons one by one and always test between. Best to start with FSUIPC anyway, as it might be interaction with that. It takes longer to find the culprit if you add them all in one go, then have to take them out one by one. Pete

Thanks! Will get to those within the next two days. Getting late here now. Pete

Might have been better to reinstall Windows first. could be a registry problem. Pete

Well, the Lua I provided is working, but it simply returned the initial values for one of the X55 units (all zeroes) then, a few seconds later you closed the session. did you "Test complete. I cycled all axes, and pressed each button during this run." within the 44 seconds it was running? If so none are logged, they still aren't being seen. If this is the case, and you definitely did your bit, then there's nothing else I can do -- the Lua is reading the USB data directly, not via DirectInput, but RAW. Something else is wrong with those units. I notice you are trying to run another Lua plug-in which has an error: 291125 *** LUA Error: SuperScript_VRS.lua:22: attempt to concatenate global 'ACTIVE_SCRIPT' (a nil value) Sorry, what do you mean? Has FSUIPC suddenly and magically recognised and is handling your X-55 units like it does more most (not all) folks? If so what did you change? I need to know to help two or three other folks -- and to relieve me of the work I've been doing to try and find another way, spending more than full time for all of ths last week , including all day today till now! (I'm flaking out now ...) Pete