Pete Dowson

If you've used a method to fool installers into thinking you are using FSX then it is possible that FSUIPC also thinks it is FSX, and that will certainly cause crashes. Without any information about your crash I can't really advise further. I would need to see the FSUIPC4.LOG and FSUIPC4 Instal.LOG files from the Modules folder, and the Crash details from the Windows even log, which will identify the module at fault -- it may not even be FSUIPC but a problem elsewhere which is influenced by the presence of FSUIPC. After all, there are many users of P3DV2 who do not experince such crashes -- myself for one. You can paste the log texts into a reply here. I don't have a site. All of my software is hosted here, on SimFlight, and accessible in the Download Links subforum above. You probably mean the Schiratti site, which is Mr. Schiratti's, not mine. His links point to software here which I can update but I cannot change his text. I wrote to him to ask him to update that when 4.928 was released, but he sometimes takes a week or two to do it. Pete

I don't know, it is not something I've ever done. It will probably be possible via camera settings and you can use controls then to select those. I know SuperTrafficBoard, with suitable camera settings (maybe FSX defaults), can select AI views for you, so I presume it can be done either via controls or via the AI_traffic interface. It's an area I've never really ventured into -- it might be worth asking in one of the other forums, maybe one on AVSIM? Pete

Sorry, then. I can't support SimConnect. All I can say is that FSUIPC uses "enum" with int32 and it works fine. Have you tried SimConnect logging to see what that shows? Pete

I don't know that code (it isn't C or ASM, the languages I understand) -- but from the output shown it looks like the "type" string for that aircraft is Nor738 and for some reason the terminating zero is being ignored in the code being used. Tell him to use FSUIPC's Monitor to log it, or to use FSInterogate. The data after the terminating zero is not relevant to the field's purpose. What is the actual problem in any case? Pete

Normally the error message you are getting occurs when there's been a crash beforehand, in a previous attempt, and pressing yes simply works, allowing things to run. It is very unusual for it not to -- in fact I've not met such a case featuring that specific message. Is there an FSUIPC4 log file produced by FSUIPC? If not, it has not been loaded yet, and the problem could be a SimConnect conflict with other add-ins. If a log is produced, show it to me please. A SimConnect log might help too -- instructions for that are provided in the FAQ subforum. Also please check the Windows error logs to see whether an error in FSX.EXE has been logged. If so please show the details. Finally, if it is an interaction in SimConnect between two add-ins, it is just possible that using the FSUIPC4 loader might help. Please see the FSUIPC4 installation guide in the original zip. Pete

Nothing can clear allocated memory without crashing the process concerned. Identifying allocated memory which is no longer needed is impossible -- only the programmer knows what he's finished with. Defragmenting process memory which is so far unallocated is not only diffcult, it takes the same sort of time that System Mechanic would take. Thus freezes or stutters. Pete

There's obviously no way to free allocated memory without causing FSX to crash when it comes to access it. And there's no way to detect memory which should have been freed up but isn't (that would only occur with buggy software, aka "memory leak").. If you mean simply consolidating fragmented free memory into larger portions, I really don't think that always helps -- free memory is free memory even when apparently fragmented. Certainly, if it makes the largest contiguous block very small (less than a page) it will cause OOMs, but the problem with memory defragmentation is that it has to be done with exclusive memory access and can take many seconds. Are you going to allow FS to pause to do this? You can't really spread it out imperceptibly. If you tried you'd simply introduce continuous stutters. There are programs which try to sort this out. Here's an extract from IOLO's "System Mechanic" publicity: See the bit about a "short" pause --- around 20 seconds? Try that program if you like. See if it helps. I have serious doubts. I have only ever suffered from one occurrence of an OOM, and that was a memory leak bug in a driver I was writing for my own cockpit, easily fixed Regards Pete

Looks to me as if the fuel selector controls are being sent automatically in any case, at regular intervals. Presumably their code is doing that each time it scans its switch settings. Annoying. I wish folks would only send controls when they actually need to change something. It's just another overhead. Not good programming then. Unlees there's a local panel variable (L:Var) you can use to operate the visible switch I'm afraid you'll have to put up with it, or change to a better aircraft. Regards Pete

