Pete Dowson

I tend to use the built-in FSUIPC "monitor" facilities to check these things -- it is so much easier, and it shows optionally in real time on screen and in the log, for proof and proper checking. Ah, yes, sorry. i read the message and replied from (bad) memory. Well, the first was certainly my error. Sorry. The FSUIPC log would have shown you that the Lua code was wrong: 64953 LUA: beginning "D:\FSX\Modules\ipcReady.lua" 64953 *** LUA Error: D:\FSX\Modules\ipcReady.lua:6: Event proc not found 64953 LUA: ended "D:\FSX\Modules\ipcReady.lua" The problem is the "local" before "function". Please delete that word -- I typed it semi-automatically because I've been using local functions a lot recently. You need any function called from an Event to be "global", else FSUIPC can't see it. Omit "local" and it becomes global. I've now tested that one here, with the 37C0 corrected to 37F0, and "local" removed, and it works fine. Well, with the 37C0 changed to 37F0 that worked fine, straight-off, here. Here's the FSUIPC4 log file with it running and the Baron left cowl flap being changed, using Monitoring of 37F0 as FLT64 and 66C0 as U16: 125281 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.078 125344 Monitor IPC:37F0 (FLT64) = 0.07800000 125391 Monitor IPC:66C0 (U16) = 1278 127766 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.156 127828 Monitor IPC:37F0 (FLT64) = 0.15600000 127828 Monitor IPC:66C0 (U16) = 2556 128234 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.468 128281 Monitor IPC:37F0 (FLT64) = 0.46800000 128281 Monitor IPC:66C0 (U16) = 7668 128641 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.78 128687 Monitor IPC:37F0 (FLT64) = 0.78000000 128750 Monitor IPC:66C0 (U16) = 12780 Maybe you should (a) make sure you are using the latest FSUIPC version (3.90 or 4.50, or 3.906 or 4.506 from the Updates above), and (b) enable the monitoring and check the log. I haven't checked this in FS9 yet -- you didn't mention which versions you were using -- but the Lua code is the same, so it should be okay. Let me know if you need me to test that too. Regards Pete

Good! Thanks for letting us know. Regards Pete

AutoSave doesn't save flights at all. It simply calls the routine in FS which saves flights, and that saves them to the My Documents\Flight simulator Files folder -- which is where your flights are saved. There's something wrong with your FS installation then, as that means it won't show flights you save explicitly in FS either. AutoSave does not choose where to save flights -- it is not possible to do so. It is FS which decides where to save them. Regards Pete

The AutoSave DLL has not been changed for many years (since 2004 -- version 1.501), so what have you changed? What IS the "latest one"? "Latest" is meaningless to me really, it just means "the last one I've seen" -- folks have said "latest" when using a year-old version before now. All my software modules have version numbers, please always quote them. Load up FS9, run it till ready to fly, and then just close it. Show me the FSUIPC.LOG file from the modules folder -- paste it here in a message, it will be quite small. It might be useful to also show me the AutoSave.CFG file, from the main FS folder. Regards Pete

Not that I know of, no. Note that one Joystick device is limited to 8 analogue axes and 64 buttons in any case. The older interface I use in Windows supports only 6 analogue axes and 32 buttons. No, not at all I'm afraid. To fool an application program (game, whatever) into thinking it's a genuine device it would need to be written as a Windows Driver. That's an area I'm never getting into. I did it with VXDs in the old 16-bit (windows 1 through to Win98) days, but today's 32 and 64 bit operating systems are another story, and I don't want to get involved in any of it. Sorry. You might want to talk about it with Bob Church -- in the CH Hangar. Regards Pete

No data from old versions is any use to me, sorry. Please download version 4.34 of PFCFSX, from the Updates announcement above, and try that as I asked. I cannot fix old versions, only the current one! If 4.34 doesn't fix the issue (other than with the Airbus, which is out of my hands evidently) then I'll work out what information I then need from you. Yes, I am using win7 64-bit dual booting with Vista 64. Thank you. Regards Pete

