Pete Dowson

Are you checking that you enter both the program name (without the .exe) and the Key, all exactly as listed? Check that your 1's are 1's, I's are I's, O's are O's and 0's are 0's -- those are the most common mis-entries. In the FS Modules folder, with FSUIPC.DLL, FSUIPC.INI and FSUIPC.KEY. That's the sum total of everything FSUIPC is and does. Regards, Pete

No, that is very unlikely -- if FSUIPC thought the version was something different it would go wrong in quite nasty ways. The most likely problem is that the registration key is not valid -- it may be a counterfeit. I could tell from an FSUIPC Log file, but FS must be closed before saving it. Get the user to ZIP the log file and his FSUIPC.KEY file and send it to me at petedowson@btconnect.com and I'll check it out. Regards, Pete

Version 3.41 is long outdated and unsupported. Current version is 3.44 and 3.45 will be released this weekend. Please always update before seeking support as I only support the supported versions listed in the supported versions list above. Thank you. Most folks always complained that the turbulence in FS was unrealistically violent. FSUIPC's random addition tries to keep the distribution of different levels normal -- so mostly there will be a little or none, and only very rarely will there be a lot. It can set the whole range, but you'd rarely see it. Maybe some of the external weather programs can set it for you -- even my own WeatherSet2 can set it. However, if you really want to simply boost its effect no matter what the scale, check out the TurbulenceScale parameter in your FS9.CFG file's [Weather] section. Experiment with higher values than 1. Regards, Pete

I don't deal with registrations at all, as explained in the Sticky thread above entitled "READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys" Anyway, if you have your KEY file you have your Key. It is just a text file -- open it with Notepad. Pete

Try that PortMon program. I've always found it invaluable. Pete

Yes. Maybe you can attract his attention by starting a new thread with Kensngton Mouse in the title? Regards, Pete

The only airliner solutions to having separate instrumentation that I am aware of are Project Magenta (payware) and FreeFD (freeware). There are links to both on the right-hand side of the http://www.schiratti.com/dowson page. No, not at all. WideClient merely provides a Networked interface to FS, for programs which use FSUIPC to interface to it. It's an interface extender. There are no FS panels which can run independently of FS, and none of them interface to FS through FSUIPC. I don't have a "site". The "Dowson" page on Enrico Schiratti's page is all Enrico's, as he makes clear in the text. Try reading some of the documentation for Project Magenta. You can download that sort of thing free from their site. I don't know about FreeFD. All this sort of thing is in the hands of those who implement the instrumentation. My programs, FSUIPC and WideFS are NOT the end user products you seem to be classifying them as, they are just interfaces to be exploited by other programs. Regards, Pete

As far as GPSout is concerned, you only need to set the speed and port in the INI file. It controls the COM port. The default values in Windows are just that, defaults. There is a free serial port monitor called "PortMon" available on http://www.systeminternals.com. Run that before FS and it will list all the transactions. Regards, Pete

There is no special procedure. If you give the correct port number and speed in the GPSout.ini file, it cannot help but send data to it. It sounds like you are either configuring hyperterminal incorrectly, or, more likely, you are not using a "null modem" cable -- i.e. one with the TX out from the FS PC connected to the RX in on the other. Regards, Pete

Are you talking about entering the details after pressing "Register an application program"? If not you are pressing the wrong button. If you are entering the correct data, then I need to see the part of the FSUIPC Log file which shows the details of the unaccredited access. Pete

Okay. This simply proves, as I thought, that the crashing problem isn't due to the error messages which were occurring. The main difference when running FS is that it drives the graphics heavily. Did you check that the network card doesn't share an IRQ with anything else, especially not the video card? This is very important on Windows 98SE especially -- Windows XP is rather better at sharting IRQs (though it still can reduce performance and reliability in my opinion). If the network card in in the slot next to the video card it will certainly be using the same IRQ, but it may be doing so in any case. Oh, I hadn't realised it was an on-board network. That makes moving it to a different slot rather difficult! :( Yes, by all means try a PCI network card if you have one. I use relatively cheap ones quite successfully. Of the three I've had fail on me in six years, two were expensive ones in any case! Also search for new drivers for the on-board one -- go to the website of the mobo manufacturer and check. Even if there are no new drivers it may be a good idea to find the drivers disk which came with the mobo and re-install. Finally, is there any good reason you are using Win98SE on the server and WinXP on the Clients? That does seem a little bit the wrong way round. If not Win98SE all round, why not WinXP all round? Regards, Pete

