Pete Dowson

If you read the first few sections of the FSUIPC User documentation you will see a lot of information about access keys and registration. It also lists all the facilities you get if you register your own copy of FSUIPC. As well as all that you'd never need to worry again about getting keys for other programs, as they aren't needed for a paid-up user. I don't like to sound like a salesman here, it isn't the reason for the Forum, but sometimes I really do need to point out that you are going through a lot of hassle, and even getting a lot of support from me, but all to save spending 20 Euros! :lol: Regards, Pete

I didn't mention EPICIO. I don't think that has a logging function -- but you could check with R&R about that. I mentioned logging in EPICINFO. That's all described in the EPICINFO documentation. But if you aren't using EPICINFO it isn't any use to you. Regards, Pete

He might just be away. Folks do take holidays. He was provided with keys for all of his programs back in August. For the freeware ones I could publish them, but I'd really want his permission. I don't think it would be proper without. Regards, Pete

I have no idea, I don't use it, but the facilities for capping the top speeds in FSUIPC were originally put into in way back in FS2000 days because occasionally Squawkbox would insert ridiculously high wind speeds (like hundreds or thousands of knots!). So I assume so. I think folks who prefer FSMeteo or other weather sources switch the SB weather off. Maybe it's off by default now? I don't know, you'll need to check. The idea of SB providing the weather is to keep it the same as on the Controller's PC. Regards, Pete

Still think it could be worked out from the FSUIPC IPC write logging. Regards, Pete

Not sure how the weather is related to the throttle position, and certainly nothing in either FSUIPC or ActiveSky will be touching the throttle. Where do you read "00" for throttle setting? Do you mean the throttle levers are being pulled back to idle? Or is it the Air Speed you are reading, rather than the throttle? If so, then what you are encountering is icing. Make sure that pitot heat is enabled and probably anti-ice also --- FS2004 seems to be prone to bunging up the pitot tube if you get anywhere near any cloud with serious icing levels. As for ActiveSky stopping updating the weather, that sounds like a problem with some of the earlier versions. Make sure you are using the latest versions of both FSUIPC (3.10) and ActiveSky (1.91 I think). Check also with Damian's forum, "Project: ActiveSky" here on Simflight. Regards, Pete

It should do. It always has! The main problem is in distinguishing which one is which, as they all have the same name, so as you scroll down the list nothing seems to change. I did ask Ralph if he could number them but he never managed to do that. Regards, Pete

If you already have a working Network, you simply put WideServer.DLL and INI into FS's Modules folder, install the WideClient.EXE and its INI file on any client PC, add a parameter to the Client INI to tell it the name of the Server PC, and run it. When FS is running with WideServer installed, any WideClient which links to it presents an FSUIPC interface to any suitable applications on the client PCs. So, if you do have other FSUIPC applications currently running on the FS PC, you can move them off. Typical client applications include FSMeteo, Radar Contact, Squawkbox, ActiveSky, TrafficLook, FSRealTime, NAV3, Flight Deck Companion, and of course Project Magenta. Do not confuse WideFS with WidevieW. The latter is by Luciano Napolitano and is for linking multiple installations of FS. I don't think there's an FS2004 version ready yet. Regards, Pete

Sorry, I know nothing about multiplayer. Maybe FS cannot support real weather and multiplayer at the same time because they can't get the weather to match? Sorry, I really don't know. Maybe someone else can jump in about this. Of course if you are using Squawkbox or similar and that is setting any aspect of the weather at all, then FS2004 automatically reverts to user-defined. The same applies to using FSUIPC with the option set for it to affect FS weather. Oh, and please be sure you are using the latest version of FSUIPC in any case (3.10). Regards, Pete