Not anything built in. The only thing I can suggest is you have a little Lua plug-in which reads the offset, converts it into a form you like, and puts it into another offset -- one of the user-free ones from 66C0 to 66FF. Something like this, for example: local function convertCowl(offset, cowl) mycowl = cowl * 16384 ipc.writeUW(0x66C0, mycowl) end event.offset(0x37C0, "DBL", "convertCowl") or alternatively (I'm not sure which method will turn out to be more efficient): while true do cowl = ipc.readDBL(0x37C0) mycowl = cowl * 16384 ipc.writeUW(0x66C0, mycowl) ipc.sleep(100) -- limit to 10 updates per second (change number of millisecs to suit use) end The first one is more amenable to further additions, other events, should you need them, but its operation isn't so obvious to non-programmers. Save one of these as "ipcReady.lua" in the Modules folder and it will load up when FS is ready to fly, and operate from then on. You can read the converted cowl flap value as a 16-bit unsigned value, from 0 to 16384, in offset 0x66C0. Note that I've not tested them, so please confirm. Regards Pete

You need to follow the procedure for the "New weather Interface" and deal with the offsets in the CCxx area first -- the string you read there will otherwise be whatever is happening to be read. Or is that what you want? Are you getting the strings you think you should have? For GLOB weather to have a good effect (a repeatable effect) when writing, you need first to put the sim into Global weather mode. Have you done that? There's a facility for this in the NWI. It only needs doing when you start your interface. Hmm. You may need to change some of it. Unfortunately the read and write formats for FSX METARs aren't the same. I think they were programmed by different people without much liaison! Devil of a job for me to sort out when I was programming this stuff. We did get agreement from the FSX team that they would put it all right in a subsequent SimConnect update (at the beginning they promised updates for SimConnect every few months!!!). The only definitions of the peculiar METAR formats they use are in the SimConnect SDK. If you have the Deluxe FSX you have that on the DVD. Else I would recommend the ESP one instead, it is better cross-referenced and the details are the same (ESP == FSX+Acceleration, less some aircraft and missions and things). You are also using an FSUIPC4 facility which, to my knowledge, nobody else has actually tried since I implemented it during the FSX Beta period, over two years ago. As I think is still noted, it isn't tested well. Maybe you can turn on the Weather Logging in FSUIPC so we can see what is happening? I'd be glad to make it work if it isn't already. Also, SimConnect logging could be useful -- it shows the actual Metar strings going back and forth too. A Loading screen? What sort of "loading" is going on? That normally only happens if the time is being changed, things like that. The weather might be unchanged because either the Global mode hasn't been set, or, if you are writing a specific WX station, because it is slow in being interpolated with the other station weather around. You really would be best setting Global mode. Or it might be unchanged because the string formatting is wrong. The log may show an error, or the SimConnect log might. There's a protocol to follow to write weather via the NWI. Just reading and writing it straight isn't enough. Aren't you referring to the (admittedly skimpy) NWI documentation -- the little TXT file and the header? Considering the weird complexities of the METAR strings, you'd probably get further using the parametric NWI -- and in fact that would be compatible with FS9 too (so you could, at a pinch, copy weather from one to the other). Ah, you are not looking in the NWI documents, then. Check the chat about protocols and sending commands in the TXT file, and you will find the Header defines the NW_GLOBAL value for setting that mode. Regards Pete

I've not dealt with EPICINFO for many years, but i seem to recall that there are facilities in the one CFG file for different sections for different aircraft, or panels -- have you checked? Only offsets working directly inside FS could conceivably crash it. All offsets assigned to individual add-ons are separate, only applying to those when they are running, so I don't see that there would be any harm. And you'd not be able to measure any performance difference unless you are talking about writing huge amounts many times per second. Regards Pete

You failed to note which was which, but I worked it out, hopefully correctly: In the Server INI you have ProtocolPreferred=UDP implying that you wish the connection to work automatically, and that when it does the Server shall tell the client to use UDP if it is given a choice. But in the Client you have: ServerIPAddr=172.20.20.200 ProtocolPreferred=UDP Four points there: 1. For automatic connection you must not provide the Server name or address. 2. In general it is far better to give the ServerName rather than the IP address, if you are specifying it. 3. "ProtocolPreferred" is not a valid Client parameter. The preference is dictated by the Server, not the Client. 4. If you do specify the Server, as you have done, you should really specify the protocol too: "Protocol=UDP", for example. That said, I still believe you should have had a connection, though it may have been via TCP not UDP because the client will be trying to initiate the connection instead of waiting for the broadcasts from the Server (it only waits when the client has no specified Server). Neither WideClient nor WideServer ses any trace of the other. So, these are the possible problems: a) The most obvious one would be a firewall, or two firewalls, one in each PC. If you have an operating firewall you need to allow WideClient and FS through, on ports 8002 and 9002 (as configured). b) For the Broadcasting to work (for automatic connection) both PCs need to be in the same workgroup -- i.e. the workgroup names must be the same in both PCs. [Note that broadcasting only applies between WinXP/Vista PCs, not any using Win2K, NT or 98 or earlier]. c) Possibly the IP address is in error: double check the server IP address, or omit it, or use the ServerName=FS_00 parameter instead, and add the Protocol=UDP line too, in this case. Regards Pete

