Pete Dowson

They work fine here. But you don't even mention which Simulator you are talking about, let alone version of FSUIPC. They wrok fine here, with FSUIPC4 and FSX. I've not tried FS9 for a while, but nothing's been changed since I saw it work there too. Are you using FSInterrogate to write, or what? Please give more information if you need assistance. You could also try using FSUIPC logging. Regards Pete

Thanks for the appreciation! I'm very glad you like my work. Regards Pete

Okay, you've now defined these a local variables, but you still do: ipc.set("Aiuto",1) rather than Aiuto = 1 The global "Aiuto" is not the same as your local one. i'm not currently understanding how the ipc.writeUB lines aren't doing anything at all. I run several Lua plug-ins on assorted Clients and if this happened to me a lot of functions on my cockpit simply wouldn't work. I might need you to do some Wideclient logging, but I need to think about it first. Why are you pressing the "New Log" button? Please don't. There's always useful information at the start. Just don't touch anything else in the Logging tab, as I asked. There's no sign of any input whatsoever from the client. Writes to a monitored offset are not only logged, they are logged with the Client PC name and the program ID. So something very odd is going on. Can you clarify please exactly which version of FSUIPC and which version of WideClient you are using? Regards Pete

Have you not bothered reading replies in this thread? Have you tried deleting the WX files? Have you shown me an FSUIC4 log at all? What's the point of posting if you ignore replies? Pete

I call it 'ranting' because you keep saying the same things without adding anything new, and certainly not appearing to take much notice of my replies. Correct. I cannot fix a problem on your network, at least not without visiting your place and doing the things you will have to do for yourself. WideFs needs a working network to start with. I don't understand ports. All I know is that numbers 8002 and 9002 are used by WideFS, and if anything else gets them first WideFS cant use them. That is precisely why they can be changed in the INI files, as you surely must know, having studied the documentation so much. Please be welcome to leave. I have tried my best with you, and spent a lot of time on it too, evidently to no avail, because you continue to ignore so much of what i write! Bye! P.S. You have still not even bothered to post the WideServer log, after this time and wasted messaging! :-( I won't bother answering you again, to avoid your eviident irritation with my attempts to help. Pete

Why do you think it relevant ot this forum, which is mainly concerned with FSUIPC and WideFS? Crashes in API.DLL are almost always a sign of a bad CFG, WX or FLT file. Try going to the My documents\Flight simulator X files folder and deleting all the WX files. They are binary-encoded weather files, and an error in any of those crashes FSX quite easily. If you have an FSUIPC problem please find the FSUIPC4.LOG file in the FSX modules folder and paste it here. Go to the Download Links subforum, where all downloads are provided. Regards Pete

Sorry, I've no idea what you are talking about. It most certainly doesn't seem to relate to FSUIPC or WideFS or Intitial.lua, which is the subject of this thread. If you have a general FSX problem I suggest you go to the FSX forum. But please be more clear about your question, which doesn't make sense the way you've put it. Regards Pete

I seem to remember you said this before. We went all through that and came to the conclusion that something has got messed up with your network. I can't sort it for you, I'm sorry. Why post the FSUIPC log for a Network problem? The only logs relevant to WideFS are the WideClinet and WideServer logs! You said that before. Have you forgotten? You said that too. Please do look back. You are repeating yourself to no purpose. Ports aren't "on" or "off", just blocked (firewalls) or used. i simply suggested you might have added something using the same port as needed by WideFs. Since you've studied the documentation so many times you will know you can change the ports used by WideFS easily by parameters. I've no idea how you 'see' ports, but perhaps you can cast your mind back and try to remember what you've changed since things worked. It's likely that one of the thngs you did, maybe one of the programs you added, has messed things up or stolen the ports. Otherwise, you need to start thinking about hardware or wiring problems. I note that you've not yet even confirmed that you have a working network in the first place! What has FSUIPC got to do with it? There's no network stuff in FSUIPC, only WideFS. FSUIPC uses SimConnect for 90% of its actions. Are you using SimConnect over the network? If so, check that none of the SimConnect applications are using the ports WideFS needs-- 8002 and 9002. SimConnect would get them first. No idea what you mean there, sorry. You ignore half of what i tell you. FSUIPC is not relevant. Where is the WideServer log file I asked you for? What's the point of you ranting on like a crazy person if you don't read what is written? I'm not going to answer many more of your rants. Please calm down and act sensibly, and for Pete's sake, please read what I write. Else i'm wasting my time altogether. I have better things to do, I assure you! Pete

