Pete Dowson

ASA's wind smoothing, or FSUIPC's? I'm not sure you should use both. Not FSUIPC no, it isn't really running then, but it doesn't smooth the wind setting it sees set when you exit menus, because you might have been in the menus to download new weather or manually change the weather. There's no way FSUIPC knows what you are doing in the menus. So, if you are using FSUIPC's wind smoothing, it doesn't smooth across Menu excursions. Effectively when you come back to flying, you get the weather you should have -- i.e. the target weather, not the weather en-route to the target at n knots per second. I expect that is what you are seeing? Regards Pete

There are at least two instructor station programs I know of, one for Project Magenta: http://www.projectmagenta.com/ and this one: http://secure.simmarket.com/luis-gordo-tion.phtml No, neither FSUIPC nor WideFS links multiple copies of FS. FSXs own multiplayer / multicrewing faxcilities do that, or you can try WidevieW, but I think that's more for multiple views and remote control. Regards Pete

Project Magenta has a chronometer in the GC package? Hmm. Interesting. I didn't know that -- where would I see it? I suspect you are a bit mixed up when you talk about "offsets 2999,62". There are no such things usable for anything like that. Offset hex 2999 is in the middle of the Hot Key table in FSUIPC. 62 is in the middle of the start-up flight name. Neither should be accessed directly using those addresses. Maybe you refer to FSUIPC control number 2999 with a parameter of 62? They are listed in the FSUIPC Advanced User's Guide, but I suspect my list is out of date. However, I do see 62 listed as the correct parameter to Set/Reset a Timer in the airbus GCthat might explain why I've not seen it as I use the Boeing set. Where do you get the idea that the numbers you refer to are anything to do with "offsets"? If that control works, and it is referring to the timer you want, yes. If it doesn't you'll need to ask PM support about it. None of those controls are dealt with by my software, they are just picked up by PM. You can assign the control to any Button or Keypress in FSUIPC, in the normal way -- have you looked at the FSUIPC user guide at all? Check the Buttons or Keys section, as you wish. The control is called PM GC controls, as it says. The 62 would be the parameter you have to enter, in the space marked "parameter". Pete

Program a button, key, or third hand to send the "Elevator trim set" control with a parameter of 0. Regards Pete

Sounds sensible. Removes a layer. No estimate, no. With FSUIPC the data is in FSUIPC's hands on each frame by virtue of direct access to FS's inner values. But then it is sitting there waiting for the Windows message from the application to actually request it. There's no way I can estimate when that will be within the frame cycle, even assuming the application can be regulating itself well enough to call on each frame rate cycle. With SimConnect, data data is requested once by the application and then supplied asynchronously, no new request needed, by SimConnect when it changes or at most on every frame. However, that is also either by messaging or by TCP/IP or Pipes and is not synchronised specifically with anything else in FSX. In my experience, in FSUIPC, I get the data some milliseconds later from SimConnect than I would getting it directly, but what is gained there is lost in forwarding it on, by request to the application. So it's swings and roundabouts. What you lose one way you pick up another. Who's to say which works out better? Yes, of course, and sometimes you might get only 5-10ms. But it varies enormously, even on the same link, presumably related to workload on each server it gets routed through and the number of users sharing the ADSL line with you and what they are doing. With so many folks now trying to stream movies and TV programs the response/ latency is varying enormously. At least it does here in the UK. Maybe, with two users on the same ISP, close to each other, it will be fine. Regards Pete

Yes. In the latest copy of the OFfsets Status list they appear as follows: 0C02 2 Aileron trim value/control: –16383 to +16383 [NEW!] Ok-SimC ?-SimC 0C04 2 Rudder trim value/control: –16383 to +16383 [NEW!] Ok-SimC ?-SimC It sounds like you are referring to an older list. Get the later one from the Updates announcement above. Regards Pete

Okay. Very silly mistake earlier this week. Very sorry. Please get version 4.439 now in the Updates section. I'm making a new full release later this coming week, to version 4.50. That'll have updated documentation and hopefully the SDK updated too. Still working on that. Thanks for the report. Regards Pete

Nor do I -- it was you that said it: "I found on the net the offset $8BAC for leveld, but on the official list of FSUIPC." That seemed to imply you found it declared for LevelD and in the FSUIPC list. (It isn't on my FSUIPC list, for sure, so I didn't understand). Ah. And not on the "official list for FSUIPC" as you said? Maybe you just made a typing error in your first message? Okay. The offset is part of his Level D 767 interface, according to my list. Okay! Thanks! :-) Pete

