Pete Dowson

Has nothing changed on your system leading to this? Because the software won't have changed -- well, except by possible corruption. The Log is odd. It finished just after this: 188 ---------------------- Joystick Device Scan ----------------------- 188 Product= Microsoft Nano Transceiver 1.1 188 Manufacturer= Microsoft 188 Vendor=045E, Product=07FD (Version 3.21) 203 ------------------------------------------------------------------- Now that point is where it tries to Acquire the identified devices so they can have buttons and axes assigned. Can you tell me what a "Microsoft Nano Transceiver 1.1" is? Is it a joystick type device? i.e. does it have buttons or axes you can use in FS? My guess is that it's a device which is not amenable to the normal DirectInput calls, and this is the cause of the problem. There was a similar report a while back, but for a different device. However, I tightended up the criteria for deciding which devices FSUIPC scanned, and released interim updates for 4.968 which proved successful, so my advice would be to download and install the newly released full version, 4.969, and try that. It is linked from the usual Schiratti site (the text there is stil out of date) and it is also available in the Download Links subforum above. Pete

You have an error then, in the data you are providing. The same source is used in the library which is supplied and linked to the UIPCHello demo. Check your code. Check the data accumulated in the mapped memory before calling SendMessageTimeout. Why are you using the original source and not the compiled LIB file? Maybe you have something ncorrectly set for your compilation. Anyway, you need to do your own debugging I'm afraid. I can't do it from here. Pete

I'm afraid the detection of the FSUIPC interface is in the province of the applications you use. To check that the interface itself is working just use one of the free programs provided -- TrafficLook or WeatherSet, for instance, in the Additional Useful programs part of the Download Links subforum. Maybe the versions of those applications you have obtained are intended for use with FSUIPC4 and FSX? Pete

Delete them when FS is NOT running I hope. As an index of profiles is read initially and maintained in memory. Maybe that's what you are seeing happen? Also, just deleting the Profile section itself does not destroy it in any case if there are any sections carrying that profile name (Buttons, Keys, Axes, Calibrations). You can edit buttons, keys, calibrations, axes, and just use the "reload" buttons in the appropriate tab to get FSUIPC to see them -- or not even that, if they are for a profile not currently in use. But you can't do this with the profiles themselves. The index is preloaded for speed in searching when you load a new aircraft, and is especially important if using "UseProfiles=Files" as then there are multiple files involved. Pete