Unfortunately there are quite a lot of "syntax errors" which should have been quite clear: (BTW use the 'code' quotes to preserve indents -- the <> button above your edit area) if KeySeen == 0 do[/CODE] The syntax is 'if .... then', not 'do'. [CODE] KeySeen = keycode then[/CODE] I don't know what is intended here. You have a 'then', associated with,what? the last 'if'? Is 'KeySeen = keycode' intended to be an assignment, which it is, or did you really mean == instead of =, for a comparison? [CODE] if KeySeen == (186, 8 ) and -- new keycode == (57, 8 ) - how should this be written?[/CODE] Since you only need to deal with two Keycodes -- 186 and 57, because these are the only ones trapped by the Events you added, the shift codes are not relevant. But, for information, the keycode and the shifts code are separate variables -- the (obscurely named?) values you've called 'keycode' and 'shifts' in the function definition (please look at it, the line starting 'function'). You can't compare both together, only one then the other. They are separate values, not joined in a way you can parenthesise like that. [CODE] ipc.macro("LevelD767: ALTInc") and KeySeen = 0[/CODE] This makes no sense. You execute a macro 'and' set 'keySeen = 0'? The 'and' is a logical condition, not an operation! What are you trying to do? [CODE] if KeySeen == (57, 8 ) and -- new keycode == (186, 8 ) - how should this be written?[/CODE] See comments above for the similar question. You are only needing to deal with the keycode, not the "shifts" as well, which are always 8 in any case. [CODE] ipc.macro("LevelD767: ALTDec") and KeySeen = 0[/CODE] Same odd syntax as commented above. I can't fix it for you because I've no idea what you really mean. [CODE] else KeySeen=keycode -- I do not understand why this is necessary [/CODE] You don't understand why KeySeen is used to keep a record of the last key seen? Why else it is existent? That's its whole purpose! [CODE]event.key(186, 8, "AltitudeChange") -- Coming after the function itself event.key(57, 8, "AltitudeChange") -- Same remark[/CODE] Why the remarks? Pete

Sounds like a connection problem. Normally such problems are due to Windows removing power from the USB port when there's been no action on it for a while. You can stop that by turning power management off for each USB hub, in the Device Manager. But I've never heard of it making a sound when it does it. Sorry, I've no idea about all that. If the joysticks are disconnecting, then simply going into FSUIPC's dialogues and exiting again causes FSUIPC to re-scan for new connections. FS itself doesn't do this -- you'd need to close FS down and restart it to get them back. Regards Pete

It's certainly not programming, but merely following some rules for macro naming and formats. The names needed are listed in the file called "PFCmacroindex.csv" which yuo wil already have. The 'starters' are part of the two 5 position Magneto switches, and are, in fact, referred to as examples in the "Macro Names" section of the PFCHid.DLL User Guide. You will see that the names as Magneto1 and Magneto2 respectively. Referring than to the formats for Macros in the FSUIPC Advanced User's guide (section entitled "Macro Controls") you will see you need an ordinary text file (which you will save as PFC.mcro initially) containing something like this: [Macros] 1=Magneto1= ... 2=Magneto2=... where the ... part is replaced by the FS or FSUIPC control needed to carry out the action. These controls are listed in the List of FS Controls document also installed with the FSUIPC documentation. Looking for MAGNETO you'll see MAGNETOn_SET listed for each of 4 engines, 1-4. The numbers given are 66400, 66401, 66402 and 66403 respectively. So, if we put: [Macros] 1=Magneto1=C64100 2=Magneto2=C64101 we should get the same results as the default driver. At least this is so if the parameter, 0-4, is the same one used by FSX. Unfortunately this is probably true only for props -- FSX does different things with Jets, which of course don't use a 5 position magneto switch for starting. I think you'll find the starter for jets is position #1, corresponding to the Right Magneto selection. The #2 position, 'Left', will enable the engine generators after the engines start. Now, you actually need Magneto1 starting engines 1 and 2, and Magneto2 starting engines 3 and 4, so you need the format of the macros allowing multiple actions, thus: [Macros] 1=Magneto1 1.1=C64100 1.2=C64101 2=Magneto2 2.1=C64102 2.2=C64103 I'm afraid I'm not in a position to test this for you at present, but do try it. But first, one more thing. Assuming you are using your Cirrus for other aircraft too, you realy only want this override to operate for the 747 when loaded. To do that you should name the macro file something different, e.g. "PFC747" then add a new section to the PFCHID.INI file: [Config.<aircraft name>] MacroFilename=PFC747 substituting the aircraft title for <aircraft name> -- you can get that from its CFG file. Regards Pete

