Pete Dowson

Either rename it as a txt file, or simply right click and select Open With ..., or actually drag it directly into an editor. I have my default text editor (UltraEdit) set csv files as one of the types it loads by double clicking, and I would have to Open With excel if I wanted to see it there. If you want the Lua plug-in to save it as a .txt file just edit the Lua file accordingly, replacing "csv" by "txt". Lua files are text files as well (unless they are compiled -- but none of those provided as examples are). Pete

I'm starting to think it is a problem with Win10 compatibility, but whether it is P3D or FSUIPC I cannot determine and won't be able to, as it can still occur even if I stop all P3D-specific things from being active in FSUIPC. Also it is suspicious that it only started with 3.4HF2. Maybe users of earlier versions get it too, but no reports so far! I use it on two Win7 systems with no problems. So far, where I've been told or can deduce it from logs supplied, all folks with this problem are on Win10. I'm still waiting to hear from 5 folks who haven't said and haven't provided logs. I even posted a separate thread asking the Question, but no replies -- yet. I do know there are dome subtle changes in Win10 which make quite a few programs which are very stable on Win7 crash. Some of my favourite programs (not related to fS) crash randomly, and several of my own cockpit drivers crash or won't even run. This is why I'm sticking with Win7, even to the extent of returning one new PC built for me because it and the supplier wouldn't support Win7 properly. (I found an alternative supplier who could and did provide a similar spec PC with Win7 installed and working fine). Pete

Lua plug-in examples are in a ZIP file there clearly named! The one which records to a CSV file is also clearly named inside of it. Please just look! Pete

Oh, good. I'll use it in the releases in future, with the comments added back and probably with the controls again instead of my keypresses. Thanks for letting me know. Pete

This is related to the thread with the corrupted title: http://forum.simflight.com/topic/82599-crash-loading-p3dvhttpforumsimflightcomtopic82599-crash-loading-p3dv34-reporte-fsuipc4dll34-reporte-fsuipc4dll/ That did get a bit mixed up, but in the main it was all about an odd (new) problem, purportedly with P3D3.4 HF2 and FSUIPC 4.959, where on an attempted reload of P3D it sometimes crashes out immediately -- disappears, effectively. I need to know if this is only with P3D3.4 HF2, not earlier versions of P3D. And I do mean exactly those symptoms, not others you may have experienced. I also need to know if all those suffering with this are on Win10. I use Win7, having tried Win10 and found that a lot of my favourite programs then crash at random, and, worse, some of the drivers I've written myself for my own cockpit. I went back to Win7 and everything is fine again. Please let me know. Thanks, Pete

I wouldn't even no how to do "live streaming" -- so how do you do that without "code"? Depending on how you plan to get the data out of the FS process, you might be able to use a simple Lua plug-in. The are examples provided in your FSUIPC Documents folder. Look, for instance, at the one that records that sort of stuff at regular intervals to a CSV file. Pete

Exactly. Hence the rest of my explanation, if you read further. But I don't think any will help. The differences are so minor. And without the P3D-specific differences, they are zero except for the additional facilities which may or may not be used. Like the Traffic Limiter. And we've now proven that the P3D specific differences are not relevant. Pete

Er, 9002 is not good. That's the port it already uses for Broadcasting its present. You need to use somethinmg other than 8002 and 9003. Didn't you see the 9002 setting already there, as Port2 in the [WideServer] section of the FSUIPC4.INI file and also in the WideClient.INI file? The data one is Port=8002, the broadcasting one is Port2=9002. Pete

I didn't think it was a solution. It was only a test. We only arrived at that with a series of eliminations of bits in the “P3dhacks” value (there are 14 active bits, each suppressing one set of hacks into P3D). With all of them set my test volunteer could reboot P3D several times without problem, so we moved on to eliminations. With any one or combination, P3D could still be rebooted, but the number of times varied before it crashed (2-5). Only this one, to do with Lua displays, lasted 8 times, as many as all bits set, and he didn’t take it further. I’ve asked him (and now others here, too) to run with it set that way because i still didn’t think this is the problem. I know you say it fails consistently with 4.959 but not at all with 4.949f, which dates back to early 2016 and was built for P3D 3.1 (15831)! That makes no sense to me at all – if anything that should be worse. It does stop a couple of features working (friction tables and the controls timer, used to let separated Control+1,2,3,4 actions work even with intervening controls from advanced panels) but otherwise is really identical.. So, I think it’s very timing critical, and the differences in the timings of events is making the differences. Even recompiling a module with small changes can change such things. I’ve no idea how to go about “fixing” it, or whether I have anything to actually fix or it’s completely down to L-M. FSUIPC itself really doesn’t change very much – I may add new facilities, and of course they are changes – but 99% is unchanged from release to release. Even the differences between FSX and P3D are very minor, just different addresses mostly. And they change from each version of P3D to the next, even between Beta releases sometimes. And now, gypsyczar and yourself, between you, have proven that stopping ALL of the special changes in FSUIPC peculiar to P3D doesn't help. There's nothing else to change. It certainly seems to be some sort of interaction between add-ons, whether only DLLs or EXE's or add-on aircraft (which use DLLs too, either by name or as GAU files). But it is so variable, so time critical, I think, that narrowing it down is going to be well nigh impossible. I'm wondering if this is specific to P3D3.4 HF2, so I'd welcome feedback from earlier P3D version users to tell us their results with 4.959, which after all is my only supported version. I can't go backwards. gypsycar was able to restart P3D after with most of the different options removed, one at a time. Unfortunately it has to be so on EVERY time, not just once, 6 or 50 times. One excption, as we have already, shows it isn't a solution. I also now think that those who find that reinstalling FSUIPC helps are just seeing the results of a different timing, resulting from the DLL file remaining cached. You could probably do something similar in other ways, like copying it or looking at its properties. Pete

