Pete Dowson

Why didn't you report it with version 4.20 then? How would you expect anything to change just by waiting? It looks like the signature on the program is not checking out correctly. Please read the User Guide section entitled Next … running FSX. But read this first: first. The message I would have thought you'd be getting is shown there, the one saying "The publisher could not be verified ...", but yours is a similar sort of error. I thought the one you are getting only occurred on completely unsigned code. There are two things I'd ask you to do. First, find the Install log, which should be in the FSX Modules folder. It is an ordinary text file. Paste it into a message here. Next, in Explorer, locate FSUIPC4.DLL in the FSX Modules folder, right-click on it, select Properties. There should be a tab called "Digital Signatures". If there isn't you have a severely corrupted version. Download a fresh copy and try again. If there is such a tab, click it and check the signature is okay. You'll need to select "Peter L. Dowson" then press "Details", and it should then say "Digital Signature Information. This digital signature is OK.". If it doesn't, then one possibility is that you've actually rejected my software before when being asked, and my name as a publisher is now catalogued in your system as being untrustworthy. You can fix that in Internet Explorer. Go to Tools–Internet Options–Content–Publishers–Untrusted Publishers, select the Peter L. Dowson entry and Remove it. If it doesn't help, then either you have some lesser corruption in the file (even a single bit wrong will do this), or the signature checking mechanisms in your PC aren't working. Maybe you have some essential Windows services stopped (Cryptographic is one such), or the GlobalSign certificate is missing. There's a Globalfix file for that, but if this is the problem it will be the first I've heard of in a system capable of running FSX. Regards Pete

FSUIPC3 uses the original Windows joystick interface which supports up to 6 axes, which use to be called X Y Z R U V. It also supports 32 buttons and 1 POV ("Point of View") hat. FS itself used the same interface until FS2002, when it changed to DirectInput. DirectInput allows up to 8 axes, 64 buttons and 2 POVs. Changing FSUIPC3 was not feasible without a gigantic re-write, and at the time FS changed to DirectInput it was not worthwhile because few if any devices exceeded the facilities in the Windows interface. Since I had to re-write FSUIPC completely for FSX, I did change over the Axis assignments part of FSUIPC4 to use DirectInput, so that now does support 8 axes and 2 POVs (but only 32 buttons still, as that part was a whole lot of more re-design work). It sounds like your un-detected axis is one of those not seen by the Windows interface at all, I'm afraid. You should be okay with FSX though. If you'd like to check this more directly, I attach "Joyview" a little program originally from Thrustmaster, which allows you to see what is going on with any joystick -- but only through the Windows interface, not DirectInput. Regards Pete joyview.zip

Why would you think there's an "offset" for every FS control event? I've no idea what those do or if they actually do anything at all. Do they do anything? If so, what? Are they related to the AP "attitude hold" option (offset 07D8) which I've never seen work, or actually do anything? If you know about these things please do tell me. I see in FSX, via SimConnect, I can get hold of a value called AUTOPILOT PITCH HOLD REF, so if you like I can put it on my list for adding in the next update to FSUIPC4. Seems to be in Radians, so it would probably have to be a floating point value. Not sure how INCs and DECs work on a continuous value like that -- we'd need to determine the increment, in radians. I've taken a look to see if I have anything related to this in FS9, and it looks like I could fish this out from SIM1.DLL as well -- at least for 9.1. It looks like it may have moved since 9.0. So, if it does actually do anything useful, please describe it to me and I'll look at adding it into both FSUIPC3 and 4 in due course. These things only get added as folks ask for them, but in order to add them to my documents I need to understand a little about them. Okay? Meanwhile, for all and any FS controls you can send them to FS from an FSUIPC client program via offset 3110. Regards Pete

The thing called loosely "TCP/IP" is not one protocol,. There are at least three protocols in there. The two dealing with sequenced packets are TCP and UDP. TCP is a "connected" protocol whilst UDP is called "connectionless". The differences program-wise a quite minor. If you've looked at the WinSock documentation you've seen details of both. TCP is heavily checked and sequenced as it is designed for transmitting data all over the world. It has layers of complicated red tape for navigation and error checking. All that is good for reliable world-wide communication but an big overhead for a reliable short piece of wire to a PC next to you. UDP does the same job but without checks and retries. It also doesn't guarantee the correct order of arrival -- but that isn't relevant if you only have one route between the PCs concerned. Only 5 fps? Goodness me! No wonder it is jerky! You try flying on FS with 5 fps. Ugh. You should be running it at the same frame rate as FS if possible. You may need to limit FS (both copies). So, set the frame rate limiters to, say, 20, then use 50 mSecs as your interval. There's no point in going faster than the FS frame rate because the data your program is receiving won't be updated quickly enough. No. WideServer runs in the Server. You'd have to have WideClient running alongside FS on the Client. You discard the prgram you wrote for the Server end and instead amend your client program to give it TWO FSUIPC interfaces: one to the FSUIPC inside FS (as now), and the other to the same interface in Wideclient. You read from WideClient and write to FS. To do this you cannot use the FSUIPC library itself. You will need to use the source code I supply instead, and modify it to use the different ClassName for that WideClient and, obviously, a different set of FSUIPC_... () calls. Alternatively you can add another parameter to the calls to identify which interface to use. Each one will need its own memory mapped file (part of the Open() actions. But this is not trivial work. Why don't you try to get your program working first? Do without that "slide" stuff, have only one FSUIPC_Process call per cycle, and try to equalise FS frame rates and your cycles, save 20 fps and50 mSecs. Regards Pete