I've not heard of a problem which only occurs when loading a flight -- unless, possibly that flight loads an aircraft with panels using FSUIPC? Is there a windows error message when this occurs? If so please tell me the details from that message. If not, perhaps you could see if there's an entry for it in the Windows event logs. Could you make sure you are using the latest version of FSUIPC4 -- see the Download Links subforum here, where you'll see that the latest is 4.756. Then, if the problem still occurs, please find the FSUIPC4.LOG file, in the FSX Modules folder, and paste it into a message here. Regards Pete

FS9 and before ( ie FS2000, FS2002, FS2004 and even CFS1 and CFS2) are supported by FSUIPC3 which is a separate, program with its own installer. Regards Pete

Okay, I managed to reproduce it. It was only the saving of the log at the end which had the problem, and it only occurs when Prepar3D is the only supported Simulator installed on your PC. Of course I have FSX and ESP installed as well. i had to edit the Registry to make them appear missing in order to see what was going on. Anyway, it is fixed in the 4.756 installer now available in the Download Links subforum. Thanks for your assistance. Seems there aren't many Prepar3D users who wish to use FSUIPC4 but don't already have FSX or ESP installed. If you were trying to Register FSUIPC4 and/or WideFS as well, you will need to download this and run it again to do so, as the same problem stops the correct KEY file being written too. Without the key file your copy will appear unregistered. Regards Pete

Not a bother. I hope you find the cause and manage to fix it. When you do it would help me and others if you'd report back. Thanks, Pete

Hmm. Interesting. I wonder if this is related to the error you originally got. The log being displayed on screen as the installer works is saved on completion to a file called 'FSUIPC4 Install.Log', to the same folder used to save all the other files including the 'FSUIPC Documents' subfolder. Seems that even though you got no error message it didn't terminate correctly. I really do need to find out why. There is a "Save" menu entry in the on-screen copy window (you can see it in your pictures), which could have been used to obtain a text file copy elsewhere once you realised there was no such file, but I've not seen a case where the file could not be saved, except where there's no installation of a supported simulator to save it into. I don't suppose you managed to find the entry for the original error in the Widows event logs? That would really be the most useful data. Regards Pete

But then, after all that, all you show me is a partial Wideclient log simpy showing that it isn't receiving any broadcasts, which also shows it is not configured to deal with a non-broadcast setup, wrongly calling it a problem with FSUIPC not finding the server it is running in, and even misleadingly entitling the thread "FSUIPC 4.70"? I assume you mean WideClient, again? The software does not change on its own. Something else has changed on your system. Good. But why, then, not say so and instead make me repeat the advice in the manual you say you've read? "Connection refused" just means that, and unfortunately Windows gives no more information. All it says (if you Google it, for example) is: WSAECONNREFUSED 10061 Connection refused. No connection could be made because the target computer actively refused it. This usually results from trying to connect to a service that is inactive on the foreign host—that is, one with no server application running. So, there are many possibilities: * The port being used (8002 by default) is already taken by another program * There is a firewall problem despite you having checked this * A hardware or wiring problem on your network * A Windows software problem, in the network driving part * FS isn't running or WideServer is not enabled. No, as it says, that is an FSUIPC4 log. I don't think FSX makes a log. The WideClient log is only half the story. What does WideServer say? Why not paste the WideServer log (instead of the FSUIPC log which isn't at all relevant). The part on Configuring the Network, and which in particular tells you about the ServerName and Prorocol parameters. The part with a bold red banner advising you to at least read that part! When you say that I "keep suggesting in reading the manual", if you refer back you will see that I did this only ONCE, so hardly "keep suggesting", and the reason I did so isd that you simply gave such little information, describning it incorrectly, that it looked like you'd nerver looked at it at all. 99% of WideFS connection problems come from matching WinVista or Win7 with WinXp which two systems use different Workgroup names. That's what it looked like in your case, with your unfortunately very flimsy report. I can only respond to what you provide with my best guess Something has changed, then, and it isn't WideFS. I'm afraid you will have to figure out what. I can't help very much from here. In your situation I'd try to work out what I changed, because certainly something changed to clobber your network. Do other Network functions operate? You'll need to go through some process of elimination. It doesn't look like it, but the firewall is probably only one of many possibilities. If it isn't the firewall then something else is wrong with your network. I can't verify that in any case because you've not shown me the WideServer log file. Regards Pete

All that is okay. Windows very often asks for confirmation of an install. You just tell it it was okay. You do have an inordinate fondness for pictures, don't you? I have no need for them, or interest in them. If you want me to view the Install log, just paste the install log text in your message -- that's why it is created, as I told you already! However, it won't tell me anything for a success. The opportuntiy to find the original problem has now passed unless you can find the details in the Windows event logs. What for? Do you have a problem running Prepar3D with FSUIPC? That is not the Instal log. Regards Pete

I think there's been a misunderstanding. I asked for a Log showing key presses and the 66C5 or whatever offset being monitored. You supplied a huge log with neither. Please do NOT check options at random. IPC Read logging is only filling a huge log with irrelevances (it won't show WideFS reads in any case because they are loacal to the Client -- the Server simply keeps the client memory updated irrespective of actual reads once notified). I'm afraid there's no useful information here at all. Please remove ALL logging options, then enable Key/Button logging and, on the right-hand side, Monitor the offset being tested, eg 66C5 or whatever, as type U8, and check the 'normal log' option below that. Do not press any other buttons or make any more check marks in that tab. Additionally, looking at the Lua you supplied, I assume it must be the wrong one, because it does not contain any "ipc.write" at all. Please do show me the one you are using. BTW with the right logging there should be no need for file attachemtns. You can paste them into your message here. It makes this easier this end. Regards Pete