Well that KEY file most certainly was not yours, and never could have been. Sorry, I've no idea how you got it, but look inside it -- it is only a text file. It is obviously someone else's KEY file, not yours! If copies of that file are flying around the aether and installing themselves automatically into folks PCs I'd be amazed, but I will have to disable that chap's key in any case. Thanks & Regards Pete

Do you mean the FSUIPC.KEY file? There's no "Reg" file. The name and email are in the KEY file you copied -- so the question then is -- where did you get it from? Please ZIP it up and send it to me at petedowson@btconnect.com. Can you also please tell me the VERSION number of the "latest FSUIPC dll", as "Latest" really means nothing exact, depending where you are looking. Thanks. You will need to find your real registration details (in your account at SimMarket) and re-register correctly, because i will probably have to disable that one you've got a copy of from somewhere. Regards Pete

Hmm. That's very strange. I'll check it out here. I'm not aware of making any changes in that section, only in the Axes, Buttons and JoystickCalibration sections. Later ... Pete

Sorry, I am confused by that statement. You say you found it assigned in both places? Not for your own application, no, it is part of a block allocated to Nico Kaan for his "FSCONV" program, which I believe is his freeware interface for the Level D 767. You'd need to avoid using his program, or contact him for permission. It may vary, but as far as I know, in Boeings at least, any significant throttle lever movement disconnects the autothrottle. Regards Pete

I fixed some bugs in the "latest beta DLLs" yesterday. Unless you can tell me the actual version numbers of the DLLs you are referring to, I can't really use your comment at all I'm afraid. Please please ALWAYS give version numbers. There have been 4 updates this week alone for one thing or another! I also need specific examples of things you say aren't recording. Everything I change records fine. I need to be able to reproduce what you see, and i can't do that by guesswork. Sorry. Pete

I doubt if that's the problem, butsimilar to yours, excepting that FSASMLIB:IPC is spelled like FsasmLib:IPC (as in theIPCUser.h header), and of course the process ID and the try number will be different -- the try number changes as you retry in any case if you have the retry loop right. Pete

