Pete Dowson

It definitely needs an update. However, I'm having immense difficulties installing the released 2.1. I had installed a Beta version (build 9790) supplied by LM, in order to get FSUIPC close, as I'm on holiday after Friday for 2 weeks, so the 9448 to 9936 update won't work, meaning I had to download the entire 10.5 Gb full version. That wouldn't install either until I completely uninstalled the previous version, which I di (all this being done overnight -- not much sleep here), and yet, even after that it still says the same thing, that it needs the previous version uninstalled first. I'm struggling with that at present. Nevertheless I hope to get a compatible FSUIPC version (4.929) out before Friday ... Pete

I don't know any way that the key assignment cannot be "taken" if it's a valid combination. There's absolutely nothing to stop a valid key combo being entered, and it would automatically replace the previous assignment to the same button. So I think you'll need to state, step by step, exactly what you are doing that leads you to believe "it won't take it". For forgotten assignments, just use FSUIPC's Button/Key logging to see what is going on. If you temporarily run FSX in Windowed mode you can enable the Console Log and see the results of your key and button presses in real time. It will show which assignment it is using and what the results are. Pete

You've pasted a WideClient ini file, no Log file unfortunately -- because that's the main one needed! You've also pasted two partial copies of the WideServer Log, both without first closing FS as I asked, and both actually showing a connection, not waiting for a connection. Obviously the files I need to see must appertain to the error you are getting, not the success. I also need the FSUIPC4 LOG file from the same folder as the WideServer LOG file. Please be sure to first CLOSE FS and WideClient so that the files are completed! Pete

Ah, thanks! Hopefully now Colin and Simon can show me the problem! Regards Pete

See Thomas's post just before yours. I don't understand why you cannot paste. I'm hoping Thomas or someone can explain this and how it is corrected. It makes no sense at all to me I'm afraid. Pete

Hi Thomas, Sorry, i'm not with you. Where does Explorer come into it? Do you mean Internet Explorer? I'm afraid I don't have that installed. Can you give step by step instructions? I've no idea why someone might not be able to do simple pasting into messages, nor therefore how to fix it. Thanks! BTW the dimmers on the Pilot side of the cockpit are all okay now. Seems to be just a bad connection on one of the plugs on the Bodnar board. I just fiddled with them and it all worked properly again! Regards Pete

Well, the text from the files is just normal text. If you couldn't paste it into a message here then you cannot edit or write text here, it is all part of the same thing. But obviously that is not true. Tell me, can you not even read the files? Just open them with Notepad. If you can read them you can copy their contents and paste them. Ask your son how to select text, copy it and paste it. I just use the mouse to select and Ctrl+Insert to copy, Shift+Insert to paste. Works every time, without fail. I can't help without information. The fact that you have WideFS working fine sometimes means it is working so there's obviously no need for you to have any "networking expertise". I suspect you are just misinterpreting some other problem, probably with scenery. Pete