I've corrected the original, which is the one in the Lua package downloadable from the Download Links subforum and also which will be installed into your FSUIPC Documents folder. If there are pasted copies in threads I'm not going to find them all in any case -- I would expect folks to use the ones installed. Thanks, Pete

If FSUIPC logs the name of the control, then you can assign using that name in the drop down list! "Custom controls" are for unnamed controls added by aaircraft such as the PMDG 737NGX. You don't need to use "custom control" for 65962 -- see the FSX Offsets list in stalled in your FSUIPC Documents folder. You will see 65962 is "Fuel selector set". I very much doubt that any aircraft would use "Fuel Selector Set" for "Avionics master". And if operating that switch sends 4 controls in sequence, then presumably you'd need to do the same thing -- which would need a macro or at least a sequence of assignments edited in the INI file. More likely that the add-on code ses the Avioics switch change and reads the fuel selector switches and sends them to FS at that time. Mouse macros only work with add-on code gauges using the C/C++ gauge SDK issued by Microsoft. Unfortunately very few do these days, and even Microsoft didn't. Most new add-on gauges use XML encoding, so Local panel variables (L:Vars) are more likely to be useful. FSUIPC can log those as well -- a list using the buil-in FS control or dynamically showing changes using a supplied Lua plug-in. Did you first not check whether the add-on is supplied with keyboard shortcuts for these things? It's nothing to do with whether it is GoFlight or any other joystick button or even keyboard you want to program. it's whether the add-on programmer has bothered to think about those who like to use hardware with their product. The laziest thing to do is simply write gauges without making any such provisions whatsoever. Have you tried their support forum? Regards Pete

Please STOP using the interim test version and remove that extra logging. I posted a fixed full update on Saturday morning -- 4.928 is the supported version now! you are out of date! I am amazed that so many folks have not heard of ZIP files -- even Windows explorer has the facility to zip files built in now. I did actually ask you to ZIP logs for email -- they are text files and would be quite small if Zipped! Anyway, the log shows nothing wrong with FSUIPC. Your hangs are due to something else. Sorry. Please, no. Update your FSUIPC please. Pete

Sorry, what Lua are we talking about here? Do you mean the one supplied as an example in the Lua package installed with FSUIPC? Or do I have to search back in this rather long (and very old) thread you've resurrected and appended to? And how are you testing to see that the last two (one rotary) doesn't work? If its my exmple rotary code than please note that there is an error in line 69: ipc.togglebitsUB(offset, thisbutton) should be ipc.togglebitsUD(offset, thisbutton) UB = Unsigned Byte (8 bits = 2 rotaries) UD = Unsigned Dword (32 bits = 8 rotaries) Odd this hasn't been discovered before! Pete

Assuming you are using the same FSUIPC settings you did on FSX, then FSUIPC is doing exactly the same thing. There is no difference in this area at all between FSX and P3D. I'm afraid your only recourse is to P3D support over in their Forum. Maybe these issues are already on their list for fixing in the forthcoming patch? BTW you may also want to try FSUIPC 4.928 which was released yesterday. Pete

The Schiratti site is controlled by Mr. Schiratti. The link there does currently point to 4.928 but the text won't be updated until Mr. Schiratti gets around to it after he sees my request. That's why I also maintain the Updated Modules subforum here. I can update the files his links point to, but not the text. The "supported versions" thread gets updated a day or two after new Installable versions are posted. Some overlap of support is reasonable. Pete

"FSUIPC4.dll_unloaded" is not actually my module. I don't know what that means. But P3Dv2 has been plagued with a number of problems of crashing after closedown. They tried to fix them and this one might be fixed in the forthcoming update, but I think you should report this on their Forum in any case. BTW please update -- 4.928 is the current version of FSUIPC4. Regards Pete