All this does ring a little bell somewhere in the back of my head. I'm going to search for Kensington right now ... [LATER] Yes! It wasn't all that long ago either -- end of November. Here's the final conclusion: Check thread: http://forums.simflight.com/viewtopic.php?t=31582 I do wish my memory worked better on these things. Maybe with this reinforcement it will next time! Thanks for letting me know! Regards, Pete

Try switching pitot heat on before take-off. The pitot inlet is freezing up. Regards, Pete

You only use the ServerNode if you are running IPX/SPX. If you install IPX/SPX on the Server then WideServer will tell you the ServerNode in its Log. If you are using TCP/IP then you only need specify the Server NAME in the Client INI files. Regards, Pete

Further to my last message, I've now managed to reproduce the 10044 error message box, on a Win98SE installation with FS2002. This occurs only with IPX/SPX not installed. Oddly, the error message on Windows 98SE is different to the one I get on Windows XP, which is why it isn't trapped as such and simply logged rather than produce a message box. However, subsequently, after OKaying out of that message box, FS2002 continued and operated perfectly. So, it doesn't really answer your questions. I will deal with the 10044 error correctly in version 6.45 (imminent), which will stop the incorrect Message Box appearing, and will stop it retrying after the first error, but it won't necessarily stop your FS crashes as we currently don't know what is causing them. There are a couple of possibilities I can think of 1. The way it is, because the 10044 error wasn't one which logically tells WideServer that there is no IPX/SPX installed, the module keeps retrying at intervals. I think it only does this until there's actually a connecting Client, however. Do you have a connecting client which is working? Maybe there's something about the drivers for your specific Network which gets upset at the retries (even though these are at only 11-12 second intervals). 2. The cross-tracks on your hard drive are causing the problem of FS crashing. You can eliminate the former by installing IPX/SPX, even if you don't use it. You can fix the latter by running the appropriate Windows check-and-fix (right click on the Drive in Explorer, select Properties, Tools, Check Now). If you still get FS crashing, and still only with WideServer installed, then I think there's certainly some problem with the Network or its drivers. You could try uninstalling the Network card and re-installing it. Check also that it isn't sharing IRQs with anything else (especially not the video card) -- you may have to move it to a different PCI slot. Regards, Pete

Get the FSUIPC SDK from http://www.schiratti.com/dowson. Regards, Pete

I assume you mean from something running inside FS? I am afraid I really don't know the answer to this. I hook into the FS chaining system (which used to be managed my CHAIN.DLL, but which was merged into the base EXE in FS2002 I think). There are a large number of chains which occur at various times, and at least one of these seems to be related to what FS calls the "frame rate" -- but is that frame rate the actual graphics rate, or is it just referring to the computation cycle? Maybe someone who is more involved with graphics design in FS can help. That side of it is a complete unknown to me. Folks who do moving parts for aircraft and scenery may well have a much better knowledge of what happens when, graphics-wise. Even gauge designers trying to make smoothly moving needles might know more than me. Sorry, but you've lost me really. This system is operating as an FSUIPC client gauge or DLL? Assuming you are using the library code I provide, the internal Close call doesn't touch FSUIPC at all, it simply clears the address of the memory, provided by the DLL or Gauge, and that flags the connection as closed. In fact that's pretty much all the external Close call does -- if closes the Memory-Mapped file and frees the Atom with the string filename. It also doesn't touch FSUIPC. There are potential problems in any case with multi-threaded use, but most of these boil down to accreditation problems. For accreditation the Open2() call used to always have to be from the main FS thread, but in the latest version of the library, and with current versions of FSUIPC, that call can be from other threads. Otherwise only the usual care needs to be taken with multiple threads -- i.e. protecting the data area being updated by FSUIPC_Read and Write calls so that only one such call is executed at a time. There are no semaphore locks in the library code I provide, you'd need to apply those yourself. Regards, Pete

