Pete Dowson

What is PCUIPC4? Do you mean FSUIPC4, or another program, not mine? Assuming you mean FSUIPC4, then I know that neither FSUIPC4 nor my PFC drivers work with Elite-badged hardware, even though I think they originated from PFC, at least in the early days. I don't know the Elite software, nor any plug-ins. I expect if you are a programmer you could write your own, if you can figure out the Elite protocol, but otherwise I'm afraid you are dependent on Elite themselves getting you sorted out. Sorry. Pete

Yes, you can. PM was the first cockpit software I worked with, and in fact both FSUIPC and WideFS were developed in cooperation with PM software, and its author Enrico Schiratti, so there were therefore always close connections -- hence the many special "PM" controls optionally) in the assignments list, and the hosting of my software on Enrico's site. Really, we were very inefficient in the use of the offsets for PM, at the time not realising how many other projects were going to want similar support. I have since moved from PM to Prosim737, and for my cockpit software I too have re-used PM offsets for interfacing to Prosim. The design of the interface limits the offset addresses to 16 bits, so the 64k I have availble in total is allocated very strictly to those requesting it for projects which are going to be published. But for sole user needs any areas not specifically used for those, or by FSUIPC itself, or by FS itself, are fine. All offsets initialise as 0 to start with. Pete

It'll be renamed "TripleUse2.lua" to make it obvious it is changed, and it will be iinstalled in the ZIP in the FSUIPC Documents folder by the next full release of FSUIPC, later this month. There's an interim release this week, but only the FSUIPC4.DLL itself. Thanks, Pete

Apparently I was wrong about "many happy users". Make that "a number". Maybe I got confused with the X52. If you search this forum for "X55" you'll find other references including one where further experimentation did eventually solve the problem -- mainly using JoyIDs by the look of it See these threads http://forum.simflight.com/topic/82017-saitek-x55-throttle-unable-to-set-axis/?do=findComment&comment=494485 http://forum.simflight.com/topic/82388-more-than-1-id-for-joystick-no-axis-control-on-rotary/?do=findComment&comment=496670 http://forum.simflight.com/topic/81462-fsuipc-49x-not-working-with-saitek-x55-and-p3wd25/?do=findComment&comment=491085 You'll see that in most cases there was a solution , using JoyIDs and getting the numbers sorted out properly. Have a search for similar threads yourself. There are obviously some DirectX peculiarities with the X55 which give difficulties, but they can apparently be overcome. Are you using Win10 by the way? That may make a difference too. I know there are some problems still on Win10 with some DirectX devices. I see that the X55 is now withdrawn and replaced by the X56. Very expensive too, else I'd possibly buy one just to find out why it's such a problem -- though of course the X56 may not be. I have no use for one. I wonder if they've made the X56 a bit more "standard" in its DirectInput behaviour -- or maybe it's a problem with their software. But I assume you uninstalled that? LATER This thread is about both X56 and X55. Seems they are both the same in this regard: http://forum.simflight.com/topic/81985-fsuipc-not-seeing-x56-buttonsaxis-anymore/?do=findComment&comment=494332 Pete

Well, yes, it does, but the button identity is the reference. There's no point in processing all the conditions all the time for every button button press. That would be a waste. And in any case the look up table is built each time you change aircraft according to whichever profile it belongs to. If this were true here you'd not be able to have multiple assignments to a button, which is often a very useful thing to be able to do. But it can. You just need all the assignments for that button in the Profile, or all in the Generic section, as you wish. Pete

That's all in German I think. Sorry, I can't check it. Pete

The parameters to configure the action are of secondary importance. It is a little odd starting there, when the main parameter is just the limit. I would expect folks to set whatever limit they wanted (in the Options screen), and only fiddle with the details (in the INI file) when they've got that they way they want for performance, or whatever. But never mind. No, the traffic limiter is completely independent of any of FS's own settings and Ultimate Traffic's setting too. It doesn't care how or why the traffic is being created, it only limits the total number. The parameters you say you understand simply modify how it determines which ones to be rid of. The limit is just that, the upper limit to how many aircraft it will allow. Full stop. And you cannot set the limit to a percentage. It is a number NOT a percentage. I have mine now set to 250, but I used to set it at 400. With both MT6 and UT2 without a limit I get over 600 aircraft normally. Pete

