Pete Dowson

Whether a value is positive or negative is all in the interpretation, not the value. In 16-bits, for example, a value 65535 looks identical to a value of -1, depending whether you treat it as signed or unsigned. In hexadecimal they both look like FFFF. If this is in a 16-bit (2-byte) word, then send 63536. It is the same. Calculate it as 65536 + (the negative value). In EPIC you would need to do 65535 - (your positive value, eg 2000) then add 1. The 1 difference is needed because 65536 cannot be accommodated in 16 bits. Regards Pete

You are correct much of the time in most of Western Europe, and even sea locations like the Canaries in many weather conditions, but I've flown all over the world and sharp horizons are also quite common, especially in the dry season or in central continental places where air moisture and pollution doesn't give that fuzzy indistinct edge. All I am saying is that it depends -- sharply delineated horizons, especially those featuring mountains -- are, in my opinion, just as realistic as fuzzy ones, and more so as you ascend (because you are looking through less moisture and pollution as you climb out of it). At very high altitudes the loss of horizon distinction in some directions (replced by a sort of glow) is more to do with sun glare and reflection/refraction effects than either pollution or moisture. A friend and occasional co-pilot of mine, also an ASv6 user, was lamenting recently because no matter what he did he couldn't get a sharp horizon, which he also thought he should see from altitude, at least much of the time. We fixed it (it was to do with visibility settings of course). I have had other questions on this too -- it was just odd to me, after those, to see someone asking the reverse! ;-) Regards, Pete

I need some information about the file. Send me an email (petedowson@btconnect.com) containing: 1. The EXE name 2. The "Product Name" 3. The "Company" Both the latter are from the Version Info -- right-click on the EXE in Explorer and select Properties-Version. If those fields aren't present it may not be possible to enable free access for it. Pete

That sounds like not so much a "lock up" as either a pause, or a zero sim-rate setting. Either that or it is the graphics section which is locked up, but I thought that would effectively freeze all FS access as I don't think it is all separately threaded -- FS2004 is *not* written to take advantage of multiple processors, which would be the case if such major portions were threads. That "goofy" file is to do with the anti-debugging and copy protection in FS2004. I shouldn't really advocate this, but I think you should try getting hold of the No-CD crack of FS9.EXE and see if that fixes your problem. I wouldn't be surprised if the anti-piracy checking is falling foul of something else in your system, like anti-virus checking or something. I have to use the No CD crack for versions of FS because there's no decent way of developing and debugging my programs with that anti-everything stuff running. Make sure you get the correct version -- there's one for FS9.0 and a different one for FS9.1. Regards Pete

There's something weird going on with your video driver then. I cannot make it disappear here. I use nVidia cards -- what video card are you using, and what drivers? It is most odd. AdvDisplay has been in use on many systems now for many years, with very few changes ever needed. This is not just with RC, though it has been the mainstay of RC's menu system since RC version 2 I think. Certainly all the way through Version 3. You shouldn't need to go to the Modules menu in any case. If you need to switch it on and off there's a Hot Key option for it in FSUIPC's HotKeys tab -- you can assign a keystroke then either use the keyboard, or program a Button to send that Keystroke. Regards, Pete

Switching views will temporarily lose the display in DOCKED mode, because the panel part is closed too, but the LOCKED mode merely re-displays over any part. I've never found a case where it doesn't work. I don't understand how it doesn't in your case. Whay mode are your two displays configured in? for FS you really need them as a single wide screen. You can't use ShowText over parts of FS. As I said, try that if your other monitor is not using any part of FS. In full screen mode, the FS windows will always prevail. That's what "full screen" means -- FS takes over the entire video system. Regards, Pete

