Pete Dowson

No. Writing it as one structure, in one Write, would work. But a lot of folks use languages which don't support structures very well, and Write things separately. I don't mean separate Process calls (which would work, but is slow and rather dangerous in case something else intervenes). If separate writes are used, since the requests are processed in order when received (via the Process call), then Parameters for Commands always need writing first. Writing it all as one structure averts any of that complication, but makes your code a little more complex, to work with structures. That's all. No. If you Clear the weather every time you'll get horrible flashing weather effects on screen. Ugh. If this is for FSX only, setting Global weather mode should be enough, but it is probably a good idea to CLEAR as well, to start off with a blank canvas, as it were. For FS9 it is more complex. Unless you CLEAR every time all FS9 weather develops into Localised weather, and then GLOB fails to change it. In FS9 there's no "GLOBAL" mode. The only sure way to control FS9 weather for continuing periods is to write all of the nearby Weather stations. If you aren't worried about FS9, it is easier. Just set GLOBAL mode -- added especially by Microsoft after our complaints about not being able to pre-determine weather properly for training purposes. Read area, of course. All the Read interaction is done in the Read area, all the Write interaction is done in the Write area. Both may be happening simultaneously. You may not even be the only program doing these things at the same time! Regards Pete

You want an abrupt change, just like that? won't that happen if you turn off all of the FSUIPC facilities and just set that into FS's weather menu? It was to prevent such unrealistic things that the visibility graduation facilities were added to FSUIPC. Well, yes, but it shouldn't be so abrupt. FSUIPC provides a transition. ErI don't understand any of the above. Sorry. The graduated visibility region operates from the top of the restricted visibility layer, eg 10,000 feet or wherever FS or you set it, gradually increasing it, linearly, to the upper visibility at the very top altitude. In other words you get three regions: 1. ground to level 1 (top of FS's restricted layer) == visibility x 2. level 1 to level 2 (usually very high, above max flight levels) == linear smoothing from x to y (so halfway it will be (x + y)/2). 3. above level 2 = FS's defined max according to current option settings. Not affected by FSUIPC. Bear in mind that the values computed in this way are the target values. If you also have smoothing enabled, then there may also be a delay according to the smoothing settings. This is the way it has worked for years, in FS2002 and FS2004 (unfortunately not in FSX though*). Please do also check the documentation. I'm sure it explains it there already better than I can here. Regards Pete * I couldn't find any way to directly control the visibility graphics in FSX, and SimConnect's weather control is rather unpredictable and arbitrary in this area, resulting in unpleasant effects when such things are tried.

Of course it is possible. I just explained how! Look: you said Now take a look at 59 and 78. If you put them next to each other it should be obvious what is wrong: 59=PA,4,C66153,0 78=CP(+A,5)A,4,C66154,0 FSUIPC sees button 4, so it obeys line 59. After all, what is stopping it? It also sees button 5 too and still button 4, so it also obeys 78. Therefore it does a "next sub view" and a "prev sub view". Result? No change in view -- they cancel each other!! Your other combinations are doing the same, it is just that they don't cancel each other so obviously. Example, Brake -- Parking Brake. The latter takes over from the former, but they both happen! If you only want one or the other to happen, you have to set the condition for that! FSUIPC cannot read your mind. Try this change: 59=CP(-A,5)A,4,C66153,0 78=CP(+A,5)A,4,C66154,0 Now do you see how the two are mutually exclusive? Instead of both actions occurring when button 5 and 4 are pressed, only one, the second one can happen, because the first only happens when button 5 is NOT pressed. If you don't tell FSUIPC that button 5 must not be pressed, there is nothing stopping both lines from activating! The same applies to some of your other settings. Pete

This is almost always a video driver problem. There are some hints which may help that I've seen recently, especially if you are using Vista: set your desktop Icon for FSX to "Disable desktop composition" and "Disable visual themes." That must surely be a timing or memory arrangement coincidence, because FSUIPC is doing nothing at all in regards to the actions you mention. in fact, unless it is being actively used by an add-on application, it really is dormant in any case, simply receiving stuff sent to it by SimConnect, none of which relate to switching between screen modes are changing focus. Possibly it is more to do with whatever is using FSUIPC? After all, its main function is a "window" into FS for other programs. What else is running? What is this hardware which actually requires FSUIPC? Perhaps you can carry out some process of elimination to see what is actually the cause? Regards Pete

Yes. "Next view" and "Prev view" cancel each other out! With combinations the action only takes place when the combination is true -- you get that right. But you forget that the button-alone actions are ALSO occurring. For button 4 without button 5 you have to have the condition "not button 5" -- that is what the "-" facility is for, opposite of "+". All button actions relevant for a button are execured, not just the one you want, but all those which are valid. you have to eliminate those you do not want as well as select those you do. You could find this out yourself using FSUIPC logging -- enable Button and Event logging and see what happens in the Log file! Regards Pete

Then so must AutoSaved flights, because they are using the EXACT same facility as you! I repeat, AUTOSAVE does NOT save flights -- FS itself saves flights. All AutoSave does is call the same facility that you do, on a timed basis. Pete

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