Okay. Let me know how you get on, please. Pete

I'm still working on reported problems with P3D, so Monday looks doubtful now. But I will release something this week. Pete

Try assigning it to something innocuous, one which does nothing of interest or note -- just for logging. There are other logging options which will do it without assignment but they are more technical. Also enable Event logging. It is designed to be loaded once and left to run, so don't assign to it. I just checked the version of TripleUse I am actually using. There are some subtle differences I don't remember doing. Perhaps you can use this as a basis for what you want to do. It sends KeyPresses, not Controls, but you can change those lines easily enough. It lacks most of the comments in the released version. Let me know if it works better for you. If so then maybe I should rleases the updated version. Here it is: -- Alternative PTT interpretations: -- Single short press = CS7 (RC Ack) -- Two short presses within a time limit = CS 6 (ProATC contact etc) joy = 20 btn = 5 interval = 500 -- 1/2 second press, gap, press limits ignorepress = false local function timebutton(test) ignorepress = true while true do time2 = ipc.elapsedtime() if (time2 - time1) > interval then ignorepress = false return false end if ipc.testbutton(joy, btn) == test then time1 = time2 return true end ipc.sleep(20) end end function buttonpress(j, b, du) if ignorepress then ignorepress = false return end -- ipc.log("buttonpress called " .. j .. " " .. b .. " " .. du) time1 = ipc.elapsedtime() time2 = 0 if timebutton(false) then -- First press / release counts: see if there's another if timebutton(true) then -- got another press in time, look for release if timebutton(false) then -- this was a double press, CS6 ipc.keypress(54,11) end else -- This was a single press, send CS7 ipc.keypress(55,11) ignorepress = false end else -- This was a single long press, send CS2 ipc.keypress(50,11) end end event.button(joy, btn, 1, "buttonpress") Let me know please Pete

Key strokes? Not button presses? And you are sure there is an ID number assigned to it? Check again using the JoyIDs utility as mentioned earlier in the thread. That's the only thing I know of which could stop it reading the data. And check the [JoyNames] section in the FSUIPC4.INI. It should be listed there with a number. Yes, and I know that many FSUIPC users are happily using it through FSUIPC. Pete

But why would that change over a few re-boots? Does that also allow FSUIPC to see it? Pete

So it must be hardware somewhere. Software doesn't change, not without re-programming. There's something wrong with the device itself if it's the same on another PC. Pete

Yes. That doesn't show anything useful, obviously. It never received anything. Did you try a different port? Pete

With really good and intense help from gypsyczar, we've possibly narrowed the crash at start down to one facility FSUIPC offers. the one to display windows on the P3D screen -- those provided for Lua displays and for some other program displays like the Radar Contact menu. I don't know if these are used by those reporting here with the crash problem, so information about that would be useful. To prevent FSUIPC providing this facility you can add: P3dhacks=x80 to the [General] section of the FSUIPC4.INI file. Currently, if you do this it will also stop traffic deletion working for those traffic management programs -- and FSUIPC's new Traffic Limiter -- but if you no longer can make P3D crash on start with that option added, I'll provide a version early next week with that additional problem fixed whilst I'm investigating why the display facility doesn't work correctly, the way I use it, in 3.4 HF2. Those who don't get the problem so often, or not at all on old versions of FSUIPC, are probably just lucky. It seems very timing dependent. gypsyczar found that sometimes all was well for several P3D reloads after each other. And I and Thomas can't make it happen at all. so it is very variable indeed. Feedback here, please, as and when you can test this. I really need to know if it is something I can solve or something we need L-M to look at. Pete

Okay. Found it. It goes weird for January, and is a month out the rest of the year. Not many folks can use this facility, or if they do they don't check the resulting date, as it looks like it's always been wrong! Thanks for reporting it. It'll be fixed in an interim update I'll probably release on Monday. Check the Download Links subforum. Pete

Why "xx"? You know that all 192.168.x.x addresses are local to your Network, don't you. They can't be accessed externally without knowing the external IP address of your Router and you allowing it by router settings. I've never had success with Wireless connections for the sort of continuous link WideFS needs. Timed out means it probably connected, sent a message, but never got a recognisable reply. Are you sure nothing else of your P3D installation is using the same ports (8002 and 9002) that WideFS uses by default? The FSUIPC.LOG is irrelevant for WideFS. You need to show the WideServer.log file. That's the other end of the connection. In FSUIPC4 it is built into FSUIPC rather than seperate as it was with FSUIPC3, but it still has it's own log. Pete .