Oh dear. Sorry, where on Earth did I say that? Which bit is too technical? Please just get the key and enter the details. All other discussion is futile really. If it doesn't work then, that's the time to get technical. All the preceding messages have been rather off-base simply because I was under the impression you'd already tried registering it and weren't getting anywhere! :( Actually, it's now getting to the point where really I think you might even consider, instead, simply registering FSUIPC and be done with it. I think you have got your money's worth of time out of me by now! :D Regards, Pete

Well, before I saw your log I would have assumed it was because he was using the external application interface to FSUIPC. But now I believe that he just doesn't realise that I'd extended the manual program registration system so it will cope with (correctly interfaced) Gauges and DLLs as well. That wasn't part of the original plans (before version 3.00 release), but it was long before Eric's applications for the Keys. Regards, Pete

No, F16.gau. Yes. Erbut I thought you already had the key? You asked him already! I don't have all that private mail anymore, but I could have sworn you said you tried it and couldn't make it work. I thought that was the whole point of me looking at the logs! Pete

I am sending you a Beta version of FSUIPC to try. Use the syntax as you have it (CRin place of CP ...). It should work okay. Let me know. Regards, Pete

Yes, thanks. But I did actually reply in the other one. Didn't you see? And the Log file you posted there was a better one -- it shows the data required. You just need to register the program F16.gau with the Key Eric gave you. Regards, Pete

It's "FS9.CFG" and it is in the documents and settings applications data, under Microsoft and flight simulator. Similarly your saved flights and so on with be in your document folder in a new sub-folder. I recommend you check out the FAQ in the FS2004 Forum here. Why not? The Fs2004 joystick assignments are better than the FS2002 ones -- more controls are now assignable. What is worng with it? Regards, Pete

If the sound is played then it isn't likely to be Esound which is crashing -- it has long since finished its part in this and relinquished control. I really cannot spend any more time on this. I think you really do need to investigate the sound files you are using. Regards, Pete

It is the method originally designed by Adam Szofran in FS5IPC back in FS95 days. It has been kept all the way through for compatibility. It uses a memory mapped file but it isn't polled, the details are passed by a message. FSUIPC not keep track of applications, the file belongs to the application and if only read/written by FSUIPC. There don't think there were any named pipe facilities available on Windows 95 (not that it would be very efficient for a many-to-one relationship), and sockets were also primitive and needing User installation, as far as I can recollect. Memory mapped file methods of transferring data betwen processes in efficient enough. In fact it is basically the same method underlying the way some of the debugging aids work, although there they are wrapped up in high level functions like "ReadProcessMemory". You can find all the details in the FSUIPC SDK on http://www.schiratti.com/dowson. Regards, Pete

There's some stuff for Java in the current FSUIPC SDK (on http://www.schiratti.com/dowson). This was kindly contributed by Mark Burton. I don't know anything about Java, but he says he's provided Java sources for Class-based access to FSUIPC. There's a lot of stuff in the ZIP he provided, including Help in html format. Regards, Pete

Of course. That is the sole and only "point" of GPSout. What did you think it was for? It can't do anything else. I thought you must have already known that, from its description, and that you were asking only if GPSout needed FSUIPC. Regards, Pete

Since the word at 0D0C contains one bit for each light switch you need to apply a mask. For instance, for the Strobes (as an example), which are switched by bit 4, you'd need 9=VW0D0C.0010=X0010,6,0 Bit 4 is the 4th bit up counting from 0: in binary 1 0 0 0 0, in hex 10. This is 16 in decimal (2^4 = 16). So, the mask of 0010 is applied, so that only that one bit is selected, then you compare the result with 0010, which is what you'll get if the switch is on. Et cetera. Regards, Pete

It sounds like you need to set the frame rate limiter in FS2004 a bit lower, otherwise it is grabbing all the processor it can, so that when a third party program does get control it has more to catch up on. If FS is forced to relinquish more often because it hits the limiter, then the third party activities will be spread out better. There are no synchronisation objects between apps and FSUIPC. It's a simple message passing/message processing interface. There's no difference -- data arrives at FSUIPC in exactly the same format, whether routed by a Message from another process in the same PC, or from WideServer. they all go through exactly the same code. Of course WideServer isn't switching processes all the time, only threads. As far back as I can remember it has ALWAYS been beneficial to FS's smooth performance to move all of the other processes you might want to run off that PC. It really isn't anything at all specific to the NWI, it wouldn't make any difference what the other processes were doing with FS, it is what they are doing with the processor and other scarce resources which matters. It may seem worse with programs using the NWI rather than any of the older methods of weather control, but that is only because they are doing a lot more. Before the NWI, programs could only set one global set of weather data. With the NWI they can and do set all the nearby weather stations, separately. Regards, Pete

Re-check that 5408 is being written incorrectly by FSCommunicator first -- do that with IPC Write logging. I don't know if it runs when PM isn't running, but best to just run FS with FSCommunicator, then you know that it is it, not something else. If FSCommunicator is writing bad Heading values to 5408 you can't really blame MCP.EXE for falling over -- even if it didn't, it would go wrong. I expect Enrico doesn't like checking all parameters because of the possible performance overheads. So, you really need to find out WHERE FSCommunicator is getting the bad data, or is it the program itself going wrong? Are you feeding the data from the EPIC? Maybe the EPIC interface is going wrong, or the EPL itself? You need to track back one stage at a time. If you were using EPICINFO I'd recommend that you enable its logging and see what the heading value was at the interfaces there -- from EPIC ot EPICINFO then EPICINFO to FSUIPC. But with FS communicator you'll need to use whatever aids it comes with. Regards, Pete

One further observation. If I understand this part right: "I noticed the value of offset 5409 is the same a 5408 when 2 byte size is used in FS Communicator." you mean that the logging shows FS Communicator writing the same value to both 5408 and 5409? Since the offset 5408 is used by the MCP to allow programs to set its Heading register, the range is presumably 0 to 359, or possibly 1 to 360. So the largest value which can possibly be valid in 5409 (the high byte of the 16-bit value) is 1. (360 = hex 168). Any more than 1 in 5409 would not be valid. Now, perhaps MCP.EXE should be resilient to such errors, but really I think you need to look at how or why FS Communicator is doing this. Trace it back. WHERE is the data coming from? Regards, Pete

Neither of those locations are touched or used at all by FSUIPC. They are purely for Project Magenta talking to various parts of itself and for programs to interface to it, via FSUIPC's application-allocated address space. I'm not really sure what you mean here, as it is a little ambiguous. The "byte size" where? Surely not in the monitoring function (you are using the on-line Monitor facilities in FSUIPC, aren't you? Much easier than poring over a lengthy log file afterwards, unless you need the 'evidence' of course :) ). I assume this is something to do with FS Communicator? I dont know FS communicator at all, I'm afraid, but this question really sounds as if it needs addressing to someone who does. But even more important, since it is the MCP program which is crashing, if it is reproducible then you should most certainly be talking to Project Magenta support. I too use all the latest Project Magenta modules along with, of course, FSUIPC and WideFs, but I don't use FS Communicator. But certainly, if I had a crash in one of Enrico's modules I'd be getting the data together and sending it to him immediately. However, I know he's a bit behind at present after some time in the states and at the AVSIM conference last weekend. Please let me know what the outcome is. Regards, Pete

Congratulations. It's an excellent, although very expensive, program. You can use my FStarRC with that, you know. Even if you don't use Radar Contact, it does provide FS plans as well as Squawkbox and Project magenta plans from those you prepare in FliteMap. GPSout 2.52 doesn't actually need FSUIPC. Earlier versions did, but only in FS2002. It was an oversight, a mistake, not a design! :) Regards, Pete