Pete Dowson

Not knowing anything really about scenery design, I'm not sure what you could or want to do with it, I suppose that's up to the imagination. As far as actually communicating between them, all I know about are the few variables which you can access (read and write I assume) in scenery files which are mapped to FSUIPC offsets for aplications also to access. See the FSUIPC SDK for more details. (Get this from http://www.schiratti.com/dowson). Regards, Pete

Okay. I'll make a note and will probably get to look at it next week. I'm a bit tied up this weekend. Regards, Pete

Isn't this the sort of response parameter which can and should be attended to in the Aircraft's CFG file? It seems to be that this is the correct and proper place for it, not artificially "slackening the wire". I've had a quick look in the Bell CFG, and there's not much there (not to say it can't be added), but the Moments of Inertia are one area for experimentation. In most sophisitcated CFGs there are many Scalar parameters which control responsiveness -- I see in the Robinson one there are several in the [Helicopter] section. Haven't you tried to get the model to your liking first, before trying rather strange external means? I think it would be better, really. Having a delay in supplied values can be done. It is messy, and I think it would tend to emulate the same effect as being slowed to a very low frame rate in FS -- i.e. you'd overcontrol. I always overcontrol the helos in any case, you must be a top notch pilot if you need it harder than it is already at full realism! Let me know, either way. I can have a look. But even if I did it I'd probably relegate it to an INI file parameter only -- it's getting far too crowded in the options and User Interfaces are not my forte as you can see! Regards, Pete

Actually, I don't like that for several reasons: 1. It cannot be named a DLL, or else must go elsewhere than in the FS Modules folder 2. It means more packaging for the software author and more to install / uninstall for the user 3. It is actually a lot more work for me to produce a new DLL in any case. 4. It would be yet another module for me to maintain and support. 5. The code is so small (miniscule), it would fit into FSUIPC without even noticing. Additionally, if it forces more folks to update to the latest supported version of FSUIPC I like it better. A lot of my support time is wasted trying to help folks using older versions before I find out they are! ;-) Okay, Regards, Pete

Pelle has confirmed that he knows no way to bind Delphi to C/C++ LIB files. He does, however, specifically say that should be no problem linking to DLLs. He says "there shouldn’t be any problem using functions from other DLL’s from within a Delphi program/DLL. I admit I haven’t done much programming using DLL’s (I normally place all my code in the EXE, making it easier to “distribute” the application), however I don’t think Delphi will have any issues with DLL’s that are not called DLL (for instance formally ActiveX are DLL’s with the extension OCX and these can be used in Delphi without any problem)." Okay. All you should need is the equivalent of LoadLibrary() and GetProcAddress(). These allow you to link at run time, without a disastrous failure (FS crash) should the DLL not be available or not have the procs you need exported. Here's an example in C (this is how it would be if I build the library into FSUIPC.DLL):: HMODULE hInstFSUIPC; BOOL (WINAPI *pFSUIPC_Open2)(DWORD, DWORD *, BYTE *, DWORD) = 0; BOOL (WINAPI *pFSUIPC_Process)(DWORD *) = 0; BOOL (WINAPI *pFSUIPC_Read)(DWORD, DWORD, void *, DWORD *) = 0; BOOL (WINAPI *pFSUIPC_Write)(DWORD, DWORD, void *, DWORD *) = 0; BOOL (WINAPI *pFSUIPC_Close)(void) = 0; ... hInstFSUIPC = LoadLibrary("FSUIPC.DLL"); (DWORD) pFSUIPC_Open2 = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Open2"); (DWORD) pFSUIPC_Process = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Process"); (DWORD) pFSUIPC_Read = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Read"); (DWORD) pFSUIPC_Write = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Write"); (DWORD) pFSUIPC_Close = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Close"); Then you should check that all five of these results are non-zero. This confirms that you have the addresses of the routines you need. At the end of the program use FreeLibrary(hInstFSUIPC); When you want to actually use any of these FSUIPC routines, you call them via the pointers. For example, again, in C: (*pFSUIPC_Close)(); The * dereferences the pointer so the call actually does go to the address contained in the variable called pFSUIPC_Close. I am sending this to Pelle too, in case you need help understanding how to do this is Delphi. It would be much easier to link to the DLL unconditionally, as you would to you own DLLs or Windows, but then you crash FS if the wrong version of FSUIPC is there, or no FSUIPC is there at all. You can check these things easily with the above code. Let me know when you decide what to do. I don't think I would have any problem adding these exports to FSUIPC, but of course I'd need to check that first, and also make sure there was no adverse affect on FS itself. I don't think it checks for other exports, but you never know! ;-) Regards, Pete

I have C source provided with SDK Ah, yes, so you do. I forgot that I provided everything for that too. Well, of course most if not all of Windows itself is written in C or C++ and all the APIs your program is using come from Windows DLLs like USER32.DLL, GDI32.DLL, KERNEL32.DLL etc. I wrote a PrivateMessage same day you told me about him, but no answers yet...I cannot find his email...could you provide it to me via PM or email (escape@cg.yu) so I can contact him... I've written to him already and asked him to look at this thread. He is pursuing investigations into what can be done at present, like you. ;-) Regards Pete

That would certainly be the best way, if it is possible. That is a little more problematic. If the DLL resides in the FS Modules folder it will have to be named other than a DLL -- I know C programs can link to any DLL even by a different name, but can Delphi? I think, if it is resolved this way then you might need to place the C DLL you are using into a separate folder of your own creation, and explicitly point your code at it at run time. There are two further alternatives which could be considered: 1. I could supply the C source for the Module User's library, for conversion to Delphi, and thence presumably building into your module in place of whatever you have now. Most of the code is similar, it is mainly the "Process" call which is different, abd of course the Open2 call in that you provide the memory, whereas for an external program the memory is a "memory-mapped file" opened with Windows. There are two small problems with this approach -- the first is finding someone who knows both C and Delphi to do the work, and the second is that the calling sequence into FSUIPC, in the Process routine, does involve a very small amount of Assembly Code which is designed to provide essential information in the call. I don't know if what it needs to do is possible in Delphi. 2. I could have a look to see if I can (or should) build the interface C procedures (Open2, Read, Write, Process and Close) into FSUIPC.DLL as exports which you can link to directly from your DLL. In other words, rather than attempt to make a separate DLL with the ensuing problems I describe above, expand FSUIPC itself to BE that DLL. I don't mind doing this last change, though I am only prepared to do it if it is indeed possible for Delphi to actually link to and use such procedures. I'm afraid my knowledge of Delphi is so poor I do not know. Perhaps you could investigate this and advise? There is another problem arising with this last alternative in any case -- obviously I have to find time to build in the code (possibly within a week or so, but I'll not know till Monday), and you would need to stipulate to your Module users that they must have version x of FSUIPC or later. Let me know your thoughts and we'll proceed from there. Did you contact Pelle, by the way? Regards, Pete

It's the commercially built one, by PFC, using my software and Project Magenta. I'm adding other bits too, but the hardware is almost all PFC and is an ongoing development. See details of their 737NG cockpit at http://www.flypfc.com, though the illustrations there are becoming quite a bit out of date I think. There are still plenty of things to do in it but for hardware I am in PFC's hands -- and I suppose they in mine for much of the software needs. Well, I did try for several years to make my own cockpit, way back in FS4-FS5-FSW95 days. Yes, I was using EPIC (two ISA EPIC cards and loads of attached expansions). I also had some FlightLink stuff which I "butchered" and re-programmed for use in it. But, whilst I could manage electrical wiring, and some electronics, I was and still am absolutely hopeless with other practical things like metalwork, woodwork, painting and so on. Nothing I did ever really looked anything much more than a ramshackle collection of computers and other boxes. So I gave up with the practical building side and concentrated only on software. ;-) Thank you for your offer! We'll see how things go in the long term. I am 63 this year and would like to see myself gradually easing out of such heavy commitments in a few years time. Don't worry though, I have ideas on this and I have high hopes for the future. ;-) Regards Pete

If you were running with IPX/SPX protocol (i.e. had "UseTCPIP=No" in the INI file of the Client), then, yes, the ServerNode is unique to the specific hardware network hardware on the Server. It would, of course, also matter if you had given the ServerName or ServerIPaddr in the INI, for TCP/IP protocol. This is not needed with WideFS 6.5x provided everything is running WinXP, because it can find out for itself. WideServer does try to send out the ServerNode data, for IPX/SPX clients, but I have no way at present of determining the correct one on WinXP -- there always seems to be several. That part was actually better on Win98. Regards Pete

Strange. The ServerNode is only needed with IPX/SPX protocol. By default WideFS would use TCP/IP. Regards Pete

Wow! I wonder what that is doing? blocking messages is one thing, but changing them? That's very naughty! The sumchecking I'm doing is only of the data parts of whatever protocol you are using. Possibly if you switched to IPX/SPX it would get through unmolested? Certainly I am not using "RAW" mode on the connections and have no access to any of the TCP/IP red tape which, possibly, they may legitimately tamper with! Thanks for letting me know. Regards Pete

Yes, that's fine. but then you said: A software emulator won't have a wire connecting it to your COM1 like your real GPS, which is why expecting it to see data pouring out of COM1 was a little, how should I say? Optimistic? ;-) No documents? no support either? Seems odd providing an emulator that cannot be used to emulate the real thing excpt by guesswork? Sorry, I guess you need help from Lowrance. Or do as the original successful poster did and use a real wire and try sending the GPS stuff to each of your real ports in turn. As I said, the most likely default it uses is COM1 -- though that often used to be taken up by a Mouse, so COM2 is another possibility. You cannot make the virtual port use real ports. I suppose you could try to remove the real ports in the BIOS of your PC and then see if you can make the virtual port program use the COM1 and COM2 addresses. Regards, Pete

What did you have on COM1 though? Sending the data OUT of COM1 will accomplish nothing at all unless there's a wire from it leading to something which can receive it. You can't just set up one half of any communications -- it takes a Receiver as well as a Transmitter, and of course a piece of wire for "real" serial ports!! I would seriously doubt that the emulator would be pre-programmed to look for input on COM12! I suspect that, if it has a default setting at all, it would be COM1. I suggest you look to set the COM port on the emulator. There's no alternative. As I said already, unless you can tell it which COM port to look at you cannot possibly use it. Why not see if it has any menus or options, or even documentation? Pete

That's what someone said, check back a few messages. You need WideFS as well. Follow the instructions. It must do otherwise it wouldn't have worked with GPSout. Please review the messages. If it can't I can't see how you can use it. Look at the program, I don't have it. Pete

The FSUIPC interface provided by WideClient is identical to the one provided by FSUIPC directly. That's the whole point. So something else is wrong. Can you try again, then close FS and WideClient down, and show me the FSUIPC and WideServer Log files from the FS Modules folder, and the WideClient LOG file from the Client. If they are large, Zip them up and send them to petedowson@btconnect.com. Regards, Pete

Which one is that? This only says "Post error"? What is that? Pete

If they have not bothered to provide keyboard controls for these switches, only mouse, then the only way I know of would be to operate the on-screen switches using something like Luciano Napolitano's Key2Mouse program. Regards, Pete

When you download the current supported FSUIPC from the site I gave you, you'll see a link for the registration. If not, it's in the first few pages of the documentation. If you don't see that either, check the Announcements here. There's one entitled "PAYING FOR FSUIPCthe Why and How". Please do keep an eye on the announcements here in any case. They are designed to help you. Regards Pete

Really? And it's in the shops is it? I must be living in a bomb shelter, I really didn't know. Most of what I've read merely advises to stay clear for now, even wait for Vista. Maybe I should get out more!? :-) Regards, Pete

No, FSNav does not use FSUIPC. In any case almost all payware add-ons, and most freeware add-ons, which use FSUIPC incorporate their own access codes which grants them access automatically. This doesn't mean your program has access. Yes, it seems so. Developers normally (100% so far) purchase a user access key for FSUIPC. This enables them to write programs, use debuggers, and so on, with FSUIPC. If you like, the payment sort of helps justify the programming support I provide (which can be extensive for languages I understand) and the upkeep of the SDK. Freeware programs can be provided with an application access key on request, but by that time they are usually mostly developed. Before that, most debugging environments wouldn't work with an application access key in any case because they'd actually be running as a different process. If you haven't got a valid access key, and haven't registered FSUIPC as a User, the initial connection to FSUIPC still works, but the data you get will not be valid, other than things like the FS and FSUIPC versions. This connection stage has to happen, as the automatic registration from your program consists of writing a Key to offset 8001 AFTER connection, but before anything else is done. If you check the FSUIPC log file you should see this. You can even (without paying!) enable IPC read and write logging in FSUIPC's options so you can see EXACTLY what transpired. I'm rather surprised you haven't actually been prompted by a message box saying there's an access error. Maybe you are trying to use an invalid user key? Please look again at the FSUIPC SDK, and in particular find the document therein on Access Registration. Regards, Pete

You are using a 64-bit operating system? This will have all new drivers for all the bits and pieces in your system, presumably mostly in Beta? Are you a Beta tester for Microsoft, or do you just like living dangerously? Really, that would be my main concern here. Nothing of mine has been tested on WinXP 64 in any case, so if its 32-bit support is iffy then that could generate problems. and, those drivers, they must all be version 1's or earlier, or Betas, surely? Isn't 1Gb RAM rather low for WinXP 64 Pro, with FS and so on? I don't really know, but I'd recommend 1Gb to anyone using FS on a WinXP 32 bit system, and MS always grow their systems bigger and hungrier, never smaller and leaner. The WideClient log shows nothing wrong, by the way. Regards, Pete

No, the airspeed has been provided in the same place since FSUIPC version 1.00, and is the same in FS98, FS2000, CFS1, FS2002, CFS2 and FS2004. However, I cannot possibly support a version which is so old! So, first please go to http://www.schiratti.com/dowson and download the currently supported version. The one you have doesn't even work with the current version of FS2004, released 18 months ago! Second, did you purchase an FSUIPC access key? Regards, Pete

Transparent is like clear glass, translucent is like cloudy glass. Pete

Does the PMDG aircraft not use the FS light operation controls? Did you try those in the Buttons FS controls drop down? You'll find controls for: * Landing lights * Panel lights * Toggle beacon lights * Toggle cabin lights * Toggle logo lights * Toggle nav lights * Toggle recognition lights * Toggle taxi lights * Toggle wing lights If these work, you can assign them to your T8 easily in FSUIPC's Buttons page. Unfortunately, the "Toggle" type controls would need synchronising with your switch positions when you start -- the others have On and Off variants so you can program them to be always in sync. In fact, using FSUIPC "Offset" controls you can implement specific on/off actions for all of these, but it is a little more complicated. I can explain more if you need me to, after you check whether these controls actually work. If they do not work, then it means PMDG have "done their own thing". Your only option is then to look and see if they have provided a way of having keyboard short-cuts for the switches. I think they do that for many things. If so, then you can assign suitable keypress combinations and program your T8 switches through FSUIPC's Buttons section, but using the left-hand side, to program the correct key presses. The other thing to look for is whether GoFlight have themselves published an interface module to work the PMDG aircraft directly. Regards, Pete

Attached. Oh, one of the problems, when the window is transparent, is that right-clicking on it to get the menu and change options is almost impossible -- the transparency means the mouse is really clicking the window below! the same seems to apply to the FS windows too, so it isn't just me. I found that if you have thick enough font characters you can, with care, right-click on one of then (just!) and get the menu, but it can take many tries! As I said, it also seems to swap between transparent and translucent all by itself, on occasion, when anything else is changed. I couldn't find out why, and I'm afraid I lost interest when I saw what it was like in full screen mode! :-( Regards, Pete Advdisp2151.zip