Lightning, like clouds themselves, are placed randomly in the graphics and effects routines of FS. There's no way I know of getting precise data for either, other than the general weather settings for each nearby weather station. To see if there are any storms nearby you would need to read the cloud data for each nearby weather station, checking the cloud type for CB ("storm"). You'd need to search the FS weather station lists to determine valid nearby weather stations -- check the Weather folder in FS. FSUIPC does allow you to read weather at any weather station given its ICAO id, or, in fact, weather near any point given a latitude and longitude -- but the weather describes that for the locale, so a storm cloud listed may simply be within several miles of the station or point. Regards, Pete

Not the surface limits in FSUIPC. Use the graduated visibility option and set the upper altitude limit. If you want a foggy horizon (odd, most folks don't, at least not all the time!) just set the upper altitude limit to 20 miles or less (2000 units). Don't set the FS view distance to the minimum -- that will operate like a cut-off, and simply stop drawing at a certain distance. Maybe that's the effect you are seeing? You want that as high as possible without degrading your frame rate too much. Same with the cloud view distance. Regards, Pete

Yes. It really does sound as if FS is not relinquishing control of the processor very often. Not surprising with only an Athlon 2100+, I found such a machine struggled with FS2002 even, let alone FS2004 (I had one similar years ago, for FS2000). No, not at all. It is really looking like a horsepower issue. I really think you either need a much faster PC or a separate Networked PC to run RC (or any other separate programs) on. Regards Pete

That's an odd complaint -- most folks complain that it isn't often as sharp as it ought to be when at altitude! This is the first time anyone has complained the other way! ;-) This really isn't a lot to do with ASV6, it is merely a combination of things -- the visibility, which is usually much greater at altitude than on the ground, and the viewing distances you've set in FS's sliders. For the former there are visibility options in FSUIPC for limiting it and have it varying according to altitude, up to whatever altitude you like, then limited to a higher value. Look there -- but you'd need a user-registration to use FSUIPC options like that. Regards, Pete

Further to the details in my last message, you should note that, like IPC transfers direct with FSxIPC the blocks defining particular read, write or other operations are themselves blocked together in frames, up to 30kb in size (though limited by parameters in the INI normally). With IPC transfers these blocked requests do not have a header, but simply a zero DWORD terminator. In WideFS transfers yjrtr#s no terminator, but each frame (blocks of requests) has a header which contains the block size, a sumcheck and a sequence number or timestamp. The WideFS logs actually do not log the header in raw bytes but decode it and show the walues at the head of each frame decode. I thought you'd see that immediately if you were monitoring the actual TCP/IP data being transferred, but if not here is the frame header format: struct { ULONG ulSize; ULONG ulTime; WORD uSum; BYTE fUsed; } PREQHDR; Don't ask me what "fUsed" is -- this is a bit historical. I would need to delve deep into code to work that out. The others should be easy enough. The Sumcheck is a byte sumcheck of the data following the header which is of size ulSize. The ulTime values used to be a timestamp but now it is just a sequence counter, at least in the ->client direction (I've not checked the other way). Well, that's about it. You should be able to go a long way with all that. I can try answering specific questions if you get stuck. Regards, Pete

Why dream? You can do that easily already in FS Options-Controls-Assignments. You don't even need FSUIPC for such straight-forward assignments. Not at present, because the Gear is only controlled by switches not axes. But it will be possible in a forthcoming version of FSUIPC. I am implementing axis assignment in FSUIPC, with the possibility of sending controls from axes too, and all optionally aircraft-specific so that you can have different joystick assignments for different aircraft, as you can now with the button and key facilities. Regards, Pete

FSUIPC only has that message on initial loading -- it in't available to it and nor is the check re-run once the initialisation of FS in completed. It is done in the DLL loading routine (DLLmain) which is called by Windows when a DLL is first loaded. Therefore, if it is happening apparently DURING an FS session, FS must have thought it crashed and it is trying to reload. There's an option check mark in the error message it displays which can be turned off to prevent automatic restarts, but it sounds like something is obscuring the whole operation on your screen, or there's some problem with the video drivers. Try running in maximised Windowed mode instead of full screen mode (ALT+ENTER) until it occurs -- maybe you can see better what is going on. The only other possibility I just thought of is that whatever is going wrong is cauing incorrect code to be executed and somehow the remnants of the DLLmain part is being jumped into by whatever is going berserk, but i think this is so unlikely as to be discountable. No, never. Where did you get that impression? Ah .... so maybe if you could get a copy of 4.6 you could at least eliminate 4.7 or nail it that way? Regards Pete