Yes, so am I! ;-) I'm giving up for now. I'm pretty sure I need L-M's help with this, and with them I imagine being so busy with the next development, I doubt I'd get anything sorted for a while. So I'm going to release 4.959e as an interim update with some unrelated changes (the main being that is is completely rebuilt with the latest compilers and libraries and with Win10 as prime target). It doesn't fix this problem though. Pete

You shouldn't need to reinstall anything after replacing RAM, surel?. Or are you suspecting the integrity of everything which has been accessed through defective memory? AND the opportunity to go back to good old Win7! ;-) BTW we built a version of FSUIPC with the latest Microsoft compiler (VS15 -- I think a new one is in Beta, but the 2015 version must be good for P3D and Win10), and with Win10 set as the target. All this was in the hope that the problem with (seemingly) Win10 only might be eradicated by a compatible FSUIPC. No such luck I'm afraid -- my very first volunteer tester got the same failure on the third try. So I don't think I can solve it. I'll need L-M to step up. Pete

Okay. Thanks Is that with no configuring, nothing set, just the LINDA lua running? I can try that here (on Win7). Pete

It isn't. It is very easy. Many many users are using Lua plug-ins all the time and don't have problems, and they are not programmers. Which part don't you understand? Have you read anything at all yet? It would be by far the quickest way. And you didn't even answer my question """"" Pete

The exact same problem? No FSUIPC4.LOG produced? Well, that's looking much more like a specific LINDA problem, or just LINDA + Win10. There have been no previous such reports, and 4.949f dates back to early 2016! I am only trying to deal with this new problem, which is more and more looking specific to P3D 3.4HF2 and Win10. Pete

Okay. I have now one report saying it made no difference, and yours saying it did something "useful". More to the point, was P3D alwats restartable without crash afterwards? No, not expected at all. It does exactly the same in both. Though some things in FSUIPC just won't work in P3D3.4 HF2. I've just been comparing the actual code between 4.958 and 4.959. There's nothing which changes normal actions. The changes are all to do with new facilities, and minor diagnostic changes (correcting or adding logging entries). And the same goes back as far as versions made in July. The only things changing affecting P3D specifically are updated links for each subsequent P3D version, and those definitely all work for the P3D versions supported by each FSUIPC release. I'm quite prepared to believe that there's a problem with the Display facilities in P3D3.4 HF2. There are other reports which look related to this, around the DXGI module (reported on the L-M forum when using an FSL addon aircraft). The other possibility is that the hacked data I'm using to drive the Display facility through P3D's "window.DLL" has been subject to a change in format in HF2. However, I'm using the facility all the time with HF2 on Win7 with no problems. I'm reaching the point where I'm going to say it's a problem between Win10 and P3D3.4 HF2. But it is very timing critical, because some folks can do several reboots without the startup crash. When I give up, and I'm fast being forced to, I would then like to be able to define a minimum setup where it (the restart crash, not necessarily the crash on exit) so I can persuade L-M to try it themselves. I would hope to be able to do this without LINDA or GSX if I can. GSX isn't so bad, but I think LINDA would be asking quite a lot -- I'm not even wanting to try anything myself with LiINDA. (Or can someone suggest a simple LINDA install without much configuring, or with a ready-made configuration, which will do the trick?). Pete

And 3.3.5 + 4.959 + Win10 is okay? Pete

Good! Well done! Pete

Another test which you could do. If you set P3dhacks=x80 into the [General] section of the INI file, it will stop two of FSUIPC's "hacks" in P3D: Displays like Lua Display and Radar Contact, and AI deletion (for traffic limiters / management (The latter was an error with this setting -- next version will separate these two). Regards Pete

Yes, I thought it might be related to the display functions used by this in P3D3.4 HF2. But there have been no changes in the ipc.display function in FSUIPC for some time, so I'm at a loss to understand how, say, 4.958 works whilst 4.959 gives a problem -- and without LINDA too, as the previous poster has also confirmed. Thomas and I have been testing Lus display quite extensively in the last day or two. I've had 4 Lua plug-ins using Lua display running at the same time, fighting to show their texts, but with no crashes and always successful exits. I'm on Win7. Thomas, with two simultaneous display users, can get a (trapped) access violation on exit under Win10, but P3D still reloads fine. However, it does possibly indicate a difference here between Win7 and Win10. I've not heard from anyone have the reload problem with either Win7 or with earlier versions of P3D. Of course, those using earlier versions of P3D might not have yet decided to update to the currently supported version of FSUIPC. But I don't believe I'm the only user still using Win7! Thanks for the feedback nonetheless. It all helps, but the situation is evidently still confused. Pete

Can you please show me a log (FSUIPC4.LOG) with a successful session with 4.958? I still don't understand why the minor differences will cause a problem. 4.958 went through many increments before becoming 4.959. Is your 4.958 just "4.958" or is there a letter at the end? There were interim releases a through to j. over a 4 week period from 12/11/2016. Do you get a crash on exit when using 4.959? I see you are another Win10 users. That's 7 on Win10, 4 unknowns with the problem. Yes, others have the issue without LINDA too. I think LINDA may contribute to a separate matter, the one of crash on exit. Pete

Very interesting and impressive -- and congratulations on mastering Lua more than I ever did (it is still an alien language to me! ;-) ). Actually the ipc.log function will send the text to the log no matter what options you use in the FSUIPC logging tab. If the Log lua separately is enabled they go to a log file named after the pluhg-in,but otherwise they merge into the normal FSUIPC4.LOG. I usually have a "debug=false" line at the top of the script, with the ipc.log lines being made dependent upon it being true. Pete

The documentation is for that. There's no demo. An unregistered install has only one function -- to support FSUIPC-using applications (oh, and, actually, a registered WideFS). Almost everything is possible, but some things are a lot more work than others. Personally I would have no idea how to send data out "over BT". I know nothing about Internet communications. There are modules you can download and install to allow Lua plug-ins to use the internet, and there are I think some examples of that. You'd certainly need to do some programming. BUT you originally said your Android was connected to your PC via Bluetooth and I said if the Bluetooth connection looks like a COM (serial) port to FSUIPC the GPSout could send to it. No. you have to get the name of that port. It may not be a "COMn" number -- I don't know about Bluetooth, but USB devices usually need some odd name construction for the port. Then comes the matter of what your device is expecting. GPSout normally only sends standard NMEA sentences. If your program on your Android device is expecting those, well and good. You only have to choose WHICH sentences it needs to get it to do what you want. there are a couple of non-NMEA formats but the output isn't user confiurable otherwise. So you need to first check what your device expects. Pete

Er, sorry. What are you "clicking"? The Lua is a plug-in for FSUIPC. You have to place it into the Modules folder and get FSUIPC to run it. There are several documented ways of doing that. Haven't you read any documentation for FSUIPC or Lua yet? This Forum is not the right way to begin if not. Three ways are: 1. Create a file "ipcReady.lua" in the Modules folder containing just the line ipc.runlua(("name of lua file") 2. Add an [Auto] section to the FSUIPC4.INI file containing just Lua name of lua file 3. Assign the Lua to a button or keypress in FSUIPC, using the Lua name of lua file control in the dropdown list. In this case only use it ONCE per session, else it will just kill the previous incarnation and start again. Pete

That makes 6 out of 10 so far ... the other 4 are as yet unknown. The majority of "crash on exit" problems earlier, with or without LINDA, were probably related to a problem with SimConnect Close, which I provided an INI parameter to avoid -- it was defaulted to avoid it in the FSUIPC releases for P3D3.0-.32 (I think), but 3.3 and certainly 3.4 seemed fine with that function being called, so it was defaulted the other way. It was the same on Win7. You could try avoiding it again, as a test. Add this to the [General] section of FSUIPC4.INI (or change it if already there). CallSimconnectEnd=No No, but neither did other reporters here who experiences the same problems. I don't have LINDA and wouldn't know what to do with it. If it is a possible cause I suspect you'd need to configure it to do something. Thanks. When I have something else to try I'll let you know. Pete

Probably, but I don't know directly because I don't have all add-on aircraft. In fact I only have the Prosim 738. I'm sure a lot has been posted about dealing with Aerosoft Airbusses. Why not check places like the User Contributions subforum? Pete

Most newer aircraft gauges don't support Mouse Macros. The gauges would have to be written using the standard C/C++ Gauge SDK. This is made clear. If there's no response then it isn't supported. Many modern aircraft add-ons use Local panel variables to operate (LVars). You might need to investigate those if you are trying to do something not directly supported by the add-on except by mouse. Pete

If the aircraft you have loaded in one of the 738 profile, then your profile specific assignments override any other non-specific assignments for the same buttons. If this wasn't so chaos could reign! If you want all 4 actions for the Profile you need to put all 4 assignments in the Profile. Pete