4.90 is well out of date and not supported. You need to update. The current version is 4.928. It is fine. But you need to consider whether one might interfere with the other. If you assign only in FSUIPC, not in FS, then you can use Profiles to define which one is to be used for each aircraft. This is really the main point of aircraft-specific or Profile-specific assignment. If both sets are assigned and active for an aircraft this can work provided that the controls are well calibrated with stabile centre areas (so no jitter at all), and are not touched whilst the other is in use. Nevertheless it is far better to have one set assigned per Profile -- the other set will then be ignored whilst not assigned for the current aircraft. Note also that if you have multiple controls it is very advisable to use Joystick Letters for identification. Then if they are ever moved (plugged into different sockets), or you reinstall Windows, they will still be recognised correctly and be assigned correctly. Best to do that now before such an event is forced upon you. There's a chapter in the user guide about this. Precisely the rerason for the joystick lettering facilities -- you need to use them. You should try to keep it up to date. Once you pay for version 4 you have all updates for version 4. The installer does not destroy your settings either, so there is no danger. Pete

Sorry, I don't understand the question. There's no "locking". If you assign a button in FS and in FSUIPC the two assignments will conflict. If you change the assignment in either it wll change. It is quite simple. Pete

This is a question about ASN. They implement the weather in ASN rather differently than in previous versions. whether that then affects the METAR readouts provided by SimConnect I've really no idea. You need to ask HiFi Simulations. Correct, though the current version is 4.928 and with that, since ASN takes over the weather hooks FSUIPC would otherwise use, the settings in FSUIPC have no relevance. Regards Pete

FSUIPC 4.928 is now available. Pete

In with the Installation program ZIP file there was a short document explaining exactly what and where things were placed, including the manuals and example files, and also explaining how to register. Did you not see this? It is specifically placed in the ZIP so that you can find it easily and see these explanations. Pete

Why use the Range section? That's for setting dfferent controls for different places on the axis range. You are using a hat. It doesn't have a "range". Simply assign in the assignments section on the left. All that's not just there for decoration. Please please please do refer to the FSUIPC user guide for assistance. It sounds like you've never looked at it. There are pictures! Pete

Found it! It's related to an option you have set (which is new in recent versions, AFTER 4.92) to stop FSUIPC's facility for associating numeric keypresses with their preceding controls when using add-on aircraft which otherwise interfere with this by continually sending controls to FS. It seems that you have set: TimeForSelect=0 in the INI file. If you remove this I think you'll find the aircraft exits work with 3367. I'll work out some way of effecting the original objective of this option without destroying FSUIPC's ability to send to related controls of its own volition. Look out for 4.928 some time tomorrow, probably. Thanks for your help in this. It's such an obscure relationship between options that I might never have found it without your help! Sorry for all the hassle involved though. Pete

STOP PRESS! The SimConnect logs were most useful. There's one important difference -- the one using 4.92 has yjis line for FSUIPC: > 10.10816 [136, 2342]SetNotificationGroupPriority:GroupID=3, uPriority=10000000 but this is missing in the log for 4.927f. This is interesting because Group 3 includes the TOGGLE AIRCRAFT EXIT event/control (and others). Checking now how this action can be skipped. I am suspecting some timing issues here -- you have a great many SimConnect clients operating simultaneousy. I'm wondering if some calls are timing out. I may need to add further loggingg in FSUIPC to find out. Pete

BTW I notice you are using the FSUIPC4 loader. Why? It isn't a good idea, it was just provided on a "use in extreme case of difficulty" basis. Best not to if you don't really need to. Just delete the Loader from the Modules folder and re-run the Installer to fix the DLL.XML file. Pete

That error is nothing whatsoever to do with FSUIPC -- it is one of the well known G3D crashes which occur in FSX with some sceneries and textures. Take a look through the FSX CTD forum on AVSIM. It is a TEXT file. A zipped version would have been small. Why do you think I asked for it to be Zipped and emailed? I even gave my email address! Anyway, it shows nothing useful. You didn't encounter anything which would have resulted in the original FSUIPC crash. Regards Pete