The COM port number will change, so you'd need to tell PFC.DLL that -- editing it in the PFC.INI file is easiest. Nothing else will change. Regards, Pete

It works here but you normally need to use "Lock" not "Dock" -- the Docking facility is used to associate it with a panel part. If there's no part of FS on the second monitor, you might want to try using the ShowText utility, supplied in the AdvDisp package, instead. Just use the Hide Always option in AdvDisplay and set up ShowText as you wih. It has rather more display options than Advdisplay in any case. You could also make it run and close automatically using the FSUIPC facilities to run programs. Regards, Pete

I don't know if this will work, but try using the FSUIPC "offset" facilities to manipulate engine selection, instead of the keypresses E+1234. The engine selection set by E+1234 is a single Byte at offset 0888. In this byte, one bit each is used per engine. Engine 1 is bit 0 (value 1), Engine 2 is bit 1 (value 2), Engine 3 is bit 2 (value 4) and Engine 4 is bit 3 (value 8). So, for example, E+12 sets offset 0888 to "3". If you have two buttons you can use, the program one to select Engine 1 and the other to select Engine 2, but only on "Release". On "press" set NO engines. Do all this using the FSUIPC control "Offset Byte Set". The Offset parameter is x888 and the data parameter is x0 for no engines x1 for Engine 1 x2 for Engine 2 Then, press and keep pressing the selection button whilst reducing the mixture lever to zero, then release the button. That SHOULD prevent the non-zero value being written to the new engine mixture. I cannot test this here at present, so please let me know if it works. Regards, Pete

I'm a bit at a loss to understand what this may have to do with a problem of FSUIPC reporting multiple copies upon trying to load FS, unless you are saying that FS9 appears to "go down" whereas it is fact only disappears from the desk top yet remains in the Windows task list as a running process? I'm not sure why you ask here, but considering that FSNav is one of the top-selling add-ins for FS, so must be in use on many thousands of systems by now, surely the problem is known to the author? Have you reported it? Have you checked that support forum? Regards Pete

You can get USB serial port adapters for $20 or so. In fact they work better than real COM ports, so much so that I'd recommend using one for the PFC gear and leave the real COM port for the less arduous GPSout tasks. Pete

The requests basically follow the same format as the requests put directly to FSUIPC, as defined in the .h header files in the sources for the libraries in the C parts of the FSUIPC SDK. They used to be identical, in fact, but I decided that was a waste of space (Adam Szofran used whole DWORDs for things only needed a byte or word, for example). Also I extended the command set. The blocks are easy to decode once you realise the structure if the FS6IPC structure , or derived from it. The codes used at present are as follows: // IPC message types #define FS6IPC_READSTATEDATA_ID 1 #define FS6IPC_READSTATEDATA_ID_NEW 0xfe #define FS6IPC_READSTATEDATA_ID_SHORT 0x1001 #define FS6IPC_READSTATEDATA_ID_NEWSHORT 0x3001 #define FS6IPC_READSTATEDATA_ID_NEWNEWSHORT 0x7001 #define FS6IPC_READSTATEDATA_ID_COMP 3 #define FS6IPC_READSTATEDATA_ID_NEWCOMP 0xfc #define FS6IPC_WRITESTATEDATA_ID 2 #define FS6IPC_SPECIALREQUEST_ID 0xabac #define FSUIPC_COMPUTER_NAME_ID 0x1002 #define FSUIPC_EXTRA_DATA_ID 0xed Some structures new in WideFS compared to FSxIPC are: // read request structure typedef struct tagFSUIPC_SHORTREAD_HDR { union { DWORD dwOffset; // state table offset, high byte = ID BYTE bBytes[4]; } Id; WORD sBytes; // number of bytes of state data to read } FSUIPC_SHORTREAD_HDR; // write computer name structure typedef struct tagFSUIPC_COMPUTER_NAME_HDR { DWORD dwId; // FSUIPC_COMPUTER_NAME_ID DWORD nBytes; // number of bytes in name string following } FSUIPC_COMPUTER_NAME_HDR; There are probably others, but I'd have to ferret them out. They should be easy enough to follow given all this though. That's there already. Aren't you seeing it? The DebugAll logging includes pretty much everything, there are separate options. Pete