Of course. Provided, that is, the throttles are assigned in FSUIPC, or, if the interface is such that the throttles are driven directly via offsets, provided you can change those offsets. Offset driven (skip if using normal assignments) If they are driven via the normal throttle offsets, 088C, 0924, 09BC and 0A54, then those must be changed to 089A, 0932, 09CA and 0A62 respectively. If this can't be changed then there's no easy way, because the 088C etc set are the true FS throttles. Either way, need Lua plug-in: You need a plug-in running which keeps the throttle disconnect flags (in offset 310A) when the A/T is enabled, but clears them when it isn't. I can't help directly with that because I don't know how the iFly A/T is flagged -- you'd need to find out. But assuming it is via an offset the your plug-in would be structured something like this (where I'm dealing with the default FS A/T indication): ATstate = false function checkDiscon() discons = ipc.readUW(0x310A) if ATstate then discons = logic.Or(discons, 0xC0C8) else discons = logic.And(discons, 0x3F37) end ipc.writeUW(0x310A, discons) end function setATstate(off,val) ATstate = val ~= 0 checkDiscon() end event.offset("DW", 0x0810, "setATstate") event.timer(5000, "checkDiscon") Explanation: Start at the end. The offset event says call "setATstate" whenever the FS offset for "AT Arm" changes. That function simply records this and then calls the function "checkDiscons" to see whether the disconnect flags in offset 310A need changing. The timer event merely calls the "checkDiscons" function every 5 seconds to ensure the flags stay as we want them -- FSUIPC clears the disconnects at 8-12 second intervals to make sure users aren't stuck forever with a disconnected device. Note that this logic is grossly oversimplified. The offset 0810 is simple "AT Arm". It doesn't necessarily mean the AT is engaged. To detect that in default FS aircraft you'd also need to check for all these A/P and A/T functions: Airspeed hold Mach hold RPM (N1) hold TO/GA It isn't worth me showing that level of complication here because it will probably be all different on the iFly. When you've got a Lua working (test by assigning a button or keypress to it so you can load and test whilst getting it working), you simply need to get it loaded automaticaly -- use an [Auto] section in the INI file, as described in the dox. Note: If this is beyond you, or more than you need, then, again if throttles are assigned in FSUIPC, you could simply use the "Throttles off/Throttles on/Throttles toggle" assignable controls in conjunction with or separately to your A/T controls, as you wish. Regards Pete

I said paste the CONTENTS of the files, not the files themselves! Just open the files in a text editor like Notepad, and cut and paste the text into the message. Pete

I'm not sure what part you think FSUIPC has in this. I assume you want to read certain values, like control surface displacements and airspeed so you can compute control loadings. Such data is available from FSUIPC for programs to read as they wish. But your UDP communication is surely part of the program you'd need to write. Information about interfacing to FSUIPC in assorted ways is provided in the FSUIPC SDK, and also in the Lua plug-ins and Offset documentation installed in your FSUIPC Documents folder. Regards Pete

WideFS doesn't care where you are. The connection is most certainly nothing to do with where you are. It sounds more likely that you have a bug in your London scenery which is causing FS to fail. There will be a WideServer log in the FS Modules folder, and a WideClient log in the same folder as WideClient on the client PC. Both are important to see what is going on. Also the FSUIPC4 log, in the FS Modules folder, may help. You can paste their contents into a message here. Please close both ends (FS and WideClient) down before getting the Logs. Regards Pete

It isn't anger, but frustration. If you read through it all you see I do everything I can to help, but so often you simply do not read what I write. You'd get frustrated I'm sure if I didn't read what you write. Think about it. I have done this, or at least examples related to the person's intentions, numerous times. but you never asked and never seemed like getting stuck. I also never understood what the **** you were trying to do, nor any reason for it. One of the frustrations was that it took a lost of exchanges to get you even to show me what you'd done or to explain where your erroneous "ipcwriteSW" was being executed. As I kept saying, you have to help me help you! There again, you so obviously don't read what I write! Please refer back and see that just is NOT true! And you wonder why I get so frustrated? Good bye. Pete

Because there's should be a space, not a "," between the B028C=0 and the rest, as shown in the documentation. If you have 9 detentes and say, a Cessna with 4 flap positions, where are you going to find the missing 5 flap settings from? You can't increase flaps beyond full flaps or decrease them below flaps up! However, for different flap positions at different detentes for each aircraft type you can of course use profiles so you can calibrate specifically for each. Pete

That's your problem. Why have you renamed Prepar3D.exe to Prepar3Dv2.exe? Unless you fix that, all of your FSUIPC related data files will probably be renamed to suit. What was the actual name of this log, for instance? Something like "FSUIPC4.Prepar3Dv2.log" perhaps? Whatever, both your INI file (if you transferred on from another FS installation), and, crucially for the registration check, your KEY file will need renaming too. Pete

I've moved this to the Support Forum, where it belongs. No, the AUTO facilities are the same for FSUIPC4 -- in fact they were implemented there first. The facilities are described in the section (obscurely?) entitled "Automatic running of Macros and Lua plugins", in the Advanced User's document. This section is even listed in the contents list at the beginning, so is it that you just didn't even bother to look?! If you have a running Lua program and simply want to know when the aircraft changes, better to use event.sim with the "AIRCRAFTCHANGE" option than reading offsets yourself. Pete

FSUIPC is working correctly, doing what you ask. Look, this shows the switch operating correctly: 398442 Button changed: bRef=0, Joy=109, Btn=7, Pressed 398442 [buttons.PMDG747-400 KLM ASIA] 19=H109,7,K67,10 You "pressed" the button (or toggled the switch to 'on' 398442 SendKeyToFS(00020043=[ctl+C], KEYDOWN) ctr=0 398442 JoystickValues PCnum=0, dwCount=1, data[2]={0000006d 000000ff} 398442 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=2 398458 Sending WM_KEYDOWN, Key=67 (Scan code 46), Ctr=1 398473 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 398473 .. Key not programmed -- passed on to FS 398473 KEYDOWN: VK=67, Waiting=0, Repeat=N, Shifts=2 398473 .. Key not programmed -- passed on to FS and as programmed it pressed Ctrl+C. (You do realise Ctrl+C is a VERY bad key combo to use, don't you. It is normally intercepted by Windows and means "terminate".) Then your button was released or switch set to Off: 399628 Button changed: bRef=0, Joy=109, Btn=7, Released 399628 [buttons.PMDG747-400 KLM ASIA] 19=H109,7,K67,10 399628 SendKeyToFS(00020043=[ctl+C], KEYUP) ctr=0 399643 JoystickValues PCnum=0, dwCount=1, data[2]={0000006d 0000007f} 399643 Sending WM_KEYUP, Key=67 (Scan code 46), Ctr=2 399659 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=1 399675 KEYUP: VK=67, Waiting=0 399675 KEYUP: VK=17, Waiting=0 And both the C key and Ctrl were released -- in the correct order, too. Then you pressed the button again 9or switched it to "on": 400205 Button changed: bRef=0, Joy=109, Btn=7, Pressed 400205 [buttons.PMDG747-400 KLM ASIA] 19=H109,7,K67,10 400205 SendKeyToFS(00020043=[ctl+C], KEYDOWN) ctr=0 So, again, Ctrl + C were pressed: 400205 JoystickValues PCnum=0, dwCount=1, data[2]={0000006d 000000ff} 400205 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=2 400221 Sending WM_KEYDOWN, Key=67 (Scan code 46), Ctr=1 400236 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 400236 .. Key not programmed -- passed on to FS 400236 KEYDOWN: VK=67, Waiting=0, Repeat=N, Shifts=2 400236 .. Key not programmed -- passed on to FS but you never released the button or switched the switch to off! This is why Ctrl C were kept pressed. It is doing EXACTLY what you programmed! Why on Earth are you wanting to hold the keypresses down with a button or toggle switch? Obviously if you opt to hold the keypress whilst the button is pressed, the keys will stay pressed until you release the button (or switch the switch off). That's the whole point of having the Hold facility. But it is normally only used for momentary buttons, you seem to be using it on a toggle switch. Why? It might beokay if you don't want to use the keyboard for anything else. But it seems daft to me. Pete

No, you kept saying, over and over, the code is ipcWriteSW(0x66C0,3), which is an error. Can you not see the difference? I have pointed it out several times! And in fact ipc.WriteSW(0x66C0,3) is also an error. Just check the log, it shows the errors. The correct syntax is ipc.writeSW(0x66C0,3) I understand you are not a programmer, so you need to start learning one crucial thing. Computers are stupid. they do not interpret what you tell them in the way you would, they need absolutely everything, every little character, to be completely correct. Check EVERY character! Just enable Lua logging and Button logging in FSUIPC to see what is happening. Show me the log if you don't understand it. i ddn't say that. I said I'm not doing any more changes to FSUIPC3. This was in relation to improving it's resilience to "Lua Kill", which I recommended in any case you do not use. I also recommended that you change to using event.timer. If I wasn't supporting FSUIPC I wouldn't be talking to you by now! Use Lua logging/tracing to see what is going on -- see the Logging tab. You seem not to be using the facilities made available to you for debugging things! Please do more to look after yoursdelf! I seem to have to nurse you through every silly little thing. It isn't as if I've got nothing else to do with my time! Sorry, I don't understand that question. If you mean "why isn't the FSUIPC library "ipc" documented by the Lua folks" -- why would they document private libraries such as all those provided in FSUIPC? There must be thousands of applications using Lua, with perhaps millions of private libraries. The FSUIPC added libraries are documented in the Lua documents I provide. It seems you've never even bothered to read them? There's only two, for Pete's sake and they aren't that long! :sad: Pete

Okay. Good, Pete

Ah, you are using FS9? Phew. I would recommend avoiding using Lua Kill. If you want to be able to stop your Lua program just have it test a button or something to see if it should terminate - maybe LuaValue and check in your loop for the parameter. I really can't do anything more with FSUIPC3, it is frozen. After continuous changes for the last 11 years just for FS9 I've had to stop messing with it. I'd hoped FS9 would be long dead by now! Correct, except you keep telling me the code is "ipcwriteSW(0x66C0,3)" which is an error, as I've already told you! I shouldn't need to keep repeating myself. And you've NEVER shown me this "WriteOffset.lua" nor told me how it is executed, so I've absolutely no information whatsoever! As I keep tel;ling you, you need to help me help you, and you are not doing so, at all. The ipc.write when written correctly will work, but you keep writing it incorrectly. What is that piece of code for? Why is it suddenly inserted without any explanation into your message? What calls function 'delay_s"? It is a VERY BAD idea to do a tight loop like that waiting for something to change without including a "sleep", because you are hofgging the processor and allowing nothing else to run! NEVER have a potentially long loop without some release like "ipc.sleep". If you just want a delay, just use sleep so that other things can be running. Use event.timer to run your code at your 4 times a second or whatever you need (though that seems rather excessive to me).. It will be MUCH MUCH better than doing an endless while loop, and you need no included "sleep" then. The program still owns the window whilst it is suspended awaiting an event, so you need not worry about the window flickering or something. The examples in the Lua package still using while loops without end need rewriting really -- they all date from a time long before the event library was added. Always use events instead. I'll get around to updating the examples one day. Pete

No, not had the opportunity. Regards Pete

Yes. All the files are renamed just like the Log. Your INI file and your registration, the KEY file. You need to rename them to match. And you should also be using 4.928 -- version 4.927 has not been supported for almost four weeks. Version 4.829 will be released soon after P3D v2.1. Pete

So. What does this mean? Sorry, I don't understand the relevance. Well, to start with I told you to set REV before calibrating not after as you've done. Please don't just look, also follow the numbered steps for good calibration. They are there for a reason. Pete

You've not shown me any "WriteOffset.lua, so I cannot comment, can I? And the code ipcwriteSW(0x66C0, 3) will fail because there's no library called "ipcwriteSW", you've missed the . out. I'm sorry, I know you are feeling your way, but it's no use asking me why something I've not seen or known about doesn't work. If you want help you have to be more helpful, and read what I say when I said your code, the code you showed me, doesn't contain that instruction. Because it is a last resort. Basically it tells Windows to forcibly terminate the thread, no matter what it is doing nor what the consequences. Unfortunately, this can cause what is known as a "deadly embrace", which is where two inter-dependent threads are running and one gets killed whilst the other is still waiting for something. I spent a lot of time over the last few years gradually nailing down and fixing these, but it isn't perfect and probably never will be. I'd like to find out why you can lock it up so readily as it normally is very rare these days. That's why I asked you, a few messages ago, for the code which does it, and what you do to lock it. I also asked you specifically for the exact version of FSUIPC, which also matters. You've totlally ignored both these requests and instead just ask me again why it locks up. Don't you think this is unreasonable? Why don't you want to help me help you? There is a MUCH better way to run a program like yours, and that's to use a timer event, not an infinite loop which can only exit by usding Kill. When we've sorted your other things out we'll discuss tat if you like, but you'll find examples of events being used among those provided. Apart from getting that ipcWriteSW wrong yet again, I have no idea what this sentence is there for. What is it supposed to mean? Oh dear. Do you not read any of my replies here? I am evidently wasting my time. I told you where to get that information in message #10. Go look. I'm not going to keep repeating myself. It gets irksome! :sad: That's the Lua symbol for concatenation, to join things together to make one string of characters. Because there's nothing following it to be concatenated. If you add 1 and 2 you don't write 1 + 2 + do you? Because the real line before ends in \ which makes the real new line code a part of the string. And it isn't just an 'n', it's \n which means 'new line'. The rest of your confusion follows on from this. I suggest you either forget Lua programming altogether or refer to the sources I pointed you to. Pete

What specific version of FSUIPC are you using? Lockups caused by Lua programs should be a very very rare occurrence in any recent version. Perhpas you'd better show me your finished program and tell me how to make it lock up FS so I can see why! You don't have any "ipc.write" in your program, or at least the part you showed me. That's why it doesn't work! I told you this already! Functions will only do things if you use them!!!!! Pete

Is this in FSUIPC? If so, which version? Sorry, what manual says that and where? I suspect you are completely misinterpreting something. If you want to reverse the action of an axis in the calibration tab of FSUIPC just use the "REV" checkbox. Calibrate properly AFTER setting that. You are doing things in the wrong order. Select the options you want FIRST. Then follow the numbered steps for calibration ennumerated in the FSUIPC user guide! I'm not going to repeat all the instructions here! ProSim uses FSUIPC, but axis calibration should be done on your axis, following the instructions, not with regard to something else entirely. Pete