Well, the calibration is saved: Are you checking the elevator in flight, or only visually from outside the aircraft? It may be operating without the visuals. The assignment itself is a little odd. You appear to have set a higher than normal Delta: 1=0Y,656,D,2,0,0,0 -{ DIRECT: Elevator }- The 656 will make it ignore changes of less than that. However, it won't ignore the whole range of course. The default is 256. Have you tested with a default aircraft at all. I'm not sure whether the one you are using will accept controls sent "direct". I knwo some Aerosoft and PMDG aircraft do their own thing with some controls -- usually throttle though. If it works with a default aircraft then you'll probably need to change to using FS controls for the add-on one -- Axis elevator set, for example. Then see if it works without calibration before calbrating. Pete

Here, with Windows 7, I get the right time but the date is wonky. Logging events I see 712643 \\LEFT\Prepar3D v3\SimObjects\Airplanes\B737_800\Boeing737-800.air 712659 *** EVENT: Cntrl= 66078 (0x0001021e), Param= 2017 (0x000007e1) ZULU_YEAR_SET 712659 *** EVENT: Cntrl= 66077 (0x0001021d), Param= -858993453 (0xccccccd3) ZULU_DAY_SET 712659 *** EVENT: Cntrl= 66075 (0x0001021b), Param= 16 (0x00000010) ZULU_HOURS_SET 712659 *** EVENT: Cntrl= 66076 (0x0001021c), Param= 30 (0x0000001e) ZULU_MINUTES_SET 712659 \\LEFT\Documents\Prepar3D v3 Files\Test at EGLL.flt which I would have expected P3D to ignore in favour of keeping whatever it has set. I'll check what is happening, but could you repeat the test but with Event logging enabled in FSUIPC's logging tab. I'm curious as to what different rubbish the day is set to. The hour is Summer Time (or Daylight Saving Time) because of the date. (The date is derived from the DAY number. There are no month/day settings). Pete

You'll need TWO centre positions, not one. There should be a centre regiod which corresponds to the range on the stick to which it will always return to when hands are off. It may be small, but not of zero size for sure. You can check by turning it repeatedly to the extremes and releasing it. For now I'd certainly leave slopes alone. Adjust later, to taste, once everything is working okay. You have not selected the Profile for Joystick Calibration. You have set the default setting for Elevator okay: but there is no calibration section for your Profile. You can rectify this by editing this line in the INI: [JoystickCalibration] to [JoystickCalibration.VRS FA18] but that is not the correct way to do it. Incidentally, why are you starting off setting a profile? Have you many others in mind? Best to set all your default controls first, then, when you create a profile, you can use the base or generic settings as a starting point. I think you may be diving into the more complex aspects of FSUIPC before doing the simple things. Pete

The frictions cannot be set because of this, shown in the FSUIPC log: 1375 ### Failed to obtain SIM1 Frictions access: no frictions facilities available! 1375 Reason 6: SIM1 base=534F0000 1375 FrictionAddr=53617220 contains FC000000 1375 BrakingAddr=536184E0 contains 65776F50 Evidently the friction tables moved in the later P3D. Also this "controls timer" link doesn't work. So, could you try the latest FSUIPC again but with this in the [General] section of the FSUIPC4.INI file, please? P3dhacks=36 That will eliminate those two "hacks". If that works, please split them: P3dhacks=32 eliminates the controls timer one, and P3dhacks=4 eliminates the friction tables one. This will help me enormously track the problem down. Without being able to reproduce it here I have to rely on user results. Thanks! Pete

"Writes to itself". Sorry, what is that supposed to mean? How do you derive that? If no log is being produced then FSUIPC isn't starting. This is therefore the same as that reported in other threads near here -- http://forum.simflight.com/topic/82599-crash-loading-p3dvhttpforumsimflightcomtopic82599-crash-loading-p3dv34-reporte-fsuipc4dll34-reporte-fsuipc4dll/ ('t know how that title got screwed up) and FSUIPC Causes P3D Failure Some do talk about LINDA's involvement. Perhaps you should look at those too? They are being actively investigated. Pete

That's just the results, which you stated in any case and I believed. You need to enable the Button logging, the input, not the output! It's the button I am suspicious about. It sounds like it is "bouncing" (technical term). Pete Repeating action buttons presses have to have the "Repeat" option selected in the assignment. You shouldn't use "repeat" with a Lua assignment! It will cause the Lua program to be loaded and killed repeatedly. There's a limit set by parameter as to how often FSUIPC allows this -- 66 mSecs is the default I think. If the Lua finishes in less time than that then it will repeat faster. If it takes longer then it will be killed some time after so it can be run again. So, yes, that could be the problem. If you wnt the Lua to repeat whilst you keep the button pressed you'd neen to program that in the Lua, but you can't do that with the TripleUse one because it is the holding down which changes the action. Pete