Pete Dowson

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

I thought SimCharts only worked on the same PC in any case? Doesn't it have its own interface to FS, rather than a GPS type input? As far as FliteMap is concerned, yes, you can run it on the same PC as FS, thought I wouldn't like to do that even on my 3.2GHz machine as two intensive graphics programs will not make for good performance. Because FliteMap needs serial input on a COM port and GPSout provides that data output on a COM port, all you need to do is link two COM ports (or USB/Serial adapters) together on the same PC, using the appropriate crossover cable, just as if they were on two separate PCs. Regards, Pete

Sorry, I don't know how to do that. It would be a very useful facility if I could implement it. The official FS Traffic Explorer program has rather an advantage here -- it was written by the actual person in the FS team who programmed the FS2004 traffic modules in the first place. Unfortunately MS don't divulge any of those methods and even by hacking into the code I've not been able to find anything more useful than what I've already offered. I think you can use the controls to put them into slew mode then move them around with the slew controls. Regards, Pete

Sounds like a pretty light load. Best thing to do is try it and see. If you have two PCs and two modems you could try it 2in house" first. Regards, Pete

I assume so if the Server has a known IP address and you allow access though any proxy or router or firewall or such. The TCP/IP protocol is used on the Internet. The is a thread here someplace from someone who connected via IPX/SPX, but I assume there's some sort of wrapper needed to make that work. The only thing which would be needed would be to specify the correct IP address for your FS PC in the WideClient.INI file. I would have thought it a bit slow for anything ambitious like Project Magenta or Radar Contact, or even Active Sky. You certainly wouldn't want anything real time via such a link, like cockpit controls and switches. But to be honest, I have no idea what would be suitable to be used over the Internet. What are you wanting to do? Regards, Pete

Okay. I don't think that's a gauge which uses FSUIPC in any case. Certainly it isn't on my list of gauges which have an access key. Regards, Pete

Actually, as far as I can see, there are 4 states. Extracting the state changes from hm's message: 0 - 1 - 0 - 1 - 0 - 1 - 0 - 1 0 - 0 - 1 - 1 - 0 - 0 - 1 - 1 you can see that they actually run through the 4 possible combinations: 00, 10, 01, 11 ... So, it seems to me that in the original, there's a "spare" button press which doesn't do anything. Adding: 06=CP(F-0,11)(F+0,12)0,3, do the fourth thing might therefore meet your needs, eh? As to how it starts, well, both flags will be off when you first load FS, but after that you are in that 4 state cycle till you close FS. If you want a reset you'd need another button! Regards, Pete Regards, Pete

Further to this: I have now completed work on a modification to FSUIPC, on FS2004 only, which will hopefully deal with the problem on XML gauges too -- via the same "fix control acceleration" option of FSUIPC's Technical tab. If you are still having problems, and have registered FSUIPC, send me an email (petedowson@btconnect.com) if you want to test an interim version of FSUIPC with this improvement incorporated. (I can't test that it works flawlessly here because I don't seem to have any of the acceleration problems with any of the panels I have, in any case). In addition to this extension to the fix I have added an event logging option which should help gauge authors see exactly what is happening when their gauge is running and thus be a help in trying to make the more efficient. Regards, Pete

Very clever, but I'm glad you had to explain it rather than me, and you did it so very well too! Thanks. Just one typo to correct -- there's an FF in line 5 which should be just F of course. Thanks again, Pete