Sounds easy enough. I'll put it on my list for attention in the next increment. Please keep an eye on the Updates announcement. If for any reason i don't do it, I'll post the reason to this thread. Regards Pete

No problem -- I'm glad it was a simple solution! ;-) Pete

That sort of thing was easy with FS9 and before, but as you've found out, not a good idea with FSX and ESP. I suspect most modern programs, designed to be Vista-entangled, would suffer from such things. The installations are not nice and clean like they once were. (I hate them too!) Pete

This is a sure indication of a bad registration. Either you purchased it legitimately, but AFTER the current date set in your PC, making it look invalid, or you obtained it from an illegal source, a pirate key generator. So, check the PC's system date. Correct it if wrong. If it was okay, and you know you purchased the FSUIPC key legitimately, please ZIP up your KEY file and send any other proof of purchase you have, to petedowson@btconnect.com, and I will check it here. Regards Pete

Hmm. Are you saying there's a difference in how the trim rocker works between 4.317 and an older one, with no other changes to the INI file or to the FSUIPC version? This is the problem where the trim rocker on the yoke does nothing, even with default aircraft? You do realise that 4.317 was a short-lived interim update, soon replaced, don't you? Could you check using the current version -- 4.34 -- please, and let me know? I need to get this straight. I have no other reports of any problem with that, and it is pretty fundamental. Right . So how do you trim it normally? I assume you mean the Schiratti site (it isn't mine). I have noticed that its copy of my PFC driver is out of date. I will have to get that changed to 4.34 -- it has a serious bug which crashes FSX has been found in that, fixed in 4.34 here. I did supply 4.34 to Mr. Schiratti a while ago but it must have been mislaid. I'll get it changed soonest. That's the same crash already reported a couple of times -- it is related to the listing of FS controls, which it gets from FSUIPC. It is fixed in the current update, which is the one which should be used. Sorry, what Installer? Are you talking about the PFC site now? Please do make sure you are using FSUIPC 4.50 or later. Regards Pete

No, it isn't checked by module. Luckily FSX doesn't crash if you address a Local Variable which isn't defined. Sounds like that variable is either disused or used internally as a flag or temporary storage, rather than the real value. Or it may be part of a protocol used in the communication between their modules and externals which need to be in a specific sequence. Right. Glad you managed something useful anyway! ;-) Thanks for posting the result. Regards Pete

Sounds like you are doing okay! Happy flying! ;-) Pete

Oh, good. Unfortunately that isn't true. Many things FS are entangled in the Windows system -- several places in documents & Settings (ProgramData and AppData in Visa), for "All Users" and specific users installing FSX too. And then of course there's the run-time library and other support systems installed into Windows by the FSX installer. And thenSimConnect, which is a Windows side-by-side library installation, affecting not only the Windows WinSxS folders, but almost uncountable places in the Windows Registry too! I did try to work out al the places in the windows system which are affected by and affect FSXbut i gave up after several pages full. Ah, you had Acceleration installed toosome mess to do with it and SP2 no doubt. They are alternatives. The Acceleration install is cleaner, and it does include SP1 and SP2. Regards Pete

Well, the installation is a mess. The Installer finds only the base version of SimConnect, no SP1 addition at all. When FSX is running and has loaded FSUIPC, it appears to be masquerading as the SP1 SimConnect, but in fact identifies itself also as the base (60905) version and refuses to allow the connection. I'm afraid there's nothing i can do about this. You have a screwed up FSX installation. I don't know how it has arisen, but the only solution which has worked in the past has been the manual deletion of the SimConnect folders in the WinSxS folder, and the reinstallation of them, usually by reinstalling FSX. If, as you say, you've tried that and have had no success I really cannot help further. You need Microsoft expertise. As one last gasp, as it were, could you show me the actual WinSxS folders -- the full names and contents? Also, do a complete search on your hard disk for all "simConnect.dll" copies, list where they are and their version numbers. You say You don't mention installing Windows. Did you format your new hard disk and install Windows from scratch, or did you copy a back-up partition from somewhere? I really cannot imagine how a straight format, Windows install, FSX install, FSUIPC4 installcan go wrong. Everything should be pristine. You DID run FSX first, after installing it, didn't you? Before installing the SP1 update, and before installing FSUIPC4? This should be the sequence: 1. Format HDD 2. Install Windows 3. Install FSX 4. Run FSX, make sure all is well. 5. Close FSX, install FSUIPC4. 6. Run FSX + FSUIPC4, ensure all is well. 7. Install FSX SP1 8. Run FSX + FSUIPC4, ensure all is well still. 9. Install FSX SP2 10. Run FSX+ FSUIPC4, ensure all is still well. Regards Pete