Is this error appearing in a Message Box on screen? It is okay it appearing in the Log file -- it just means you haven't got IPX/SPX installed. WideServer can continue with TCP/IP. However, if it is appearing in a Message Box, there is certainly something wrong. This is with FS2002 on a Windows 98SE system isn't it? I'll try to set something up here to see if I can reproduce it. Maybe the error is not one I would normally expect for a protocol missing. Have you tried installing IPX/SPX at all? You don't need to use it, just add it and bind it to your adapter. If that gets over the problem then let me know immediately as it will be a good clue for me to work out what is happening. What's a "filecheck"? Something is wrong with your hard disk. It looks like you have badly crossed-tracks. The second part of the file you are showing is part of FSUIPC.LOG, not WideServer.LOG at all! I urge you to run the Windows disk check on this drive and get rid of any cross-tracked files before things get worse! It will play havoc else, and will certainly make FS crashes more and more likely. Regards, Pete

F14 and F15? I've never heard of such keys. All my keyboards only go up to F12! Just checking Micrsoft development documentation, I see codes defined up to F24, so I can add most of these to the ones FSUIPC already recognises, but I can't test them here as I have no such keyboard. Oddly, the Microsoft documentation says that the code for F24 is the same as that which I have already for the Enter key (on the numeric keypad), which works as such. So I cannot support F24 separately. Anyway, I'll add F13-F23 decode in the next version of FSUIPC (3.45), which is imminent. Meanwhile, you should be able to get around it by programming, say, F12, then, after closing FS, edit the [buttons] section in FSUIPC.INI. Find the entry you just programmed (it'll be the line with the value K123,8 at the end) and change the 123 to 125 for F14 or 126 for F15. It should work, but you won't get a correct read-back in FSUIPC's dialogues at present. Regards, Pete

You only need FS2004 and GPSout. The latter doesn't need FSUIPC. GPSout is freeware still. Regards, Pete

It sounds very much like a problem with the driver of your Network on that PC. The network driving part of WideServer is virtually unchanged now for 6 years and is based on examples from Microsoft themselves. Try TCP/IP instead -- that's default in any case. Also try the test release available in the Announcement at the top of this forum. 80Mb large? Have you been messing with the options or is that all with default logging? Do NOT send me those. Change to defaults, keep the session short, show me an extract if there errors showing. Regards, Pete

I repeat: Right click on the desktop and select "Properties". Then choose the Appearance tab, and press the Effects... button. Uncheck "Show window contents while dragging". This is the only known thing which, if set incorrectly, stops it working. It you can't change that option or that doesn't fix it you presumably have some third party program installed which is interfering with Windows, like WindowBlinds or something similar. Regards, Pete

Pardon? Pete

Do it exactly as if you had two PCs, but just on the one. Pete

Looking at this very closely: The sequence of flag 11 is 1 0 1 0 ... The sequence of Flag 12 is 0 1 1 0 ... So the sequence of the active lines executed above is Flags: Result: 1 0 line 3 0 1 line 6 1 1 line 4 0 0 line 5 Since your lines 5 and 6 (presumably toggling the same PSS keyboard command) are never sequenced next to each other, I assume they are just doing the same thing, i.e. setting MAX. Note that without line 6 the order was as you wanted: 3, 4, 5. If you renumber the lines and put them in the order they will be sequenced in, maybe you can see what happens? i.e. Here's what I think you meant: 3=CP(F+0,11)(F-0,12)1,27,K119,11 4=CP(F-0,11)(F+0,12)1,27,K120,11 5=CP(F+0,11)(F+0,12)1,27,K121,11 6=CP(F-0,11)(F-0,12)1,27,K121,11 Regards, Pete