You probably need some extra action. It may need an additional call (macro entry) for the action of releasing the mouse button -- please look at the optional parameters you can use for such things, in the documentation. There's only so much can be done via the semi-automatic macro generation facility. Regards Pete

The C2 Pro is driven using a separate driver which interfaces to FSUIPC. FSUIPC is only the interface used for most of the functions. The throttle quadrant is different because it is interchangeable, so FSUIPC assignment is generally needed (though the default is designed to suit the normal quadrant supplied). The 'cause' is that the C2 PRo console is designed for 2 engined aircraft, and the PFCHID driver supplied handles it as such. If you want to program is differently you can do, with a Registered copy of FSUIPC, but you have to provide parameters in the appropriate files. Please see the PFCHID documentation, and in particular the section entitled "Macros: configuring a PFC HID device for FS add-ons". As it says there, every switch and encoder (but none of the analogue inputs) can be diverted, individually, to operate via FSUIPC “macros”. Regards Pete

FSUIPC is running in the Server -- it runs inside FS. You are talking about the Client, and as it says it isn't receiving broadcasts from the server. Please read the section in the WideFS user guide which tells you how to configure things for this. Why? What's that going to change? Please use the documentation provided. You need to either make sure all your PCs are in the same workgroup, or else use the ServerName and Protocol parameters, as documented. Regards Pete

Hmm. that's a new one. Unfortunatey there's no useful information in the fancy picture you posted. I might have seen more if you moved the top window away from the log, but far better to actually paste the Log itself into your message. That's what it is for. If will be in the Prepar3D modules folder. The other information desperately needed is the location of the crash, whch is hidden in the picture further down in the Windows crash data -- it realy is pointless providing such pretty pictures when essential information is hidden like that. If you must post pictures please show the WHOLE set of information. Probably much easier just to write down the details -- Module Name, Exception Code and Offset or Location (the most important part, missing off the bottom of the display). BTW, from what I can see of the Log it has actually finished the installation part -- it looks like it is crashing just before providing the Registration dialogue. Regards Pete

It's almost certainly down to the trust-checking bug in SimConnect. Please see the FAQ subforum thread entitled FSX fails to run after FSUIPC4 first installed Regards Pete

I was comparing your original post: 0=CU(-0,7)0,6,C1003,10 1=CU(-0,6)0,7,C1003,10 2=CP(-0,7)0,6,C1004,10 with what actually got processed according to your FS9 log: 61277 [buttons] 5=CP(-0,6)0,7,C1004,10 61277 [buttons] 6=CP(-0,6)0,7,C1003,12 61277 [buttons] 8=CP(F+0,11)0,7,C1004,11 61277 [buttons] 9=CP(+0,6)0,7,C1003,13 61558 [buttons] 1=CU(-0,6)0,7,C1003,10 61558 [buttons] 7=CU(F+0,12)0,7,C1004,12 61558 [buttons] 10=CU(F+0,13)0,7,C1004,13 There's obviously a lot more going on that wat was implied by your first posting. That was my only comment. If it was a subtle error in FSUIPC, I'd need to compare apples with apples not with oranges. However, that is all moot now. I found the problem. it was a bit weird -- it worked fine if you are also using my PFC driver (PFCFSX), as I am. I had to trace through to spot that there was an unintended dependency. The error has been in for years, so it seems the InitialButton option is either rarely used, or few bother to report problems. So thanks for doing so. It's fixed in 4.756, just placed in the Download Links subforum. Regards Pete