Yes Yes Well, that should be okayprovided Lua file 2 is declared correctly in the INI file. I'll do some tests here. doesn't the FSUIPC log file show anything if you enable Button/Key logging? Really, it would be tidier for you to put the other macro actions in the Lua file and assign to the Lua file instead of the Macro. That way it becomes independent of where the Lua file entry is in the INI file list, and is a neater approach in any case. [LATER] Ughbug! I've found out why the Lua file isn't called from a Macro. It actually tries to use entry 0 in the LuaFiles list, and logs a failure to load file ".lua". I'll fix this now, watch for another update in the Announcement. Regards Pete

Phew! You are missing it? I don't know how it could escape! ;-) Does it not contain a paragraph, in the section I referred you to, beginning Surely that is also in your copy? As it says, FSUIPC will automatically load Lua files with the given filenames. You have several choices. First, please note that the term "pre-loaded" merely means "loaded before" -- i.e. loaded before the event which you are using to trigger the actions they specify. Preloading is NOT the same as "automatically loading", which I think is perhaps where you are getting mixed up? There are several ways of "pre-loading": 1. You can assign a button or keypress to the Lua file, and use that to pre-load it. This would be a user-controlled pre-loading. 2. As 1 but make your assigned button an "initial button" which is automatically triggered. This initial button facility is an old one in FSUIPC, and is described in the Advanced Users guide. 3. You can name your Lua file "ipcinit.lua" or "ipcready.lua" (the latter is safer usually), as documented in the part of the PDF you appear to be missing. 4. You can leave your file named as it is now, and create an "ipcready" or "ipcinit" file which simply loads all the Lua files you want running. That used to involve writing strings to offset 0x0D70, but the latest FSUIPC interim releases (4.505 and 3.905) make that easier by the addition of the new: ipc.macro() library function, which can load macros or Lua programs by name. Okay? Please do take another look, as I'm sure that section of the PDF can't have gone missing! :-( Regards Pete

here is a part of your landing.lua Yes, that is a specific example of using Events. That is, I think, the only one with such an example -- and rather the most complex one to look at to start with. There are much simpler ones. The use of Events to drive actions needs local functions defining, because the Event needs to know what function to call. In your case all you are trying to do is make a sequence of actions when your Lua program is run -- and it is run when you press the button which is assigned, in the Buttons assignments, to make it run. You have no need to go into complex arrangements with events and functions. No, there is no use of Events or local functions there. There's an example of a simple loop, that is all. Ah, okay. I hope you make good progress with it, now, then. Regards Pete

Okay, can you tell me how you arrived at the misconceptions and I'll try to improve the documentation. The two threads started today about the Lua facilities are actually the very first feedback I've received since adding them six months or more ago. If possible I'd like to try to make things clearer, but I'm rather at a loss to understand how you arrived at where you were. No questions are senseless -- and the only stupid questions are those which go unasked, so what exactly do you mean? I've been asking for feedback, it has been a long time coming though. And really but i do need folks to actually read what I provide first, else it isn't really feedback on what i provide, is it?. Sorry, I don't understand this part at all? Can you explain please? Regards Pete

Erwhat do you mean? You don't need to install anything other than FSUIPC -- it has a built-in Lua interpreter. Why are you referring to this 5.1.4 -- are you planning to program Lua into one of your own applications? If you are thinking of using the Lua plug-ins facilities in FSUIPC, you need nothing extra but a text editor to create the little Lua files. The only reason I provide a link to the Lua site is to show you where to get Lua language documentation from - or you can order the books from any bookshop or Amazon. Did you not even bother to look at the examples i supply and try them, in order to get the hang of it? Do I waste my time on these things? :-( If you put the lines into a local function, you need to add code to actually CALL that function. There is no need for the trrivial task you are trying to do. Delete the function line and the "end" at the end. You just want the statements in between! If you'd bothered to look at some of the simple examples supplied, you would have seen howe much easier it is thn you seem to be making it. It is NOT "programming" for simple tihngs, just a list of things you are asking FSUIPC to do! Regards Pete

Well, that line on its own does nothing. You need the function BrakeApplied for it to call on your stated event. Why "research the forum" when it is all written in the documents in the Lua package, or installed in your FS modules folder (for FSX)? Please look at the document which actually describes the FSUIPC Lua provisions, the one entitled "FSUIPC Lua Plug-Ins". It is explained in the section "What is provided in FSUIPC for Lua programming". The document isn't all that big, you should be able to find such information easily! Regards Pete