To get them logged in the next versions you'll need these in the [General] section: Debug=Please LogExtras=x10 Or, with just Debug=Please there, you can edit the LogExtras value in the Logging tab. The sorts of lines in the log you'll get then are like these (for one being SENT by or through FSUIPC, as opposed to being received -- you won't get so many for an interception only: 432248 ExSendEvent(196881, 12345, 0) 432248 ... evnum mask=0, preval=0 432248 ... not intercepted or in options 432248 Sending "????" 196881 [0x30111], Param 12345 432279 *** Intercepted EVENT (direct): Cntrl= 196881 (0x00030111), Param= 12345 (0x00003039) <unknown> 432279 *** EVENT: Cntrl= 196881 (0x00030111), Param= 12345 (0x00003039) <unknown> 432279 FS Control Sent: Ctrl=196881, Param=12345 Pete

Ok. There are flag bits already for logging more "event" information. It'll be one of those, so you'll get other stuff too. More details next ... Pete

I'm not filtering them from being sent, only their logging on receipt. There's no change there in what you are seeing except the log entries like this: *** EVENT: Cntrl= 65732 (0x000100c4), Param= 0 (0x00000000) EXIT You'll still see the FS Control Sent: Ctrl=196881, Param=12345 and that means FSUIPC has sent it, in this case using SendMessage as I explained. Maybe that rather suspicious WM_COMMAND value you are seeing is a result rather than an instigator. You mean the "*** EVENT" entry? I'd rather not log those values (0x20000 and above) normally, as they are rather misleading when they occur as internal communications. (At least they've been misleading me ;-)). But if you wish I'll keep them optional via a LogExtras or TestOptions bit. Let me know -- I'd rather do any such changes before my next full releases, 4.969 and 5.103, hopefully tomorrow. Pete

I think 196881 (0x30111) is part of a system of internal messages. I've seen events logged by FSUIPC like 0x30110, and this is without any FSLabs or other such addons running. In the next updates to FSUIPC I am filtering those out of the logging. How have you identified it as operating a function in the FSLabs aircraft? I would be a bit worried if FSL are using controls in such a range. They could be affecting other things in the simulator. And I can confirm that FSUIPC does send them on. It cannot send them as a Simconnect Event, as it does for all named controls (SimConnect uses names which FSUIPC has to link to the numbers we use -- the same numbers as actually used in FS9 and before and internally by FSX and P3D). So it sends them, as it does with <custom> controls, using "SendMessage", with Windows message WM_COMMAND, the control number as wParam and the parameter as lParam. This is just as FSX/P3D does internally in any case. You could probably detect these with SpyXX set to log WM_COMMAND messages on the main FSX/P3D window (class "FS98main"). Pete

Sorry, Vic, but I can't make it go wrong at all. I have created these profiles: [Profile.B73x] 1=73 [Profile.Carenado] 1=Carenado [Profile.King Air] 1=King Air [Profile.Lockheed] 1=Lockheed With any of my 737's or 738's loaded (starting name iFly, Prosim, Boeing) the B73x profile is selected. With the Carenado A36 loaded the Carenado profile is the one. With the Beech King Air selected, the King Air profile is selected. With any Lockheed the Lockheed profile is loaded. If I change the option to ShortAircraftNameOk=Yes then only the Carenado and Lockhheed ones get selected, the other aircraft are then profile free, as expected. Maybe there's something wrong with your INI: possibly duplicated section names? Best post it here so I can look. Pete

It should be ShortAircraftNameOk=Yes for that option. I'm also testing it now ... Pete

With the "substring" setting it should also work for those with, say, just Electra and Baron too. That's how my 737 matches Boeing 737 and PMDG 737. Just not Boeing 738, say. With "ShortAircraftNameOk=Yes" the abbreviation is from the start, but with substring can occur anywhere in the full name. Even just an E or a C would match both Electra and Beech, though obviously it wouldn't be sensible to choose such a shoort substring. I'll double check in the morning. Pete

Please see the other threads on this same subject. That's the point of an open Forum, so that many can benefit without the same thing occurring over and over. And you always need to give the version number of the FSUIPC you are using. Are you using the latest Interim update, 5.102a, form the Dowsnload Links subforum? Always check there first, before reporting a problem. There is still one further problem with joystick scannig which is fixed by 5.102b, and there's a link to that in another thread. But 5.103 is due to be released very soon in any case. Probably Monday. [LATER] Ah, I saw Thomas managed to find that one and quote it for you before I got to it! ;-) Pete

The facility means that YOU can just supply the substring. with a name like "Lockheed Electra 10A-MCA" then it will match any aircraft with that somewhere in the name. But that's the whole substring Really? Something is wrong then. Well, I'l do some new testing here. Nothing there has changed for many years and is has worked fine here for that time. It'll be tomorrow now though. Mind you, my installations using Profiles are all for FSUIPC3 and FSUIPC4. Maybe it is something to do with the conversion to 64-bit. (I don't really use P3D4 yet. I still need some more facilities). Have you ever used the facilities in FSUIPC4 at all? I know you aren't new to simming or to FSUIPC! It would be a little less of a problem here doing investigations if you mention such things, like "this used to work in FSUIPC4, but not now in FSUIPC5" rather than just blaming it on old age. (I am 74 this year, but i have to figure these things out in my "dotage"! ;-)) Pete

Well my recent install says "v0.99" in the title bar, if you run it on its own, as well. But, yes, the version in the EXE's "Properties" say 0.95. However, that look's to be more an omission rather than a fact. I don't think 0.95 would work in P3Dv3 with the MakeYunways command line parameter. Note that it isn't my program. You need to tell the author on his website. Pete

Well, in that case there's something odd going on. Because since version 5.102 they are both the same in all things to do with joysticks. Yes, thanks. To save time exchanging more details, it might be a good idea to add more diagnostic logging before you run P3d4 again, as I need to make new releases on Monday so i could do with fast feedback if possible. To do this please add these lines to the [General] section of the FSUIPC5.INI file: Debug=Please LogExtras=x200000 and before testing, please download this file, and copy the FSUIPC5.DLL from inside the ZIP into your P3D4 Modules folder. FSUIPC5102b_TEST.zip This is the Release Candidate for version 5.103 which I intended to release on Monday, if all is well. When you supply the files listed by Thomas above, please ZIP them. The log in particular will be too big otherwise. If you definitely were using FSUIPC version 4.968 in your P3D3 installation, and if you still have that installation working, perhaps you could also do the same there, same extra logging, so I can see why there's a difference when the code, whilst not identical (one is 32-bit the other 64-bit) are logically so, do different things. Oh, and congratulations on becoming a Dad! I'm a Dad too, three sprogs, but all 50 or more this year! (I am 74). Thanks, Pete