Hmmmif RC is actually running okay except for this apparent delay, could that delay be in the spoken response you are expecting rather than the action RC is taking? In other words, maybe there's a problem with the sound subsystem? Try shutting FS's sound off (Q) to see if that may be related. Maybe changing the sound acceleration in Windows may help (e.g. turning it off). I really have no experience of ever trying to run things on the same PC as FS except with hyperthreading PCs (P4 3.0 GHz or better), where there certainly is no problem. The symptoms you describe seem most odd, though, as you say somehow dependent on some common resolurce, as I'd expect setting RC at a higher priority than FS to cause some about of jerky behaviour in FS. Could it be a memory capacity problem? How much memory does your PC have? (What processor is it anyway? Achieving only 20 fps with all sliders low it sounds rather underpowered for FS2004). Regards, Pete

On the contrary, if the stutters are shorter when the transfer speed is higher, that indicates that the programming in PocketFMS is rather assuming no other processes are running when it is receiving data. It should be using overlapped I/O which allows the data to accumulate independently of program action instead of looping for each character without relinquishing control. If the stutter was due to graphics updates then they would be the same no matter what speed of transfer were used, as the update of the graphics would be independent of that. Regards, Pete

How odd. All that happens with the keystrokes is that they set a flag inside FSUIPC which is read by RC on its next scan. No, I am quite sure that is an incorrect interpretation of what you are seeing. The same will probably occur whenever you do something which takes the processor away from FS. Advdisplay is not at all involved in anything to do with keystrokes, it is merely a passive display window -- but right-clicking puts FS into a menu mode which stops a lot of its other activity. I think that something is really very very heavily using the processor (you ARE running RC on the same PC as FS I assume?). Maybe you have FS's settings turned up rather high for the power of the video card and main processor, and RC is not actually getting to run very often? Try limiting FS's frame rate (Options-Settings-Display-Hardware I think). Reduce it to something low to start with, like 15. If that helps, increase it until you get problems, then reduce it a little. This sort of thing is really quite important whjen trying to get things to share the processor well with FS, which otherwise wants to use it 100%. If you have a dual processor system, or one with Hyper Threading then it shouldn't be necessary. Regards Pete

Add parameters to FSUIPC.INI, as described in the Advanced User's documentation under the heading "Programs: facilities to load and run additional programs". Have a look, come back if you have any questions. There's a utility called RunOptions by Jose Oliveira also which may help -- see http://www.schiratti.com/dowson. Regards, Pete

No encryption, but a very simple compression is used -- replacing multiple copies of the same value by a count, with a special escape value. Don't remember what it is though. Maybe hex AA. You can use "Log=DebugAll" in WideClient to log almost everything and see the data as it has been received and how it expands. Should help. The logs can get pretty big quite fast, mind. Regards, Pete

Well, it is internally, yes, but most of what it does is automatic and doesn't worry you. Otherwiese it is only a collection of little, easier, things which you choose whether to use or not. No. When it is installed into FS it runs automatically. you can forget it is there. Everything described in the documentation. Before laying out good money, why not just download the FSUIPC.ZIP, and pull out the User documentation. Read through it and see if you really want to spend the money. Regards, Pete