You have to revise your program, the one controlling the client aircraft (copilot?) to obtain the data from that WideClient instead of via your TCP/IP connection. That's all. WideServer sends to Wideclient whatever WideClient wants. The same as what you are doing, except that now WideFS is doing the transfer between PCs for you. Pete

Nevertheless, I'll look to see how easy it is to add a forceful "KILL" option to WideClient. Regards Pete

There's no place I know of supplying old versions. I don't support them so there is no point. The current version is 4.25. Regards Pete

Oh, I see. This is interpolation, to get around some delay or lack of good frame rates over the Network. You did your own TCP/IP code, didn't you? Are you using TCP or UDP? UDP is faster -- less checking, no repeats on error and so on. What sort of update rate are you achieving from the Server to the Client? You should be able to maintain the visual frame rate FS is achieving. If you can set the frame rate limiter in both Server and Client to, say, 25 or 30, so they are both updating at the same rate, and you send new positions at that rate, you should get no jerkiness (what you call "slide", as I now understand it). Certainly WideFS can achieve this on every system I've seen. BTW, did you not think of using WideFS and only doing the software for the client end? You should be able to run WideClient next to FS if you change the Window class name it uses so that it doesn't clash with FS's "FS98MAIN". There's a parameter for that you can add to the INI file -- it is documented. Then you have to interface to it using the new Class name instead of either FS98MAIN or UIPCMAIN (the two names built into the FSUIPC SDK library code I provide -- you can see this in the source, also provided). Regards Pete

All that WideClient does (can do, really) is send a "WM_CLOSE" message to the top-level Window associated with that process. i.e. SIMboards.EXE. That's normally exactly the same as you clicking the X close button on the window's title bar. Does the program close down properly if you do that manually? You might need to ask the folks who make that program what is going on. I don't know it all all I'm afraid. BTW Do try the very latest WideClient version from the Other Downloads announcement above, just in case. I did make some changes to cope with programs needing to vbe closed before computer shutdown. I don't see how that can help in this case, because effectively all that means is sending them a WM_CLOSE a few seconds before asking Windows to shutdown the system. If there's no alternative I might be able to offer a "Terminate Forcibly" option in WideClient -- that's pretty drastic, not allowing any tidy up action in the target program. It's the same as going into the Windows Task Manager, finding the process, and killing it there. Regards Pete

I thought I told you right at the beginning that it was payware, not free? is this the Normal ou Slowest rate? It's a zero (i.e. stopped, no simulation, nothing), rate. I mentioned this before. You've forgotten already? I said "Sim Rate 0 is by writing 0 to the Sim Rate offset.". Sounds more like you reduced the FS frame rate so much nothing much was happening. I'm afraid that might be the case with zero sim rate -- that effectively stops the FS simulation altogether. The client copy of FS just becomes a dummy worked by the server. Isn't that what you want? I think that's what WidevieW would do too. Well, a little -- that's why the LLAPBH ones are contiguous. They are a struct inside FS. But the main thing is to do it in one Process call. The loop inside FSUIPC is pretty tight anyway. cuz the pos_slide uses Process too, so, i put it after the engines/position dont had refresh, to see is solve, but not x) Yes, well, I don't understand all that "position slide" stuff. Sorry. Not got my head around that at all. Regards Pete

If you really can reproduce a problem, with no additional add-ons, just with a default aircraft, and using FSUIPC 4.25, can you provide the saved FLT + WX files so I can try it please. And your FSUIPC4.INI file so I have the same settings. Tell me exactly what to do and what to check. Okay? (Zip them and send to petedowson@btconnect.com) Pete

Serial? WidevieW? Not last time I looked. TCP/IP, and I think IPX/SPX was added. Or was it the other way round? There's no way it uses a seriasl port, it's a Netwrok program. Yes, a lot of people have said that. It's the FS sim engine taking over. Try a sim rate of zero. Overload? Sorry, don't know what that means. If the processor is too heavily loaded, your FS frame rate will suffer, but things don't just stop working. I really don't want to examine code. I've never tried to do what you are trying to do. If it works except with the LevelD you might need to find out what the LevelD is doing differently. Erdid you find you needed to write to those 3xxx offsets too? Normally the whole position and attitude is set directly via the 05xx values, they represent the structure used inside FS, LLAPBH (Lat Long Alt Pitch Bank Heading). And why separate Process calls? You need to write everything you need to write in one Process per iteration. Regards Pete

It isn't FSUIPC doing it. I've got any number of ways of changing the QNH here, and they all work. You can enable QNH smoothing in FSUIPC, but that won't stop it changing. Incidentally, 4.241 isn't supported now that 4.25 is released. Pete