Which version of FS? Please give version numbers both of FS and FSUIPC. If you are using FS9 or before then, no, it doesn't exist. For FSX and later only FSUIPC5 has no memory count, because it's the 64-bit version for P3D version 4, and the total VAS available is some enormous number. Otherwise, in FSUIPC4, is is not a feature in the sense that a memory checker is incorporated. FSUIPC just keeps such a value in an offset for programs to read. You can Monitor it using the Monitor feature in the Logging tab, or run program to read it and display it 9not provided), or use a Lua plug-in (for which both a local and a WideFS version of a VAS Monitor are supplied in the Lua Examples installed). Pete

I've now released MakeRunways 4.82, which can use the Lorby-SI AddonOrganizer for both P3D3 and P3D4. It will also handle scenery paths which already have the "scenery" part explicitly included -- but it does first check that there's no subforlder from than also called "scenery". If there is it will use that. Pete

In P3D3 was the version of FSUIPC4 being used up to date (4.968)? Because if it was you will get EXACTLY the same results in both FSUIPC5.102a (the current P3D4 version) and FSUIPC4. Without the information that Thomas mentioned, I'm guessing that your problem is the same as a known one. The problem of missing devices is reported and already described in two other recent threads near here, one for FSUIPC4 and the one for FSUIPC5. For FSUIPC5, in the most appropriate thread here, there is also a link posted to an update a 5.102b interim TEST version, which is working fine. It does really pay to look for similar reports in recent threads. That's why the Support of FSUIPC is done openly in public, so all can benefit. Both FSUIPC4 and FSUIPC5 fixed versions will be in full Installer releases soon, probably Monday -- look out for FSUIPC 4.969 and FSUIPC 5.103 please. Pete

Not derailing -- very relevant. But I'm not intending to add those details in any case. It's just a matter of dealing with the different structure size, which i think I've done. Since the structures were different the ID really had to be changed. Luckily they decided to keep the original data exactly the same and just add to the end. Thanks, Pete

Ah, in that case MakeRunways should cope. I'll look at that. But this is a change from FS9 and FSX days, as the folder needed to point to the palce where both Scenery and Texture folders were to be found. Also it presumably means that the folder name need not necessarily be SCENERY. What happens then, if there are other subfolders? I often save diused BGLs in a subfolder inside the scenery folder called "saved". And I have seen scenery folders inside scenery folders. Something is wrong with this design! Ah, so perhaps this design is intended to allow tetures for a scenery to be kept somewhere else, maybe even conglomerated with others from different layers? The only danger in that is where someone has decided to have a scenery folder within a scenery folder. I'm just not sure how this is all supposed to work sensibly, as per my worries above. Thanks. Now I really need is someone to test with genuine P3Dv4-targetted scenery now. Pete

A picture from the ProSim computer is a waste of time. You need to look at the "Network" entries on the main Sim PC, in Windows Explorer (probably the last entry).This will show the connect PCs, by name, AND the shared folders, also by name. So under "Network" you should see "Boeingsystem" and if you expand that the folder "ProSim737". If you don't see this, then you have not correctly shared that folder on that system. Furthermore, since the file must be written to that folder, you must have shared it for writing -- i.e. "full control". Try copying a file to it as a test. Also, of course, make sure you have Active Sky running properly on the Sim PC. That program supplies the weather radar. All this is really a subject for ProSim support or even Microsoft support. Not FSUIPC. Pete

No, but the AddOnOrganizer is supposed to provide me with the correct SCENERY.CFG by analysing the XML files. It needs to be able to correct for such installers, especially if those entries still work fine with P3D. Exactly. So AddOnOrganizer needs to deal with it. Or perhaps MakeRunways should work if a regular SCENERY.CFG path includes the Scenery part? Do you know if 3D works with such paths? I'll have to try it. Anyway, please do try MakeRwys 4.81 and let me know. Pete

Oh, I see. Sorry. Shall I delete the messages after your question, so it is the more prominent, or wil you "bump" it by re-posting? Pete

You are using AddOnOrganizer? I'll ask the author to check for that if so. MakeRunways itself doesn't look for any XML files. I've been experimenting by treating the new IDs as if they were the same as the old ones. and I've found that, although the structures are loger (extra information), the first part is exactly like the old. Only the length of each part is longer, but I am not using the extra information, whatever it is. I've tested version 4.81 here with ADE 1.75 recompiled scenery the one you sent me) and it works exactly the same now as with FSX-format sceneries. I can't guarantee it will apply to new P3D4-dedicated sceneries though. Get 4.81 using the llink below, and try it please. If there are any problems with specific BGLs, please do send me them (just the AFD BGL) so I can see what's up. (petedowson@btconnect.com). MakeRwys481_TEST.zip Pete

Very strange. It's exactly the same size as when you posted it first! ZIPs are always much much smaller with these text files. Pete