Really? Why do you think that? Looks okay to me. I assume it is in the correct character form for the Windows API you are calling with it (ASCII -- i.e. 8-bit character codes, not the 16bit codes? I can't tell as I don't know your programming language. I have no idea what that call "API(...)" does, but everything you are passing it seem to be strings of characters! Is that correct? I mean "HFFFFFFFFF" surely isn't the same as the number resulting from hexadecimal FFFFFFFF, is it? (the same as -1 in a 32-bit value). And those names PAGE_READWRITE and MAX_SIZE are defined as numbers too, via the windows.h C header file, using #define lines. Does your system look those up for you via the names? If so how does it distinguish between what you want to be a real string and what you want to be a number. It really makes no sense at all to me. Sorry. You need numbers for numerical parameters, strings (in ASCII) for string parameters. I've no idea how your compiler interprets what you have there. Regards Pete

In that case i don't understand the question about different versions of FSUIPC. You will both be using FSUIPC3, the same version. In fact, if you want support, you'll both be using current releases, not old ones -- not that the area in which you are querying will have ever changed. In that it has no asynchronous part, SimConnect, between it and the data it is grabbing from FS, yes, it should be a lot better. Well certainly if you want synchronisation you want both to be running at the same frame rate. There's no real possibility of true synchronisation otherwise. You should use the limiter at a value which both systems can always achieve. I don't think there's anything different FSUIPC could ever do for you. Really it then becomes totally dependent upon what the software that links you both is doing. And the network, of course. If you really are doing this over the internet rather than a local network then I'm surprised you see any smooth operation at all! Incidentally, with FSX the multiplayer facilities actually built into FS were extended to provide multi-crew operation. I've never used it but I've seen it demonstrated and it looked pretty good. Regards Pete

How are you assigning the throttle? The INI file you sent shows you are not using FSUIPC for it, and if you assign it to the normal throttles in FS itself you get no reverse thrust zone - FS itself treats -16384 as ildle and +16384 as max thrust. Only the old FS98-style FS axis controls provide reverse thrust for negative values, and you can't assign to those controls in FS itself. If you are now assigning or calibrating in FSUIPC, then the single throttle for all engines calibration on page 1 of the Joysticks tab (the page with the aileron and elevator and rudder too), then that provides no reverse either. The only reverse thrust throttle facility in on page 3, the 4-throttle page, and if you are using the latest update version of FSUIPC (from the Updates announcement above), you can opt for a "no reverse zone" operation there, too, via a checkbox. Otherwise you'd have to calibrate with the max reverse and idle zone coinciding. Regards Pete

If you mean between FS versions (FSX versus the rest) then there will be some difference, yes. On FS9 and before FSUIPC grabs the values on every frame directly from the innards of FS. On FSX (and ESP) it has to wait for SimConnect to supply it. In both cases they are operating at the frame rate, but in FSX's case it is SimConnect which gets the data direct from FS innards and then posts it to FSUIPC asynchronously. Usually the difference would be hidden by the fact that the program interfacing to FSUIPC to get the data is polling at intervals in any case. It would become just noticeable, I suppose, if the polling from the application arrived at a time which on FS9 is just after a frame update of the position but on FSX is just before the arrival of data from SimConnect. But I would have thought such millisecond differences could occur between two like systems (both FS9 for instance) as well -- and at most you should never be more than 1 frame out. At 10 fps that may just be noticeable, but at 20 or more it shouldn't be. Are the frame rates compatible in both? Which one is FSX and which FS9? It sounds simply like the FSX end is getting overloaded at times and SimConnect's messages to FSUIPC are piling up as a result. If your FSX is not up to SP2/Accel level it is likely to be a darn sight worse, as SimConnect is then using TCP/IP to send me the data. Ugh. With the SP2/Accel update, SimConnect got changed to use shared memory (via pipes). Regards Pete

There's nothing about a change of operating system that will stop you registering. You are either making a mistake in entering your name, address and keys (ALL parts must be 100% correct), or you are using Vista with FS2004 or before and haven't read the important note in the FSUIPC user documentation, right near the beginning, regarding registering under Vista. Regards Pete

Good. Glad that all worked for you. I'll be adding the ex-PFC offset information to the Offsets documentation when I get around to the next SDK update. Oh, please be sure to update from the version of FSUIPC to the very latest. Early this morning I fixed a serious bug which can corrupt your FSUIPC INI file! Regards Pete

Good! Thanks for confirming. Regards Pete

That's right! DLL.XML is missing on my Flight Sim account. I only ran Wilco installation after FSUIPC, but something must have corrupted it. Can I just copy it now? Yes, you can. Regards Pete

If you using a version of FSUIPC which you downloaded from the Updates announcement here, I strongly advise you to download the latest, posted early this morning. I found and fixed a recent (within the week) bug which can severely corrupt the INI file. Not the sort of corruption you obtained though -- that sort usually arises when folks load a file for viewing, then don't realise that perhaps a book or a cat sat on one of the keys, and then when they come to exit from the viewer it prompts them to save the changed document and they automatically do it! ;-) Regards Pete

I don't support PFC's own software page, sorry. ALL of my Fs related software is ALWAYS available, courtesy of Enrico Schiratti, on the http://www.schiratti.com/dowson page, as is surely made quite clear in all my documentation as well as in the Announcements above. However, currently that also only shows 4.30. I will need to give Enrico a nudge about that. Interim updates are always provided here, in the Forum, and you will certainly find 4.34 in the Updates Announcement here, as well as the latest versions of many other things. (That's what I meant when I said "but there's a better 4.438 in the Updates"). I am constantly surprised by how many visitors and posters here never look at the Announcements. I post loads of things in those which I feel folks should know. I don't know how else to do it, but it plainly doesn't work and I don't understand why. :-( Regards Pete

Not easily. It would be a lot of work, sorry. The whole of the way FSUIPC buttons and switches (and axis) system works is based on detecting CHANGES only. To avoid having to re-write a large amount of code which is only handling changes I'd need to invent a third state for each switch - neither on nor off -- so that either of the "real" states would immediately represent a change. There are two problems with that which would make it pretty horrible and a great deal of work to implement properly: 1. A three-state switch needs 2 bits instead of one. This means doubling the arrays used for switch states throughout, and changing all references to match. This would affect not only FSUIPC3 and FSUIPC4 but also my PFC drivers and other programs. The third "don't know" state would need to be restored on every new Flight load. The whole exercise would be very error prone (i.e. likely to cause bugs), and I really don't think it justified after over 10 years of it working as it does now. 2. There would have to be some clever interlock to prevent switches activating or changing things inside FS whilst it was still loading and therefore not ready to make the change requested. Mostly this does no harm on FSX but it can crash FS9, and before, because variables or procedures being referenced aren't yet loaded. I think such synchronisation problems could probably be resolved with a small Lua plug-in which deals with only the specific switches which may be of concern on your particular system. Otherwise I'm afraid you will need to resort to the same technique i have always used now for over 10 years -- operate every single toggle or latching switch back and forth as part of pre-flight cockpit preparation. At least when not loading one of my standard "cold and dark" flights. And I have a full 737NG cockpit, so you can imagine how many toggle switches that entails! 747 pilots are luckier -- at least pretty much all of their switches are push buttons, not toggles! ;-). Actualy, I think most of the newer airliners today are. But I like the 737! ;-) Regards Pete