Wind smoothing doesn't touch the QNH. Pete

Yes. didn't you even refer to the documentation I supply in the SDK, describing what units the altitude at 0570 are in? 566534471680 is the altitude in metres * 65536 * 65536 -- because the top 32 bits represent the integer part and the lower 32-bits represent the FRACTION! That "big number" is actually 131.9065856934 metres. There are 3.28084 feet per metre. You work it out. Why didn't you look at the examples in the SDK in the first place? It would be much more efficient, much less time-wasting for both of us if you actually try to use the resources already provided for you! Even just looking at what FSInterrogate was doing (it even shows the raw and computed values and the formula used) would have shown you. Please, next time, just look at what is already there in front of you! :-( Pete

Well, if such an experienced C# / PHP prograsmmer cannot see what is wrong here, I'm afraid I have no chance as I know so little about it. Surely there's an example in the C# part of the SDK. Did you look at all? Do I have to look for you? ... ... Well, what do you know?! In the "C Sharp" ZIP in the SDK there's a file called "TestConsoleForm.cs", and what do think I found starting at line 497? Code to read and compute the Latitude and Longitude! I'm sure it can't be such a big step for you to convert that to getting and computing the altitude. All three values are 64-bit (long long) values. Regards Pete

Yes, it should do -- all versions. I originally did the smoothing developments on Acceleration, thinking foolishly that they would then work fine on SP2 -- but I was wrong. SP2's simulation engine turned out to be more like SP1's, and very different from Acceleration, even though it had a later build number! So, I had to spend time to work out how to do it on SP2 separately. Having done that it was easy to apply it not only to SP1 but also to the original RTM code, all very similar. To check that I've actually succeeded, look at the start of the FSUIPC4.LOG file after starting FSX with 4.25 installed. It should say that Wind Smoothing is fully installed -- before it would have only been partial. Regards Pete

Ok. Let me know afterwards. I can set up a test here too, though it would really only be to confirm an error report to PM. The new CDU is in the "intermediate versions" list, not the main list, but the latter does say, in small print, that it fixes a "major bug". Regards Pete

Yes (I think it says that in the chat I supplied to Thomas), though that doesn't seem possible with the Engravity one, though. Sorry. Regards Pete

We never did get to the bottom of your problem in Registering FSUIPC4, but please now download version 4.25, from the FSX Downloads Announcement above. The Installer is now responsible for handling the registration, so hopefully it will have the necessary privileges. It certainly managed to do everything else correctly on your Vista system. Let me know please. Regards Pete

And did you insert the path to FSX where it says to? Check that you got it right. SimConnect won't give any log at all if it doesn't manage to create the file, and if the file path provided is invalid, it cannot. If you got the file correct SimConnect cannot fail to create a log file, as many folks before you can attest to. Regards Pete

Well, if your dwResult is where the stuff you are reading is supposed to end up, that will certainly give strange results. However, are you sure "dwResult" is not simply an error code, returned when the function fails for some reason? At least, it is certainly like that in the C/C++ version of the interface. As I said, I don't know C# at all. There is no "token" or "FSUIPC_Get" in the C/C++ interface, so I assume that's something to get around the problems with pointers in a Managed environment. Are you sure the result isn't returned somewhere else than the dwResult you are using? Well, that would certainly happen if my suppositions above are correct. If I were you I'd either change to C or C++, or see if you can find some examples or documentation for C#. Isn't there an example in the FSUIPC SDK? I'm sure someone contributed something on that. There's also an improved C# interface in the client DLL offered in the sticky entitled "FSUIPC Client DLL for .NET - Release Version 1.3", above. Why don't you look at that? Regards Pete

The default value is what I think is the most reasonable, smoothing the wind enough to avoid any problems, but not stopping it changing so much that it is never what it should be. This may be a symptom of exactly the faults in FSX which folks were complaining about and for which I added the smoothing. Sorry, I don't know. but generally, in my experience and at least in Europe, the problems mostly occur with disparate weather at nearby stations, OR when you are flying at a level close to the boundary with a very different wind layer. If all of your weather stations on all sides, and all of the levels, above and below, show similar winds, and you are getting opposites, I'm afraid I've no idea what is happening. It is something no one else has reported at all. I suggest you ask HiFi Simulations. Maybe you have some ASX settings wrong. Regards Pete

Sorry Thomas, but that's the altimeter reading, not necessarily the aircraft altitude. Regards Pete

Okay. I'm a bit lost with C#. Is that "dwResult" a 64-bit integer? You are correctly reading 8 bytes (which is 64 bits), but it looks like you maybe are only using the first 32-bits, which would be the fraction of a metre in 1/(65536*65536) ths. Also, in the line double acalt = dwResult/ (65536 / 65536); Does your compiler convert the "dResult" to floating point first, before the division? It would need to, but it doesn't seem likely. Finally, you are dividing by 65536 / 65536 which even I can compute in my head as being equal to 1. Why divide by 1? Three possible errors already, in not as many lines? I don't know C# I'm afraid. Maybe it is all good code, but it doesn't look like it! Why not try using FSInterrogate to see what you are really supposed to get? Regards Pete